What is OID4VP?
OpenID for Verifiable Presentations (OID4VP) is a protocol for a verifier to request credentials from a wallet and receive a presentation in response. It uses OpenID and OAuth request and response patterns, but the result is credential presentation data rather than an OAuth access token.
OID4VP defines the exchange. It does not define which issuers a verifier trusts, which credentials a service accepts, or what the service should do after validation. Those decisions come from the credential profile, trust configuration, and the relying party's own policy.
See the EUDI Wallet glossary for definitions of credential, presentation, issuer, holder, verifier, and related terms.
The verifier, wallet, and holder
- Verifier / relying party: creates a request for specific credentials or claims and validates the response.
- Wallet: receives the request, selects a matching credential if one is available, and presents it after the holder interaction required by its profile.
- Holder: reviews the request and can approve or decline the data sharing interaction.
The wallet and verifier need a compatible profile. OID4VP can carry different credential formats, but it does not make those formats or their trust models interchangeable.
A typical presentation flow
- The verifier creates an authorization request with its client identifier, a transaction nonce, and the requested credential formats and claims.
- The holder opens the request in a wallet. A cross-device flow commonly starts on a verifier's website and continues after scanning a QR code; same-device flows can open the wallet directly.
- The holder reviews the wallet's disclosure screen and approves or rejects the request.
- The wallet returns one or more presentations using the response mechanism supported by the profile.
- The verifier checks the response against the original request, validates each credential and its issuer trust, and applies its own decision policy.
The OID4VP 1.0 specification defines the request and response framework, including the vp_token response parameter. Credential-format profiles add the format-specific request fields and cryptographic checks.
What the verifier must bind and validate
The verifier should treat the presentation as untrusted input until every check passes. In particular, it must verify that the holder or device proof binds the presentation to the intended verifier and the current transaction. The proof mechanism depends on the credential format; the verifier checks it using the expected audience and nonce from the request.
The verifier must also check that each returned credential:
- matches a credential format and request that it supports;
- has a valid cryptographic signature or issuer proof;
- chains to an issuer or trust anchor accepted for this purpose;
- contains the requested claims and satisfies any status or validity checks required by the configured profile.
See OID4VP nonce and state validation for transaction binding details. state correlates a response with local application state; it does not replace cryptographic holder binding.
OID4VP needs an interoperability profile
The base protocol intentionally supports multiple credential formats and deployment patterns. Implementations need agreement on request transport, response mode, client identifier scheme, credential format and query language, signing or encryption requirements, trust, and error handling. Consequently, two products that both support OID4VP are not automatically interoperable for every request.
For implementation examples, continue with the DLBR API quickstart, the advanced OID4VP guide, and the guides for SD-JWT and ISO mdoc. See the EUDI Wallet overview for ecosystem roles and the OID4VP vs. OpenID Connect comparison for the difference between login and credential presentation. Visit the OID4VP verification API for DLBR's supported integration path.