Device binding ties a credential to a private key held inside the wallet’s secure cryptographic device or keystore. Presenting it requires proving control of that key, so a copied credential is useless to anybody else. ISO/IEC 18013-5 calls it mdoc authentication, SD-JWT VC calls it key binding.
At issuance the wallet proves possession of a key and the issuer binds the credential to it. At presentation the wallet signs over the verifier’s nonce with that same key. A verifier checking this signature knows the presentation came from the device the credential was issued to.
This is what separates a credential from a document image. A photographed passport can be replayed by anyone who gets the file. A device-bound credential cannot, because the attacker does not have the key.
It is not uniformly mandatory. PIDs need it, because they sit at Level of Assurance High and that is unreachable without binding to a secure device. ISO/IEC 18013-5 attestations need it too. For SD-JWT VC attestations the ARF recommends rather than requires it, and OpenID4VP lets a verifier insist per request through the require_cryptographic_holder_binding parameter. Checking the signature is itself only recommended on the verifier side, so it is worth being deliberate about.
Do not confuse it with holder binding as the ARF uses that phrase. There, holder binding is a synonym for User binding, the separate question of whether the person presenting a credential is the person it was issued to. Device binding is a precondition for that check, not the check itself.
Defined in
ARF v3.0.0 sections 6.6.3.8 and 6.6.3.9, Annex 2 ISSU_17 and ISSU_27; OpenID4VP
Device binding is why wallet verification resists the attacks that beat document-upload KYC. If your verifier skips the key binding proof, you have thrown away most of the advantage.
Authbound handles the protocols, formats, trust lists and revocation checks behind these terms. See what people build with them.
