Binding Mechanisms
OpenID4VP gives Relying Parties several mechanisms for checking different types of binding. Which of them work for a given credential depends on the features the issuer provided at issuance time and the relying parties use case:
| Binding type | Question it answers | Attack it prevents | Mechanism | Provided By |
|---|---|---|---|---|
| Key Binding | Is the presenter the same entity the credential was issued to, provably by a device-bound key? | A copied credential presented by anyone other than its rightful holder | A proof-of-possession signature made with a device-bound key established at issuance | Issuer |
| Claim Binding | Does the presenter still has control over a credential the issuer drew identifying data from at issuance? | A copied credential presented by someone who no longer controls the identifying source it was tied to | Claims copied from another credential checked without a cryptographic key | Issuer |
| Session binding | Was this proof made for this exchange, right now, and which of my sessions does it belong to? | Replaying a captured, genuine presentation against a different verifier or a later session; a response being credited to the wrong session | A per-request nonce, echoed inside the holder's cryptographic proof, plus a per-session state, echoed in the response envelope | Relying Party |
| Transaction binding (planned) | Did the user consent to this exact business transaction? | Reusing a valid presentation to authorise a transaction the user never actually saw or approved | transaction_data, signed alongside the credential proof | Relying Party |
Neither feature depends on the other. Issuers can issue a credential with key binding only, claim binding only, both together, or neither, though issuing neither leaves every Relying Party unable to confirm the presenter is who the credential was issued to at all.
Getting all four right is what separates "the wallet showed a valid credential" from "the wallet showed a valid credential, bound to this holder, for this session, for this exact transaction".
A Verifiable Credential is just signed data. Once a Relying Party receives one, it can check that your signature is genuine, but that check alone does not tell the Relying Party whether the person presenting the credential is the person you issued it to. Establishing that link, known as binding, does not happen by itself: it depends on choices you make when you design and issue the credential. That decision belongs in the credentials rulebook and the OpenID4VCI issuer configuration. It directly shapes what a Relying Party is able to check when the credential is presented to them later. A credential issued without any binding feature only proves that its content is authentic, not who is holding it. The credentials rulebook should state explicitly which feature, or combination, the credential type provides, and why. You should not assume a Relying Party will infer availability of a feature from the credential format, the assurance level, or from what other issuers offer for similar credential types.