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

← Return to home

VC Presentation — How is the credential being asked for?

A credential is only useful when it is shown to someone. This workflow is the presentation half of SD-JWT VC: a verifier asks for particular claims, and the wallet answers with those claims and no others — over OpenID for Verifiable Presentations (OID4VP), using the presentation format RFC 9901 defines. It presents whatever credential the issuance workflow left in this browser.

 
Configuration Parameters

What this wallet needs to know about the verifier. Unlike an issuer, an OID4VP verifier publishes no discovery document — there is no well-known endpoint to retrieve and nothing to populate these from, so they are set by hand. Restore Defaults fills in this suite’s own mock verifier.

The origin the verifier's own pages live under. It builds the three start links below (/oid4vp/verifier and /oid4vp/start), which are this debugger's mock verifier's own pages — a real verifier has none, so against one of those you paste a request into step 1 instead.
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 already has. Leave it empty and a signed request is reported as unverifiable rather than trusted.

 

 

All three end the same way: your wallet builds an SD-JWT+KB — the issuer-signed JWT, the Disclosures you chose, and a Key Binding JWT signed by the key the credential is bound to — and the verifier checks every part of it. What differs is how the request reaches the wallet and how much the wallet can prove about who sent it.

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.