OIDC4VP

A core privacy feature that allows a user to reveal only specific claims from a Verifiable Credential without exposing the entire document. For example, a user can prove they are over 21 from a driver's license credential without revealing their exact birth date, address, or license number. This is enabled through cryptographic techniques like BBS+ signatures.

The protocol is designed around user agency, where the Holder (user) initiates and controls the presentation of their credentials. The Verifier (relying party) sends a Presentation Request, but the Holder's wallet software evaluates this request, gathers the required credentials from their digital wallet, and decides whether and how to respond. This prevents unsolicited data requests.

Verifiers structure their data requirements using a machine-readable Presentation Definition. This JSON object specifies:

• The type of credentials accepted (e.g., "type": ["VerifiableCredential", "DriversLicense"]).
• The specific claims required (e.g., "family_name", "birthdate").
• Optional constraints like issuer trust lists or status check requirements. The Holder's wallet uses this definition to find matching credentials.

The cryptographically secured package created by the Holder in response to a Presentation Request. A Verifiable Presentation bundles one or more Verifiable Credentials (or selective disclosures from them) and is signed by the Holder's wallet. This signature provides proof that the Holder is the legitimate owner of the credentials and consented to their presentation, ensuring non-repudiation.

OIDC4VP leverages Decentralized Identifiers (DIDs) as the foundational identifier for all parties. The Holder, Issuer, and Verifier each use a DID, which resolves to a DID Document containing public keys and service endpoints. This removes dependency on centralized identity providers and allows for interoperable, self-sovereign identity interactions across different systems.

Credentials and presentations are encoded in standardized, interoperable formats. JWT-based Verifiable Credentials are common for simplicity. For advanced selective disclosure, the SD-JWT (Selective Disclosure JWT) format is used, which allows a Holder to disclose only specific JSON object properties from a signed JWT. This ensures the protocol works with existing OAuth 2.0 and OpenID Connect infrastructure.

The entity (user or organization) that possesses one or more Verifiable Credentials and creates a Verifiable Presentation to share with a Relying Party. The Holder controls which credentials are shared and manages their private keys for signing presentations.

• Role: End-user, data owner.
• Key Action: Selects credentials, creates and signs presentations.
• Example: A user proving their age to a website using a digital driver's license.

The authoritative entity that creates and cryptographically signs Verifiable Credentials for a Holder. The Issuer's signature provides the credential's authenticity and integrity.

• Role: Trusted authority, credential source.
• Key Action: Issues signed credentials to Holders.
• Example: A government agency issuing a digital passport credential or a university issuing a digital diploma.

The service or application that requests and verifies a Verifiable Presentation from a Holder. It validates the presentation's signature and the credentials within it to grant access or services.

• Role: Service provider, verifier.
• Key Action: Requests presentations, validates signatures and claims.
• Example: A financial service requiring proof of accredited investor status before allowing investment.

The OAuth 2.0 component that authenticates the Holder and issues an Access Token. In OIDC4VP, this server is extended to understand requests for verifiable presentations and to facilitate the presentation exchange flow.

• Role: Authentication and token issuance.
• Key Action: Authenticates user, processes presentation requests, issues tokens.
• Protocol Extension: Implements the presentation_definition parameter.

A cryptographically verifiable data format, created by the Holder, that packages one or more Verifiable Credentials to satisfy a Relying Party's request. It is signed by the Holder to prove control over the credentials.

• Format: Typically a JWT or JSON-LD with Linked Data Proofs.
• Contents: Selected credentials, Holder's signature, proof of linkage.
• Purpose: Selective disclosure of verified attributes.

A machine-readable specification, defined by the Relying Party, that details the required credentials and claims it needs from the Holder. It is passed to the Authorization Server as part of the authorization request.

• Standard: Defined by the Presentation Exchange (DIF PE) specification.
• Content: Specifies credential types, required fields, and constraints.
• Function: Enables interoperability by standardizing request formats.

OIDC4VP is the core protocol enabling user-controlled identity wallets (e.g., digital driver's licenses) to share Verifiable Credentials. Users can present cryptographically signed proofs of attributes (like age or residency) to a Relying Party without revealing their entire identity or using a central database.

• Example: A user proves they are over 21 to access a service by sharing a verifiable credential from their wallet, without showing their birthdate.

OIDC4VP enables strong authentication by replacing passwords with cryptographic proofs from a user's identity wallet. This creates a phishing-resistant login flow where the user proves control of a Decentralized Identifier (DID) and presents required credentials.

• Example: Logging into a financial service by scanning a QR code with a wallet app, which signs a challenge and presents a verified 'KYC Complete' credential.

A key feature of OIDC4VP is supporting selective disclosure, allowing users to share only the specific claims needed. This enforces the data minimization principle of GDPR and similar regulations.

• Example: Proving you are a resident of a specific country for tax purposes by presenting a credential containing only that claim, rather than a full passport document with extraneous personal data.

Financial institutions and regulated platforms use OIDC4VP to streamline Know Your Customer (KYC) and onboarding. Customers can present reusable, verified credentials from trusted issuers, eliminating repetitive document submission.

• Process: A bank issues a Verifiable Credential after initial KYC. The customer can then present this credential via OIDC4VP to instantly onboard with partner fintech apps, with the bank's attestation.

Educational institutions and certification bodies issue diplomas, degrees, and professional licenses as Verifiable Credentials. OIDC4VP allows graduates to present these directly to employers or other schools in a tamper-evident format.

• Example: A job applicant shares a verifiable university degree and professional certification from their digital wallet during an application, with the employer instantly verifying the issuer's signature and status.

The authorization and authentication frameworks upon which OIDC4VP is built. OIDC4VP extends these standards to support Verifiable Presentations.

• OAuth 2.0: Provides the authorization framework for requesting access.
• OpenID Connect: Adds an identity layer on top of OAuth 2.0 for authentication.
• Integration: OIDC4VP maps the Verifiable Presentation request/response to the OIDC id_token flow.

Common, interoperable serialization formats for Verifiable Credentials and Verifiable Presentations using JSON Web Tokens (JWT). OIDC4VP frequently uses these formats for easy integration with existing OIDC infrastructure.

• JWT-VC: A JWT that contains a Verifiable Credential as a claim.
• JWT-VP: A JWT that contains a Verifiable Presentation (which itself may contain one or more JWT-VCs).
• Advantage: Leverages well-understood JWT libraries and validation patterns.