What is OpenID4VCI?

OpenID4VCI (OpenID for Verifiable Credentials Issuance) is a technical protocol that extends the widely used OpenID Connect and OAuth 2.0 frameworks to enable the secure and standardized issuance of digital verifiable credentials. It defines a standard API and a set of rules that allow a trusted entity, known as a Credential Issuer (like a government, university, or bank), to provide a user with a cryptographically secure digital credential that they can store in a personal digital wallet. This process is designed to be interoperable, secure, and privacy-preserving, giving users more control over their personal data.

By building on familiar technologies like OAuth 2.0, OpenID4VCI makes it easier for developers and organizations to adopt. It provides a bridge between existing, centralized identity systems and the emerging world of decentralized identity. The protocol supports different user scenarios through two main "flows": one for when a user needs to log in to prove their identity to claim a credential, and a streamlined one for when the user is already known to the issuer. Ultimately, OpenID4VCI is a foundational piece of technology for the next generation of digital identity, enabling everything from digital driver's licenses to academic diplomas.

---

The design philosophy behind OpenID4VCI is evolutionary, not revolutionary. Instead of creating an entirely new security paradigm from scratch, its architects made a strategic decision to build upon the world’s most trusted and widely deployed protocols for web authorization and identity: OAuth 2.0 and OpenID Connect (OIDC). This approach is fundamental to its rapid adoption and success, as it leverages the existing global infrastructure and deep knowledge base of millions of developers.

At its core, OpenID4VCI uses OAuth 2.0 as its security backbone. The entire process is modeled as a standard OAuth 2.0 interaction: a user's digital wallet acts as an "OAuth 2.0 client application," the Credential Issuer acts as a protected "Resource Server," and an Authorization Server issues access tokens. To get a credential, the wallet must first obtain an access token, which it then presents to the Issuer's protected Credential Endpoint. This is the same fundamental mechanism that protects countless APIs across the internet, from Google to your banking application.

This design choice has profound implications. It means that existing OAuth 2.0 Authorization Servers and OpenID Connect Providers (OPs) can extend their services to become Credential Issuers, often with minimal disruption to their existing infrastructure. For large enterprises with mature Identity and Access Management (IAM) systems, this is a significant advantage. They don't need to replace their battle-tested security stack; they can augment it to support the next generation of digital identity.

The decision to build upon OAuth 2.0 and OIDC is arguably the protocol's most critical strategic advantage, functioning as a powerful go-to-market strategy. The greatest barrier to adopting any new identity protocol is the steep learning curve, perceived risk, and high integration cost. Developers and enterprise architects are rightfully cautious about introducing entirely new, unproven security primitives into their systems. By defining OpenID4VCI as an API protected by standard OAuth 2.0 flows, the protocol's authors effectively bypassed this barrier. A developer doesn't need to learn a new security model from scratch; they only need to learn the new API endpoints (like /credential) and request parameters (like authorization_details) that are layered on top of the familiar flows. This dramatically reduces adoption friction and implementation risk, reframing the business decision from "Should we invest in this new, complex identity technology?" to "How can we extend our existing, trusted IAM system to issue Verifiable Credentials?"

A core feature of the OpenID4VCI specification is its flexibility. It recognizes that not all credential issuance scenarios are the same and provides two distinct patterns, or "flows," to accommodate different business needs and user journeys: the Authorization Code Flow and the Pre-Authorized Code Flow. Understanding the differences between these two flows is key to implementing the protocol effectively.

The Authorization Code Flow is an interactive, user-driven process designed for "public" offers where the Issuer doesn't know the user beforehand and needs to verify their identity during the issuance process.

Analogy: This flow is like applying for a new digital alumni card from your university. The university might post a QR code on its website that anyone can scan. However, to actually claim the credential, you must be redirected to the university's official login page to authenticate with your username and password, proving you are indeed a graduate.

This flow is the ideal choice when a user's eligibility must be confirmed on the spot. It is perfectly suited for open campaigns, public services, or any scenario where a user must actively prove their identity to receive a credential.

Technical Steps:

1. Credential Offer: The process starts when an Issuer creates a credential_offer, which can be shared publicly as a QR code or a deep link. This offer contains metadata about the Issuer and the type of credential being offered.

2. Wallet Interaction & Discovery: The user scans the QR code or clicks the link with their digital wallet. The wallet parses the offer and uses the information to query the Issuer's public metadata endpoint (typically at /.well-known/openid-credential-issuer) to discover supported flows, endpoints, and credential types.

3. Authorization Request & User Authentication: The wallet constructs a standard OAuth 2.0 Authorization Request and redirects the user's browser to the Issuer's Authorization Server. This is the critical authentication step where the user logs in and provides consent. The request is enhanced with OpenID4VCI-specific parameters, such as authorization_details, to specify which credential is being requested.

4. Code Exchange: After successful authentication, the Authorization Server redirects the user back to the wallet, providing a short-lived, single-use authorization_code.

5. Token Request: The wallet makes a secure, back-channel request to the Authorization Server's Token Endpoint, exchanging the authorization_code for an access_token.

6. Credential Request: Finally, the wallet uses this access_token to make an authenticated API call to the Issuer's Credential Endpoint and securely receives the signed Verifiable Credential.

The Pre-Authorized Code Flow is a streamlined, often non-interactive process designed for scenarios where the Issuer already knows and trusts the user's identity because they have been authenticated through another channel.

Analogy: This flow is like being logged into your mobile banking app. The bank already knows it's you. When they offer to issue a digital proof-of-funds document, you can claim it with a single tap. There is no need for a separate login screen because your identity has already been established within the secure context of the app.

This flow is used to create a seamless user experience where re-authentication would be redundant and create unnecessary friction. It is perfect for issuing credentials to existing, logged-in customers, employees, or any user within a trusted session.

Technical Steps:

1. Out-of-Band Authentication: The Issuer authenticates the user through its own existing process (e.g., the user is logged into a secure web portal). This crucial step happens before the OpenID4VCI flow begins.

2. Credential Offer with Pre-Authorized Code: The Issuer's backend, now certain of the user's identity, requests a pre-authorized_code from the Authorization Server. This single-use code, along with the user's claims data, is embedded directly into the credential_offer.

3. Secure Delivery: This user-specific offer is delivered directly to the user via a secure channel, such as being displayed within their logged-in session or sent via a trusted email.

4. Direct Token Request: The user's wallet receives the offer and uses the pre-authorized_code to make a direct, back-channel request to the Token Endpoint to obtain an access_token. This flow completely bypasses the user-facing browser redirect and authentication steps of the Authorization Code Flow.

5. Optional Transaction Code: For enhanced security, the Issuer can require a tx_code (e.g., a numeric PIN). This code would be sent to the user via a separate channel (like SMS) and must be submitted along with the pre-authorized_code to the Token Endpoint, acting as a form of two-factor authentication for the issuance process.

6. Credential Request: As with the other flow, the wallet uses the newly acquired access_token to make an authenticated API call to the Credential Endpoint and retrieve the credential.

The choice between the two flows is a critical design decision for any implementation. The following table provides a clear comparison to guide developers and product managers.

While the technical details of OpenID4VCI are important, its true significance lies in its role as a foundational pillar for the future of digital identity. This protocol is not merely an incremental improvement; it is a key enabler of a paradigm shift towards a more secure, private, and user-controlled internet.

OpenID4VCI is a critical enabler for decentralized identity (DID) ecosystems. While the protocol itself does not require a blockchain or any distributed ledger technology, it provides the standardized mechanism for getting trusted credentials into the hands of users. Once a credential is issued via OpenID4VCI and stored in a user's wallet, that user (the Holder) gains full control over it. They can present it to any number of Verifiers without the original Issuer needing to be online or even aware of the transaction, which fundamentally enhances user privacy and breaks down the data silos that define the modern web.

This vision is not just theoretical; it is being actively validated by massive regulatory and market forces. OpenID4VCI is a required standard within the European Union's Digital Identity Architecture and Reference Framework (ARF), which underpins the ambitious EUDI Wallet initiative. This means that soon, 450 million EU citizens will have digital wallets built on this technology, used for everything from accessing government services to proving their age. Real-world applications, such as the European Social Security Pass (ESSPASS), are already demonstrating how OpenID4VCI can be used to issue credentials that simplify cross-border interactions.

This regulatory backing is fueling enormous market growth. In the banking sector alone, the market for OpenID4VCI solutions was valued at $1.42 billion in 2024 and is projected to grow to $7.04 billion by 2033, driven by the need for secure digital onboarding and robust KYC/AML compliance.

Ultimately, the most profound impact of OpenID4VCI may be its role as a pragmatic and powerful bridge between the centralized identity systems of Web2 and the user-centric vision of Web3. A major challenge for decentralized identity has always been the "oracle problem": how to get trusted, real-world data (like your legal name or university degree) into a decentralized system with a verifiable link to a real-world authority. OpenID4VCI elegantly solves this. It allows a trusted, centralized Web2 entity (like a government, bank, or university) to use a familiar, secure protocol (OAuth 2.0) to issue a portable, cryptographically secure digital asset (the Verifiable Credential). Once issued, that credential can be used in more decentralized, Web3-style interactions, such as being presented via the companion OpenID4VP protocol without the Issuer's direct involvement. In this way, OpenID4VCI is not just an issuance protocol; it is a critical piece of transitional infrastructure that facilitates the migration of trust from the centralized web to a more decentralized, user-empowering model, making the entire vision practical and achievable for mainstream adoption.

For developers tasked with building solutions using OpenID4VCI, the ecosystem of tools and libraries is rapidly maturing. Because the protocol is built on open standards, a growing number of open-source projects are available to accelerate development for both Issuers and wallets.

Open Source Libraries and SDKs

The community has produced libraries in a variety of programming languages, reflecting the protocol's broad appeal. It is important to note that the OpenID4VCI specification has evolved through several drafts; developers should always verify which version of the specification a library supports to ensure interoperability.

Key projects include:

• TypeScript/JavaScript: The OpenWallet Foundation is incubating a suite of foundational TypeScript libraries, including OpenID4VC TypeScript, which provides an environment-agnostic implementation of OpenID4VCI and OpenID4VP. Sphereon's OID4VC is another prominent project in the TypeScript ecosystem.

• Kotlin/JVM: The eudi-lib-jvm-openid4vci-kt is a key library developed for the official EU Digital Identity Wallet, providing a reference implementation of the wallet's role in Kotlin.

• Rust: For developers focused on performance and security, projects like one-core from procivis and the openid4vc library from impierce offer Rust implementations of the OpenID4VC standards.

Supported Credential Formats

A key feature of OpenID4VCI is that it is credential format-agnostic, meaning it can be used to issue credentials of any type. The specification defines profiles for several major formats, ensuring interoperability for the most common use cases:

• W3C Verifiable Credentials Data Model (VCDM): Often encoded as a jwt_vc_json, this is a flexible format for general-purpose claims.

• IETF SD-JWT VC: Selective Disclosure JWTs are a powerful new format that allows a user to reveal only specific claims from a credential while keeping others private.

• ISO/IEC 18013-5 (mdoc): The international standard for mobile Driver's Licenses (mDL) and other mobile identity documents.

Key API Endpoints for Implementation

An organization looking to become a Credential Issuer using OpenID4VCI will need to implement or configure several key API endpoints, which will be protected by their OAuth 2.0 Authorization Server:

• Issuer Metadata (/.well-known/openid-credential-issuer): A public JSON document where the Issuer advertises its capabilities, supported credential types, and endpoint locations.

• Authorization Endpoint (/authorize): The standard OAuth 2.0 endpoint where users are redirected to authenticate and grant consent during the Authorization Code Flow.

• Token Endpoint (/token): The standard OAuth 2.0 endpoint where a wallet exchanges a code for an access token.

• Credential Endpoint (/credential): The new, OAuth 2.0-protected resource endpoint where the wallet presents a valid access token to request and receive the signed Verifiable Credential.

Think of it as a secure, standardized digital mail service for official documents. A trusted organization uses OpenID4VCI to securely send a tamper-proof digital ID (like a diploma or passport) to your personal digital wallet, all built on the same security technology that powers "Log in with Google."

OIDC is for authentication; it proves who you are in the moment to log you in. OpenID4VCI is for issuance; it is used by an authority to give you a reusable, long-lasting digital credential that proves a specific fact about you, which you can then use in many different places.

Use the Authorization Code Flow when you need to offer a credential to the public and must verify each user's identity before issuing (e.g., a new user signing up). Use the Pre-Authorized Code Flow for a frictionless experience when you already know who the user is (e.g., issuing a digital membership card to a customer already logged into your app).

No. OpenID4VCI is a communication protocol that operates over standard web technologies (HTTPS) and does not require any blockchain or distributed ledger technology. It is designed to be a key component of decentralized identity ecosystems, but its core function is independent of any specific ledger.

OpenID4VCI is format-agnostic and can be used to issue any type of Verifiable Credential. Common formats include W3C VCs (for general claims), SD-JWTs (for selective disclosure), and ISO mdocs (for mobile Driver's Licenses), covering everything from university diplomas and employee badges to government-issued IDs.

While other protocols exist (e.g., based on DIDComm), OpenID4VCI is rapidly becoming the dominant standard for enterprise and government use cases. Its foundation on the widely adopted OAuth 2.0 protocol and its mandate within major regulatory frameworks like Europe's eIDAS 2.0 give it significant momentum and a broad adoption base.