To prevent attacks in which an SD-JWT is presented to a Verifier
without the Holder's consent, this specification additionally defines
a mechanism for binding the SD-JWT to a key under the control of the
Holder (Key Binding). When Key Binding is enforced, a Holder has to
prove possession of a private key belonging to a public key contained
in the SD-JWT itself. It usually does so by signing over a data
structure containing transaction-specific data, herein defined as the
Key Binding JWT. An SD-JWT with a Key Binding JWT is called SD-
JWT+KB in this specification.
Key Binding is not performed to prevent attacks without the "Holder's consent".
Key binding will be ineffective if the End-User consents to perform a collaborative attack against a Verifier
for the profit of another individual by performing all the cryptographic operations that the other individual needs
... unless the Holder supports specific characteristics that are able to prevent such collaborative attacks.
Once again, a Holder is an application, i.e., it is not a human being.
Key Binding only demonstrates the use of a private key corresponding to a public key contained in a SD-JWT.
It does not demonstrate the possession of a key.
A key binding is performed (a) when requesting a SD-JWT to an Issuer, while (b) the demonstration of that key binding
is performed to a Verifier at the presentation time.
Replace by:
When requesting a digital credential to an Issuer, the Holder CAN
demonstrate to the Issuer that the request originates from an
application that supports specific characteristics. In that case,
the Holder CAN include in his request a public key and demonstrate
to the Issuer the use of the corresponding private key.
The Issuer CAN include in the SD-JWT a claim that indicates
the Holder characteristics: "hcahr" (for holder characteristics).
When presenting a SD-JWT + Sel.Claims to a verifier, the Holder CAN
then add a key-binding JWT, called KB-JWT, that allows to integrity
protect the "SD-JWT + Sel.Claims" structure. In this way, the
Verifier will be able to verify that the "SD-JWT + Sel.Claims"
structure and the KB-JWT " originate from a Holder that supports
specific characteristics.
The strength of the key binding is dependent upon the characteristics
of the Holder. Such characteristics include the generation of
key pairs, their protection as well as additional characteristics in
particular to demonstrate its ability to counter collaborative or
collusions attacks between End-Users
Unless the Verifier is able to know the characteristics of the Holder by using information present in the SD-JWT,
the key binding mechanism can be easily defeated. The claim that shall be placed into the SD-JWT is currently missing
and should be added. This new claim could be called "hcahr".
The fifth paragraph mentions:
Key Binding is not performed to prevent attacks without the "Holder's consent".
Key binding will be ineffective if the End-User consents to perform a collaborative attack against a Verifier for the profit of another individual by performing all the cryptographic operations that the other individual needs ... unless the Holder supports specific characteristics that are able to prevent such collaborative attacks.
Once again, a Holder is an application, i.e., it is not a human being.
Key Binding only demonstrates the use of a private key corresponding to a public key contained in a SD-JWT. It does not demonstrate the possession of a key.
A key binding is performed (a) when requesting a SD-JWT to an Issuer, while (b) the demonstration of that key binding is performed to a Verifier at the presentation time.
Replace by:
Unless the Verifier is able to know the characteristics of the Holder by using information present in the SD-JWT, the key binding mechanism can be easily defeated. The claim that shall be placed into the SD-JWT is currently missing and should be added. This new claim could be called "hcahr".