OAuth2 & OpenID Connect Debugger — VC Presentation (3 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

← Back to step 2 (choose what to disclose)

VC Presentation — Step 3 of 3: The Verdict

Two accounts of the same event: what the wallet sent — with the presentation checked here, over the bytes themselves — and what the verifier did, check by check. “Accepted” is the least interesting part: a wallet that disclosed more than was asked for gets an accepted too, and this page says so.

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

What The Wallet Sent

Presented toThe verifier's Client Identifier, and the Response URI the presentation was POSTed to.	`—`
WhenA Key Binding JWT is signed for one moment and one request; a verifier may refuse a stale one.	`—`
KB-JWT payloadiat, aud, nonce, sd_hash — the four claims RFC 9901 section 4.3 requires, as signed.
KB-JWTThe holder's signature over this presentation.
What they can readThe claim set that follows from the bytes sent — computed here from the presentation itself.
Answered the request?What the verifier's DCQL query asked for, against what was actually disclosed. A verifier need not check this — walt.id's does not — so the wallet is often the only party that can tell you.

The presentation, with its parts called out: issuer-signed JWT · Disclosure · KB-JWT.

The Wallet's Own Checks

Run here, over the bytes that were sent, doing what the verifier does: recompute sd_hash, look up every Disclosure's digest in _sd, and compare the Key Binding JWT's nonce and aud with the request. If the wallet cannot verify its own presentation, no verifier will.

What The Verifier Decided

The verifier’s own verdict, check by check. Reading it back like this is not part of OID4VP — a real verifier shows the End-User its own page — but a debugger needs to see which rule was broken, not just that something was.

It asked forThe claims in its DCQL query.	`—`
It receivedThe Disclosures the wallet actually sent.	`—`
Over-disclosureClaims it did not ask for and got anyway. No verifier will complain about this, which is exactly why the wallet has to care.	`—`
What it now knowsThe claim set the verifier ended up with.
Fetch the verifier's verdict again.

VC Tools

Tools that are useful at any point in these workflows, and belong to none of their steps.

DID Tools Resolve a DID to its document, read the keys it publishes, check that one of them really signed the credential this browser is holding, and check that the DID and an origin are the same entity.	Resolve a Decentralized Identifier (`did:jwk`, `did:key`, `did:web`) to its document, verify that a key it publishes signed the credential in this browser, and verify a domain linkage (DIF Well Known DID Configuration). Opens in this tab; the workflow's state is untouched.
Certificate Authority & X.509 Tools Build a Root, Intermediate and Issuing CA, issue certificates with any X.509v3 extension, and test a real TLS or mutual-TLS handshake with what you issued.	Build a certificate authority — Root, Intermediate and Issuing — and issue TLS server, TLS client, code-signing and S/MIME certificates with full X.509v3 extension control. Useful when the issuer or verifier is behind TLS you control. Opens in this tab; the workflow's state is untouched.