0. Choose a flow How the verifier asks 1. The request Who is asking, and for what 2. Choose & present Select disclosures, sign the KB-JWT 3. The verdict What the verifier saw and decided ← Back to step 1 (the request)
SD-JWT VC Presentation — Step 2 of 3: Choose What To Disclose This is the page selective disclosure exists for. The credential carries everything the issuer put in it; the verifier asked for some of it; what leaves this browser is the holder’s choice. Pick the Disclosures to send, and the wallet assembles the presentation — the issuer-signed JWT, those Disclosures, and a Key Binding JWT signed over this request’s nonce, addressed to this verifier, carrying sd_hash over exactly the bytes being sent (RFC 9901 section 4.3 ). Nothing is sent until you press Present.
Collapse all panes Tip: click a pane's title to collapse/expand it.
What This Verifier Asked For Verifier The Client Identifier from the request. It becomes the aud of the Key Binding JWT.
—nonce Signed into the Key Binding JWT, which is what ties this presentation to this one request.
—Claims requested The claim paths in the DCQL query. Everything else in the credential is the holder's business.
—Holder binding require_cryptographic_holder_binding in the credential query. It defaults to true: a presentation without a holder proof is the exception.
—Always visible Claims in the issuer-signed JWT itself rather than in a Disclosure. They cannot be withheld without breaking the issuer's signature, so they travel whatever you choose below.
The Presentation Assembled from the choice above, before anything is sent: issuer-signed JWT ~ selected Disclosure ~ …~ KB-JWT .
Holder private key The private half of the key the credential is bound to (its cnf claim). Needed to sign the Key Binding JWT. It is not in this browser's storage — either it was never generated here, or "Save this holder key pair in browser localStorage" is turned off on issuance step 2 — so paste it here. The file from Download Key Pair works as-is, and so does a bare private JWK.
sd_hash base64url of the hash of the issuer-signed JWT and the selected Disclosures, each followed by a tilde. Recomputed here; the verifier recomputes it too, and a mismatch means the presentation was altered after it was signed.
—KB-JWT header typ must be kb+jwt and alg must not be none (RFC 9901 section 4.3).
KB-JWT payload Exactly iat, aud, nonce and sd_hash. OID4VP fixes two of them: the nonce is the request's, and the aud is the verifier's Client Identifier.
KB-JWT The signed Key Binding JWT, as it will be appended to the presentation.
Presentation The SD-JWT+KB in Combined Serialization: what the verifier will receive.
vp_token OID4VP section 8.1: a JSON object keyed by the DCQL credential query id, each value an array of presentations.
What they will know The claim set that follows from exactly these bytes — computed from the presentation, not from what this page intended to send.
