OpenID for Verifiable Credentials (OID4VC)

OID4VC is the overarching term for a set of specifications that integrate Verifiable Credentials (VCs) with the widely adopted OAuth 2.0 and OpenID Connect (OIDC) authorization framework. It enables standardized, secure, and privacy-preserving credential flows, allowing users to present proofs derived from their credentials without relying on centralized identity providers for every transaction.

SIOPv2 is a core dependency of OID4VP that enables decentralized authentication. It allows an end-user to act as their own OpenID Provider (OP) using a Decentralized Identifier (DID). Instead of logging in via Google or Facebook, the user authenticates directly from their wallet by signing a challenge with their DID's cryptographic keys, establishing a holder-binding between the credential subject and the presenter.

OID4VC specifies interoperable formats for encoding credentials:

• JWT Verifiable Credential (JWT-VC): A W3C VC encoded as a JSON Web Token (JWT). It provides integrity and proof of issuance but discloses all claims at once.
• Selective Disclosure JWT (SD-JWT-VC): An advanced format enabling selective disclosure. The issuer provides a signed JWT with hashed claims, allowing the holder to reveal only specific claims to a verifier, enhancing data minimization and privacy.

OID4VC flows use OAuth 2.0's Authorization Details extension to communicate credential-specific requirements. Key grant types include:

• Pre-Authorized Code Flow: For issuance, where a user is pre-authorized and uses a one-time code (often from a QR scan).
• Authorization Code Flow: The standard OAuth flow adapted for credential issuance or presentation, where the wallet exchanges an authorization code for an access token and then the credential or presentation.

Financial institutions are piloting OID4VC to streamline Know Your Customer (KYC) processes.

• Reusable KYC: A user obtains a verified credential from one bank (e.g., proof of identity and address) and can re-present it to another institution, avoiding repetitive document submission.
• Enhanced Privacy: Banks receive only the necessary, verified data, reducing data liability.
• Regulatory Alignment: Supports Travel Rule compliance by verifiably linking transaction origins to credentialed identities.

Universities and employers use OID4VC to issue and verify tamper-proof digital diplomas and transcripts.

• Issuer: University signs a VC containing the graduate's degree data.
• Holder: Graduate stores it in their digital wallet.
• Verifier: Potential employer requests a presentation via OID4VP, instantly verifying the credential's authenticity and issuer without contacting the university.
• Global Standard: Aligns with W3C Verifiable Credentials Data Model.

OID4VC is built on three key specifications:

• OID4VCI (Issuance): Defines how a Credential Issuer (like a government or university) can issue VCs to a Wallet using an OAuth 2.0 authorization flow.
• OID4VP (Presentation): Defines how a Verifier (like a website) can request and receive VCs from a Wallet, enabling selective disclosure of claims.
• SIOPv2 (Self-Issued OpenID Provider): Allows a user's Wallet to act as its own OpenID Provider, enabling decentralized authentication without a traditional Identity Provider.

The protocol defines clear roles for interoperability:

• Holder/Wallet: The user's software that stores VCs and interacts with Issuers and Verifiers.
• Issuer: The entity that creates and cryptographically signs VCs (e.g., a diploma issuer).
• Verifier: The relying party that requests and validates VCs to grant access or services.
• Authorization Server: Manages the OAuth 2.0 flows for secure credential exchange. This separation ensures data minimization and user control over their digital identity.

OID4VC leverages and extends existing web standards:

• OAuth 2.0 Authorization: Uses grant types and scopes to securely authorize credential issuance and presentation requests.
• Decentralized Identifiers (DIDs): Often used as the subject identifier in VCs, enabling issuer and holder control without centralized registries.
• Selective Disclosure: Allows the Holder to prove specific claims from a VC (e.g., "over 21") without revealing the entire document.
• JSON Web Tokens (JWTs): A common format for representing VCs and presentation requests within the protocol.

OID4VC enables portable, user-centric identity across sectors:

• Digital Driver's Licenses & mDL: Aligns with the ISO 18013-5 standard for mobile driver's licenses.
• Educational Credentials: For verifiable diplomas and certificates (e.g., EBSI, Open Badges).
• Know Your Customer (KYC): Streamlines reusable identity verification for financial services.
• Healthcare: Secure sharing of vaccination records or medical credentials. Adoption is driven by the need for interoperability between different wallet and issuer implementations.

OID4VC is a transport and authorization layer for the W3C's Verifiable Credentials Data Model. It does not define the credential format itself. Think of it this way:

• W3C VC Data Model: Defines the data structure (the 'what')—the JSON-LD or JWT VC itself.
• OID4VC: Defines the protocol (the 'how') for getting that VC from an Issuer to a Holder and from a Holder to a Verifier over the web. This separation allows OID4VC to be agnostic to the specific VC format or cryptographic proof type used.

A core privacy feature allowing a holder to reveal only specific attributes from a verifiable credential, rather than the entire document. This is enabled by cryptographic techniques like BBS+ signatures or CL signatures.

• Example: Proving you are over 21 from a driver's license credential without revealing your exact birth date or address.
• Benefit: Minimizes data exposure and supports the principle of data minimization.

Mechanisms that cryptographically bind a credential to its legitimate holder and prove they control the associated Decentralized Identifier (DID) during presentation.

• Holder Binding: Ensures a credential issued to Alice cannot be presented by Bob.
• Proof-of-Possession (PoP): Requires the holder to sign the presentation request with a private key linked to their DID, proving they are the subject of the credential.

Guarantees that the data presented by a holder cannot be tampered with and that the presentation act is auditable.

• Integrity: The verifiable presentation is cryptographically signed, allowing the verifier to detect any alteration of the disclosed claims.
• Non-Repudiation: The holder's signature on the presentation serves as cryptographic proof that they authorized the disclosure, preventing them from later denying it.

Protocol flows ensure all parties are properly authenticated to prevent impersonation and man-in-the-middle attacks.

• Issuer Authentication: The holder must authenticate the issuer (e.g., via their DID and public key) before trusting and storing a credential.
• Verifier Authentication: The holder's wallet authenticates the verifier's identity (via its DID or OAuth client ID) before releasing any credentials, preventing credential phishing.

Privacy-preserving properties designed to prevent different interactions from being linked back to the same user.

• Unlinkable Presentations: Using different presentation tokens or zero-knowledge proofs for each verifier prevents them from colluding to track a user.
• Correlation Resistance: Techniques like using pairwise pseudonymous DIDs for different relationships make it difficult for issuers and verifiers to correlate a user's activities across contexts.

Methods for an issuer to invalidate a credential before its expiration, a critical security control.

• Status List 2021: A privacy-preserving method where revocation status is encoded in a bitstring, allowing the holder to prove non-revocation without revealing the credential's unique identifier.
• Trade-offs: Balances issuer control with holder privacy, avoiding centralized query endpoints that leak user activity.

The core data model standardized by the W3C. A Verifiable Credential is a tamper-evident digital claim with a cryptographic proof, issued by an issuer to a holder. OID4VC provides standardized protocols for requesting, transmitting, and presenting these credentials, but does not define the credential format itself.

• Structure: Contains claims, issuer metadata, proof, and status information.
• Example: A digital driver's license issued by a state DMV.

A W3C standard for cryptographically verifiable, self-sovereign identifiers. DIDs are a foundational component for many VCs and OID4VC flows, allowing entities (issuers, holders, verifiers) to be identified without a central registry.

• Format: did:method:identifier (e.g., did:key:z6Mk...).
• Role: Often used as the id of the credential subject and to anchor the cryptographic keys for signing and verification.

An OID4VC profile where the holder acts as their own OpenID Provider. Instead of relying on a traditional IdP (like Google), the user's wallet generates and presents a Self-Issued ID Token directly to the relying party (verifier). This is a key mechanism for user-centric, decentralized authentication.

• Core Benefit: Eliminates dependency on corporate identity providers.

Two complementary specifications that define machine-readable formats for credential interactions. A Credential Manifest specifies what credentials an issuer can issue. A Presentation Definition (from DIF Presentation Exchange) specifies what credentials a verifier requires.

• Workflow: These formats structure the requests and responses in OID4VC's Authorization Code Flow and Pre-Authorized Code Flow.

The foundational authorization and authentication frameworks upon which OID4VC is built. OID4VC extends OAuth 2.0 flows and OIDC constructs (like the ID Token) to handle Verifiable Credentials.

• Key Adaptation: Re-purposes the scope parameter for credential requests and uses the vp_token as a new response type alongside id_token.

The user-agent software that enables individuals or organizations to manage their digital identity. In OID4VC, the wallet (acting for the holder) is a critical component that:

• Stores DIDs, private keys, and Verifiable Credentials securely.
• Implements the OID4VC client-side protocols to interact with issuers and verifiers.
• Presents credentials based on user consent.