Issuing a verifiable credential is easy to describe and surprisingly easy to get wrong.

At a high level, an authoritative organization creates a signed statement about a person or organization and places it in a wallet. But an interoperable implementation needs more than an API that returns a document. It needs a way for wallets to discover what an issuer supports, obtain authorization where required, prove control of an appropriate key, and receive credentials in a format both sides understand.

That is the job of OpenID for Verifiable Credential Issuance, or OID4VCI.

OID4VCI applies familiar OAuth 2.0 and OpenID Connect patterns to a different outcome. Instead of using a token only to authorize access to an API, a wallet uses the protocol to obtain a cryptographically protected credential from an issuer.

The three actors

An OID4VCI integration has three core roles:

• The Credential Issuer defines and issues credential types.
• The wallet acts as an OAuth client and receives the credential for its holder.
• The Authorization Server authorizes issuance. It may be operated separately or by the issuer itself.

The distinction matters because issuance is not the same as a user downloading a file. The issuer must decide whether the recipient is entitled to a credential. The wallet must demonstrate that it is the intended recipient and provide cryptographic material for the issued credential when the profile requires it.

The resulting credential is signed data: metadata, claims, and an issuer proof. It can be represented in more than one format, including SD-JWT, mdoc, or JSON-LD-based verifiable credentials. OID4VCI is designed to be format-neutral; the issuer and wallet negotiate the relevant credential configuration rather than hard-coding a single representation into the protocol.

Start with discovery, not a bespoke endpoint

A wallet first needs to understand the issuer's capabilities. OID4VCI supports issuer metadata that describes the available credential configurations and the endpoints used during issuance.

The important endpoints fall into a small set:

• A credential endpoint issues an individual credential.
• A batch credential endpoint can issue multiple credentials in one interaction.
• A deferred credential endpoint supports cases where issuance cannot complete immediately.
• A credential offer lets an issuer initiate the journey, commonly through a QR code or deep link.

This metadata-driven model is one of the protocol's practical benefits. A wallet does not need a custom integration for every issuer just to locate a credential endpoint or learn what types of credential are available.

Two ways an issuance journey begins

OID4VCI has two main issuance patterns. They solve different product situations.

The authorization-code flow

In the authorization-code flow, the wallet initiates the interaction. It discovers issuer metadata, requests authorization for the desired credential, and sends the returned authorization code to the token endpoint. With an access token, the wallet can make the credential request.

This is a good fit when a person begins in the wallet or has not yet completed the issuer's authentication and consent process. It follows the same broad separation of responsibilities as OAuth 2.0: authorization happens before the protected operation.

The pre-authorized-code flow

The pre-authorized-code flow starts from the issuer's side. The issuer has already prepared the issuance journey, perhaps after an enrollment or registration step outside the wallet. It sends a credential offer, which can be carried by a QR code or a deep link. The wallet reads the offer, obtains a token using the pre-authorized code, and requests the credential.

This produces a smoother handoff from an issuer-controlled journey to a wallet. It is also a security boundary: a pre-authorized code must not be treated as a reusable credential. The protocol can require a transaction code, sometimes presented to a user as a PIN-like value, when the wallet redeems the code. That additional value helps bind the handoff to the intended person or session.

Choose a flow by product scenario

Use the authorization-code flow when the wallet is the natural starting point and the issuer still needs to authenticate the holder, collect consent, or evaluate eligibility during the issuance journey. This is the familiar OAuth-shaped path: authorization happens first, then the wallet requests the credential.

Use the pre-authorized-code flow when the issuer has already completed the relevant enrollment, eligibility, or identity-proofing step outside the wallet. It is particularly useful for an issuer-controlled handoff: a portal, counter, email, or another device can deliver a credential offer through a QR code or deep link, and the wallet completes the protected redemption. A transaction code can add a user/session binding where the handoff needs it.

Where OID4VP picks up

OID4VCI and OpenID for Verifiable Presentations (OID4VP) are complementary, not competing protocols. OID4VCI moves a signed credential into a wallet. OID4VP later moves a presentation of that credential from the wallet to a verifier.

The contact point is the wallet-held credential and, where applicable, the key material bound to it at issuance. In OID4VP, a verifier sends an authorization request describing what it needs—typically a dcql_query in OID4VP 1.0—alongside verifier metadata and a nonce. The wallet selects an appropriate credential, creates a presentation response, and the verifier validates the issuer signature, holder binding, audience, and its own policy.

The credential request is where the wallet becomes a cryptographic participant

The final credential request is more than “give me my data.” Along with authorization, the wallet supplies a proof. This lets the issuer associate the credential with cryptographic material controlled by the wallet.

That association is important later. When a credential is presented to a verifier, the holder can prove possession of the key bound to it. The credential is therefore more resistant to simple copying and replay than a static document.

Some deployments add wallet and key attestations to this boundary. A wallet attestation is a signed statement about the wallet client, while a key attestation describes relevant properties of cryptographic key storage and user authentication. These mechanisms let an issuer make more informed policy decisions about the wallet and the key that will protect the credential.

They are not a replacement for authorization. They are evidence used alongside it.

What builders should design for

OID4VCI is often introduced as an issuance endpoint. That is too narrow a model. A production integration needs deliberate decisions at every stage:

1. Credential design: Which claims are signed, which formats are supported, and what wallet key material is required?
2. Discovery: Can a wallet reliably find metadata and compatible credential configurations?
3. Authorization: Which user journey uses authorization code, and which uses a pre-authorized offer?
4. Handoff security: When should a transaction code or equivalent protection be required for an issuer-initiated flow?
5. Proof and key policy: What proof must the wallet provide, and when are wallet or key attestations appropriate?
6. Lifecycle: Is issuance immediate, batched, or deferred—and how will a wallet learn the final result?

The protocol gives these choices a shared shape. It does not remove the need for product, privacy, and trust decisions.

The useful mental model

OID4VCI is not a document-download API with OAuth vocabulary attached. It is an issuance protocol that makes a wallet a first-class participant.

The issuer still decides what it will attest. The authorization system still decides who is eligible. But the wallet receives a signed credential in a standard flow and contributes the proof material that can bind that credential to its holder.

For builders, that creates a clean division of labor: OAuth-style authorization controls the right to receive a credential; OID4VCI standardizes the delivery; and the credential's cryptography makes the result usable later in a verifiable presentation.

References

1. OpenID for Verifiable Credential Issuance 1.0 — normative protocol specification for issuer metadata, credential offers, authorization, credential requests, and proofs.
2. OpenID for Verifiable Presentations 1.0 — normative presentation protocol specification for authorization requests, wallet responses, verifier metadata, and credential queries.
3. RFC 6749: The OAuth 2.0 Authorization Framework — baseline authorization framework.
4. OpenID Connect Core 1.0 — identity layer built on OAuth 2.0.