Key Binding

Key binding - also known as device binding - lets a Relying Party check that the entity presenting your credential is the same entity you issued it to, by requiring that entity to prove control of a device-bound key you bound to the credential at issuance. Without it, a Relying Party can only confirm that a credential is authentic: signed data can be copied exactly, out of a backup, off a compromised device, or out of a badly secured log, without invalidating your signature.

At Issuance

1. Your issuer metadata declares which key binding methods you support, via cryptographic_binding_methods_supported (for example jwk for the SD-JWT VC format, cose_key for the mdoc format; see rulebook §3 for how you choose between them).
2. During the OpenID4VCI (the protocol your issuer uses to hand credentials to wallets) credential request, the wallet generates a fresh key pair for this specific credential and sends you the public key together with a proof of possession for it.
3. You validate that proof, embed the public key inside the credential, and sign the credential as a whole. From this point, the key is part of what you vouch for.

The concrete metadata fields, proof types, and request/response shapes are covered in EAA Issuance: Credential formats and rulebook decisions, Proof-of-possession mechanisms, and Implementing the credential endpoint.

What it does and does not prove

Once issued, key binding confirms only that the presenter holds the private key bound to this credential. It does not, on its own, say anything about how that holder came to have it. If your issuance process identified the holder through a different credential, for example a PID (Person Identification Data), before issuing this one, key binding gives a Relying Party no guarantee that the holder still controls that other credential at presentation time. It confirms continuity with your own credential, not with whatever you used to identify the holder before you issued it. This is not a gap you need to close by default: for the majority of use cases, proving continuity with your own credential is exactly what a Relying Party needs. Where a Relying Party's use case additionally cares about a specific claim staying tied to its original source, independent of the key, that is what Claim Binding is for.

After issuance: rotation and loss

A device-bound key is fixed to one credential instance for its lifetime. If you support credential refresh (see Lifecycle: Credential refresh), your rulebook must state whether a refreshed credential keeps the same bound key or requires the wallet to generate a new one. If the holder loses the device holding the private key, the credential itself becomes unusable for presentation even though it may still be technically valid and unrevoked; your operational documentation should cover how holders in that situation obtain a new credential.

At Presentation

The wallet does not just hand over the credential. It additionally signs a fresh proof of possession with that same private key, covering the disclosed claims together with your nonce and client_id. You verify two signatures, not one: the issuer's signature confirms the credential itself is genuine, and the proof-of-possession signature, checked against the public key bound to the credential, confirms the presenter holds the matching private key.

The exact data structure this proof takes, and how the bound key is carried, differs by credential format. See the dedicated format reference for the details.

What matters at this level is the shape of the check, which is identical regardless of format: one signature proves the credential is genuine, a second, independent signature proves the presenter holds the key that credential was bound to.

The verifiers response validation should perform those checks where needed. Verifying only the issuer's signature on the credential and skipping the proof-of-possession check, silently downgrades the system to "accepts any copy of a valid credential".

---

Further Reading

Documentation	Read this, when ...
EAA Issuance: Credential formats and rulebook decisions	... you need the exact metadata fields for cryptographic_binding_methods_supported
EAA Issuance: Proof-of-possession (PoP) mechanisms	... you need the proof-of-possession request/response shapes
EAA Issuance: Implementing the credential endpoint	... you are building the endpoint that validates the proof and embeds the key