Wiki · Concept · Last reviewed June 25, 2026

OpenID for Verifiable Credential Issuance

OpenID for Verifiable Credential Issuance, often shortened to OpenID4VCI or OID4VCI, is the OpenID Foundation protocol for issuing verifiable credentials from an issuer to a wallet.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: digital identity, wallets, verifiable credentials, OAuth, agent governance

Definition

OpenID for Verifiable Credential Issuance 1.0 is an OpenID Final specification, published on September 16, 2025. It defines an OAuth-protected API for issuing verifiable credentials. It is an issuance protocol, not a credential format, wallet product, identity proofing rule, trust framework, or browser API.

OpenID4VCI sits beside OpenID for Verifiable Presentations. Issuance is when a credential enters a wallet. Presentation is when a holder proves something to a verifier. Keeping those moments separate matters because the issuer, wallet, holder, verifier, status service, browser, and policy may all be different institutions.

Roles and Boundaries

The specification uses the issuer-holder-verifier model. A Credential Issuer issues credentials and acts as an OAuth 2.0 resource server. A Wallet acts as an OAuth 2.0 client that requests, receives, stores, presents, and manages credentials and key material for the holder.

The protocol is credential-format agnostic. It defines format profiles and extension points for SD-JWT VC, ISO mobile documents, and W3C Verifiable Credentials Data Model credentials. A claim that "the credential used OpenID4VCI" identifies the delivery ceremony, not the credential's data model, proof suite, revocation mechanism, selective-disclosure properties, or legal force.

Issuance Flow

OpenID4VCI supports authorization-code and pre-authorized-code flows. In an authorization-code flow, OAuth machinery helps the issuer gather user authorization and return an access token the wallet can use at the Credential Endpoint. In a pre-authorized-code flow, preparation happens before the OAuth exchange; the issuer may give the wallet a credential offer through a link, QR code, or URI.

The specification warns that a valid pre-authorized code can let whoever possesses it receive a credential unless the deployment adds suitable mitigations. One mitigation is a transaction code delivered over a separate channel. The governance lesson is direct: convenience flows can turn a credential offer into a bearer object unless they are bound to the right wallet, user, device, or second factor.

The Credential Endpoint can return credentials immediately or defer issuance. Immediate issuance returns one or more credentials. Deferred issuance returns a transaction identifier and interval so the wallet can return later, for example when a manual review or offline business process must finish first.

Metadata and Endpoints

The Credential Issuer API has a mandatory Credential Endpoint. It can also include an optional Nonce Endpoint for fresh c_nonce values used in proof-of-possession, an optional Deferred Credential Endpoint, an optional credential-offer mechanism, an optional Notification Endpoint, and issuer metadata.

Issuer metadata describes capabilities, supported credentials, and display information. The spec defines /.well-known/openid-credential-issuer and requires TLS for the metadata endpoint. Metadata may be unsigned JSON or a signed JWT, but metadata is not institutional trust. Wallets still need policy for which issuers may issue which credential types.

Agent Context

For AI agents, issuance is an action boundary. A browser agent, benefits assistant, travel assistant, or procurement agent might help obtain an age credential, student credential, professional license, employment attribute, organization authority, or eligibility document. The agent may be able to click the offer link, scan a QR handoff, choose a wallet, approve a code flow, or store the credential.

That does not make issuance a routine click. The record should say who initiated issuance, which issuer offered it, which credential configuration was requested, what claims will be encoded, whether holder binding is cryptographic or claims-based, which wallet received it, and what presentations it could enable. An agent can explain the ceremony, but it should not silently accept credentials that expand identity or authority.

Governance Risks

Credential offer phishing. A malicious offer can steer a wallet toward an attacker-controlled issuer, reveal wallet behavior, or induce the user to accept a misleading credential.

Bearer-code leakage. Pre-authorized codes and transaction codes need binding, expiry, and channel separation so possession alone does not become authority.

Issuer confusion. A credential issuer identifier, a credential's internal issuer field, a DID, a certificate subject, and a trust-framework entry may not be the same thing.

Correlation by issuance design. Unique values, issuer signatures, wallet attestation subjects, timestamps, and issuer identifiers can later help correlate a holder's activity.

Consent laundering. A user-facing issuance prompt can look voluntary while access to work, school, benefits, travel, or services depends on accepting the credential.

Governance Pattern

Source Discipline

Claims about OpenID4VCI should name the specification version, credential format, credential configuration, grant flow, endpoint, holder-binding method, issuer metadata, and trust framework. Do not collapse OpenID4VCI into OpenID Connect login, OpenID4VP presentation, W3C Verifiable Credentials, the Digital Credentials API, or a national digital-identity wallet.

Spiralist Reading

Spiralism reads OpenID4VCI as the credential minting ceremony. A credential is not born as truth; it is born as an assertion by an issuer, carried by a wallet, and later tested by institutions. The humane version makes that chain legible. The dangerous version turns every threshold into a vending machine for identity.

Open Questions

Sources

Return to Wiki