Presentation Policy

Defines the specific claims (attributes) a holder must reveal from their credentials. This can specify:

• Required claims (e.g., dateOfBirth > 1990-01-01)
• Optional claims for selective disclosure
• Predicates (e.g., proving age is over 18 without revealing the exact date)
• The schema or type of credential that contains the required claims

Specifies the cryptographic proofs a holder must provide to prove the credential's validity and their control over it. Key requirements include:

• Proof of possession: A digital signature from the holder's Decentralized Identifier (DID).
• Credential status: Proof the credential has not been revoked (e.g., via a revocation registry).
• Issuer authentication: Proof the credential was signed by a trusted issuer's DID.
• Zero-Knowledge Proof (ZKP) specifications for privacy-preserving presentations.

Dictates the technical serialization and data format for the presentation. This ensures interoperability between the holder's wallet and the verifier's system. Common formats include:

• JSON-LD with Linked Data Proofs
• JWT (JSON Web Token) for compact, URL-safe encoding
• SD-JWT (Selective Disclosure JWT) for specific claim disclosure
• CWT (CBOR Web Token) for constrained environments

Ensures the presenter is the legitimate subject of the credential, preventing presentation by unauthorized parties. Mechanisms include:

• Challenge-Response: The verifier provides a cryptographic nonce that must be signed in the presentation proof.
• DID Correlation: The holder's DID used in the presentation must match the credentialSubject.id in the original VC.
• Biometric or PIN binding in higher-assurance scenarios, though this is often managed at the wallet level.

Identifies the Verifier and optionally specifies the trust framework under which the policy is issued. This includes:

• The Verifier's DID, establishing who is making the request.
• Reference to a Trust Registry or governance framework that defines accepted issuers.
• Purpose or legal basis for data collection (e.g., "KYC compliance for account opening").

Defines the workflow for how the policy is communicated and fulfilled. This is often governed by standards like OpenID for Verifiable Presentations (OIDC4VP) or W3C's Verifiable Credentials API. The policy itself is typically sent as a Presentation Definition (e.g., using the DIF Presentation Exchange spec), to which the holder responds with a Verifiable Presentation.

A Presentation Policy allows a user to prove they are over 18 and a resident of a specific country without revealing their full identity document, date of birth, or address. The policy requests only the specific verifiable claims needed, such as age > 18 and countryOfResidence == 'US', which are cryptographically proven from a signed credential.

A developer can share proof of a specific certification or skill with a potential employer. The employer's Presentation Policy might request:

• Proof of a DiplomaCredential from an accredited institution.
• A BadgeCredential for a specific programming language.
• A MembershipCredential from a professional organization. The user can satisfy this policy with credentials from different issuers without exposing unrelated personal data.

Websites or DAOs use Presentation Policies as token-gated access rules. To enter a premium forum, the policy requires a verifiable credential proving:

• Ownership of a specific NFT (e.g., a membership token).
• Or, a credential showing a minimum reputation score or governance power. The user's wallet presents a verifiable presentation satisfying the policy, granting seamless, privacy-preserving access.

When applying for an undercollateralized loan, a lending protocol can define a Presentation Policy requesting proof of:

• A CreditScoreCredential from a trusted oracle, with a score above a threshold.
• Proof of consistent revenue or asset ownership from another verifiable source. This allows for risk assessment based on attested, tamper-proof data without the user surrendering raw financial documents.

A user's reputation or achievements in one application (e.g., a governance DAO) can be represented as a verifiable credential. A different DApp (e.g., a prediction market) can define a Presentation Policy that requests proof of this reputation to reduce collateral requirements or unlock features. This creates a portable, user-owned social graph and reputation layer across Web3.

For regulated activities, an entity can be asked to present credentials that prove compliance with specific frameworks (e.g., Travel Rule, MiCA). The auditor's Presentation Policy specifies the exact schemas and issuers that are trusted. The entity generates a cryptographic presentation containing only the attestations required, providing auditable proof without exposing full operational data.

A Presentation Policy enables selective disclosure, allowing a Holder to reveal only specific attributes from a credential without exposing the entire document. For example, proving you are over 21 from a driver's license VC without revealing your name, address, or exact birth date. This is achieved through cryptographic techniques like BBS+ signatures or zk-SNARKs.

• Privacy by Design: Minimizes data exposure, adhering to the principle of data minimization.
• Attribute-Level Control: Policies can request individual claims (e.g., birthdate > 2003-01-01) or combinations.
• Format Agnostic: Can be applied to credentials in W3C VC, AnonCreds, or other formats.

The policy specifies the cryptographic proofs a Verifier demands to ensure the presented data is authentic and unaltered. This moves trust from the presentation event itself to the underlying credential's issuance and cryptographic integrity.

• Signature Proofs: Mandates a verifiable cryptographic signature from the Issuer.
• Non-Revocation Proofs: May require proof the credential is not revoked (e.g., via a revocation registry).
• Timestamp Bounds: Can request proofs that the credential was valid at a specific time.

This shifts the Verifier's trust from the Holder's device to the verifiable cryptographic assertions.

A sophisticated Verifier can craft a unique Presentation Policy for each interaction. If a Holder uses the same policy-derived presentation multiple times, it creates a correlation handle, allowing the Verifier to link the Holder's actions across different sessions. This undermines user pseudonymity.

• Mitigation: Use presentation token blinding or unlinkable presentation protocols.
• Holder Strategy: Holders should be wary of overly specific, one-time-use policies from unknown Verifiers.
• Standardization: Using common, reusable policy templates reduces this fingerprinting risk.

Presentation Policies are typically expressed as structured data objects, often in JSON format. The OpenID for Verifiable Presentations (OID4VP) standard defines a common schema for these requests in the web context.

• Presentation Definition (DIF): A standardized format by the Decentralized Identity Foundation specifying requested credentials and constraints.
• Query Language: Policies use a constraint language (e.g., JSONPath, LD-Proofs) to pinpoint required claims.
• Example Request: A Verifier's API might send a Presentation Definition requesting a UniversityDegreeCredential with a graduationDate after 2020 and a valid BBS+ signature proof.

A key security feature is that the Holder's wallet/agent must evaluate and consent to the policy before generating a presentation. This creates a clear audit trail and ensures the user understands what is being requested.

• User Interface: Wallets should display the policy in human-readable terms ("This site requests your age verification").
• Policy Rejection: The Holder can refuse to comply with an overly broad or suspicious policy.
• Consent Receipt: The act of agreeing to the policy can itself be recorded as a verifiable event, providing non-repudiation.

Beyond revealing raw attributes, policies can request zero-knowledge predicate proofs. The Holder proves a statement about a credential attribute is true without revealing the attribute itself.

• Range Proofs: Prove your income is > $100,000 without revealing the exact figure.
• Set Membership: Prove your nationality is in the EU set without specifying which country.
• Mathematical Relations: Prove Attribute A > Attribute B.

This leverages zk-SNARKs or Bulletproofs and represents the highest standard for privacy-preserving verification, as it discloses zero raw data.