Holder binding explained: why a copied credential is worthless
A signed credential is a very good copy of itself. Anyone who gets hold of one has a document with a valid issuer signature on it, and checking that signature will happily tell them it is genuine. Holder binding is the part that closes that gap: it ties the credential to a key that only one person can use, so presenting it takes more than possessing it.
This page is the plain-language version. It covers what the binding actually is, when it is created, how the two European credential formats each do it, and the part most explanations skip: what holder binding still does not tell a verifier.
The problem it solves
Digital documents copy perfectly. A photograph of a passport is a poor forgery because paper carries physical features that a photocopy loses, but a signed credential has no such tell. Copy the file and the copy verifies exactly as well as the original, because the issuer signature covers the contents and the contents did not change.
So a verifier that only checks the issuer signature is answering the wrong question. It has learned that the claims are authentic. It has learned nothing about whether the party in front of it is entitled to them, which is usually the thing it actually needed to know.
The claims
The facts the credential states: a name, a date of birth, a licence category, a company number. This is the part everybody pictures when they think of a credential.
The issuer signature
Proof that those facts came from the issuer and have not been altered since. It says nothing at all about who is holding them now.
The holder public key
The piece that does the binding. The issuer writes the holder public key into the signed credential, so the credential now names the key that is allowed to present it.
When the binding is created, and when it is used
The binding is made once, at issuance, and it is exercised every time the credential is shown. Nothing about it is visible to the holder beyond the unlock prompt they already expect.
1. The wallet makes a key
Before it asks for anything, the wallet creates a fresh key pair inside the phone’s own secure hardware. The private half cannot be read back out, not even by the wallet app.
2. The issuer writes it in
The wallet sends the public half with its request and proves it holds the private one. The issuer puts that public key inside the credential before signing it.
3. A verifier asks
The request carries a fresh random value and says who is asking, so the answer can only be used once and only by the party that asked for it.
4. The wallet signs
The wallet signs the response with the private key, usually after a fingerprint or a PIN. The verifier checks that signature against the key inside the credential.
Where the private key actually lives
The binding is only ever as good as the difficulty of using the key without the holder. That is why wallets generate these keys inside dedicated hardware, the secure element or equivalent that also protects the phone’s payment credentials, rather than storing them as a file the operating system can hand to any app that asks.
A verifier cannot see any of that from the presentation itself. A signature proves the key was used, not that it was well kept. Whether the key really sits in certified hardware is a separate assurance, carried by the attestations a wallet presents to an issuer before it is given anything, and under the European rules that is what wallet and key attestation exist for.
Holder binding answers
Was this response produced by the key this credential was issued to, for this request, just now?
Key attestation answers
Is that key held somewhere an attacker cannot extract it from? Different question, different evidence, decided at issuance.
How the two European formats do it
The idea is the same in both formats the European wallet is built on. The mechanics differ, which matters to whoever implements a verifier and to almost nobody else.
SD-JWT VC
The issuer puts the holder public key in a confirmation claim inside the signed credential. At presentation the wallet adds a small separate token, signed with the private key, that covers the verifier identity and the random value from the request. A verifier that ignores that token has checked the issuer and nothing else.
Read the definitionmdoc
The device key is named in the signed object that protects the data elements, and the phone signs the transcript of the session it is in. Because that transcript covers the exchange between the two devices, a recording of one presentation cannot be replayed into another, which is what makes an offline check at a roadside or a door safe.
Read the definitionA wallet in the European ecosystem generally carries the same attestation in both formats and hands over whichever the other side speaks, so an organisation accepting credentials has to be able to check the binding in both.
What holder binding does not prove
Holder binding proves control of a key. It does not prove who is holding the phone. Somebody who has been given the device and the PIN produces exactly the same valid response as the rightful holder, and no amount of cryptography in the credential can see the difference.
Nor does it say anything about how well the issuer checked identity before issuing. A credential bound to a key is still only as trustworthy as the process that created it, which is what levels of assurance are there to describe. Binding a weakly issued credential very strongly to a key does not make the claims inside it any more true.
Read together the division of labour is clear enough. Holder binding stops replay and copying, the wallet unlock ties the key to a present human, the level of assurance describes how well that human was identified, and a trusted list says which issuers you accept at all. A verifier that wants a real answer needs all four, not just the one that comes free with the credential.
What this means for you
Issuer
Your credentials stop being useful to anyone who steals a copy of them, which removes a whole class of fraud you would otherwise have to detect after the fact. The cost is that you must be ready to reissue whenever a holder changes device.
Verifier
Check the binding, not only the issuer signature. Send a fresh random value with every request and reject a response that does not sign it, otherwise a recorded presentation can be replayed at you later.
Wallet holder
Nothing to manage, and one thing to know: your credentials are tied to this device, so a new phone means getting them again rather than restoring them from a backup.
Related terms
Frequently asked questions
Is holder binding the same as key binding or device binding?
In practice yes, and the different words come from different specifications rather than from any difference in meaning. Holder binding is the property: this credential belongs to this holder. Key binding is the mechanism the SD-JWT VC world names it by, and the ISO side talks about device binding or device authentication because the key sits in a specific phone. If a document uses one of these terms, read it as the same idea seen from a different angle.
Does holder binding prove that the person presenting the credential is the subject?
No, and this is the single most common misreading. It proves that whoever produced the response controls the key the credential was issued to. Whether the human tapping the phone is the person the claims describe depends on how the wallet unlocks, how carefully the issuer checked identity in the first place, and whether the holder has handed the device and the PIN to somebody else. For a high value check you pair the binding with a wallet that requires a biometric and with a credential issued at a level of assurance that matches the risk.
What happens to a bound credential when the holder gets a new phone?
It does not move. The whole point of keeping the private key in secure hardware is that it cannot be exported, so a credential bound to the old phone cannot be restored onto the new one and be expected to work. The new device generates its own key and the credential is issued again against it. Plan for reissuance as a normal, frequent event rather than an exception, because for your users it is simply the day they replaced their phone.
Are there credentials without holder binding?
Yes, and they have their place. A credential with no holder binding is a bearer credential: whoever presents it gets the benefit, like a paper ticket. That is a reasonable trade for something low value and short lived, where the cost of a copy being replayed is small and you would rather not ask the holder to unlock anything. It is the wrong choice for identity, entitlements and anything a fraudster would find worth reusing.
Sources
This page is informational and does not constitute legal advice. Consult the specifications directly for the authoritative wording.