OpenID for Verifiable Credentials (OpenID4VC)

What it is

OpenID for Verifiable Credentials (OpenID4VC) is a family of OpenID Foundation protocols that move verifiable credentials between issuers, wallets, and verifiers. If DIDs and the VC data model are the nouns of decentralized identity, OpenID4VC is the verbs: how a credential gets issued to a wallet and later presented to a verifier. It builds on OAuth 2.0 and OpenID Connect, so identity teams reuse authorization servers, libraries and threat models they already know.

The core decision for practitioners in 2026 is simple: implement the 1.0 Final specs profiled by HAIP, not the dozens of earlier drafts that early wallets shipped.

Status (November 2026)

The Digital Credentials Protocols working group lists formal security analyses of OpenID4VP (July 2025) and of OpenID4VCI and OpenID4VP (October 2023). The OpenID Foundation publishes errata-corrected text at the base URL and keeps the approved text at the -final URL.

How issuance works (OpenID4VCI 1.0)

The wallet is an OAuth client; the credential issuer is a resource server that may also run the authorization server.

1. Credential offer. The issuer gives the wallet an offer by value (in a URI or QR code) or by reference (an HTTPS URL the wallet fetches). It lists credential configuration IDs and the grants available.
2. Authorization. Either the authorization code flow (a normal OAuth request, optionally with PKCE, PAR and an issuer_state linking it to the offer) or the pre-authorized code flow, where the issuer already authenticated the user out of band and hands over a short-lived single-use code. An optional transaction code (tx_code) sent through a second channel limits the damage of a leaked offer.
3. Proof of possession. The wallet gets a fresh c_nonce from the nonce endpoint and signs it with the key the credential will be bound to. Proof types are jwt, di_vp and attestation (a key attestation).
4. Credential endpoint. The wallet calls it with the access token and proof and receives one or more credentials. Batch issuance returns several copies with different keys so each presentation can use a fresh one. Deferred and notification endpoints handle slow issuance and lifecycle feedback.

Appendix A covers W3C VCs (JWT and Data Integrity variants), ISO mdoc (ISO/IEC 18013-5) and IETF SD-JWT VC.

How presentation works (OpenID4VP 1.0)

A verifier, say a bank onboarding a customer, sends an authorization request with response_type=vp_token, a mandatory nonce, and a DCQL query listing the credentials and claims it needs and, optionally, trusted_authorities naming acceptable issuers. The verifier identifies itself with a client identifier prefix: redirect_uri, x509_san_dns, x509_hash, verifier_attestation, openid_federation or decentralized_identifier, with origin reserved for the Digital Credentials API.

• Same device: redirects, with the response in the fragment by default.
• Cross device: a QR code carries a request URI; the wallet fetches the signed request and posts the response with direct_post, or encrypted with direct_post.jwt.
• Browser: Appendix A runs the same request through the W3C Digital Credentials API, which registers openid4vp-v1-unsigned, -signed and -multisigned protocol identifiers.

The wallet returns presentations bound to the nonce, with selective disclosure so only the requested claims leave the device.

What HAIP pins down

HAIP 1.0 turns options into rules:

Two caveats from the profile itself: it references pre-final drafts (SD-JWT VC draft-13, Token Status List draft-14) on purpose, and conforming to it is not enough on its own to reach eIDAS level of assurance high; additional measures outside its scope are needed.

Who implements it

• walt.id: feature list shows OID4VCI 1.0 and OID4VP 1.0, with deprecated services still covering OID4VCI drafts 11 and 13 and OID4VP drafts 14 and 20.

• Procivis: standards page lists OpenID4VCI 1.0, OpenID4VP 1.0, OpenID4VP over BLE, and a proprietary OpenID4VP-over-MQTT adaptation.

• MATTR: docs start with the OID4VCI pre-authorized code flow and remote verification over OID4VP.

• Microsoft Entra Verified ID: its standards page links OpenID4VCI draft 11, SIOPv2 and DIF Presentation Exchange v2.0.0, which predates the 1.0 and HAIP choices.

• Google Wallet: accepts mdoc IDs over OpenID4VP 1.0.

• Talao: its site describes issuance and presentation "through OID4VCI and OID4VP" for SD-JWT VC, mdoc and W3C credentials; it does not state a version.

Compare options in best verifiable credential platforms.

Security and privacy pitfalls

• Draft drift. "Supports OID4VP" can mean draft 14, draft 20 or 1.0, and they do not interoperate. Ask for the version and the HAIP conformance result.
• Pre-authorized code theft. Anyone holding the offer can redeem the code. Require tx_code for anything sensitive and keep code lifetimes short.
• Cross-device phishing. A QR code can be relayed from an attacker's session to a victim. HAIP makes same-device redirects mandatory and says verifiers must reject presentations when the wallet does not return to the original session; the Digital Credentials API adds origin information the wallet can show.
• Unauthenticated verifiers. redirect_uri client IDs prove nothing about who is asking. Use signed requests with x509_hash or a verifier attestation so the wallet can display and enforce who receives data.
• Replay and linkability. Enforce the nonce, reject reused key binding, and use batch-issued credentials once each so verifiers cannot correlate users by a stable signature or key.
• Treating SIOPv2 as done. It is still an Implementer's Draft; few production wallets depend on it.

How it connects

OpenID4VC carries SD-JWT VC and W3C VCs and mDLs. Issuer and verifier identifiers can be X.509 certificates or DIDs. The EU Architecture and Reference Framework names OpenID4VP over the Digital Credentials API, ISO/IEC 18013-7 over the API, and OpenID4VP with a custom URI scheme as presentation options for the EUDI Wallet.

Related

Guides: verifiable credentials implementation guide, choosing a decentralized identity platform, what is decentralized identity. Standards: Verifiable Credentials, DID, mDL, eIDAS 2 / EUDI Wallet, FAPI, OAuth 2.1. Glossary: OpenID4VCI, OpenID4VP, verifiable presentation, SD-JWT. Vendors: decentralized identity.

Who wrote it

OpenID4VP and OpenID4VCI are edited by Kristina Yasuda, Torsten Lodderstedt, and Tobias Looker. More in the experts directory.