Wiki · Concept · Last reviewed June 25, 2026

OpenID for Verifiable Presentations

OpenID for Verifiable Presentations, often shortened to OpenID4VP, is the OpenID Foundation protocol for requesting credentials from a wallet and returning presentations to a verifier.

Category: Concept Updated: June 25, 2026 Tags: digital identity, wallets, verifiable credentials, OAuth, AI governance

Definition

OpenID for Verifiable Presentations 1.0 is a Final specification from the OpenID Foundation's Digital Credentials Protocols workgroup, published on July 9, 2025. The specification defines a protocol for requesting and presenting credentials.

OpenID4VP is not a credential format and not a wallet by itself. It is the exchange layer between a verifier that asks for evidence and a wallet that can return a presentation. The protocol is built on OAuth 2.0 concepts, but the thing returned is not an OAuth access token. The signature move is the response type vp_token, a container that can carry one or more presentations.

The W3C Verifiable Credentials Data Model v2.0 supplies the broader issuer-holder-verifier vocabulary: issuers make claims, holders control credentials, and verifiers evaluate presentations. OpenID4VP gives that model a web and app protocol path.

Protocol Flow

In a same-device flow, the verifier sends an authorization request to the wallet. The request can include a Digital Credentials Query Language query that describes what credential type, format, or claim set the verifier wants. The wallet checks whether matching credentials are available, authenticates the end user, gathers consent, prepares the presentation, and sends an authorization response containing the vp_token.

The specification also covers cross-device use. A verifier can render a request as a QR code; the holder scans it with a wallet on another device, and the wallet can respond using a direct HTTP POST response mode such as direct_post. That pattern matters for kiosks, desktop-to-phone flows, and in-person checks.

OpenID4VP is credential-format agnostic. The specification names W3C Verifiable Credentials Data Model credentials, ISO mdoc credentials, and IETF SD-JWT VC credentials as examples, and it lets deployments define format-specific parameters. Interoperability still requires profiles for optional features, response protections, credential formats, trust frameworks, and metadata conventions.

Relation to Issuance

OpenID4VP handles presentation. OpenID for Verifiable Credential Issuance 1.0, published as a Final specification on September 16, 2025, handles issuance. OID4VCI defines an OAuth-protected API through which a wallet can request and receive verifiable credentials from a credential issuer. Its credential issuer API includes a mandatory Credential Endpoint and optional mechanisms such as a Nonce Endpoint, deferred issuance, credential offers, and issuer metadata.

Digital Credentials API

The W3C Digital Credentials Working Draft dated June 26, 2026 describes a browser API for mediating presentation and issuance requests through user agents. That W3C draft references OpenID4VP as a presentation protocol and describes OpenID4VP over the Digital Credentials API path. OpenID4VP itself includes a section for use with the Digital Credentials API, including signed and unsigned requests, expected origins for signed requests, and response modes such as dc_api and dc_api.jwt.

This creates a layered architecture. W3C Digital Credentials is the browser mediation surface. OpenID4VP is an exchange protocol. A VC, mdoc, or SD-JWT VC is the credential format. Trust frameworks, issuer policy, verifier authorization, retention, and appeal still live around those layers.

Agent Context

For AI agents, OpenID4VP is a concrete place where delegation meets identity. A browser agent, procurement assistant, travel assistant, benefits navigator, school-service bot, or compliance workflow might encounter a verifier asking for age, license status, professional authorization, citizenship attribute, student status, or organizational authority. The technical request may be well formed while the delegation is not.

Agent systems should treat a presentation request as a high-friction event. The wallet owner needs to know who is asking, what claims are requested, why they are needed, whether the request is signed, and what the verifier will retain. An agent can help interpret the request, but it should not silently present credentials unless a narrow policy has already authorized that disclosure class.

Governance Risks

The first risk is over-requesting. A verifier may ask for a whole credential when a yes-or-no attribute would do. The second risk is correlation: reused identifiers, repeated claims, wallet metadata, verifier metadata, or consistent response patterns can let separate verifiers connect a person's activity. The third risk is verifier legitimacy. A request can be syntactically valid while the requester has no reasonable authority to demand the credential.

The fourth risk is audit confusion. OpenID4VP specifies protocol behavior, not the whole institution. It does not decide which issuer is trusted, which verifier is allowed, what counts as consent, how long disclosures are retained, or how a person contests harmful use.

Governance Pattern

Source Discipline

Claims about OpenID4VP should name the specification version, credential format, response mode, trust framework, wallet behavior, and verifier metadata. Do not collapse OpenID4VP into OpenID Connect login, OID4VCI issuance, W3C Verifiable Credentials, or the W3C Digital Credentials API. They are connected layers, not synonyms.

Spiralist Reading

Spiralism reads OpenID4VP as an identity ceremony written in protocol form. The hopeful version lets a person prove less, more precisely, with a visible request and a real chance to refuse. The dangerous version makes every threshold ask for a wallet. Machine-mediated life needs protocols that slow identity disclosure down enough for judgment to enter.

Open Questions

Sources

Return to Wiki