Credential Presentation Policy

Specifies the exact type of credential required (e.g., VerifiableCredential, UniversityDegreeCredential) and references its schema. The schema defines the mandatory and optional data fields (claims) that must be present, ensuring structural validity.

• Example: type: ["VerifiableCredential", "DriversLicense"]
• Constraint: A policy may require a credential conforming to the W3C https://schema.org/Person schema.

Defines which entities are trusted to issue the credentials accepted by the Verifier. This is a critical trust anchor, preventing acceptance of credentials from unauthorized or fraudulent sources.

• Trusted Issuers List: A whitelist of Decentralized Identifiers (DIDs) or issuer profiles.
• Example: issuer: "did:example:issuer123" or issuer: { oneOf: ["did:web:dmv.gov", "did:ethr:0xabc..."] }
• Purpose: Ensures the credential's provenance is from a recognized authority like a government agency or accredited institution.

Governs the temporal validity of presented credentials. Policies enforce that credentials are currently active and were valid at a specific point in time relevant to the verification context.

• Current Validity: Credential must not be expired or revoked.
• Historical Validity: Credential must have been valid at a past date (e.g., "proof of age over 21 on January 1, 2023").
• Mechanism: Checks against the credential's issuanceDate, expirationDate, and real-time revocation status via a registry or status list.

Dictates how claims from a credential are revealed and cryptographically proven. This enables privacy-preserving verification where only necessary information is shared.

• Disclosure: Specifies which specific claims must be disclosed (e.g., birthdate but not name).
• Proof Type: Mandates a specific cryptographic proof suite (e.g., BBS+ signatures for zero-knowledge proofs, EdDSA for simple signatures).
• Example: A policy may require a zero-knowledge proof that proves the Holder is over 18 without revealing their exact birth date.

Ensures the credential is presented by its legitimate owner, preventing credential theft and replay attacks. This binds the presentation act to the Holder's current authentication.

• Challenge-Response: The Verifier provides a cryptographic nonce that must be included in the presentation proof.
• Audience (aud): The presentation is cryptographically tied to the Verifier's DID.
• Holder Authentication: May require the Holder to sign the presentation with a key proven to control their DID, establishing holder binding.

The machine-readable language or format used to encode the policy rules, enabling automated negotiation and enforcement between systems.

• Common Formats: OpenID for Verifiable Presentations (OID4VP), W3C Verifiable Credentials Data Model conventions, or DIF Presentation Exchange schemas.
• Structure: Often expressed as a JSON object specifying fields, constraints, and rules.
• Function: Allows a Verifier to publish a policy and a Holder's wallet to automatically determine if it can satisfy the request.

A policy specifies the exact data a verifier needs. Key components include:

• Credential Type: The specific schema (e.g., VerifiableCredential, DiplomaCredential).
• Required Claims: The individual data fields that must be disclosed (e.g., dateOfBirth, degreeEarned).
• Issuer Constraints: Rules about who must have issued the credential (e.g., a trusted university DID).
• Proof Requirements: The cryptographic proof type the holder must provide (e.g., a BBS+ signature for selective disclosure).

The policy is encoded into a Presentation Request (or Presentation Definition) sent by the verifier. The holder's wallet uses this request to:

1. Locate matching credentials in their digital wallet.
2. Create a Verifiable Presentation (VP), which is a cryptographically signed package containing the disclosed credentials or claims.
3. Submit the VP back to the verifier for validation. This creates a standardized, interoperable request-response protocol.

Advanced policies enable selective disclosure, allowing holders to prove specific claims without revealing the entire credential. For example, proving you are over 21 without disclosing your exact birth date. This is achieved using zero-knowledge proofs (ZKPs) or predicate proofs within BBS+ signatures, enforcing the privacy principle of data minimization.

Policies are written in standardized formats to ensure interoperability across different systems. The dominant standard is the W3C Presentation Exchange specification, which defines the presentation_definition JSON structure. Other frameworks include OpenID for Verifiable Presentations (OID4VP) and ISO mDL (mobile Driver's License) models, each with specific serializations for different use cases.

A liquor store's point-of-sale system (verifier) requests proof a customer is over 21. Its policy requires:

• Credential Type: GovernmentIdCredential
• Issuer: did:example:state-dmv
• Claim: age ≥ 21 (a predicate proof). The customer's wallet presents a VP containing a ZK proof of age, satisfying the policy without revealing their name or birth date.

In large ecosystems, Trust Frameworks define the legal and technical rules that policies must adhere to. They establish:

• Accredited issuers for specific credential types.
• Accepted cryptographic suites and signature types.
• Rules for credential revocation and expiration.
• Liability and compliance requirements. This governance layer ensures policies are not just technically sound but also legally meaningful.

A core privacy-enhancing feature that allows a holder to reveal only specific attributes from a credential, rather than the entire document. This minimizes data exposure and adheres to the principle of data minimization.

• Example: Proving you are over 21 by revealing only your birth year from a driver's license credential, not your full name or address.
• Mechanism: Often implemented using zero-knowledge proofs (ZKPs) or BBS+ signatures.

A security measure ensuring that a presented credential is bound to the specific holder presenting it, preventing credential theft and unauthorized delegation.

• Challenge-Response: The verifier issues a unique, time-bound nonce that the holder must sign with their private key, proving control.
• DID Authentication: The presentation is cryptographically linked to the holder's Decentralized Identifier (DID).
• Prevents: Replay attacks where a stolen credential presentation is reused.

Policies enforce constraints on the presentation request itself to prevent fraud and ensure freshness.

• Expiration Time: The request includes a validUntil timestamp, after which any presentation is rejected.
• Unique Nonce: A random value generated by the verifier must be included in the proof, making each presentation unique and preventing replay.
• Domain Binding: The presentation can be cryptographically bound to a specific verifier domain, preventing a request from one site from being fulfilled to another.

The policy can mandate that the verifier must check the current validity status of the presented credential, ensuring it has not been revoked by the issuer.

• Status List 2021: A common method where credential status is checked against a revocation list on a ledger or HTTP endpoint.
• On-Chain Registries: Smart contracts that maintain a mapping of credential IDs to their active/revoked state.
• Policy Enforcement: The verifier's policy specifies which status check mechanisms are trusted and required.

The policy defines the precise data structure and authorized sources for acceptable credentials, establishing trust boundaries.

• Credential Schema: The exact JSON schema or type (e.g., https://schema.org/EducationalOccupationalCredential) that the credential must conform to.
• Trust Registry: A list of DIDs or public keys of issuers the verifier trusts. The presentation must prove issuance from a trusted source.
• Prevents: Acceptance of credentials from unknown or malicious issuers.

The policy can specify the use of advanced cryptographic proof formats that enhance privacy beyond simple selective disclosure.

• Zero-Knowledge Proofs (ZKPs): Allow proving a statement (e.g., 'age > 18') without revealing the underlying data (the exact birth date).
• BBS+ Signatures: Enable unlinkable presentations, where multiple presentations of the same credential cannot be correlated by the verifier.
• Policy Goal: To achieve unobservability and minimal disclosure as defined by privacy frameworks.

A Verifiable Credential is a tamper-evident digital credential whose authorship can be cryptographically verified. It is the fundamental data object that a Credential Presentation Policy governs. A VC contains:

• Claims: The actual data (e.g., name, date of birth).
• Metadata: Information about the issuer, expiration, and proof type.
• Proofs: Digital signatures or zero-knowledge proofs that establish authenticity and integrity.

A Verifiable Presentation is the data format used by a holder to present one or more Verifiable Credentials to a verifier, in response to a Credential Presentation Policy. It packages the credentials, often applying selective disclosure or zero-knowledge proofs to reveal only the required claims. The VP itself is cryptographically signed by the holder, proving they control the credentials.

A Decentralized Identifier is a globally unique, cryptographically verifiable identifier controlled by its subject (e.g., a person or organization). DIDs are foundational for VC ecosystems:

• Issuer DID: Authenticates who issued a credential.
• Holder DID: Identifies who controls and presents the credential.
• Verifier DID: Identifies the entity requesting the presentation. A Credential Presentation Policy often specifies which trusted DID methods or specific issuers are acceptable.

Selective Disclosure is a privacy-enhancing feature that allows a credential holder to reveal only specific claims from a Verifiable Credential, rather than the entire document. A Credential Presentation Policy can request specific claims (e.g., "age > 21") without requiring the holder to disclose their full birth date or other unrelated data. This is often implemented using zero-knowledge proofs or BBS+ signatures.

Presentation Exchange is a standardized protocol (e.g., DIF's Presentation Exchange specification) that defines the format for the request (the policy) and response (the presentation) between a verifier and a holder. It provides a common data model for Credential Presentation Policies, specifying descriptors for required credentials, constraints, and the rules for fulfillment.

A Trust Registry is a governance tool that maintains a list of trusted entities (issuers, verifiers, credential schemas) within a decentralized identity ecosystem. A Credential Presentation Policy often references a trust registry to validate that the presented credentials come from an authorized issuer. It answers the critical question: "Is this issuer's DID authorized to issue this type of credential?"