Original text:
presented at the same time, etc. It is important that a Verifier does not make its security policy <del> decisions based on data that can be influenced by an attacker or that can be misinterpreted.  For this reason, when deciding whether Key Binding is required or not, Verifiers MUST NOT take into account: </del>  If a Verifier determines that Key Binding is required for a particular use case and the Holder presents either a bare SD-JWT or

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:
presented at the same time, etc. It is important that a Verifier does not make its security policy  <ins> decisions based on data that can be influenced by an attacker.  For this reason, when deciding whether Key Binding is required or not, Verifiers MUST NOT take into account whether the Holder has provided an SD-JWT+KB or a bare SD-JWT, since otherwise an attacker could strip the KB-JWT from an SD-JWT+KB and present the resulting SD-JWT. Furthermore, Verifiers should be aware that Key Binding information may have been added to an SD-JWT in a format that they do not recognize and therefore may not be able to tell whether the SD-JWT supports Key Binding or not. </ins> If a Verifier determines that Key Binding is required for a particular use case and the Holder presents either a bare SD-JWT or