OpenID4VCI is the protocol used for verifiable credential issuance. It defines how a wallet requests a credential from an issuer, how client settings are established, and how the resulting credential is delivered in a standardised way that can be integrated across different identity systems.
OpenID4VCI as a credential issuance protocol
OpenID4VCI standardises how an issuer delivers a verifiable credential to a wallet after a request is made, so different wallets and issuers can interoperate without bespoke issuance flows.
The main value of the protocol is consistency at the issuance boundary. It gives implementations a common way to handle client settings, issuance exchanges, and credential delivery, which reduces integration drift when multiple identity systems need to participate in the same credential ecosystem.
How issuance flows are structured
At a practical level, OpenID4VCI sits between the credential issuer and the wallet that receives the credential. The issuer defines how a wallet can request issuance, what parameters must be satisfied, and how the resulting credential is packaged or delivered. That makes the protocol closer to a transaction model than a static file transfer.
This structure matters because issuance is where trust is established. The protocol has to support issuer policy, wallet capability, and the data needed to create a credential that can later be presented or verified in other systems. OpenID Connect Core 1.0 is relevant as a neighbouring identity specification because many implementations in this ecosystem borrow familiar identity concepts and layered trust patterns.
OpenID4VCI is not the same thing as presentation or verification. Its role is issuance only, so the design questions are about who can request a credential, how the issuer validates that request, and how the issued credential is handed off safely.
Security and trust implications
The protocol’s security properties depend on the issuer correctly binding a request to the intended wallet and ensuring that the credential is only issued under the right conditions. If those checks are weak, an attacker can try to obtain credentials illegitimately, redirect issuance, or exploit weak issuer policy enforcement.
Because the credential often becomes a portable proof of some real-world claim, compromise at issuance can have downstream effects far beyond the issuance transaction itself. A weak issuance path can undermine trust in the credential even if later verification logic is strong.
For implementation teams, the key security question is not just whether issuance works, but whether the issuer, wallet, and transport flow preserve integrity, authenticity, and the correct recipient binding throughout the exchange.
Where OpenID4VCI fits in the verifiable credentials stack
OpenID4VCI is one part of a broader verifiable credentials architecture. It connects the credential lifecycle at the point of creation to later use cases where a wallet presents proofs to relying parties. In practice, this makes it a foundational interoperability layer for digital identity programmes that need repeatable issuance across issuers and wallet vendors.
It also helps organisations avoid one-off issuance APIs that lock them into a single implementation. Standardised issuance can simplify multi-issuer environments, reduce wallet fragmentation, and make it easier to govern issuance policy consistently across use cases.
For readers comparing adjacent standards, a useful mental model is that OpenID4VCI handles getting the credential into the wallet, while other protocol layers handle what the wallet later proves. That distinction is important when designing identity systems that must support both controlled issuance and portable verification.
Risk and Threat Considerations
OpenID4VCI creates a high-value trust boundary because issuance determines whether a wallet receives a credential at all, and with what claims attached. Weak client binding, poor issuer validation, or misconfigured issuance policies can let an attacker obtain a credential that should never have been minted, or cause a credential to be delivered to the wrong recipient.
Failure mechanism: An attacker abuses the issuance flow by replaying requests, exploiting weak wallet or client authentication, or leveraging an issuer integration flaw to obtain an issued credential under false pretences.
Impact: The resulting credential may be accepted as legitimate by downstream systems, turning a single issuance weakness into broader identity fraud, trust compromise, or unauthorised access to services that rely on the credential.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-63, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Covers issuer, authenticator, and trust decisions for digital credential issuance. |
| Recommendation — Apply phishing-resistant identity and binding practices to issuance flows and credential lifecycle decisions. | ||
| NIST SP 800-53 Rev 5 | IA-8 — Identification and Authentication (Non-Organizational Users) | OpenID4VCI issues credentials to wallets used by external users and verifiers. |
| Recommendation — Use IA-8 controls to validate external user identity before issuing credentials. | ||
| OWASP ASVS | V10 — OAuth and OIDC | OpenID4VCI builds on OpenID/OAuth-style request and token exchange patterns. |
| Recommendation — Verify issuer and wallet flows against OAuth and OIDC security requirements. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Wallet and issuer authentication are central to secure credential issuance. |
| NHI-05 — Overprivileged NHI | Issuance clients and issuer components can be overprivileged in credential workflows. | |
| Recommendation — Harden issuer-to-wallet authentication to prevent unauthorized credential issuance. Restrict issuance component privileges to the minimum needed for credential minting and delivery. | ||
Practitioner Guidance
Why practitioners should care: OpenID4VCI is only as trustworthy as the issuance policy and recipient-binding controls behind it. Treat the issuance flow as a security boundary, not a convenience API, because mistakes here can invalidate every credential produced by the issuer.
What to watch for: Pay close attention to how the issuer authenticates the wallet, how client settings are established, and whether issuance is narrowly scoped to the intended credential type and recipient. Inconsistent handling across issuers is often the first sign that interoperability is outpacing governance.
Practitioner takeaway: Standardisation reduces integration friction, but it does not remove trust decisions. The protocol should be implemented so that every credential issuance event is intentional, bound to the right party, and auditable in practice.
