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 page on the verifier's own website where a person starts a verification — a relying party's "prove your age" page, say. Every flow below sends you there, and you choose on that page how the request is made. OpenID4VP does not say what such a page is called, so this is a whole URL rather than a path under the verifier. Against a verifier with no such page, paste a request into step 1 instead.
The verifier's own origin, which the JWKS URL below defaults under.
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.