OpenID for Verifiable Presentations lets a verifier request a verifiable presentation from a holder through an OpenID-style flow. The holder’s wallet returns signed proof that can be checked against issuer trust and presentation rules, so teams should verify audience binding, nonce use, credential freshness and revocation status.
How OpenID for Verifiable Presentations fits into the issuer-holder-verifier model
OpenID for Verifiable Presentations, often called OpenID4VP, is the request-and-response layer that lets a verifier ask a holder’s wallet for a verifiable presentation in a familiar OpenID-style flow. The verifier does not receive raw credentials by default, it receives signed proof that can be checked against the issuer’s trust and the presentation rules that were requested.
The useful mental model is: the verifier expresses what it needs, the wallet decides what it can disclose, and the returned presentation proves control and validity without turning every interaction into a bespoke integration. That is why teams usually pair OpenID4VP with the broader OpenID and verifiable credentials stack, including OpenID Connect Core 1.0 and the NHIMG Verifiable Credentials Guide.
In practice, OpenID4VP is about packaging trust signals into a presentation the verifier can evaluate consistently. The holder’s wallet may satisfy only part of the request if the presentation definition allows selective disclosure, but it still has to satisfy the verifier’s audience binding and anti-replay requirements before the proof is useful.
What the verifier asks for, and what the wallet proves
The verifier begins by describing the evidence it needs, such as a credential type, a claim set, or a format it can process. The holder’s wallet then builds a presentation from one or more credentials and returns it with cryptographic proof. In a well-formed flow, the verifier can check that the response was meant for this request, not copied from another session, and that the credential still satisfies the policy in force.
This request-response shape matters because it separates intent from proof. The request defines the presentation rules, while the returned object proves possession or control in a way the verifier can validate. The NHIMG OAuth 2.0 and OpenID Connect Guide for Identity Teams is useful background here because OpenID4VP inherits the same discipline around state, redirects, tokens, and audience-sensitive responses, even though the payload is a verifiable presentation rather than a standard login assertion.
That same pattern is why the verifier should treat presentation formatting as security-relevant, not cosmetic. If the wallet can answer any request without binding it to the original verifier, the flow stops being a trust exchange and becomes an easy replay target.
Which checks make an OpenID4VP exchange trustworthy
The security of the flow usually turns on a short list of checks. Audience binding tells the verifier that the presentation was minted for this verifier. Nonce use prevents replay. Credential freshness limits the value of old but still technically valid proofs. Revocation or status checking helps the verifier avoid trusting a credential that should no longer be accepted.
Teams should also care about presentation rules, because they define what the wallet is allowed to reveal and what the verifier is actually allowed to require. If those rules are too loose, the verifier may accept overbroad disclosures. If they are too strict, valid users may fail even when they hold a good credential. The NHIMG NHI Authentication Guide is relevant because the same questions appear whenever a non-human or wallet-mediated actor authenticates through tokens, certificates, or delegated trust.
Risk and Threat Considerations
OpenID4VP moves trust into a narrow protocol exchange, so the main risks are replay, weak audience binding, stale credentials, and overly permissive presentation requests. If any of those break down, a verifier may accept a proof that is valid in format but invalid in context, which is exactly how phishing, relay, and credential-substitution attacks gain traction.
Failure mechanism: An attacker reuses a presentation outside its intended audience, injects a forged or stale response, or tricks the wallet into revealing more than the verifier should see.
Impact: The verifier can grant access, issue assurance, or make a business decision on a proof that does not actually establish the right holder, the right moment, or the right claims.
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, OWASP ASVS 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 | Covers phishing-resistant authentication and assertion assurance for presentation-based identity flows. |
| Recommendation — Apply 800-63 assurance checks to validate binding, freshness, and replay resistance before trusting a presentation. | ||
| OWASP ASVS | V10 — OAuth and OIDC | OpenID4VP builds on OpenID/OAuth-style request and response handling with redirect and state security. |
| Recommendation — Enforce OIDC request integrity, state handling, and redirect protections in the presentation flow. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential freshness, revocation, and lifecycle checks are central to trusting wallet-issued proofs. |
| Recommendation — Manage credential lifecycle and revocation so stale or compromised proofs are not accepted. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The flow depends on strong holder authentication and proof binding, not just a signed payload. |
| Recommendation — Require strong holder authentication and proof binding before accepting a verifiable presentation. | ||
Practitioner Guidance
What to verify: Make audience binding and nonce handling non-negotiable, then confirm that your verifier rejects responses that are valid cryptographically but wrong for the current transaction. If the request can be replayed or the response can be detached from its session context, the flow is not yet safe enough for production reliance.
Decision rule: If the credential is time-sensitive or revocable, require status and freshness checks before you accept the presentation as an access decision input. If your use case tolerates stale assertions, document that exception explicitly, because the business risk is no longer just authentication, it is trust in old proof.
Practitioner takeaway: OpenID4VP works when the verifier is strict about context and the wallet is selective about disclosure; most implementation failures come from treating a signed presentation as automatically trustworthy without checking who it was for and whether it is still current.
Related resources from NHI Mgmt Group
- OpenID for Verifiable Presentations (OID4VP)
- How should scheme operators govern OpenID for Verifiable Credentials implementations?
- Why do verifiable credentials change trust assumptions compared with SAML or OpenID Connect?
- How do OAuth 2.0 and OpenID Connect authentication and authorisation flows work?
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 October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org