OAuth2 & OpenID Connect Debugger — SD-JWT VC Presentation (1 of 3)

0. Choose a flowHow the verifier asks
1. The requestWho is asking, and for what
2. Choose & presentSelect disclosures, sign the KB-JWT
3. The verdictWhat the verifier saw and decided

SD-JWT VC Presentation — Step 1 of 3: The Verifier’s Request

A verifier has asked for a presentation. Before any part of the credential is disclosed the wallet has to establish three things: who is asking (the Client Identifier, and what its prefix lets the wallet prove about them), what they are asking for (the DCQL query, next to the credential this wallet actually holds), and how the answer travels back. Nothing is disclosed on this page.

Collapse all panes Tip: click a pane's title to collapse/expand it.

The Verifier's Authorization Request

OID4VP is OAuth 2.0 with a different response type: vp_token. The request below either arrived in the query string (by value) or was fetched from a request_uri where it could be signed — and if it was signed, the wallet checks that before believing any of it.

Where it came fromBy value in the verifier's redirect, fetched from a request_uri, or pasted in from a QR code on the verifier's screen.	`—`
client_idThe Client Identifier: who is asking. It is also the aud of the Key Binding JWT, which is what stops a presentation made for one verifier being replayed at another.	`—`
Identifier prefixOID4VP section 5.10. The prefix decides what the wallet may conclude about the verifier's identity and where its metadata and keys come from.	`—`
SignatureA Request Object fetched by reference can be signed (RFC 9101). Verified here against the keys this wallet trusts for the verifier.	`—`
nonceThe freshness of the whole presentation rests on this: the wallet signs it into the Key Binding JWT, so a presentation cannot be replayed for another request.	`—`
response_type / modevp_token is the response type OID4VP defines. direct_post means the wallet POSTs the presentation to the verifier rather than returning it through the browser.	`—` / `—`
response_uriWhere the presentation will be POSTed. With the redirect_uri client identifier prefix this URL IS the verifier's identity.	`—`
stateThe verifier's own handle for this transaction, echoed back with the presentation so its frontend and its response endpoint can find each other.	`—`
dcql_queryThe Digital Credentials Query Language query: which credential, of which format and type, and which claims. A verifier has no way to ask for "everything".
client_metadataThe verifier's own metadata, passed in the request: its name, and the credential formats and algorithms it accepts.
As receivedEvery parameter this page recognised, exactly as it arrived.

What Is Being Asked For

The DCQL query, decoded, against the credential this wallet holds: a claim in green is one the credential can disclose, a claim in red is one it cannot — and a vct in red means the verifier is asking for a different kind of credential altogether.

Receive a Request (cross-device)

In the cross-device flow the verifier's screen shows a QR code and the wallet is on another device, so nothing navigates here. Paste what the code encodes — an openid4vp:// URI, an https:// link carrying the same parameters, or just the query string — and the wallet will read it, fetching the Request Object if it is passed by reference.

Request URIWhatever the QR code encodes. Nothing is disclosed by reading it.
Verifier JWKS URL Where this wallet looks for the verifier's keys when a request is signed. For a pre-registered client this is the "out of band" knowledge OID4VP assumes the wallet has.
Read the request and show what it asks for. Nothing is sent to the verifier.