DIF Presentation Exchange

A Presentation Definition is a machine-readable JSON object that specifies the exact verifiable credentials a Verifier requires from a Holder. It defines:

• Input Descriptors: The types of credentials and specific claims needed.
• Constraints: Rules like credential schema, issuer DID, or specific claim values.
• Submission Requirements: How multiple credentials should be grouped and presented.

A Presentation Submission is the Holder's response to a Presentation Definition. It is a JSON wrapper that contains:

• The Verifiable Presentation(s) fulfilling the request.
• A descriptor map linking each presented credential to the specific Input Descriptor it satisfies.
• Proofs and signatures that bind the submission to the Holder's Decentralized Identifier (DID).

An Input Descriptor is a component within a Presentation Definition that describes a single type of required credential. Each descriptor includes:

• id: A unique identifier for the requirement.
• schema: The credential schema URI that must be matched.
• constraints: Filters on fields (e.g., issuer, credentialSubject.id, specific claim values).
• purpose: A human-readable reason for requesting this data.

The Descriptor Map is a critical JSON structure within a Presentation Submission that creates a verifiable link between the submitted credentials and the Verifier's request. It:

• Maps each Verifiable Credential in the presentation to a specific Input Descriptor id from the Presentation Definition.
• Uses a path (e.g., $.verifiableCredential[0]) to pinpoint the credential's location within the submission.
• Ensures the Verifier can algorithmically verify all requirements were met.

Submission Requirements define the logical rules for how multiple Input Descriptors must be satisfied. They enable complex request logic using:

• pick: The Holder must submit credentials matching a specified number of optional descriptors.
• all: The Holder must submit credentials matching all listed descriptors.
• Nested Rules: Requirements can be combined using and, or, and not to create sophisticated conditional logic for multi-credential presentations.

Constraints within an Input Descriptor use Filter Objects to specify precise criteria a credential must meet. Key filter types include:

• fields: Constrains specific claim values (e.g., credentialSubject.age >= 21).
• issuer: Restricts acceptable issuers by DID or pattern.
• schema: Mandates a specific credential schema URI.
• subject_is_issuer: Requires the credential subject to also be its issuer (for self-attested claims).

Employers and licensing boards can request proof of qualifications. A job applicant can selectively disclose a university degree credential and professional certifications to satisfy the employer's input descriptors. The protocol ensures the credentials are cryptographically verifiable and from accredited issuers, drastically reducing fraud and the time spent on manual background checks.

Online services requiring age verification (e.g., alcohol delivery, adult content) can request a presentation that proves a user is over a certain age without requiring a full birth date or ID scan. The Holder presents a verifiable credential containing an "over 21" attestation from a trusted issuer, satisfying the constraints in the presentation request while minimizing data exposure.

Airlines and border agencies can request a presentation containing a verifiable credential for a passport, visa, and vaccination record. The Holder's wallet assembles these credentials into a single, cryptographically verifiable package. This enables faster, more secure digital check-ins and border crossings using interoperable standards, as seen in projects like the IATA Travel Pass initiative.

DeFi protocols can use Presentation Exchange for credential-based gating. To access a high-tier lending pool, a user might need to prove they are an accredited investor or have completed specific KYC. The user presents a verifiable credential from a qualified issuer directly from their wallet, enabling trustless verification without the protocol ever seeing or storing the underlying sensitive data.

Patients can securely share specific health records with providers or researchers. A clinic's EHR system (Verifier) sends a presentation request for a vaccination record or lab result. The patient's holder wallet evaluates the request, obtains consent, and presents only the required credentials from their issuer (e.g., a hospital). This gives patients control over their health data while ensuring data integrity and provenance.

Presentation Exchange defines a data format and protocol for a Verifier to request specific credentials from a Holder. It uses a Presentation Definition to specify required credentials and a Presentation Submission to return them. This creates a machine-readable, privacy-preserving negotiation layer, separating the what (the request) from the how (the transport protocol).

PE enables selective disclosure and reusable KYC, forming the backbone of decentralized identity. Key applications include:

• Token-Gated Access: Proving ownership of a specific NFT or token balance to access a DAO or event.
• Sybil Resistance: Proving unique humanity or specific credentials without revealing full identity.
• DeFi & Compliance: Submitting proof-of-address or accredited investor status for regulatory compliance.
• Cross-Chain & Cross-Platform Identity: Using the same verifiable credentials across different blockchains and applications.

PE is the primary method for requesting and presenting W3C Verifiable Credentials (VCs). The Presentation Definition can request specific claims (like a birth date) or entire credential types (like a KYC credential). The Holder's wallet uses this definition to locate matching VCs in its storage and construct a Verifiable Presentation for submission, ensuring cryptographic proof and data integrity.

PE is often layered atop existing authentication protocols to add rich, credential-based claims. A common pattern is SIOPv2 (Self-Issued OpenID Provider v2) with Presentation Exchange, where an OIDC flow is enhanced with a PE request. This allows users to sign in with their wallet and simultaneously present verifiable credentials, merging authentication and authorization.

PE differs from simpler attestation models by providing a structured, declarative request. Key distinctions:

• vs. Simple Signature Requests: PE requests specific credential schemas and constraints, not just a signature on arbitrary data.
• vs. OAuth Scopes: OAuth scopes grant access to data held by a provider; PE enables the presentation of data held by the user.
• vs. ZK-SNARKs: PE is a data format; it can be used to request Zero-Knowledge Proofs (ZKPs) as a type of presentation, but it is not a proving system itself.

The core privacy principle of Presentation Exchange is data minimization. Instead of presenting an entire credential, a Holder can use cryptographic techniques to prove specific claims (e.g., "I am over 21") without revealing the underlying data (e.g., their exact birth date). This is achieved through Zero-Knowledge Proofs (ZKPs) or BBS+ signatures, drastically reducing the privacy surface area.

Security is enforced through cryptographically verifiable trust frameworks. The Verifier's Presentation Definition specifies not only the required claims but also the trusted issuers and credential schemas. The Holder's wallet cryptographically validates that the presented credentials are signed by an authorized issuer and conform to the expected structure, preventing the use of forged or malformed data.

The protocol is designed around user-centric identity. The Holder's wallet acts as a secure agent, evaluating the Verifier's request. The Holder must explicitly consent to share the requested presentation. This prevents credential "phishing" and ensures the user maintains control over what is shared, with whom, and for what purpose (purpose binding).

A generated Verifiable Presentation is a cryptographically signed package. This signature provides non-repudiation, proving that a specific Holder authorized the presentation of those credentials at a specific time. This creates a tamper-evident audit trail for compliance, essential for regulated use cases like KYC/AML, while preserving the privacy of the underlying credential data.

A key privacy challenge is preventing Verifiers from correlating a user's activities across different services. Presentation Exchange supports unlinkable presentations through techniques like holder-binding with decentralized identifiers (DIDs) and the use of unique, session-specific presentation tokens. This prevents a Verifier from linking two presentations from the same user unless explicitly designed for continuity (e.g., a login session).

The security of the entire system depends on the Holder's digital wallet. This wallet must securely manage the Holder's private keys (for signing presentations) and credential storage. Best practices include:

• Using hardware security modules or secure enclaves.
• Implementing robust backup and recovery mechanisms (e.g., seed phrases).
• Ensuring the wallet software itself is free from vulnerabilities that could lead to credential exfiltration.