Presentation Request

A core privacy principle enforced by the request format. It allows the Verifier to request only the specific claims needed, not the entire credential. The Holder can then choose to disclose:

• A single attribute (e.g., just a birth year "over 21").
• A cryptographic proof of a claim without revealing the raw data (using zero-knowledge proofs).
• This prevents unnecessary data exposure and limits correlation.

Presentation Requests are typically signed by the Verifier. This cryptographic signature ensures:

• Authenticity: The Holder can verify the request originated from a legitimate Verifier.
• Integrity: The request parameters (requested claims, challenge nonce) cannot be altered in transit.
• Non-repudiation: The Verifier cannot later deny making the specific request. The signed request acts as an audit trail.

To prevent a malicious actor from reusing a previously submitted Presentation, requests include a unique challenge nonce and often a domain or expiration timestamp.

• The nonce is a cryptographically random string that must be included in the Holder's signed response, making each Presentation unique.
• The domain binds the request to a specific Verifier's origin (e.g., a website domain).
• Together, these mechanisms ensure a Presentation cannot be replayed in a different context or after expiry.

The security of the entire flow depends on the Holder correctly authenticating the Verifier. This is not automatic. Risks include:

• Phishing Verifiers: Malicious sites mimicking legitimate ones to steal credentials.
• Holder Responsibility: Wallets/agents must implement robust Verifier Identity checks, often via DID resolution and TLS certificate validation for web-based requests.
• Trust Registries: Some ecosystems use decentralized registries to maintain a list of authorized/revoked Verifier DIDs.

The request can specify advanced proof formats that enhance privacy:

• Zero-Knowledge Proof (ZKP) Requests: Ask for a proof of a statement (e.g., "age >= 18") without revealing the exact birth date.
• BBS+ Signatures: Allow selective disclosure of attributes from a single cryptographic signature.
• Blinded Signatures: Enable issuance of credentials without the Issuer learning the Holder's identifier.
• Supporting these formats in the request enables unlinkable and minimal disclosures.

The request defines the required credential schema and optional issuer DID. This allows the Holder's wallet to:

• Validate that the offered credential matches the expected data structure.
• Check the credential's status against a revocation registry.
• Verify the Issuer's DID is from a trusted source (if specified).
• Enforce presentation policies (e.g., "require a government ID AND a proof of residency"). This shifts policy logic to the client side.

A Verifiable Credential is a tamper-evident digital claim issued by an entity about a subject. It is the core data object requested in a Presentation Request. Key attributes include:

• Issuer: The entity that created and signed the credential.
• Subject: The entity the credential is about (e.g., a user).
• Claims: The actual data or attributes (e.g., date of birth, KYC status).
• Proof: A cryptographic signature enabling verification of authenticity and integrity.

A Verifiable Presentation is the response to a Presentation Request. It is a wrapper, created by the holder, that contains one or more Verifiable Credentials and is itself cryptographically signed. Its purpose is to:

• Selectively disclose only the credentials and claims required by the verifier.
• Prove control over the credentials via the holder's signature.
• Maintain the privacy of the holder by not revealing unrelated credentials.

A Decentralized Identifier is a globally unique, cryptographically verifiable identifier controlled by its subject (e.g., a user, organization, or device). DIDs are foundational to VCs and Presentation Requests because they:

• Provide the issuer, holder, and verifier with persistent, self-sovereign identities not reliant on a central registry.
• Enable the resolution to a DID Document, which contains public keys and service endpoints essential for issuing, holding, and verifying credentials.

The Holder is the entity, typically an end-user, that possesses one or more Verifiable Credentials and creates a Verifiable Presentation in response to a Presentation Request. The holder's key responsibilities are:

• Securely storing credentials in a digital wallet.
• Consenting to share credentials by signing a presentation.
• Managing selective disclosure to reveal only the requested claims, protecting privacy. The holder is distinct from the subject of a credential, though they are often the same entity.

The Verifier is the entity that defines and sends a Presentation Request to a holder, requesting specific credentials to grant access, prove eligibility, or verify attributes. The verifier's role involves:

• Defining policy by crafting the Presentation Request's challenge and domain.
• Receiving and validating the Verifiable Presentation, checking signatures, expiration, and revocation status.
• Making a trust decision based on the verified claims to authorize a transaction or interaction.

A Presentation Request is a machine-readable query that defines what a Holder must prove. Its key components include:

• Challenge: A cryptographic nonce to prevent replay attacks.
• Domain: Context for the request (e.g., the Verifier's DID).
• Requested Credentials: The specific claims or credential types required, often using schemas or specific DID methods.
• Proof Requirements: The allowed signature suites (e.g., Ed25519Signature2018) and optional constraints like credential status or issuance date.

The Presentation Request is the second step in the core Verifiable Credentials interaction model, acting as the Verifier's "ask."

1. Issuance: An Issuer provides a Verifiable Credential to a Holder.
2. Request: A Verifier sends a Presentation Request to the Holder.
3. Presentation: The Holder uses a wallet or agent to select compliant credentials, generate proofs, and create a Verifiable Presentation in response.
4. Verification: The Verifier validates the presentation against the original request.

Interoperability is driven by standard request formats that ensure different wallets and verifiers can communicate.

• W3C Presentation Exchange (PE): A specification defining a presentation_definition object for expressing complex credential requirements, dependencies, and disclosure rules.
• DIF Presentation Exchange: An implementation and extension of the W3C PE spec by the Decentralized Identity Foundation.
• ISO/IEC 18013-5 (mDL): Defines a specific request format for mobile Driver's Licenses using QR codes.

A minimal JSON Presentation Request asking for proof of being over 18 might look like this:

jsonCopy
{
  "challenge": "a1b2c3d4-e5f6-7890",
  "domain": "verifier.example.com",
  "presentation_definition": {
    "id": "proof-of-age",
    "input_descriptors": [{
      "id": "age_descriptor",
      "constraints": {
        "fields": [{
          "path": ["$.credentialSubject.age"],
          "filter": {"minimum": 18}
        }]
      }
    }]
  }
}

This requests a credential where the age claim is greater than or equal to 18.

Requests can encode sophisticated logic for real-world use cases:

• Predicate Proofs: Requesting proof a claim meets a condition (e.g., age >= 21) without revealing the exact value (zero-knowledge proof).
• Credential Status: Requiring the credential to not be revoked (checked against a revocation registry).
• Holder Binding: Proving the presenter is the same subject listed in the credential, often via a DID Auth signature.
• Selective Disclosure: Allowing the Holder to reveal only specific claims from a larger credential.