Verifiable Presentation

A Verifiable Presentation is how a credential holder actually shows up to be checked. Where a verifiable credential is data signed by an issuer, a presentation is data assembled and signed by the holder at the moment of sharing. It wraps one or more credentials — or carefully chosen subsets of them — and binds them to the holder, so a verifier can confirm two distinct things in a single exchange: that the issuer really signed the claims, and that the party presenting them really controls the credential rather than replaying someone else's.

The three-party model

The W3C Verifiable Credentials Data Model describes an ecosystem of issuers, holders, and verifiers. The issuer signs claims into a credential; the holder stores it in a wallet they control; and when proof is needed, the holder generates a Verifiable Presentation for the verifier. The holder's signature over the presentation is what makes the model work — it proves possession of the private key anchored in the holder's DID Document, the same control-of-keys logic a Bitcoiner already lives by with a private key. To stop replay, the verifier typically supplies a fresh challenge that must be signed into the presentation, so a captured presentation is useless in any other session. Presentations are deliberately short-lived and not meant for long-term storage: produced fresh per interaction, which is exactly what limits a verifier's ability to hoard reusable proof about you.

Selective disclosure and privacy

A presentation does not have to reveal the whole credential. Using selective disclosure, the holder presents only the specific claims a verifier needs — proving age without revealing a birthdate, or membership without an account number. Signature schemes like BBS+ push further, letting each presentation be cryptographically unlinkable from the last, so repeated use of one credential cannot be stitched into a profile. A single presentation can also combine claims from several credentials — one government-issued, one employer-issued — into a single coherent proof, with the holder deciding exactly what crosses the wire. For a sovereign user this is the practical difference between proving a fact and surrendering a dossier.

Why this matters to a sovereign stack

The presentation layer is where self-sovereign identity either delivers or fails. If verifiers demand full credentials every time, the architecture degrades into document photocopying with extra steps. If holders can present minimal, fresh, holder-signed proofs, then identity starts to behave like cash instead of a surveillance record: each transaction reveals what it must and nothing more. The parallels to Bitcoin practice are direct — keys you hold, signatures you produce on demand, and a default posture of revealing the minimum. Anyone comfortable managing a hardware signer already has the mental model; the wallet just holds credentials instead of coins.

Formats and exchange protocols

In the wild, a presentation is a concrete artifact with a concrete delivery path. The W3C data model can be serialized as JSON-LD with embedded proofs or wrapped in JWT form, and credential formats like SD-JWT define their own presentation encodings; verifiers advertise what they accept, and wallets negotiate. The exchange layer is converging on OpenID for Verifiable Presentations (OID4VP), which reuses familiar OAuth-style redirects so a website can request a presentation the same way it requests a login today — and cross-device flows let you scan a QR code on a terminal and approve the disclosure on your phone. The details matter less than the pattern: a request arrives stating what claims are wanted, your wallet shows you exactly what would be revealed, and nothing moves without your signature. Any implementation that skips that consent step has abandoned the model's entire point, whatever standards it cites.