Holder Binding

Holder binding is what stops a credential from being freely copy-pasted and presented by anyone who gets hold of the bytes. Without it, a Verifiable Credential is a bearer token, whoever has a copy of it can present it, exactly like a paper ticket or a gift card. Holder binding cryptographically ties a credential to a specific private key, so presenting it convincingly requires proving you control that key, not just having a copy of the credential file.

The mechanism is simple once stated: at issuance, the issuer embeds the holder's public key inside the signed credential (conventionally in a cnf, "confirmation," claim). At presentation time, the holder proves possession of the matching private key, typically by signing something fresh and verifier-specific (a nonce, an audience identifier) on the spot. The verifier checks that fresh signature against the public key the issuer originally embedded. Copy the credential file alone, and you get nothing usable: you'd also need the private key, which never leaves the legitimate holder's device.

This is a narrower guarantee than it might sound: holder binding proves this presenter controls a specific key. It says nothing about whether two different presentations, both correctly bound to the same key, can be linked to each other by a colluding pair of verifiers. That's a separate property (see Unlinkability); holder binding and unlinkability solve different problems and neither substitutes for the other.

Where it comes from

The core idea, a cnf claim naming a key a token is bound to, is RFC 7800, "Proof-of-Possession Key Semantics for JWTs and CWTs," an IETF specification with Michael B. Jones, John Bradley, and Hannes Tschofenig among its authors, published in 2016. SD-JWT VC (edited by Daniel Fett, Kristina Yasuda, and Brian Campbell, among others) reuses the same cnf claim and pairs it with a dedicated presentation-time proof, the Key-Binding JWT, its own Lexicon entry. ISO/IEC 18013-5's mdoc format solves the same underlying problem with a different mechanism, DeviceAuth, that Solidus has not implemented (see the mDoc entry). None of this is Solidus's design.

Solidus status

Shipped, testnet-live, via the cnf.jwk + Key-Binding JWT path. issueSdJwtVc in @solidus-network/sdk accepts an optional holder public key and, when supplied, embeds it as cnf: { jwk: {...} } in the issued credential (RFC 8037's OKP/Ed25519 JWK shape). verifySdJwtVc can then require and check a Key-Binding JWT against that exact key. The live capture-api issuer confirms this is wired end to end: its published metadata (checked 2026-07-17) lists "cryptographic_binding_methods_supported":["did:solidus","jwk"], key-bound issuance, not just bearer credentials, is a real, advertised capability of the running testnet issuer.

Ed25519 itself is scrutinized, well-deployed cryptography (see Ed25519 / EdDSA), the risk isn't the primitive. What's unaudited is Solidus's own assembly of it into this specific mechanism, and this runs on testnet only; there is no mainnet.

Proof you can run yourself: npm i @solidus-network/sdk, issue a credential with a holderPublicKey, then try to present it with the wrong private key. verifySdJwtVc rejects it with an explicit KB-JWT signature mismatch, checkable on your own machine.