Key Binding JWT (KB-JWT)
Also called KB-JWT, Key-Binding JWT, holder key-binding proof
A Key-Binding JWT is a small, single-use JWT a credential holder signs fresh at presentation time, separate from the credential's own signature, to prove they control the private key the credential was bound to at issuance. It's the concrete mechanism that makes Holder Binding (see that entry) enforceable rather than merely declared: the issuer says "this credential belongs to whoever holds key K" via a cnf.jwk claim, and the KB-JWT is the holder actually proving that, on the spot, for this specific presentation.
A KB-JWT's payload carries a handful of claims that, together, stop it from being reused somewhere it shouldn't be:
{
"iat": 1752710400,
"aud": "https://relying-party.example/verify",
"nonce": "3kX9mQ2v...",
"sd_hash": "8f2a9c1e..."
}
aud, who this proof is for. Ties the presentation to one specific verifier; replaying it against a different one fails.nonce, a fresh, verifier-supplied, single-use value. Stops a captured presentation from being replayed later against the same verifier.sd_hash: a hash of the SD-JWT credential body this KB-JWT is attached to. Stops the KB-JWT from being detached and reattached to a different set of disclosures than the one the holder actually consented to reveal.
It's appended to the end of the SD-JWT's compact form, <jws>~<disclosure1>~<disclosure2>~<kb-jwt>, as its own, separately signed, three-part JWT.
Where it comes from
KB-JWT is defined inside the IETF SD-JWT specification itself, edited by Daniel Fett, Kristina Yasuda, and Brian Campbell, the same editors responsible for SD-JWT VC generally (see that entry). It builds directly on RFC 7800's cnf claim mechanism (see Holder Binding). Solidus designed none of the construction; it implements the spec's requirements.
Solidus status
Shipped, testnet-live. presentSdJwtVc in @solidus-network/sdk always emits a KB-JWT: Solidus's SDK doesn't have a middle mode where binding is declared but not enforced. verifySdJwtVc checks the KB-JWT's signature against the key named in the credential's cnf.jwk, and separately checks aud, nonce, and sd_hash against what the verifier expected, returning a specific mismatch reason for each failure rather than a single opaque "invalid": a code detail worth naming, since it's what makes the mechanism debuggable rather than a black box.
The usual caveat applies in full: this is unaudited assembly on top of a scrutinized primitive (Ed25519), running on public testnet only, no mainnet exists.
Proof you can run yourself: npm i @solidus-network/sdk, call presentSdJwtVc, and split the result on ~: the last segment is a standard three-part JWT, decodable with any JOSE tool. Its payload is exactly aud, nonce, iat, and sd_hash, nothing hidden, nothing that requires trusting Solidus's account of it.
Where it comes from
Someone else specified this. Solidus assembles it.
Defined inside the IETF SD-JWT specification itself (draft-ietf-oauth-selective-disclosure-jwt), edited by Daniel Fett, Kristina Yasuda, and Brian Campbell, the same editorial group behind SD-JWT VC (see that entry). It's the concrete presentation-time proof that makes Holder Binding's cnf claim (RFC 7800) actually enforceable, rather than just declarative. Solidus implements the mechanism via the @sd-jwt/core library, wrapped by @solidus-network/sdk, and writes its own compact-JWS parsing for the KB-JWT specifically (see JSON Web Signature): it did not design the KB-JWT construction or its required claim set.
How to check this
Running on the test network. Not mainnet.
npm i @solidus-network/sdk, call presentSdJwtVc, then split the compact result on '~' and take the final segment: a standard three-part JWT you can decode with any JOSE tool, no Solidus tooling required. Its payload carries exactly aud, nonce, iat, and sd_hash, decode it and check. The hand-rolled compact-JWS parsing logic that verifies it lives directly in the published SDK source, sdjwt/verify.ts: nothing about it is hidden behind a dependency.