HomeW3C VCDMPresentations

Verifiable Presentations

How holders package and present credentials to verifiers, including holder binding, challenge-response, and multi-credential presentations.

What is a Verifiable Presentation?

A Verifiable Presentation (VP) is a container for one or more verifiable credentials that a holder presents to a verifier. The presentation can include a proof that binds the holder to the presentation, preventing credential theft.

Aggregation

Combine multiple credentials from different issuers into a single presentation.

Holder Binding

Cryptographically prove that the presenter is the legitimate holder of the credentials.

Selective Disclosure

Include only the claims needed for the specific verification request.

Freshness

Challenge-response mechanism proves the presentation was created recently.

Presentation Flow

The typical flow involves the verifier requesting specific credentials, the holder selecting and packaging them, and the verifier validating the result.

Loading diagram...

1. Presentation Request

The verifier specifies what credentials or claims are needed, often with a challenge for freshness. Standards like DIF Presentation Exchange define request formats.

2. Credential Selection

The holder (via their wallet) selects credentials that satisfy the request. For SD-JWT, they choose which disclosures to include.

3. Presentation Creation

The wallet creates a VP containing the selected credentials and signs it with the holder's key, including the verifier's challenge.

4. Verification

The verifier checks the VP proof, each VC's proof, issuer trust, temporal validity, status, and applies business rules.

Presentation Structure

A Verifiable Presentation has a similar structure to a Verifiable Credential, but contains credentials rather than claims.

Loading diagram...

Property	Type	Required	Description
@context	Array<string \| object>	Required	Must start with "https://www.w3.org/ns/credentials/v2".
type	Array<string>	Required	Must include "VerifiablePresentation".
verifiableCredential	Array<VC>	Optional	Array of verifiable credentials being presented. Can be empty for holder authentication only.
holder	string \| object	Optional	Identifier of the entity presenting the credentials. Usually a DID.
proof	object \| Array<object>	Optional	Holder's cryptographic proof binding them to the presentation.

@contextRequired

Type:Array<string | object>

Must start with "https://www.w3.org/ns/credentials/v2".

typeRequired

Type:Array<string>

Must include "VerifiablePresentation".

verifiableCredentialOptional

Type:Array<VC>

Array of verifiable credentials being presented. Can be empty for holder authentication only.

holderOptional

Type:string | object

Identifier of the entity presenting the credentials. Usually a DID.

proofOptional

Type:object | Array<object>

Holder's cryptographic proof binding them to the presentation.

Complete VP Example

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2"
  ],
  "type": ["VerifiablePresentation"],
  "holder": "did:example:holder",
  "verifiableCredential": [
    {
      "@context": ["https://www.w3.org/ns/credentials/v2"],
      "type": ["VerifiableCredential", "IdentityCredential"],
      "issuer": "did:example:gov",
      "credentialSubject": {
        "id": "did:example:holder",
        "givenName": "Alice",
        "familyName": "Smith"
      }
    },
    {
      "@context": ["https://www.w3.org/ns/credentials/v2"],
      "type": ["VerifiableCredential", "EmploymentCredential"],
      "issuer": "did:example:employer",
      "credentialSubject": {
        "id": "did:example:holder",
        "employeeId": "EMP-12345"
      }
    }
  ],
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "ecdsa-rdfc-2019",
    "created": "2024-01-15T10:30:00Z",
    "verificationMethod": "did:example:holder#key-1",
    "proofPurpose": "authentication",
    "challenge": "abc123xyz",
    "domain": "https://verifier.example.com",
    "proofValue": "z3FXQehH..."
  }
}

Holder Binding

The VP proof demonstrates that the presenter controls the private key associated with the holder identity. This prevents credential theft.

Challenge-Response

The verifier provides a random challenge value that the holder includes in their proof. This proves the presentation was created specifically for this request and prevents replay attacks.

"challenge": "n-0S6_WzA2Mj",
"domain": "https://verifier.example.com"

Key Binding in Credentials

For maximum security, the credential subject ID should match the holder's DID, and the VP proof should use a key from that DID.

// In VC:
"credentialSubject": {
  "id": "did:example:holder"
}

// In VP proof:
"verificationMethod": "did:example:holder#key-1"

Bearer Credentials

Credentials without subject IDs or holder binding can be used by anyone who possesses them. This may be intentional (bearer tokens) but reduces security.

Verification Process

Verifiers must perform multiple checks to ensure a presentation is valid.

Structure Validation

Check that the VP conforms to the VCDM specification with required properties.

VP Proof Verification

Verify the holder's signature on the presentation, check challenge and domain.

VC Proof Verification

For each credential, verify the issuer's signature is valid.

Issuer Trust

Check that each credential's issuer is trusted for that credential type.

Temporal Validity

Verify current time is between validFrom and validUntil for each credential.

Status Check

If credentialStatus is present, query status list to check for revocation.

Business Rules

Apply verifier-specific rules to the claims (e.g., age >= 21, valid license type).

Verification vs Validation

Verification is cryptographic (signature checks). Validation is business logic (claim value checks). Both are required for a complete assessment.

Securing Mechanisms Revocation