Presentation Exchange

A Presentation Exchange is a machine-readable data format and negotiation protocol that defines how one party (the verifier or relying party) requests specific proofs of identity, and how another party (the holder) can selectively disclose verifiable credentials to satisfy that request. It standardizes the communication flow for requesting and presenting Verifiable Presentations, moving beyond simple credential issuance to enable complex, real-world interactions. This protocol is a core component of the W3C Verifiable Credentials data model and is essential for implementing Self-Sovereign Identity (SSI) principles.

The protocol operates through two primary JSON objects: the Presentation Definition and the Presentation Submission. The verifier creates a Presentation Definition specifying the required credentials, their types, the trusted issuers, and any constraints on the data fields. The holder's wallet processes this definition, matches it against their available credentials, and, if possible, constructs a Presentation Submission. This submission contains the actual verifiable credentials or derived proofs, packaged as a Verifiable Presentation, and references back to the specific requirements it fulfills in the definition.

Key technical features of Presentation Exchange include support for selective disclosure, where holders reveal only the necessary attributes from a credential, and predicate proofs, where they can prove a claim about data (e.g., "age > 21") without revealing the exact value. It also enables credential nesting and combining multiple credentials from different issuers to satisfy a single, complex request. This makes it far more flexible and privacy-enhancing than simply sending a raw credential, as it minimizes data exposure and gives the holder granular control.

A common use case is age verification. A liquor store's website (verifier) sends a Presentation Definition requiring proof that the user is over 21. The user's digital wallet (holder) holds a verifiable driver's license credential from their state's DMV (issuer). Using Presentation Exchange, the wallet can create a Verifiable Presentation that contains only a cryptographic proof of the "over 21" claim, without disclosing the user's exact birth date, address, or license number. This satisfies the business rule while maximizing user privacy.

Presentation Exchange is foundational for interoperable digital trust ecosystems. By providing a common language for credential requests, it allows wallets from different vendors to interact seamlessly with verifiers across various industries. Major frameworks implementing the protocol include the Decentralized Identity Foundation's (DIF) Presentation Exchange specification and its integration within OpenID for Verifiable Credentials (OIDC4VC). This standardization is critical for scaling verifiable credential adoption beyond isolated pilots into a global utility for identity verification.

Presentation Exchange is a W3C-Recommended data format and process that structures the interaction between a verifier (relying party) and a holder (user). It operates through two primary JSON objects: the Presentation Definition and the Presentation Submission. The verifier creates a Presentation Definition that specifies the exact credentials or claims required, including the credential types, trusted issuers, and any constraints. The holder's wallet processes this definition, selects matching credentials from their digital wallet, and constructs a Presentation Submission that fulfills the request, which is then packaged into a Verifiable Presentation for submission.

The protocol's core innovation is enabling selective disclosure and data minimization. Instead of presenting an entire credential, a holder can prove they possess a credential meeting the verifier's criteria without revealing all its contents. For example, a verifier could request proof a user is over 21 by defining a requirement for a BirthdateCredential where the age field is greater than 21. The holder's agent can generate a cryptographic proof satisfying this predicate without disclosing their actual birth date. This is often implemented using BBS+ signatures or zero-knowledge proofs.

The technical flow follows a clear sequence. First, the verifier embeds or transmits the Presentation Definition to the holder, typically via a QR code or a direct API call. The holder's identity agent (e.g., a mobile wallet) evaluates the definition against its stored Verifiable Credentials. If suitable credentials exist, the agent creates a corresponding Presentation Submission—a manifest listing which credentials fulfill which requirements. This submission is then wrapped, along with the credentials or proofs, into a Verifiable Presentation, which is cryptographically signed by the holder. Finally, this VP is transmitted back to the verifier for validation.

Interoperability is a key goal, achieved by leveraging other core standards. Presentation Definitions reference credential schemas defined in the W3C Verifiable Credentials Data Model and can mandate specific proof formats like JSON Web Tokens (JWT) or Linked Data Proofs. The protocol is transport-agnostic, meaning it can be used over various communication channels such as OpenID Connect (OIDC), CHAPI (Credential Handler API), or direct HTTPS APIs. This decoupling of the what (the data request) from the how (the transport mechanism) ensures broad compatibility across different SSI (Self-Sovereign Identity) ecosystems and implementations.

In practice, Presentation Exchange is foundational for user-centric identity. Use cases range from know-your-customer (KYC) processes, where a bank requests proof of address and identity from government-issued credentials, to access control, where a website requests a credential proving membership or professional accreditation. By providing a machine-readable format for credential negotiations, it eliminates the need for custom, one-off integrations and allows holders to maintain control over their personal data, sharing only what is necessary for a specific transaction.

The flow is initiated by a Verifier who creates a Presentation Definition, a machine-readable specification detailing the required credentials. This definition outlines the specific Verifiable Credential types, the claims (or attributes) needed, and any constraints, such as the identity of the trusted Issuer. This request is typically encoded in a presentation_definition object and transmitted to the Holder, often embedded within a DIDComm message or a SIOPv2 (Self-Issued OpenID Connect v2) authentication request.

Upon receiving the request, the Holder's wallet software evaluates the presentation_definition against its secure credential store. The wallet identifies which credentials satisfy the Verifier's requirements. The Holder then constructs a Verifiable Presentation, which is a cryptographically signed package containing the selected credentials and optional proof of Holder control. A key step is the creation of a Presentation Submission, a data structure that explicitly maps the submitted credentials to the specific requirements in the Verifier's original definition, proving compliance.

The completed Verifiable Presentation and its accompanying Presentation Submission are then sent back to the Verifier. The Verifier performs several critical validations: verifying the digital signatures on both the presentation and the embedded credentials, confirming the credentials were issued by trusted entities, checking that all required claims are present and correctly mapped, and ensuring no credentials have been revoked (e.g., by checking a revocation registry). This entire exchange allows for selective disclosure, where the Holder can share minimal necessary information without revealing their entire credential wallet.