OIDC4VCI

The protocol introduces a machine-readable Credential Offer object, typically a URI or QR code. This object contains the metadata needed for the wallet to initiate the credential issuance process, including:

• The Issuer's credential endpoint URL.
• The unique identifiers (credential_configuration_ids) for the offered credentials.
• Optional Grants specifying the authorization mechanisms (e.g., a pre-authorized code). This decouples the offer from the issuance flow.

Issuers publish a Credential Issuer Metadata document (similar to OIDC Discovery). This allows Wallets to dynamically discover:

• Supported credential formats (e.g., JWT-VC, SD-JWT, or JSON-LD).
• The cryptographic proof types required.
• The specific claims available in each credential type. The Holder's wallet requests a credential in its preferred format, and the Issuer responds with a credential in one of the mutually supported formats.

OIDC4VCI supports two primary issuance flows:

• Pre-Authorized Code Flow: The Issuer generates a short-lived, single-use code before user interaction. The wallet uses this code directly at the token endpoint, ideal for QR-based onboarding where the user is physically present.
• Authorized Code Flow: The user completes a full OAuth/OpenID Connect authorization with the Issuer, which returns a standard authorization code. This is used for online services where the user logs in via a web browser.

A core security feature is cryptographic binding of the issued credential to the Holder. This is achieved through a Proof-of-Possession (PoP) mechanism. When requesting the credential, the Holder must sign the request with a key they control (e.g., from their wallet's Decentralized Identifier - DID). This key proof ensures that only the intended recipient, who holds the corresponding private key, can receive the credential, preventing interception and replay attacks.

OIDC4VCI is designed for interoperability, acting as a bridge between the traditional federated identity world (OIDC) and the emerging SSI (Self-Sovereign Identity) ecosystem. It allows existing identity providers (e.g., government portals, universities, corporations) to become VC Issuers without overhauling their infrastructure. Wallets that support the protocol can receive credentials from any compliant issuer, promoting a unified credential market.

Financial institutions can use OIDC4VCI to streamline Know Your Customer (KYC) processes. After a user completes verification with a trusted provider, that provider issues a Verifiable Credential attesting to their verified identity. The user can then present this credential to multiple banks or exchanges, eliminating redundant checks. Key benefits include:

• Reduced friction for customer onboarding.
• Enhanced privacy as users share only necessary proof, not raw documents.
• Auditable compliance through cryptographically verifiable attestations.

Universities and certification bodies can issue tamper-proof digital diplomas and certificates. A graduate authenticates, and the institution's OIDC4VCI-compliant service issues a Verifiable Credential representing their degree. This credential can be instantly verified by employers or other institutions without contacting the original issuer. This application provides:

• Instant verification eliminating manual transcript requests.
• Reduced fraud via cryptographic signatures.
• Lifelong portability for the credential holder.

Healthcare providers or insurance companies can issue Verifiable Credentials for vaccination records, lab results, or insurance eligibility. A patient controls these credentials in their digital wallet and can present them as needed. This enables:

• Patient-controlled data sharing with clinics, pharmacies, or travel authorities.
• Privacy-preserving verification (e.g., proving you are vaccinated without revealing your birth date).
• Interoperability across different healthcare IT systems using a common standard.

In Web3, OIDC4VCI can bridge off-chain identity with on-chain activity. A DAO might issue a Verifiable Credential attesting to a member's reputation or contribution level. A DeFi protocol could require a credential proving jurisdiction or accredited investor status for compliance (DeFi compliance). This allows for:

• Sybil-resistance by linking unique identity to on-chain addresses.
• Gated access to financial products based on verified attributes.
• Reputation-based governance where voting power is linked to verified credentials.

OIDC4VCI defines a standardized API for issuing credentials. The flow typically involves:

• Credential Offer: An issuer presents a machine-readable offer (e.g., via a QR code or deep link).
• Authorization: The holder authenticates using OIDC to obtain an access token.
• Credential Request & Issuance: The holder presents the token and a proof of key possession to a credential endpoint, which returns the signed Verifiable Credential. This decouples authentication from issuance, enabling scalable, user-controlled credential distribution.

The protocol is foundational for portable digital identity ecosystems:

• Self-Sovereign Identity (SSI): Issuing Decentralized Identifiers (DIDs) and verifiable credentials to users' digital wallets.
• Know Your Customer (KYC): Financial institutions can issue reusable, privacy-preserving KYC attestations.
• Academic & Professional Credentials: Universities issuing diplomas or employers issuing proof-of-employment credentials.
• Access Credentials: Issuing verifiable membership or access passes for physical or digital services.

OIDC4VCI is part of a suite of OpenID specifications for verifiable credentials:

• OIDC4VCI (Issuance): This protocol, for issuing credentials.
• OIDC4VP (Presentation): For presenting and verifying credentials. A holder uses it to share a VC with a verifier.
• SIOP (Self-Issued OP): Allows a user to act as their own OpenID Provider using a Decentralized Identifier, enabling authentication without a central IDP. Together, they form a complete stack for credential lifecycle management.

The specification defines several critical data structures and endpoints:

• Credential Offer Object: A JSON object containing the issuer, credentials offered, and grants.
• Credential Endpoint: The API where authorized holders request credentials.
• Credential Response: Contains the issued credential, often in JSON-LD or JWT-VC format.
• Metadata: Issuers publish metadata (.well-known endpoint) describing supported credential types, cryptographic suites, and endpoints, enabling wallet discovery.

OIDC4VCI is seeing rapid adoption as the standard for interoperable credential issuance:

• European Digital Identity (EUDI) Wallet: The EU's framework for digital identity wallets mandates its use for issuing Person Identification Data (PID) and Attestations of Attributes (AA).
• OpenID Foundation: The OpenID Connect Working Group maintains the specification, ensuring broad industry alignment.
• Wallet & Issuer Ecosystem: Major SSI wallet providers (e.g., those supporting W3C Verifiable Credentials) and trust framework operators are implementing the protocol to ensure interoperability.

Standardizing on OIDC4VCI provides significant advantages:

• Interoperability: Any compliant wallet can receive credentials from any compliant issuer, breaking vendor lock-in.
• Security: Leverages battle-tested OAuth 2.0 authorization flows and requires Proof of Possession (PoP) binding for key security.
• User Experience: Enables familiar, streamlined UX patterns (QR scans, deep links) for acquiring credentials.
• Discoverability: Standardized metadata allows wallets to automatically configure connections to issuers.

The Authorization Server is the central trust anchor in OIDC4VCI. It authenticates the holder, manages authorization, and issues the Authorization Code or Access Token required to request a credential. Security relies on:

• TLS-secured communication for all endpoints.
• Strong client authentication methods (e.g., private_key_jwt).
• Strict validation of redirect URIs and client metadata to prevent phishing and code injection attacks.

The Credential Issuer is responsible for the cryptographic signing and issuance of the Verifiable Credential. Trust is established through:

• Issuer Identifiers: A cryptographically verifiable DID or a HTTPS URL that serves the issuer's metadata.
• Credential Signing Keys: The issuer's private keys used for signing credentials, published in a DID Document or a .well-known configuration.
• Credential Schemas: The structure and semantic meaning of the credential data, often referenced by a URI to ensure interoperability and prevent misinterpretation.

The Wallet (Holder) must securely manage sensitive artifacts. Key security responsibilities include:

• Private Key Custody: Safeguarding the Decentralized Identifier (DID) keys used to receive and prove control of credentials.
• Token Storage: Securely storing the Access Token and Credential Response.
• User Consent & UI Integrity: Providing a clear, tamper-resistant interface for the user to review and consent to the credential being issued, as mandated by the authorization_details parameter.

OIDC4VCI supports Deferred Credential Issuance, where a credential is prepared asynchronously. This introduces the Deferred Credential Endpoint, secured by a unique Transaction ID. Critical considerations are:

• Transaction ID Binding: The ID must be strongly bound to the original authorization request and the holder's session.
• Token Replay Prevention: The Access Token used to poll the deferred endpoint must be single-use or scoped exclusively to that transaction to prevent credential theft.
• Expiration & Cleanup: Deferred transactions must have strict timeouts to prevent resource exhaustion attacks.

Automated discovery of issuer capabilities via OpenID Provider Metadata or Credential Issuer Metadata reduces configuration errors but requires secure retrieval. Key practices:

• HTTPS Enforcement: All metadata URLs must use TLS.
• Signed Metadata: Use of Signed JWT Metadata (signed_metadata) allows issuers to cryptographically sign their configuration, creating a verifiable trust chain from the issuer identifier to their endpoints and supported credential formats.

Security properties depend on the Credential Format (e.g., W3C Verifiable Credentials, ISO mDL). Each format has distinct considerations:

• Proof Mechanisms: JWT vs. Linked Data Proofs (LD-Proofs) have different cryptographic suites and key management requirements.
• Selective Disclosure: Formats like SD-JWT enable disclosure of specific claims; the wallet must correctly implement the complex Key Binding process to prevent claim re-use.
• Cryptographic Agility: The protocol must support deprecation of weak cryptographic algorithms across the entire stack, from TLS to credential signatures.