OpenID4VCI is the issuance flow for getting a verifiable credential into a wallet, while OpenID4VP is the presentation flow for sending a credential or proof from a wallet to a verifier. The first covers credential acquisition, issuer metadata, and binding; the second covers request handling, consent, and proof presentation.
Credential issuance versus credential presentation
OpenID4VCI and OpenID4VP sit on opposite sides of the verifiable credential lifecycle. OpenID4VCI is about getting a credential into a wallet from the issuer, while OpenID4VP is about taking a credential or proof out of a wallet for a verifier. That difference changes who starts the flow, what metadata is needed, and where consent and trust checks happen.
OpenID4VCI is the acquisition path. The issuer publishes enough information for the wallet to discover how to request a credential, what format will be issued, and how the credential is bound to the holder. OpenID4VP is the disclosure path. The verifier sends a request that the wallet evaluates before producing a presentation or proof, often with selective disclosure rules and context-specific consent.
That split matters operationally because the two flows solve different problems. Issuance is concerned with onboarding, credential offer handling, binding, and how the wallet proves it is the intended recipient. Presentation is concerned with request validation, user consent, and limiting what the verifier learns from the wallet.
Why the trust model changes between the two flows
In OpenID4VCI, the wallet must trust the issuer’s metadata and issuance process enough to accept a credential into its local store. In OpenID4VP, the verifier must trust that the wallet can respond to a request without revealing more than the user intended. That means the security focus moves from credential delivery integrity to proof generation integrity.
OpenID4VCI also tends to involve stronger binding questions, because the issuer needs confidence that the credential is going to the right wallet or holder. OpenID4VP shifts the emphasis to proof freshness, audience restriction, and the verifier’s ability to validate the presentation in context. The same credential can participate in both flows, but the control point is not the same.
Verifiable Credentials Guide is the most complete starting point when you want to place both flows inside the wider credential ecosystem, including selective disclosure, DIDs, status data, and presentation patterns.
Where implementations go wrong in practice
The most common mistake is treating issuance and presentation as mirror images. They are not. An issuance integration that works well for onboarding can still fail at presentation if the verifier request model is weak, if the wallet cannot validate the request cleanly, or if consent is handled as a UI afterthought rather than a security decision.
Another frequent error is assuming that credential possession alone is enough. In OpenID4VCI, the issue is not only whether the credential was issued, but whether it was bound correctly and can be stored safely. In OpenID4VP, the issue is not only whether a proof was produced, but whether the verifier asked for the right thing and whether the wallet disclosed only what was necessary.
For teams building both sides, the interfaces are different enough that they should be tested separately. Issuer metadata, wallet attestation, and issuance errors belong in one test path; request validation, presentation integrity, and consent handling belong in another. Collapsing them into a single “VC integration” test usually hides the failure mode that matters most.
OpenID for Verifiable Credential Issuance Guide helps when you are validating issuer-side flows, while OpenID for Verifiable Presentations Guide is the better reference for verifier-side request handling and wallet response behaviour.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-63 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | VC issuance and presentation rely on identity proofing, binding and authenticators. |
| Recommendation — Apply the identity assurance guidance to validate proofing, binding and replay-resistant presentation. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Wallet binding and proof flows depend on secure credential lifecycle and authenticators. |
| Recommendation — Manage credential issuance, storage, rotation and revocation as controlled authenticator lifecycle events. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Both flows expose request and response handling where weak authentication breaks trust. |
| Recommendation — Validate request authentication and binding before accepting issuance or presentation messages. | ||
Practitioner Guidance
What to verify: Treat the two flows as separate security boundaries. For issuance, verify offer discovery, issuer metadata, binding, and wallet storage assumptions. For presentation, verify request authenticity, consent handling, audience restriction, and whether the verifier can validate what was disclosed without over-collecting.
Decision rule: If the problem is “How does the wallet get the credential?”, you are in OpenID4VCI. If the problem is “How does the wallet prove something to a verifier?”, you are in OpenID4VP. Do not try to solve one by copying controls from the other, because the failure conditions are different.
Practitioner takeaway: The clean mental model is issuance in, presentation out, and the hard part is not the credential itself but the trust and consent mechanics on each side of the wallet.
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org