Claim Binding

Claim binding lets a Relying Party check that the presenter still controls a specific piece of identifying data you bound to the credential at issuance, by comparing a claim you copied into the credential against a fresh presentation of the credential you originally drew it from. A vehicle registration credential can carry the vehicle identification number copied from the vehicle's own registration document; a professional credential can carry the holder's name copied from the identity document used to identify them. Checking the copied claim against a fresh presentation of the original tells the Relying Party that the presenter genuinely still controls the identity or object the claim represents, not merely that they hold a copy of your credential.

This is a feature you provide deliberately, independent of whether the credential is also cryptographically bound to a device key.

At Issuance

To offer claim binding, your issuance flow must:

1. Identify the holder through the source credential (the one the claim will be drawn from), as part of the same or a preceding issuance session.
2. Copy the relevant claim, or claims, verbatim from that source credential into the new credential you are constructing.
3. Document in your rulebook which claims are claim-bound, which source credential type they are drawn from, and how a Relying Party is expected to re-check them.

Because the check depends on requesting and comparing against the original source credential at presentation time, this feature is only useful to a Relying Party that also knows to request that source credential alongside yours. State this explicitly in your rulebook, and reflect it in the schema metadata entry you publish to the catalog of attestations, so integrators discover the requirement rather than finding out from a failed verification.

Claim binding and key binding are not mutually exclusive. When you issue a credential with both features, they work independently: the device-bound key continues to prove the presenter holds this specific credential, on top of, not instead of, the claim check. A Relying Party that only cares about one of the two guarantees is free to check only that one.

If you do not also offer key binding, say so explicitly

A credential type that carries claim binding but no device-bound key needs that stated explicitly in your rulebook. A Relying Party requesting a credential like this needs to know in advance that no proof of possession will be available, so it can adjust its presentation request accordingly and rely on the claim check, together with its own request-freshness mechanism, instead.

The PID claim binding use case

A common source credential for claim binding is the PID. If your credential type draws a claim, typically the holder's name, from a PID presentation during issuance, that PID presentation is a distinct data-processing event with consequences beyond the credential you are actually trying to issue.

Consequences for the issuance flow. Requesting the PID during issuance requires the holder to authenticate to their wallet, entering their wallet PIN and to consent to sharing the requested PID claims with you. This applies even when your own identification method for the credential you are issuing is otherwise independent of the PID: if claim binding is what pulls the PID into the flow, that authentication and consent step becomes part of your issuance journey, and holders should be told in advance why it is happening.

Data protection considerations. Receiving PID claims, even a single attribute such as a given name, is processing personal data under the GDPR (General Data Protection Regulation), regardless of how briefly you hold it. Requesting a PID presentation purely to construct a claim-bound value requires its own lawful basis and a purpose that is clearly documented in your rulebook: "binding this claim to the PID at issuance" is a distinct, statable purpose, not an incidental side effect of issuing your credential. Reusing PID data received for this purpose for any other purpose, without a separate lawful basis, is not compliant.

Data minimization. Request only the specific PID claims your claim binding actually needs. Do not persist the received PID claims beyond what is required to construct and sign the resulting credential: once the claim has been copied into the new credential and that credential is signed, the source PID data itself has served its purpose and should not be retained in your issuance backend unless a separate, documented reason requires it.

Claim staleness. Because the claim is copied at issuance, your credential becomes a secondary, point-in-time copy of PID data that can change at the source, for example after a legal name change. Your rulebook's validity period policy should account for this: state how long a claim-bound value is considered current.

At Presentation

At presentation, you request both the claim-bound credential and the credential the claims were originally drawn from, and compare the copied claims against a fresh presentation of the original. A match tells you the holder still controls the authentication means they used when the claim-bound credential was issued, not merely that they once did.

This approach has its own consequences:

• Because the check runs against the copied claims rather than a device-bound key, it does not require the claim-bound credential and the original authentication means to still live on the same device. Validity can be confirmed even if they have since been separated.
• The cost is that you must additionally request and verify the original credential every time, alongside the one you actually wanted. For a PID, this means the user has to re-authenticate and share personal claims with you again, even though the credential you needed was a different one.
• Claim binding and key binding routinely coexist on the same credential. When a credential supports both, the client_id and nonce guarantees described under Key Binding apply exactly as before, on top of the claim check.
• If, and only if, this credential does not also support key binding, your presentation request must indicate that no proof of possession is required for it. Without a signed proof of possession to carry it, your nonce has nothing to be checked against, so the freshness check session binding normally gives you is unavailable for this credential. Generate a fresh, unpredictable state per request, the same way you would otherwise generate nonce, so your backend can still confirm the response belongs to this exchange and not a replayed one.

---

Further Reading

Documentation	Read this, when ...
Key Binding	... you want to see the key-based feature this can complement or stand in for
Rulebook §i: Validity Period	... you are defining how long a claim-bound value stays current
Lifecycle: Credential refresh	... you need to decide whether refresh re-draws the claim from a fresh PID presentation
OpenID4VP: Requesting Presentations without Key Binding Proofs	... you need the spec detail for requesting a credential that relies on claim binding without a cryptographic key