Original text:
8. <del> TBD </del> 

Reviewer comments:
Clarify the optionality of the cnf claim (to
please see issue and note that the text in this PR has "This [cnf] claim MUST be present when cryptographic Key Binding is to be supported." Also note this PR isn't for issue and it was probably a mistake on my part to have suggested text there that touches two issues. But they were both on cnf so I did what I did [no pun intended]. This PR only attempts to clarify the optionality of the cnf claim for issue . There doesn't yet seem to be consensus on .
URL
NAME you probably made the comment while I was updating my original comment based on re-reading the PR. I still think it should remain "required when cryptographic binding is used"
what does this mean? you believe sd-jwt-vc should have more than one way to do cryptographic holder binding? or that many of the credentials will not use cryptographic holder binding?
No, I just mean SD-JWT VCs can be key bound, but they don't need to be. Therefore it is an optional feature.
I see, the difference here is that if key binding shall be used, then cnf must be used while the other formulation leaves more space?
If that's the intent, sounds more appropriate to me. just saying would lead to confusion that it is optional even when cryptographic binding is used.
I also like the proposed version more. The proposed language addresses which is based on developer feedback that were confused by the current language that uses REQUIRED if ... . So I think that OPTIONAL seems to solve that issue. IMO, it is also appropriate since we have the additional requirement in the paragraph that says MUST be present if cryptographic binding is required.
Sorry, I don't understand why more space is needed here? The less optionality in key binding, more interop. with the current PR, it would be ok to use a top level sub claim and put a DID there (instead of using URL). I think it is harmful for the interop, that SD-JWT VC is hoped to bring
I don't see that this optionality is allowed by the following?
I see your point. The proposed text opens a door for key binding without using the cnf claim. However, the new text is more initiative and we could add this constraint as an additional sentence or in the section on key binding
Okay, it is already present. Sorry I didn't recheck the changes. Lgtm then
I'm struggling to understand the disagreement/argument here. But I'm trying... The text for cnf in the PR has: which seems to me to clearly says that cnf is the required way to do key binding, if doing key binding. Especially the "This claim MUST be present when cryptographic Key Binding is to be supported" sentence. Would changing that sentence to "This claim is REQUIRED when cryptographic Key Binding is to be supported" help? Maybe I'm missing the point of contention but that and the current PR text and the current text in the draft all say the same thing - that cnf is the one and only way to do key binding in SD-JWT VC but b/c key binding isn't itself required, the claim also isn't required.
I thought that was better phrasing anyway so made the change w/ 9edae9d4aa1dc2b647c77029b7d415d384cded49
Seems great to me.
You're suggested pedantic wording is indeed better than what I'd had. Thanks. I've accepted it w/ c6b138036e035e6df2a2f983aa4cf8b183d39fc2
Not all VCs require key binding. For those, cnf should be made optional.
I've read the text in URL that says "REQUIRED when Cryptographic Key Binding is to be supported." as being optional or not required when key binding isn't needed. Perhaps we need to discuss and/or make things more clear?
Do you think we should also explain the OPTIONAL case or replace the REQUIRED with something else? CONDITIONAL is not a reserved word unfortunately.
I would propose to clarify this. From a quick reading this is not obviously optional and it does not match the other claims that only state REQUIRED/OPTIONAL without any conditions. As cryptographic binding is optional, I think this line should begin with "OPTIONAL. [...]"
URL attempts to do just that
thank you!lgtm, see my comment in the discussion.I like this version. CNF is more optional to me and having required as the first keyword seems less rightI'm generally fine with the change, but I think I want to be pedantic here and resolve the contradiction.

Revised text:
8.  <ins> This specification defines validation and processing rules for verifiable credentials using JSON payloads and secured by SD-JWT I- D.ietf-oauth-selective-disclosure-jwt.  Other specifications exist that define their own verifiable credential formats; for example, W3C Verifiable Credential Data Model (VCDM) 2.0 W3C.VCDM defines a data model for verifiable credentials encoded as JSON-LD, and ISO/IEC 18013-5:2021 ISO.18013-5 defines a representation of verifiable credentials in the mobile document (mdoc) format encoded as CBOR and secured using COSE. </ins>