Category: credential-presentation standard / verifier-request control plane / wallet-and-verifier interoperability middleware / identity-control-plane specification
Summary: OpenID4VP is best understood not as just another verifiable-credentials spec or generic wallet login flow, but as a concrete presentation control plane that decomposes how a verifier asks for credentials, how a wallet is invoked, how claim requirements are expressed, how responses are delivered, and how verifier trust gets signaled back to the holder. The specification defines an OAuth-based protocol for requesting and receiving credential presentations across same-device, cross-device, and Digital Credentials API flows, but the more durable analytical value is the way it separates verifier query construction, request transport, client identifier policy, wallet metadata, verifier metadata, verifier attestation, direct-post response handling, encryption, and conformance profiling into distinct layers. That makes OpenID4VP a useful comparison point for OpenID4VCI, walt.id, OpenID4VC ecosystem profiles, passport-style proof containers, and verifier SDK stacks: many systems talk about credential presentation as one app feature, while OpenID4VP makes the verifier-side control surface itself legible as reusable infrastructure.
What it does:
Defines an OAuth-2.0-based protocol for requesting and delivering presentations of credentials, including W3C VC, ISO mdoc, and SD-JWT VC formats
Introduces the vp_token response type so verifier requests return one or more credential presentations instead of an access token
Supports both same-device and cross-device presentation flows, including QR-mediated request handoff and direct HTTP POST return paths for larger or cross-device responses
Defines Digital Credentials Query Language (DCQL) so verifiers can ask for specific credential types, trusted issuers, claim subsets, and credential-set combinations instead of relying on a single opaque verifier request shape
Separates wallet invocation and transport choices across redirects, request_uri, response_uri, direct_post, direct_post.jwt, and Digital Credentials API-native flows
Adds verifier and wallet metadata surfaces, client identifier prefix rules, and a verifier attestation JWT media type so verifier identity and policy can be conveyed as part of the protocol itself
Anchors implementation maturity through OpenID Foundation working-group repositories, conformance tests for wallets and verifiers, and a self-certification program tied to HAIP and jurisdiction-specific profiles
Key claims:
OpenID4VP’s main analytical contribution is that it breaks credential presentation into explicit, reusable sub-layers. Query construction, wallet invocation, response transport, verifier authentication, selective disclosure, and metadata publication are all separate concerns instead of one wallet-vendor black box.
DCQL is one of the most important additions because it turns verifier demand into a first-class protocol surface. The verifier does not merely ask for a credential; it can define credential queries, trusted-authority constraints, claim selection, and credential-set logic. That makes verifier-side policy legible in a way many product-level credential stacks obscure.
The split between same-device redirect flows, cross-device QR / request_uri flows, and Digital Credentials API flows is analytically important because it shows that presentation is not only about credential formats. The invocation channel itself is a control surface, and different ecosystems can centralize power in browser APIs, QR bootstrap UX, wallet deep links, or hosted request-object endpoints.
Response handling is a real governance and trust layer here, not just transport plumbing. direct_post, direct_post.jwt, response encryption, response URI validation, and replay protections determine what a verifier can safely request and how much sensitive presentation data can traverse ordinary web infrastructure.
Verifier metadata, client identifier prefixes, and verifier attestation JWTs matter because they expose verifier legitimacy as a protocol concern instead of leaving it entirely to browser PKI, wallet allowlists, or bespoke app trust heuristics. That makes OpenID4VP a useful comparison point for WalletConnect Verify, OpenID4VC profiles, and other request-origin trust systems.
The specification’s privacy section is analytically valuable because it makes minimization pressure explicit: user consent, purpose legitimacy, selective disclosure, verifier-to-verifier unlinkability, and trust in issuers are all treated as part of the presentation layer rather than external policy gloss.
OpenID4VP is intentionally a framework that requires profiling to achieve interoperability. That is a feature worth retaining in the corpus because it means real control can shift from the base spec into HAIP-style profiles, conformance suites, and jurisdiction-specific deployment packages.
OpenID4VP belongs in the active corpus because it helps separate credential syntax from verifier query power, wallet invocation policy, verifier trust signaling, and response-delivery design — layers that many identity stacks quietly collapse together.
Whitepaper: No standalone whitepaper surfaced in this pass. The strongest primary materials were the OpenID Foundation specification, the OpenID4VC specifications index, the OpenID4VP working-group repository, the official conformance-testing guide, and the OpenID Foundation self-certification announcement collected in ../../whitepapers/openid4vp-primary-sources-2026-05-15.md.
Reusable lens: if a stack claims to solve credential presentation, ask whether the decisive leverage sits in query construction, wallet invocation, verifier attestation, or transport profiling.