OpenID4VP explained: how a wallet presents credentials

OpenID4VP, short for OpenID for Verifiable Presentations, is the standard that governs how a digital wallet shows credentials to a service. A verifier, for instance an online shop that needs an age check, sends a request describing the attributes it needs. The wallet asks the user for consent, prepares a signed proof containing only those attributes, and returns it. The verifier validates the proof and continues.

What OpenID4VP is for

Today, proving something online usually means uploading a photo of an ID card, giving away far more data than necessary. OpenID4VP replaces that with a precise exchange: the service asks for specific facts, the user sees what is requested, and the wallet shares only those facts, backed by a cryptographic signature from the original issuer. The concept of such credentials is explained in verifiable credentials.

OpenID4VP is developed by the OpenID Foundation’s Digital Credentials Protocols working group. The final text is available at openid.net/specs. openideurope.eu is an independent guide and not affiliated with the Foundation.

The roles

Role	What it does	Example
Holder	The person with the wallet	You
Wallet	Stores credentials, asks for consent, creates presentations	The EU Digital Identity Wallet app
Verifier (relying party)	Requests and checks the presentation	An online shop, a bank, a car-rental desk
Issuer	Originally signed the credential	A government agency, a bank

The verifier is what other standards call a relying party. Credentials reach the wallet through OpenID4VCI.

How a presentation works, step by step

1. The user starts at the verifier, for example “Verify my age” on a website.
2. The verifier builds an authorisation request. It includes a query in DCQL (Digital Credentials Query Language), a JSON format that names the credential types and attributes wanted, plus a nonce and information about itself.
3. The request reaches the wallet in one of three ways: a redirect on the same phone, a QR code scanned from a computer (cross-device), or the browser’s Digital Credentials API, which lets a web page ask the operating system for a credential.
4. The wallet checks who the verifier is, shows the user a consent screen listing the requested attributes, and asks for confirmation with biometrics or a PIN.
5. The wallet creates a presentation: the credential with only the approved attributes revealed, plus a signature by the user’s key over the nonce and the verifier’s identity. This proves the credential is held by the user and is meant for this verifier.
6. The wallet returns the result as a vp_token. For cross-device flows it is posted to the verifier’s server, optionally encrypted.
7. The verifier checks the issuer signature, the holder binding, the nonce, the expiry and the revocation status, and then accepts or rejects.

A simplified query asking only for an age confirmation might look like this (illustrative):

{
  "credentials": [{
    "id": "age_proof",
    "format": "dc+sd-jwt",
    "claims": [{ "path": ["age_equal_or_over", "18"] }]
  }]
}

Everyday examples

• A website confirms you are over 18 without learning your name or birth date, see EU age verification.
• A bank opens an account after you share name, address and tax number from your wallet, instead of a video call.
• A car-rental desk checks a mobile driving licence at the counter.
• A university checks a diploma credential for an application.

Security aspects

• Verifier identity. The wallet should show who is asking. The protocol supports several ways to identify a verifier, for example with X.509 certificates, and in the EU, relying parties are meant to register and receive certificates that wallets can check. This is a defence against fake verifiers that ask for too much.
• Holder binding and freshness. The presentation is signed over a verifier-supplied nonce, so a copy cannot be replayed elsewhere.
• Data minimisation. Selective disclosure keeps unrelated attributes private. See EU wallet privacy for what that does and does not guarantee.
• Encrypted responses. For cross-device and backend flows, responses can be encrypted to the verifier.
• Cross-device phishing. A QR code can be shown by an attacker. Wallets and verifiers add checks, such as proximity or origin binding in the Digital Credentials API, to reduce this risk.
• Over-asking. A legitimate-looking verifier may request more than needed. Read the consent screen, and expect regulation and wallet design to push back on this.

Status and versions

OpenID for Verifiable Presentations 1.0 was approved by the OpenID Foundation’s membership as a Final Specification in July 2025. It defines the request and response, DCQL, response modes such as direct_post, and the Digital Credentials API integration. It works with W3C Verifiable Credentials, ISO mdoc and IETF SD-JWT VC. Higher-level profiles, for example the OpenID4VC High Assurance Interoperability Profile, narrow the options for high-assurance use such as government ID. Earlier drafts used different names, for example presentation_definition instead of DCQL, which matters when reading older examples.

How it relates to the other standards

OpenID4VP reuses OAuth 2.0 request and response ideas, see OAuth 2.0 explained. It is the counterpart of OpenID4VCI: issuance in, presentation out. The credential formats it carries are described in SD-JWT and mdoc and ISO 18013-5. Unlike OpenID Connect, no central login provider sits in the middle: the issuer is not told when you present your credential.

Role in the EUDI Wallet

OpenID4VP is the main online presentation protocol of the EU Digital Identity Wallet. The Commission’s implementing rules on wallet protocols and interfaces (Regulation (EU) 2024/2982, see EUR-Lex) and the Architecture and Reference Framework point to OpenID4VCI and OpenID4VP for exchanging credentials. In person, the wallet can also use the ISO 18013-5 proximity flow. Member states are expected to offer wallets by the end of 2026, so verifiers, from banks to shops, are already building OpenID4VP support.