Protocols
OpenID for Verifiable Presentations (OpenID4VP)
OpenID for Verifiable Presentations, or OpenID4VP, is the protocol a verifier uses to ask a wallet for credentials and receive the presentation back. It is format neutral: the same exchange carries SD-JWT VC and ISO mdoc, and it is what the EU Digital Identity Wallet uses.
Also called: OpenID4VP, OID4VP, verifiable presentation
At a glance
- Spec
- OpenID for Verifiable Presentations 1.0
- Format-neutral
- Carries SD-JWT VC and ISO mdoc alike
- Query language
- DCQL, the Digital Credentials Query Language
- Client identifier
- x509_san_dns: the request host must match the certificate
- Wallet checks first
- Reader authentication happens before the consent screen
The shape of an exchange
The verifier builds a presentation request: what it wants, who it is, where to send the answer, and a nonce that ties the response to this request and no other. The request is signed, and the wallet fetches it, and does not trust a request handed to it directly. The user is shown what is being asked for and by whom, approves or declines, and the wallet posts the presentation back to the response endpoint.
Because the request is signed and its signing certificate travels with it, the wallet can decide whether to answer before showing anything to the user. That ordering is the important part: authentication of the asker happens before the consent screen, not after.
What the wallet checks before it answers
A production wallet does not release data to whoever asks politely. It reads the signing chain from the request, checks it against the access-certificate providers it trusts, and confirms the certificate covers the hostname the request came from. If any of that fails, it refuses before the user is involved at all.
This is the step that surprises people building against a sandbox. The protocol works end to end, the request parses, and then a real wallet says no, because the development certificate is not one it trusts. That refusal is the wallet behaving correctly.
Response encryption and why it matters
The response can be encrypted to a key the verifier publishes in the request metadata, which keeps the presented attributes from being readable in transit or by anything sitting between the wallet and the verifier. For a check that deliberately reveals as little as possible, leaving the response in the clear would undo some of the point.
Practically, a wallet needs client metadata in the request to know which key to encrypt to, so an omitted or malformed metadata block is a common reason a wallet declines a request that otherwise looks fine.
Why it matters
If a real wallet refuses your request while your sandbox accepts it, look at reader authentication before looking at your code. The usual answer is that your signing certificate isn't one the wallet trusts.
The nonce and the response endpoint are what stop a presentation being replayed elsewhere. Treat them as security parameters rather than plumbing.
Frequently asked
Is OpenID4VP the same as OpenID Connect?
No, though it comes from the same community. OpenID Connect is about logging in with an identity provider. OpenID4VP is about a wallet presenting credentials it already holds, with no identity provider in the loop at the moment of presentation.
Does the verifier need to be online with the issuer?
No, and that's a large part of the appeal. The credential was signed when it was issued; verifying it needs the issuer's key and trust list, not a live call to the issuer.
Can I test without a real wallet?
Yes, against a sandbox or a reference wallet, and most integration work can be done that way. What you can't test without a trusted access certificate is a real wallet completing the exchange.
Primary sources
This is a plain language explanation, not legal advice. Specifications and dates in this area move, so check anything you are going to rely on against the primary sources.
Keep reading
Age verification API
Or skip the theory and build against it
Tessio proves someone is over 18 from their EU Digital Identity Wallet and stores no personal data. Access is invite only while we onboard design partners. Tell us what you're building.