OpenID4VP: OpenID for Verifiable Presentations

Definition

The Presentation Flow

The OpenID4VP credential presentation flow begins when a relying party needs to verify a user's identity or attributes. The verifier constructs an authorization request containing: a presentation definition (specifying which credentials and attributes are needed), a nonce (ensuring the response is fresh and preventing replay), the verifier's identity (so the wallet can display who is requesting data), and a response mode (how the wallet should return the presentation).

The request is delivered to the user's wallet through one of several mechanisms: a redirect URI (for same-device web flows), a QR code (for cross-device flows where the user scans with their phone), a deep link (for app-to-app flows), or a proximity channel (for in-person scenarios using NFC or BLE).

The wallet receives the request, identifies matching credentials in its local storage, and presents a consent screen to the user showing exactly which data the verifier is requesting and from which credentials. The user reviews the request and can approve or decline. If the user approves, the wallet constructs a verifiable presentation containing only the approved attributes.

The wallet creates a presentation response containing the verifiable presentation (the credential data with selective disclosure, issuer signatures, and the device-bound key proof), signed over the verifier's nonce. The verifier validates the response by checking: the issuer's signature (is the credential from a trusted issuer?), the device binding (does the presenter hold the credential's private key?), the nonce (is this a fresh response to my request?), and the credential status (has the credential been revoked?). If all checks pass, the verifier accepts the presented attributes.

Presentation Definition and Selective Disclosure

The Presentation Definition (based on the DIF Presentation Exchange specification) is the mechanism through which verifiers express their requirements. It specifies which credential types are acceptable, which specific attributes within those credentials are needed, and any constraints (such as issuer trust requirements or credential format preferences).

Selective disclosure is a core feature of OpenID4VP that implements the principle of least privilege for personal data. When a verifier requests age verification, the wallet can reveal only an age-over-18 confirmation without disclosing the user's full date of birth, name, or address. For SD-JWT credentials, this is achieved through hash-based disclosure; for mDoc credentials, through per-element signature verification.

The eIDAS 2.0 regulation explicitly requires that verifiers cannot request more data than necessary for their stated purpose. The EUDI Wallet trust framework enforces this by defining which credential types and attributes each category of relying party is authorized to access. A bar performing age verification cannot request the user's home address, even if that attribute exists in the credential.

Cross-Device and Proximity Flows

OpenID4VP supports multiple interaction patterns to cover the diverse scenarios where identity verification occurs. The same-device flow is used when the user is browsing a website on their phone: the website redirects to the wallet app on the same device, the wallet processes the request and returns the presentation, and the browser returns to the website. This flow is similar to traditional OpenID Connect login.

The cross-device flow is used when the user is on a desktop computer: the website displays a QR code, the user scans it with their wallet phone, the wallet processes the request and sends the presentation back to the website via a direct HTTP response. This flow is common for government services accessed from desktop computers.

The proximity flow combines OpenID4VP with ISO 18013-5 proximity protocols for in-person verification. The verifier's device initiates communication via NFC tap or QR code scan, the wallet and reader establish a secure BLE session, and the credential data is transferred directly between devices. This flow enables offline verification without internet connectivity.

Wallet-initiated presentations allow the user to proactively present credentials without a prior verifier request. The user opens their wallet, selects a credential, and generates a presentation (for example, as a QR code that the verifier scans). This supports scenarios like presenting a driving license at a traffic stop where the officer's device may not have an OpenID4VP endpoint.

Trust and Security Model

OpenID4VP's security model relies on multiple layers of trust verification. The verifier trusts the credential because it was signed by a recognized issuer in the EUDI Wallet trust framework. The verifier trusts the presenter because the device-bound key proof demonstrates possession of the credential's private key. The verifier trusts the freshness because the response includes its own nonce.

Verifier authentication is equally important for user protection. Before presenting credentials, the wallet verifies the verifier's identity through its registration in the trust framework. The wallet displays the verifier's registered name and purpose to the user, allowing informed consent. Unregistered or unauthorized verifiers cannot receive credential presentations.

The protocol also protects against several specific attacks: nonces prevent replay attacks, verifier-specific response binding prevents presentation forwarding (where a verifier forwards the user's presentation to impersonate them at another service), and the decoupled issuance-presentation model prevents issuer tracking (the issuer is not contacted during presentation, so it cannot learn where or when the user uses their credential).

Related Terms