Original text:
3.5. <del> A recipient of an SD-JWT VC MUST apply the following rules to obtain the public verification key for the Issuer-signed JWT: </del>  Separate specifications or ecosystem regulations MAY define rules complementing the rules defined above, but such rules are out of scope of this specification.  See ecosystem-verification-rules for security considerations.  4. This specification defines the JWT Issuer Metadata to retrieve the

Reviewer comments:
This PR introduces the following changes: - Made all public key validation rules conditional Rejecting the SD-JWT VC if public key validation cannot be done
This harms interoperability, since some implementations will use DIDs and others will use . A more interoperable approach would be to drop and to always use DIDs. Those who want to use domain names and web servers can then still use . DIDs have always been designed as an abstraction layer for different types of resolvable identifiers. To build yet another layer of optionality, where DIDs are one option out of others, does not make much sense. Now you will have to deal with different metadata formats (JWT Issuer Metadata, and DID document). Similar arguments apply to the vs discussion. But I already know the response.. "Simple is a feature", and "DIDs have more boilerplate that is not needed", right? :)
NAME Let's have the discussion in . As long as we haven't resolved the discussion I keep the DO NOT MERGE label on it.
Let me try to update the PR.
NAME I made all rules now conditional from a verifier perspective. In this way a verifier is compliant if they don't support all rules but the SD-JWT VC would fail validation. Note, it is impossible for a verifier to support all rules that may be defined by ecosystems anyways. Are you ok with the updated language?
As a DID maximalist, I would personally prefer DIDs to be the only mechanism that is used whenever public keys are needed, instead of allowing more static public key mechanisms like "jwt-issuer" or "cnf". Unlike "jwt-issuer", DIDs support identifiers that are persistent, decentralized, and cryptographically verifiable. Unlike "cnf", DIDs support key rotation and other updates. And as I said above, with DIDs there would be only one syntax and one resolution mechanism and one metadata format, instead of multiple different ones that individual implementations may or may not support. But I also understand that for some communities, "keeping it simple" is more important than the above properties, so yes I'm fine with the language, thanks for the effort to update it!
While I understand your points, I think some of them are not true. DIDs may be decentralized, may support key rotations and may have other features. There are enough examples of DID methods that do not have those properties. Making DIDs mandatory would limit optionality. But also with DIDs the optionality in my view shifts just shifts a layer further down as there are many DID methods. Indeed allowing DIDs expands optionality by 200+ did methods, so this could indeed be a counterargument. "Cnf" isn't actually far away from DIDs, as the content can vary, there is a registry at IANA for supported methods, with different properties. In my view the cleanest approach for the keybinding would be to register a new cnf type "did" in this registry. But that's off topic in this PR. I'm fine to keep some optionality in the specification at the beginning and then see what is actually being used
True. :) But with "JWT Issuer Metadata" discovered from domain names you will never have the kind of decentralization, persistence, and cryptographic verifiability that DIDs can offer. Sounds interesting! But I agree off-topic. You can still restrict the DID methods you want to use in a specific application such as eIDAS2. For example, if you want to support 1. domain names, 2. plain public keys, and 3. EBSI, then: With the current approach in this specification: For 1. you need to support JWT Issuer Metadata (= a new format introduced by this spec). For 2. you need to support "cnf" and JWK (= a format that has been around for a long time). For 3. you need to support DID documents (= a format that has been around for a few years). Compare that to a DID-only approach: For 1. you need to support did:web (= DID document format) For 2. you need to support did:jwk (= DID document format) For 3. you need to support did:ebsi (= DID document format) You see what I mean? Yes with a DID-only approach you would still have a layer of optionality with regard to DID methods, but you'd only have that ONE layer of optionality instead of TWO layers of optionality, and you'd have a harmonized identifiers syntax and harmonized metadata format. But I understand there are communities that simply don't want to use DIDs, so I think this current PR is a good middle ground.
The current text is basically a normative requirement to support all DID resolution. Which is too much, even to the extent we want to allow for or support some DID usage. We need to revisit how this is phrased in the document and even how much (if any) is said. created from discussion in PR : B: "IMHO DIDs can be accounted/allowed for via the "Separate specifications or ecosystem regulations MAY define rules complementing the rules defined above" criteria below and shouldn't receive 1st order treatment like this in the spec." O: "We added DIDs to make the spec useful also for the credential market that uses DIDs. For those people it is required to demonstrate how that can be done. I'm wondering how other folks are thinking about dropping DIDs from getting 1st order treatment. You are right, one can create another draft that just explains how to use DIDs with this spec." Originally posted by NAME in URL
It was definitely not the intend to support all DID methods and all kind of DID resolutions. We need to make DID support optional for verifiers and if they don't have support they won't be able to verify DID-based SD-JWT VCs which is fine.
I made a proposal here

Revised text:
3.5.  <ins> A recipient of an SD-JWT VC MUST apply the following rules to validate that the public verification key for the Issuer-signed JWT corresponds to the value: </ins> Separate specifications or ecosystem regulations MAY define rules complementing the rules defined above, but such rules are out of scope of this specification.  See ecosystem-verification-rules for security considerations. <ins> If a recipient cannot validate that the public verification key corresponds to the value of the Issuer-signed JWT, the SD-JWT VC MUST be rejected. </ins> 4. This specification defines the JWT Issuer Metadata to retrieve the