Section 9.5 (Key Binding) needs to be revised to consider the case of a collusion between End-Users

[Denisthemalice]

Section 9.5 (Key Binding) states:

Key Binding aims to ensure that the presenter of an SD-JWT credential is actually the legitimate Holder of the credential. An SD-JWT compatible with Key Binding contains a public key, or a reference to a public key, that corresponds to a private key possessed by the Holder. The Verifier requires that the Holder prove possession of that private key when presenting the SD-JWT credential.

Without Key Binding, a Verifier only gets the proof that the credential was issued by a particular Issuer, but the credential itself can be replayed by anyone who gets access to it. This means that, for example, after a credential was leaked to an attacker, the attacker can present the credential to any verifier that does not require a binding. But also a malicious Verifier to which the Holder presented the credential can present the credential to another Verifier if that other Verifier does not require Key Binding.

These two paragraphs are incorrect.

Let us suppose that an End-User B connects to a Verifier in order to perform an operation. The Verifier then returns a selection of issuer names, claim names and a nonce. Let us now assume that an End-User A accepts to collaborate with an End-User B. The End-User B transmits the nonce to the End-User A. The End-User A then provides
a "SD-JWT + Selected Disclosures + KB-JWT " structure to the End-User B. In this way, the End-User B can take benefits of claims that belong to the End-User A.

The Verifier is not in a position to know who is "the legitimate Holder of the credential" ... unless the set of disclosed claims allows to unambiguously identify the End-User.

The collusion attack has been described on the OAuth mailing list on 07 November 2016. The ABC attack (the Alice and Bob Collusion attack). See: https://mailarchive.ietf.org/arch/msg/oauth/UIsbsVtINPifrCjG7GDZM7FOi2g/.

A few extracts:

Whatever kind of cryptographic is being used, when two users
collaborate, a software-only solution will be unable to prevent 
the transfer of an attribute of a user that possess it to another 
user that does not possess it .

The use of a secure element or of a Trusted Application (TA) running in a TEE only protecting the confidentiality and the integrity of some secret key or private key will be ineffective to counter the Alice and Bob collusion attack.

Additional properties will be required.

Change into:

An SD-JWT compatible with Key Binding contains a public key, or a reference to a public key, that corresponds to a private key that can be used by some entity. The Verifier requires that a Holder proves that it is able to use that private key when presenting an SD-JWT + Selected Disclosures + KB-JWT structure to a Verifier. Key Binding aims to ensure that the presenter of a SD-JWT + Selected Disclosures + KB-JWT structure to a Verifier has either the ability to use a private key corresponding to a public key contained in a SD-JWT or has had the ability to obtain a cryptographic result performed using that private key.

Without Key Binding, a Verifier only gets the proof that the redential was issued by a particular Issuer, but the credential itself can be replayed by anyone who gets access to it. A malicious Verifier to which the Holder presented the credential can also present the credential to another Verifier if that other Verifier does not require Key Binding.

With Key Binding, if two End-Users accept to collaborate, unless specific characteristics are supported by the Holder, the SD-JWT + Selected Disclosures + KB-JWT structure can voluntarily be computed and then transmitted to another Holder by the legitimate Holder of a private key with the consent of the End-User. Using the "hchar" claim, the Verifier may be able to know whether some of these characteristics are able to counter Holder collaborative attacks against a Verifier.