MNEURIX
SD-JWT Verification Banner
SD-JWT Verifier · RFC 9901 Recomputed SHA-256 Digests & Real Ed25519 Checks
← Verifiers Hub Client-Side Verification Engine

SD-JWT & Key Binding (KB) Verifier

Verify SD-JWT issuer signatures (Ed25519/WebCrypto), recompute salted SHA-256 disclosure digests (~sd), and check Key Binding proofs — in your browser, by recomputation rather than pattern-matching.

What this tool does

It verifies SD-JWTs (RFC 9901 — selective disclosure for JWT-style verifiable credentials) by recomputation, not pattern-matching. Three things are checked for real: the issuer's Ed25519 signature over the JWT parts, verified with the browser's WebCrypto; every disclosure segment — each is base64url-decoded, its salted SHA-256 digest recomputed, and the result matched against the _sd digest list inside the payload; and the Key Binding JWT — the holder's proof of possession, verified with the key referenced in the credential's cnf.jwk. The result cards show each verdict separately, the decoded claims including what the attached disclosures actually reveal, and — on failure — the specific reasons, step by step.

How to use it

  1. Paste a compact SD-JWT: issuer_jwt~disclosure~…~kb_jwt.
  2. Provide the issuer's public key as a JWK. If the token's iss is did:web:mneurix.dev, leave the field empty and the key is fetched from this site's own /.well-known/did.json.
  3. Press Verify by recomputation — or press a demo button first: one constructs a genuinely signed token in this tab's memory and verifies it; the other tampers with a disclosure and shows the digest mismatch being caught.

Where your data goes

The verification mathematics runs in your browser via WebCrypto — no libraries, no third-party calls. The only network request this page can make is a same-origin fetch of this site's own DID document, and only for tokens issued by this site's DID with an empty key field. Pasted tokens are never uploaded or stored; the demo keys are generated in the tab and discarded with it.

Who it's for

Implementers building SD-JWT issuance or verification who want a second opinion on a failing token; holders checking which claims a presentation actually discloses before presenting it; and anyone debugging a verifier rejection — the reasons box names the exact step that failed (signature, digest, or key binding) instead of a generic "invalid".

Honest limits

  • Ed25519 / EdDSA only. Other algorithms get an honest UNVERIFIABLE verdict, never a guess.
  • Browser support matters: WebCrypto Ed25519 needs Chrome/Edge 137+, Firefox 129+, or Safari 17+. Older browsers get a clear error, not a fake verdict.
  • No third-party key fetching. Keys are pasted, or come from this site's DID document — the verifier will not resolve arbitrary DIDs for you.
  • An absent Key Binding is reported, not failed: a token without a KB-JWT shows NOT PRESENT; whether that matters is your policy's call.
  • VALID is a math verdict, not a trust verdict — it means the signature checked against the key you supplied. Whether you trust that issuer is a separate, human decision.

Related: the JSON-LD schema verifier for the structure of JSON-LD credentials, the credential inspector for decode-only views, and the verifiers hub for the full cluster.