Home Supported Standards Terms & Conditions Privacy Policy Documentation Contact About
  1. 0. Choose a flowHow the verifier asks
  2. 1. The requestWho is asking, and for what
  3. 2. Choose & presentSelect disclosures, sign the KB-JWT
  4. 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.

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

What The Wallet Sent
 
The verifier's Client Identifier, and the Response URI the presentation was POSTed to.
—
A Key Binding JWT is signed for one moment and one request; a verifier may refuse a stale one.
—
iat, aud, nonce, sd_hash — the four claims RFC 9901 section 4.3 requires, as signed.
 
The holder's signature over this presentation.
The claim set that follows from the bytes sent — computed here from the presentation itself.
 
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 Answered

The Verifier’s answer to the presentation, which is all OID4VP gives a wallet: 200 and, optionally, a redirect_uri to send the browser to (section 8.2). Which of its checks passed is the Verifier’s own record; the wallet’s re-check above is the half a wallet can see.

 
The body the Response Endpoint answered the wallet's direct_post with.
 
VC Tools

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

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.
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.