OID4VP Explained for Builders

A service that needs evidence from a digital wallet has a deceptively difficult job. It must say what it needs, make clear who is asking, obtain a response that is fresh and intended for that service, and validate the evidence against a trust policy.

OpenID for Verifiable Presentations (OID4VP) provides the interaction model for that job. It adapts the familiar shape of an authorization request to credential presentation: the verifier is the client, the wallet plays the identity-provider role, and the response can carry verifiable credentials selected by the wallet.

The useful mental model is not “ask a wallet to send an ID.” It is:

A verifier sends a scoped request for evidence; a wallet returns a presentation that must be verified in the context of that specific request.

That distinction drives the protocol design, the privacy model, and the checks a production verifier needs.

The roles are familiar, but the payload is different

OID4VP has two main participants:

• The verifier, also called a relying party, requests evidence and makes the final decision.
• The wallet, acting for the holder, selects credentials and returns a presentation.

The verifier starts with an authorization request. The wallet evaluates the request, typically involves the holder in the approval decision, and responds with a vp_token containing the verifiable-presentation material.

This looks structurally similar to an OpenID Connect interaction, but the verifier is not merely receiving a profile response. It is receiving cryptographic evidence that must be checked for issuer authenticity, data integrity, presentation freshness, and intended audience.

Start with the question, not the credential

A verifier should begin by defining the decision it needs to make. Only then should it construct a request for the smallest set of credential data that supports that decision.

In OID4VP 1.0, the request for issuer-verified credentials is expressed with DCQL, the Digital Credentials Query Language, in the dcql_query parameter. A DCQL credential query can identify:

• a local identifier for the requested credential;
• an expected credential format, such as mso_mdoc or dc+sd-jwt;
• format-specific metadata, such as a document type or credential type; and
• the individual claims the verifier needs.

For example, a verifier can ask for a specific claim from a particular document type rather than asking the wallet to reveal every available field. The query is therefore not an implementation detail: it is the service’s data-minimization policy made executable.

DCQL can also include intent_to_retain, allowing the verifier to state whether it intends to keep a requested value. That signal does not replace product policy or informed user consent, but it makes retention intent part of the request rather than an invisible backend choice.

OID4VP 1.0: use DCQL, not an old request model

Builders working from older examples should account for an important version boundary. In OID4VP 1.0, presentation_definition was removed and the presentation query is carried through dcql_query. Older drafts and integrations may still expose Presentation Exchange terminology such as input_descriptors, but that is not the OID4VP 1.0 request model.

The same caution applies to credential-format identifiers. For SD-JWT VC, OID4VP 1.0 uses dc+sd-jwt; examples based on earlier drafts may use vc+sd-jwt instead.

This is more than naming cleanup. A verifier and wallet must agree on the request shape and the credential formats they support. Treating version-specific fields as interchangeable is a reliable way to turn an apparently standards-based flow into a one-wallet integration.

One request can ask for two different kinds of claim

A wallet interaction may need both a user-declared field and issuer-verified evidence. These are separate branches, even when they are requested together.

A combined interaction can use response_type=vp_token id_token. The id_token branch uses OpenID Connect mechanisms such as scope and the claims parameter. The verified branch uses dcql_query.

The distinction matters in product language as well as code. An email claim in a self-issued ID token is not automatically equivalent to an email attribute signed by a credential issuer. A verifier should label, process, and rely on these outputs according to the assurance they actually carry.

A presentation needs context: nonce and verifier identity

A credential presentation cannot be treated as a reusable file. The verifier needs evidence that it is receiving a live response intended for its own request.

For SD-JWT-based credentials, holder binding supplies that evidence through a Key Binding JWT, or KB-JWT. The credential contains a confirmation (cnf) reference to the holder’s public key. During presentation, the holder signs a KB-JWT using the corresponding private key.

Two request-bound values are central:

• the verifier’s fresh nonce, which makes the presentation specific to this session and helps prevent replay; and
• the verifier’s client_id, which binds the presentation to the intended relying party.

The verifier validates the KB-JWT against the key associated with the credential and checks that the nonce and client identity match the request it created. A valid issuer signature alone is not enough: it says who issued claims, not whether the current presentation is live or intended for this verifier.

The verifier must be recognizable too

A wallet needs to understand who is requesting data before it can present a meaningful consent screen or apply its policy.

OID4VP uses client_id to identify the verifier. In newer versions, a client-identifier prefix can signal how the wallet should validate the verifier’s metadata. Depending on the deployment, the request may also carry inline client metadata or use a signed Request Object through JAR.

The response delivery mode is part of this contract. OID4VP supports modes including redirect-oriented responses and direct-post patterns. A cross-device wallet interaction often uses a direct-post response to a verifier endpoint rather than returning through a browser redirect. The correct choice depends on the user journey and integration architecture, but it must be deliberate: response handling is part of the security boundary, not plumbing added afterward.

Verify a stack of evidence, not a token string

Receiving a vp_token is the start of verification, not its conclusion. A robust verifier evaluates several separate questions:

1. Request correlation: Does the response match the transaction state and fresh nonce created for this interaction?
2. Verifier binding: Is the presentation addressed to this verifier’s client_id or, where applicable, to the platform-verified origin?
3. Issuer trust: Is the credential’s issuer signature valid and acceptable under the verifier’s trust policy?
4. Data integrity and disclosure: Do the disclosed claims and format-specific proofs validate as expected?
5. Holder binding: Did the current wallet prove control of the key bound to the credential?
6. Credential validity and status: Is the credential within its accepted validity window, and are applicable status checks satisfactory?

These are complementary checks. Issuer trust establishes where claims came from. Holder binding makes the presentation live and credential-bound. Request correlation prevents a response from becoming detached from the transaction that requested it. None is a substitute for the others.

Higher assurance is a request-design choice

In many presentation flows, trust in the wallet is indirect. An issuer may already have evaluated wallet attestation when issuing the credential, and the verifier then validates the issuer-signed credential plus the holder-binding proof.

Some high-assurance scenarios need an additional direct signal. In that case, a verifier can use DCQL to ask for a Wallet Instance Attestation as another verifiable credential alongside the data credential. The wallet attestation can then be validated as evidence about the wallet provider and wallet instance.

This is not a universal default. It adds another credential request, another verification path, and another privacy decision. The right rule is to request it when the service’s assurance model justifies it—not simply because the protocol allows it.

Where the W3C Digital Credentials API is used, the platform can provide the wallet with a verified verifier origin. Binding the response audience to that origin adds a further phishing-resistance property. Again, the implementation must validate the resulting binding; the presence of an API call alone does not establish trust.

Privacy is part of the protocol surface

OID4VP gives a verifier expressive ways to ask for evidence. That power needs restraint.

Selective claim requests are the basic control: ask for the facts required for the decision, not a general-purpose identity record. Value matching deserves particular care. A verifier can express acceptable values for a claim, but repeated, narrowly varied requests could be used to probe a credential. The source material recommends explicit consent and caution for this reason.

A useful implementation review asks:

• Is every requested claim necessary for the service decision?
• Is retention intent accurate and visible where the user can understand it?
• Are self-attested and issuer-verified outputs kept distinct?
• Is a higher-assurance request, such as a wallet attestation, proportionate to the use case?
• Can the verifier explain to a user who is requesting the evidence and why?

Good credential UX is not just a wallet screen. It begins with the verifier’s query.

What builders should take away

OID4VP gives digital-credential presentation a disciplined OpenID-style shape, but a production verifier is more than an endpoint that accepts a vp_token.

It needs to construct a minimal DCQL request, identify itself clearly, bind the response to a fresh transaction, validate issuer evidence and holder binding, and apply a transparent trust and privacy policy. When self-attested data is also requested, it must keep that branch distinct from issuer-verified credentials.

The result is a better model for both engineering and product design: the verifier does not collect an identity document from a wallet. It requests narrowly defined evidence, receives a live presentation, and makes a decision from a stack of cryptographic and policy checks.

References

• OpenID for Verifiable Presentations 1.0
• OpenID Connect Core 1.0
• JWT Secured Authorization Request for OAuth 2.0 (RFC 9101)

These public references are included for reader verification. The article itself was derived exclusively from the LLM Wiki pages in the source map; human review should confirm deployment-specific and version-sensitive behaviour before publication.