EAA ConformanceETSI TS 119 472-1 (v1.2.1) clause 5.5
EAA-5.5-01:EAA should incorporate the cnf claim for key binding
- should
- Ordinary EAA
- QEAA
- PuB-EAA
- SD-JWT VC
- Issuer
- Verifier
Spec text
A SD-JWT VC EAA should incorporate the cnf claim as specified in IETF SD-JWT, implementing the semantics specified in clause 4.5 of the present document.
ETSI TS 119 472-1 (v1.2.1), clause 5.5, page 34.
In plain English
An SD-JWT VC EAA should incorporate the cnf claim, the holder's key binding confirmation. The claim ties the EAA to a specific cryptographic key that the holder controls, so a verifier can later check that whoever presents the EAA also proves possession of that key.
Why it matters
Without cnf, an EAA is a bearer credential: anyone who gets a copy can replay it. With cnf, presentation requires a signed challenge from the bound key, which closes off the simplest replay attack and matches the EUDI Wallet's holder-binding model.
Common mistakes
- Issuing cnf-free EAAs that holders then cannot demonstrate ownership of.
- Putting the public key in a custom claim name instead of cnf.
- Embedding a long-lived static key the holder cannot rotate.
Conformance check
Auto-tested. Use the action in the sidebar to run a Self-Assessment for this control.