Skip to main content

OID4VCI protocol

When a bank needs to issue a credential to a customer's EUDI Wallet—for example, an Account Ownership Credential after opening an account—both systems need a standard way to exchange that credential securely. OpenID for Verifiable Credential Issuance (OID4VCI) is that standard. It defines how credential issuers create offers, how wallets discover what an issuer supports, and how wallets request and receive credentials.

The Truvity EUDIW Connector implements OID4VCI as the core protocol for all credential issuance flows. Where OID4VP handles the presentation side (wallet to Relying Party), OID4VCI handles the issuance side (issuer to wallet). Together, they form the two complementary credential exchange protocols in the EUDI ecosystem.

Why OID4VCI matters​

Before OID4VCI, there was no standard way for issuers and digital wallets to exchange credentials. Each implementation used proprietary protocols, making cross-border and cross-vendor interoperability impossible.

OID4VCI defines the message structures, transaction flows, and interface specification for credential issuance, building on OAuth 2.0. Because every EUDI Wallet and every credential issuer implements the same protocol, a credential issued by one organization can be received by any compliant wallet in any member state.

Key benefits:

  • Standardized issuance across the EUDI ecosystem. Any compliant issuer can deliver credentials to any compliant wallet, regardless of vendor or member state.
  • Built on OAuth 2.0. OID4VCI extends familiar OAuth 2.0 grant types, so the token exchange and authorization patterns are well-understood and widely supported.
  • Interoperability by design. Wallets don't need custom integrations for each issuer. A single protocol implementation handles all credential types.

Protocol flow​

The OID4VCI flow begins when the issuer creates a credential offer and ends when the wallet receives a signed credential. The flow is asynchronous from the issuer's perspective: the issuer creates the offer, and the connector delivers a callback when the wallet completes (or fails) the exchange.

Conceptual steps​

  1. The issuer creates a credential offer. The issuer's backend tells the connector what credential to issue and provides the claims. The connector returns a credential offer URI that the issuer displays to the user as a QR code or deep link.

  2. The wallet discovers issuer metadata. The wallet retrieves two metadata documents: one describing the issuer's capabilities (supported credential types, signing algorithms, proof requirements) and one describing the authorization server (token endpoint, supported grant types). This discovery step lets the wallet configure itself automatically for any issuer.

  3. The wallet exchanges the pre-authorized code for an access token. The wallet presents the pre-authorized code from the offer to the authorization server's token endpoint. The wallet includes a DPoP proof to bind the resulting access token to its key, preventing token theft.

  4. The wallet requests a nonce. The wallet obtains a single-use nonce from the connector. This nonce prevents replay attacks during the credential request.

  5. The wallet creates a key proof. The wallet generates a cryptographic proof demonstrating possession of the key that the credential binds to. The proof includes the nonce from the previous step.

  6. The wallet requests the credential. The wallet sends the key proof and its DPoP-bound access token to the connector's credential endpoint.

  7. The connector signs and returns the credential. The connector validates the proofs, signs the credential using the issuer's signing certificate, and returns it to the wallet. The credential is cryptographically bound to the wallet's key, so only the wallet holder can present it later.

  8. The connector delivers a callback to the issuer backend. The connector notifies the issuer's backend whether issuance succeeded, failed, or expired. The issuer uses this callback to update its own records (for example, marking an account as fully set up).

Pre-authorized code flow​

OID4VCI supports multiple grant types, but the connector uses the pre-authorized code flow. In this flow, the issuer has already authenticated the user and decided to issue a credential—the wallet doesn't need to authenticate the user again at an authorization server.

This is the natural fit for scenarios where issuance happens as part of an existing business process. For example, after a bank completes identity verification during account opening, it already knows who the customer is. The pre-authorized code flow lets the bank issue a credential directly, without requiring the customer to log in again through a separate authorization step.

The pre-authorized code flow extends OAuth 2.0 with a dedicated grant type. The authorization server issues a pre-authorized code when the issuer creates the offer, and the wallet exchanges that code for an access token at the token endpoint—the same token endpoint pattern used in standard OAuth 2.0 flows.

Metadata discovery​

Before a wallet can request a credential, it needs to know what the issuer supports and where to exchange tokens. OID4VCI solves this with two metadata documents that the wallet retrieves automatically.

Credential issuer metadata describes the issuer's capabilities: which credential types are available, what formats they use, which signing algorithms are supported, and what proof types the wallet must provide. This document lets the wallet determine whether it can handle the offered credential type before starting the exchange.

Authorization server metadata describes the token endpoint and the grant types it supports. The wallet uses this to locate the token endpoint where it exchanges the pre-authorized code for an access token.

Together, these two metadata documents make the protocol self-describing. A wallet encountering a new issuer for the first time can configure itself automatically by reading the metadata, without any prior knowledge of that specific issuer's setup.

Relationship to OID4VP​

OID4VCI and OID4VP are complementary protocols that cover the two directions of credential exchange in the EUDI ecosystem:

  • OID4VCI moves credentials from issuer to wallet. The issuer creates an offer, and the wallet receives a signed credential.
  • OID4VP moves credentials from wallet to Relying Party. The Relying Party creates a presentation request, and the wallet shares selected attributes from a credential.

The same wallet, the same credential formats, and the same trust infrastructure underpin both protocols. A credential issued via OID4VCI can be presented via OID4VP to any Relying Party that trusts the issuer. This symmetry is what makes the EUDI ecosystem work—issuance and presentation are standardized independently, so any issuer-wallet-verifier combination is interoperable.

Specification references​

Further reading​