Skip to main content

Device binding

A digital credential is a file. Without additional protection, anyone who obtains a copy could present it as their own. Device binding solves this by cryptographically linking each credential to the Wallet Secure Cryptographic Device (WSCD) in the holder's wallet. Because the WSCD prevents the private key from being extracted or copied, the credential becomes non-transferable.

Terminology

The Architecture Reference Framework (ARF) uses "device binding" as the primary term. The SD-JWT VC specification calls the same mechanism "key binding." This page uses "device binding" to align with the ARF.

When device binding applies​

Device binding is mandatory for PIDs (Personal Identification Data), because PIDs require a high level of assurance that in turn requires binding to a WSCD. For other SD-JWT VC attestations, device binding is recommended but not mandatory—an attestation provider may choose not to include it.

The Truvity EUDIW Connector requests and verifies device binding proof by default. A Relying Party can indicate in the presentation request whether it requires proof of device binding for a requested attestation.

How device binding works​

Device binding relies on asymmetric cryptography across three stages of the credential lifecycle.

Issuance​

When a holder receives a credential, their wallet generates a cryptographic key pair inside the WSCD. The wallet sends the public key to the issuer, who embeds it in the credential and signs the entire package. This binds the public key to the credential's attributes permanently.

Storage​

The WSCD stores the private key in tamper-resistant hardware (such as a Secure Element or Trusted Execution Environment). This hardware-backed storage ensures the private key cannot be exported or copied, which is the core security guarantee of device binding.

Presentation​

When the holder presents the credential, the wallet proves possession of the private key stored in the WSCD:

  1. The connector sends a unique challenge (nonce) in the presentation request
  2. The wallet signs this challenge using the private key in the WSCD
  3. The connector verifies the signature using the public key embedded in the credential

If the signature is valid, the connector confirms the presenter controls the WSCD bound to the credential. An attacker who obtained the credential file would lack access to the WSCD and could not produce a valid signature.

Verification checks​

During presentation verification, the connector validates the device binding proof by checking:

  • Signature validity: The proof signature matches the public key embedded in the credential
  • Nonce match: The challenge in the proof matches the nonce from the presentation request, preventing replay attacks
  • Audience binding: The proof is addressed to the correct Relying Party
  • Disclosure binding: The proof is cryptographically tied to the specific attributes disclosed in this session

Authenticating transactional data​

Device binding can go beyond proving possession of the WSCD. The same mechanism can authenticate transactional data that a Relying Party includes in the presentation request. For example, in a payment scenario the Relying Party can include the payment amount and payee in the request. The wallet signs this transactional data using the same private key in the WSCD, creating a cryptographic link between the user's consent and the specific transaction details.

This extends device binding from a proof of possession into a form of strong customer authentication where the user explicitly authorizes a specific action. See Transactional data for implementation details.

Recognizing returning users with kbKeyId​

The connector provides a Key Binding Key Identifier (kbKeyId) derived from the holder's public key. Because the public key remains constant across presentations of the same credential, the kbKeyId provides a consistent way to recognize returning users.

Connector-specific feature

The kbKeyId is a connector-specific feature, not a concept defined by the ARF. The EUDI ecosystem's privacy model uses mechanisms like short-lived attestations and batch issuance to limit Relying Party linkability. A stable identifier across presentations may conflict with these unlinkability goals, depending on the attestation's re-issuance strategy.

You can use the kbKeyId to:

  • Link a presentation to an existing user account
  • Recognize a returning user across different sessions
  • Associate multiple credentials with the same user profile, if the wallet uses the same key pair

Further reading​

  • SD-JWT VC format—the credential format that implements device binding (called "key binding" in the specification)
  • HAIP profile—the interoperability profile that requires device binding
  • OID4VP protocol—the presentation protocol that carries device binding proofs
  • Transactional data—how to authenticate transactional data using device binding