OpenID4VCI explained: how credentials get into a wallet

OpenID4VCI, short for OpenID for Verifiable Credential Issuance, is the standard that lets an issuer deliver a digital credential to a person’s wallet. The issuer might be a government agency issuing an identity credential, a transport authority issuing a driving licence, or a university issuing a diploma. The protocol makes sure that the right person receives the credential, and that the credential is tied to a key held in that person’s wallet.

What OpenID4VCI is for

A digital wallet is only useful if it can be filled with credentials in a safe, uniform way. Without a shared protocol, every issuer would need its own app and its own interface. OpenID4VCI defines one common way for any wallet to ask any compatible issuer for a credential. It is the counterpart of OpenID4VP, which handles showing credentials later. What a credential is, and how the formats differ, is covered in verifiable credentials.

The specification is a product of the OpenID Foundation’s Digital Credentials Protocols working group and is published at openid.net/specs. openideurope.eu is an independent guide and not affiliated with the Foundation.

The roles

Role	What it does	Example
Credential issuer	Creates and signs the credential, publishes metadata	Civil registry, driving licence authority, university
Authorisation server	Authenticates the user and issues access tokens	Often run by the issuer, sometimes separate
Wallet	Requests, receives and stores the credential	The EU Digital Identity Wallet app
User (holder)	Approves the issuance	You

How issuance works, step by step

1. Offer. The issuer shows a credential offer, usually a QR code or a link in the issuer’s app. It says which credential is on offer and which flow to use, either directly or through a reference.
2. Discovery. The wallet reads the issuer’s metadata (published at a well-known address) to learn the endpoints and the credential types, formats and key requirements.
3. Authorisation. The wallet obtains an access token in one of two ways:
   • Authorisation code flow: the wallet sends you to the issuer’s login. You authenticate, for example with a national eID, and consent. The wallet receives a code and swaps it for a token, using the same pattern as in OAuth 2.0.
   • Pre-authorised code flow: the issuer has already identified you, for instance at a counter or in an online account, and includes a one-time code in the offer. A separate transaction code, sent by another channel, can be required.
4. Nonce. The wallet may ask the issuer for a fresh nonce to prove freshness.
5. Proof of possession. The wallet creates a key pair, or uses a key in a secure element, and signs the nonce to show it controls the key. Optionally it adds a key attestation showing that the key is held in certified hardware.
6. Credential request. The wallet calls the issuer’s credential endpoint with the access token and the proof.
7. Credential response. The issuer returns the signed credential bound to the wallet’s key. If the issuer needs time, for example for manual checks, it can answer with a transaction ID for deferred issuance and the wallet collects it later.
8. Notification. The wallet can tell the issuer whether the credential was accepted or deleted.

A trimmed credential offer looks like this:

{
  "credential_issuer": "https://issuer.example.gov",
  "credential_configuration_ids": ["eu.example.pid"],
  "grants": {
    "urn:ietf:params:oauth:grant-type:pre-authorized_code": {
      "pre-authorized_code": "oaKazRN8I0IbtZ0C7JuMn5",
      "tx_code": { "input_mode": "numeric", "length": 4 }
    }
  }
}

Everyday examples

• You scan a QR code in a municipal app, log in with your national eID, and your identity data lands in the wallet.
• A licensing authority lets you add a mobile driving licence to your wallet after an online application, see mobile driving licence.
• A university sends a diploma credential to the graduate’s wallet by link.
• An employer issues a proof of employment to a staff member.

Security aspects

• Strong authentication at the issuer. What the credential is worth depends on how well the issuer verified you. The EU describes this through levels of assurance.
• Holder binding. Because the credential is tied to the wallet’s key, a copied credential file is useless to anyone else.
• Wallet and key attestation. Issuers can demand proof that the wallet app is genuine and that keys sit in secure hardware, which protects against cloned or modified wallets. This also raises questions of vendor lock-in that EU rules try to address.
• Pre-authorised code risks. If a one-time code is intercepted or the offer is shown to the wrong person, a credential can end up in the wrong wallet. The optional transaction code is a countermeasure.
• Phishing offers. Only accept offers you expected, from issuers you trust. A rogue QR code can trigger an authentication at a fake site.
• Standard OAuth hygiene. PKCE, exact redirect URIs and short-lived tokens apply, see RFC 9700.

Status and versions

OpenID for Verifiable Credential Issuance 1.0 was approved by the OpenID Foundation membership as a Final Specification and published on 16 September 2025. It supports several credential formats, including ISO mdoc and IETF SD-JWT VC (see SD-JWT and mdoc and ISO 18013-5), and the W3C format. Earlier drafts changed names and endpoints, for example the nonce endpoint is a later addition, so older tutorials may not match the final text.

How it relates to the other standards

OpenID4VCI is an OAuth 2.0 extension: it adds a credential endpoint and new grant details to an existing framework. The login that authorises issuance can itself use OpenID Connect. Its sibling OpenID4VP takes over once the credential is in the wallet.

Role in the EUDI Wallet

In the EU Digital Identity Wallet, OpenID4VCI is how person identification data (PID) and further attestations get into the wallet. Commission Regulation (EU) 2024/2982 on wallet protocols and interfaces (see EUR-Lex) and the Architecture and Reference Framework build on OpenID4VCI for this step. Member states are expected to offer wallets by the end of 2026, and national PID issuers, private attestation providers and qualified trust service providers will all rely on this protocol to reach your wallet.