Category: credential-presentation data model / verifier-request grammar / transport-agnostic proof-selection middleware / identity-control-plane specification
Summary: Presentation Exchange is best understood not as a wallet app, credential format, or end-user login flow, but as a lower-layer grammar for how verifiers describe proof requirements and how holders map submitted proofs back to those requirements. Its primary materials repeatedly emphasize that it is both claim-format agnostic and transport agnostic: the spec defines Presentation Definitions, Presentation Submissions, input descriptors, constraints, and submission requirements, while leaving QR handoff, OpenID, DIDComm, or other delivery protocols outside scope. That decomposition is the main reason it belongs in the corpus. It makes verifier-side request design legible as its own control plane beneath OpenID4VP, verifier SDKs, passport-style proof containers, and wallet UX layers, instead of flattening everything into one generic credential presentation bucket.
What it does:
Defines a Presentation Definition object that lets a verifier specify what claims, credentials, or proof-bearing artifacts it wants a holder to present
Defines a Presentation Submission object that lets a holder describe how its submitted proofs satisfy the verifier’s requested inputs
Uses input_descriptors, field constraints, filters, and optional submission requirements so a verifier can express required fields, acceptable formats, and allowed combinations of credentials rather than asking for one opaque blob
Stays claim-format agnostic as long as the material can be serialized as JSON, so the same request grammar can be used across VC, JWT-based, or other JSON-serializable claim systems
Stays transport agnostic, explicitly expecting other protocols such as OpenID, DIDComm, or QR / well-known retrieval flows to carry the request and return the response
Supports optional feature extensions such as holder-binding and relational constraints, making the base model extensible without forcing every consumer to implement every feature
Includes schema, test, sample-implementation, and playground material in the official repository, which makes the spec more than a conceptual paper
Key claims:
The spec’s most reusable insight is that verifier demand deserves its own structured object model. A verifier is not merely asking for a credential; it is publishing a machine-readable policy about what kinds of proofs count, which fields matter, and which combinations are acceptable.
The transport-agnostic design is analytically important because it keeps request grammar separate from wallet invocation and network delivery. That makes it a useful lower-layer comparison point beneath OpenID4VP and other presentation protocols that add redirects, response modes, metadata, or verifier attestation on top.
Submission Requirements are one of the strongest reasons to keep this spec explicit in the corpus. They let a verifier express combinatorial logic across requested inputs, which means real authority can sit in request composition rather than only in issuer lists or wallet UX.
The spec’s field constraints and path-based matching make selective disclosure and proof selection partly a verifier-authored query problem. That is a real control surface: whoever writes the Presentation Definition decides what becomes legible, acceptable, or rejectable.
The feature model matters because it exposes interoperability pressure directly. Conformant consumers do not have to support every feature, so practical interoperability can shift into ecosystem conventions, verifier assumptions, and profile-level expectations.
Presentation Exchange belongs in the active corpus because it gives the identity cluster a lower-bound request grammar beneath richer protocol stacks. Without it, many later systems would misleadingly collapse verifier query design, transport, wallet invocation, and credential syntax into one layer.
Whitepaper: No standalone whitepaper surfaced in this pass. The strongest primary materials were the DIF ratified specification and the official repository / README collected in ../whitepapers/presentation-exchange-primary-sources-2026-05-15.md.