A (KB-JWT) does not demonstrate a "proof of possession" of private key

[Denisthemalice]

Item 2 from Section 1.1. (Feature Summary) states:

2. SD-JWT+KB is a composite structure enabling cryptographic key binding when presented to the Verifier. It comprises the following:

   • (...)
   • A format for a Key Binding JWT (KB-JWT) that proves possession of the private key of the associated key pair

There is no "proof of possession".

Change the last bullet into:

   *  A format for a Key Binding JWT (KB-JWT) that allows to 
      demonstrate to a Verifier that a cryptographic result 
      computed using a private key corresponding to a public key 
      contained in a SD-JWT is correct.

[paulbastian]

There is a whole specification called DPoP by this working group which clearly indicates that there is such thing as a proof of possession

[Denisthemalice]

The abstract from RFC 9449 OAuth 2.0 Demonstrating Proof of Possession (DPoP) states:

This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens.

Section 11 (Security Considerations) from RFC 9449 only considers replay attacks by an "adversary". Section 11.1 (DPoP Proof Pre-generation) from RFC 9449 only considers "an attacker in control of the client".

RFC 9449 applies to the OAuth 2.0 framework but not to the Holder, Issuer, Verifier model. RFC 9449 does not consider collusion attacks between End-Users.

The current draft does not consider either collusion attacks between End-Users. The threats that apply to the OAuth 2.0 model and to the Holder, Issuer, Verifier are different.

The term "Key Binding" that used in the draft is the right wording. When key binding is used, it demonstrates the ability of an entity :

• to correctly use a private key that corresponds to a public placed in the SD-JWT or
• to use the cryptographic result of computation made using that private key, if there was a collusion between End-Users.

In the context of the Holder, Issuer, Verifier model, "Key binding" does not demonstrate a "Proof of Possession" of any kind.