Original text:
5.1.2. If the Issuer wants to enable Key Binding, it includes a public key <del> associated with the Holder, or a reference thereto.  The </del>  <del> member of the </del>  <del> claim as defined in Section 3.2 of RFC7800 is suggested for doing so, however, other means can be used. </del>  It is out of the scope of this document to describe how the Holder key pair is established.  For example, the Holder MAY create a key

Reviewer comments:
More definitive language around the exclusive use of the cnf claim for enabling Key Binding might just
Need to look at text in one or more of the sec considerations too... todo
Right after the IETF 119 OAuth session yesterday in a talk with NAME and NAME that started with discussion of PR , the question again came up (with some surprise on their part) as to why the claim isn't the one and only way specified to put the holder's public key in the issuer-signed JWT. I honestly had a hard time giving a good rational for SD-JWT not being more prescriptive with it's requirements here. It seems that using the claim exclusively would be more straightforward and much better for interop. NAME has previously made similar comments, "it seems like there's an unnecessary level of ambiguity around how the Issuer-signed JWT binds to a holder public key. Can we not just say ? Why do we need more? This point actually worries me more than [others] -- without clarity on this, there is no hope of writing stacks that interop." Using the claim exclusively could also help with some clarity in the where there currently has to be wording like "[if there's] no recognized Key Binding data is present in the SD-JWT..." and " ... the Issuer might have added the key to the SD-JWT in a format/claim that is not recognized by the Verifier.". Note this is related to but separate from the question of if the presence of a claim in the issuer-signed JWT means that the verifier should have to require a KB-JWT. The claim can be made the way to do holder binding while still leaving that up to verifier policy.
I support defining as the way to do holder binding. I'll note that is extensible via a registry, so should the existing parameters not work for a use case, a new one can be defined and used.
Yep, this sounds good to me.
:+1:
maybe leaving the door open to something like
I'd be fine with having as the only defined mechanism but leaving the door open for or similar.
PR URL aims to make cnf the one true way to bind to a holder public key while leaving room (same as RFC7800) for other as yet to be defined ways to deal with more than one key

Revised text:
5.1.2. If the Issuer wants to enable Key Binding, it includes a public key  <ins> associated with the Holder, or a reference thereto, using the </ins>  <ins> claim as defined in RFC7800.  The </ins>  <ins> confirmation method, as defined in Section 3.2 of RFC7800, is suggested for doing so, however, other confirmation methods can be used. Note that, as was stated in RFC7800, if an application needs to represent multiple proof-of-possession keys in the same SD-JWT, one way to achieve this is to use other claim names, in addition to , to hold the additional proof-of-possession key information. </ins> It is out of the scope of this document to describe how the Holder key pair is established.  For example, the Holder MAY create a key