Verifiable Presentation

4 min read

Pronunciation

[ver-uh-fahy-uh-buhl pree-zen-tey-shuh n] or [prez-uh n-tey-shuh n]

Analogy

Imagine you have a collection of official, digitally signed certificates in your secure digital – like a digital driver's license, a university diploma, and a professional certification (these are your Verifiable Credentials). When you need to apply for a new job that requires proof of your degree and a valid driver's license, instead of just sending unprotected copies, you use your to create a special 'presentation package' (the Verifiable Presentation). In this package, you might include your full diploma VC and only the 'license class' and 'validity' claims from your driver's license VC. You then digitally sign this entire package with your personal cryptographic key. The potential employer (the verifier) receives this package. They can see it's authentically from you (by checking your signature on the package) and can independently verify that the included diploma and license information are genuine, untampered, and were issued by the correct authorities.

Definition

In the context of Verifiable Credentials (VCs) and Self-Sovereign Identity (SSI) systems, a Verifiable Presentation (VP) is a data object created by a 'holder' of one or more VCs. The VP is used to present these credentials, or specific selected claims from them, to a 'verifier' in a manner that allows the verifier to cryptographically confirm the authenticity and integrity of the presented information, as well as the fact that the holder authorized this specific presentation. It essentially acts as a secure, digitally signed wrapper for sharing VCs.

Key Points Intro

Verifiable Presentations are the standardized and secure mechanism by which individuals (holders) share their Verifiable Credentials with other parties (verifiers), enabling trust and data exchange while preserving privacy and holder control.

Key Points

Securely Packages VCs for Sharing: Bundles one or more Verifiable Credentials, or specific claims derived from them, into a single data object for presentation to a verifier.

Demonstrates Holder Authorization and Control: Contains a cryptographic proof (typically a digital signature) generated by the holder, which demonstrates their control over the VCs being presented and their explicit consent for sharing them in that specific context.

Cryptographically Verifiable by Recipient: Allows the verifier to independently and cryptographically check the authenticity and integrity of the VCs within the presentation, the identity of their original issuers, and the integrity of the presentation itself.

Supports Privacy-Preserving Selective Disclosure: Can be used in conjunction with techniques like Zero-Knowledge Proofs to present only specific, necessary claims from VCs without revealing the entire credential or other sensitive data.

Example

A user (the holder) wants to prove to an online streaming service (the verifier) that they are over 18 years of age to access age-restricted content. They have a Verifiable Credential in their , issued by a trusted identity verification service, which attests to their date of birth. Using their , the user creates a Verifiable Presentation. This VP might not contain the full date of birth VC, but instead a Zero-Knowledge Proof derived from it, proving only the statement 'The holder's age is greater than or equal to 18.' The VP itself is then signed by the user's Decentralized Identifier (DID) and includes a challenge (nonce) provided by the streaming service to prevent replay attacks. The streaming service receives this VP, verifies the holder's signature on the VP, and verifies the ZKP. If all checks pass, access is granted without the service ever learning the user's actual birthdate.

Technical Deep Dive

A Verifiable Presentation, as typically defined by the W3C Verifiable Credentials Data Model, is a JSON-LD document that includes several key components: 1. `@context`: Specifies the JSON-LD contexts necessary for interpreting the VP and any embedded VCs. 2. `type`: An array of types, which must include `VerifiablePresentation`. It can also include other types to further specify the presentation's nature. 3. `verifiableCredential` (optional): An array containing one or more Verifiable Credentials that the holder is presenting. These VCs can be embedded directly or referenced by URIs. 4. `proof`: A cryptographic proof (or an array of proofs) created by the holder. This proof is crucial as it demonstrates holder control and consent. It typically includes: * `type`: The type of proof suite used (e.g., `Ed25519Signature2020`, `JsonWebSignature2020`). * `created`: The creation of the proof. * `verificationMethod`: The DID URL identifying the holder's used for signing. * `proofPurpose`: Typically `authentication` (to prove control of the DID) or `assertionMethod` (if the VP itself is making new assertions based on the VCs). * `challenge` (optional but recommended): A or challenge string provided by the verifier to prevent replay attacks. * `domain` (optional): A string identifying the intended verifier or context for this presentation. * The signature value itself (`proofValue`, `jws`, etc.). 5. `holder` (optional but common): The DID of the entity (the holder) creating and presenting the VP. When a verifier receives a VP, they must: 1) Verify the proof(s) on the VP itself, ensuring it was signed by the claimed holder and that the challenge/domain match the current interaction. 2) For each VC within the VP, verify its own proof(s) (issuer's signature), check its validity period, and potentially check its revocation status (e.g., via a status list VC or a revocation list).

Security Warning

The security of a Verifiable Presentation ecosystem relies on several factors: the holder must securely manage the private keys associated with their DID that are used to sign the VP. Verifiers must meticulously perform all necessary cryptographic checks, including validating the holder's signature on the VP, ensuring the challenge/nonce is fresh and correct to prevent replay attacks, and thoroughly validating the authenticity, integrity, and status (e.g., not revoked) of each Verifiable Credential contained within the presentation. They must also verify the trustworthiness of the original issuers of the VCs.

Caveat

Crafting and verifying Verifiable Presentations, especially those that involve complex cryptographic mechanisms like Zero-Knowledge Proofs for advanced , can be technically intricate. User-friendly and secure software is absolutely crucial to abstract this complexity from the end-user and to guide them in making safe and informed data-sharing decisions. Ensuring broad interoperability of VP formats, proof types, and communication protocols across different SSI wallets, issuer platforms, and verifier systems is also an ongoing area of significant development and standardization efforts.

Blockchain & Cryptocurrency Glossary

Verifiable Presentation - Related Articles