OpenID4VP is not merely a credential-format or wallet-login effort. The core spec defines an OAuth-based protocol for requesting and receiving credential presentations across multiple credential families, including W3C VC, ISO mdoc, and SD-JWT VC.
The most important structural contribution is the decomposition of presentation into separate protocol surfaces: verifier queries, wallet invocation, request-object transport, response delivery, encryption, verifier metadata, wallet metadata, verifier attestation, and conformance profiling are all first-class parts of the stack.
The spec’s same-device and cross-device flows are analytically important because they show that presentation transport is not incidental UX. Request transport, QR/bootstrap behavior, request_uri hosting, and direct-post response handling are part of the protocol’s real control plane.
DCQL is one of the clearest reasons this entry belongs in the corpus. It makes verifier demand explicit by defining credential queries, trusted-authority constraints, claims queries, and credential-set logic instead of collapsing verifier policy into an opaque application-defined request format.
The vp_token response type matters because it reorients an OAuth transaction away from API access-token issuance and toward the return of one or more presentations. That keeps presentation as a transport/governance problem distinct from ordinary login or API delegation.
Verifier metadata, client identifier prefix handling, and verifier attestation JWT support make verifier legitimacy a first-class protocol surface. That is important because many real deployments otherwise move verifier trust into wallet allowlists, browser trust cues, or app-specific heuristics.
The privacy/security sections are part of the mechanism, not just boilerplate. The spec explicitly surfaces replay prevention, response URI protection, selective disclosure, verifier-to-verifier unlinkability, purpose legitimacy, issuer trust, and conformance testing as requirements for safe presentation.
The OpenID Foundation materials make it clear that OpenID4VP is already operating inside an implementation-governance environment: wallets and verifiers have conformance tests, HAIP-coupled test plans, and a 2026 self-certification path tied to jurisdiction-specific deployment profiles.
Specific source signals worth retaining
The main 1.0 specification page and the raw WG draft show the architectural split clearly: vp_token, same-device versus cross-device flows, request_uri, direct_post, direct_post.jwt, DCQL, wallet metadata, verifier metadata, verifier attestation JWT, and Digital Credentials API integration are all explicit sections rather than secondary notes.
The raw 1.0 working-group draft is especially useful because it spells out the cross-device QR / request-object flow and makes the profiling requirement unusually explicit: OpenID4VP is a framework that still expects ecosystems to constrain optional features and parameter values.
The OpenID4VC specifications index is the best compact source for situating OpenID4VP inside the broader OpenID4VC family and for seeing how OIDF treats the specs as a maintained package rather than isolated PDFs.
The OpenID4VP repository README is the clearest source for implementation-adjacent maturity signals: actively maintained 1.0 and 1.1 WG drafts, public draft builds, and a dedicated conformance-testing path for wallets and verifiers.
The conformance-testing guide is a strong signal that interoperability is being operationalized through concrete test-plan expectations for response modes, client ID schemes, credential formats, request methods, and same-device versus cross-device behavior.
The February 2026 self-certification announcement is the best primary source for the governance/adoption layer: OIDF positions OpenID4VP 1.0 plus HAIP 1.0 as infrastructure already selected across dozens of jurisdictions, with open-source tests, CI integration, published certification results, and localized profiling paths.
Why this entry belongs in the corpus
It gives the corpus a standards-level baseline for the presentation phase beneath credential wallets, verifier SDKs, passport-proof containers, and region-specific digital-ID rollouts.
It strengthens the identity cluster by isolating a frequently flattened layer: verifier-side query design, wallet invocation, verifier trust signaling, and response-delivery policy are not the same thing as credential issuance or credential syntax.
The durable insight is that presentation ecosystems can centralize power in query languages, verifier-authentication policy, request-object hosting, transport profiles, and conformance packages rather than in the credential object alone. OpenID4VP makes those seams unusually visible.