Code change:
Two approvals, merging now.
The text currently says: It must by the Issuer's choice to support either x5c, jwt-vc metadata or both, this is also how HAIP defines it. Extending this thought, the Verifier has no means of understanding what the issuer supports, given that may be an HTTPS URI but no support is avaiblable for jwt-vc metadata. This is because is the best indicator but in Section 5 only described as RECOMMENDED. Proposal is that the Issuer may chose this and that the presence of in SD-JWT VC indicates jwt-vc metadata.
This is from HAIP: By following the HAIP text, I don't understand how an issuer can support both options in an SD-JWT VC? Can you give an example? Furthermore, DNS name is not a URI and strictly speaking is this not allowed as per SD-JWT VC where has to be a URI. For that reason, SD-JWT VC says that the value needs to be encoded using the dns URI scheme. I'm not saying SD-JWT VC should not be changed in that regards because I do see some potential for improvement and I think as well that an issuer might want to support both and that needs to be addressed. We should discuss ways how this can be achieved. But I don't think is appropriate for this to control whether a verifier fetches well-known or not. I would assume that a verifier will likely know which issuer ( value) to trust and also know if the issuer is part of some trust framework that supports well-known. If not, the verifier will have to try in the same way as they try other well-knowns. I don't see the need to connect the presence of with the presence of well-known if this is what you suggested. Furthermore, I believe your specific use cases is already supported by: using an HTTPS URI for the value hosting a well-known for that URI including a x5c header with a URI SAN entry that matches the value
I don't think using to indicate whether well-known is supported is a good solution. I don't think we need this indication for the reasons pointed out above. (we can discuss whether URI scheme is a good solution in general but this is a separate topic and whether we should not limit to be a URI)
NAME at least for using kid with openid federation is resonable, because that kid is resolved within a federation trust chain
I think there is nothing wrong with: using an HTTPS URI for the value hosting a well-known for that URI including a header with a URI SAN entry that matches the iss value adding to the header In that case, using the to indicate whether well-known is supported or not would not work because like NAME mentioned, apparently OpenID federation uses as well and I believe in that case, well-known is not required. Please correct me if I'm wrong. NAME Can you explain how OpenID federation resolves the ?
To be clear, the above is valid. To be clear, the above just means that using to control how the verifier has to resolve the key does not work because people using OpenID federation might not host a well-known endpoint but will also need a .
NAME sure, thank you for asking imagine the federation trust chain like an object, related to a subject (giuseppe, a trustable entity) linked to a trust anchor (a trusted party over all the others), wwhere in the middle we may have zero, one or more intermediaries between the subject (leaf) and trust anchor. the leaf's metadata can be overloaded by the statements within the chain, along the trust anchor. Therefore the jwks the leafs claims to use, and any other protocol specific metadata, can be dynamically overloaded within the trust chain, by applying the metadata policies. once the policies are applied, the resulting metadata is called final metadata and contains all the jwks related to an entity, for each protocol (since a federation entity configuration may have more than a single metadata creafted for a speicifc role, such as VCI, RP, OP and so on). using the final metadata, the kid is needed in the form of lookup parameter within the JWKs provided within the final metadata
the resolution of the kid is interesting we may have a discovery, using well known endpoints we may have a static trust chain, provided like a x.509 certificate chain
NAME To be even more clear, they might not host a SD-JWT VC Issuer Metadata well-known endpoint but they might host an OpenID Federation well-known endpoint.
Thank you for this elaboration! It means that in this case, you won't need SD-JWT VC Issuer Metadata well-known, right?
using federation the metadata must be signed and evaluated within the trust chain, therefore, yes, there are no direct dependencies with the SD-JWT VC Issuer Metadata well-known endpoint, even if these two can cohexist within the same entity.
I'm supportive of changing value requirements for the following reasons: using could be a bit misleading using to match against the SAN DNS value is error prone (some devs might forget to do and instead do ) and perhaps misleading if does not exist (although the domain exists). Perhaps an edge case but it might have security implications.
to chage the requirement to be not a URI but a string for cases when is a DNS SAN value? the point of in HAIP was that the issuer can use the same value in sd-jwt vc to support various key resolution mechanisms - web-based key resolution (.well-known/jwtvcissuer with or without openid federation) or x509. so I am supportive of keeping a URI in sd-jwt vc, but change the scheme to as opposed to regarding your points 2 and 3, for example, in HAIP, the idea was for the issuer to support both key resolution mechanisms, so the chance of devs forgetting doing is low, and the verifier supporting x509, would have to extract dns name from as part of validations steps, so I see your points, but still think the the benefits of the same with different key resolution mechanisms is strong.
I support this, see my reasoning here: URL
NAME and I chatted briefly and are leaning towards keeping the requirement on iss to be a URI while using an https scheme for both key resolution mechanisms.
NAME said she might have some suggested text or a PR along those lines
NAME I'm going to work on this tomorrow (hopefully) so if you have anything that might help in that effort, please comment or post it or whatever works.

Related discussion:
text: array instead of retrieving the respective Type Metadata elsewhere as follows: <ins> 6.4. An SD-JWT VC type can extend another type.  The extended type is identified by the URI in the property.  Consumers MUST retrieve and process Type Metadata for the extended type before processing the Type Metadata for the extending type. The extended type MAY itself extend another type.  This can be used to create a chain or hierarchy of types.  The security considerations described in circular-extends apply in order to avoid problems with circular dependencies. 6.5. 6.5.1. Schemas for Verifiable Credentials are contained in the or retrieved via the Type Metadata parameters (as defined in type-metadata-format).  A schema MUST be represented by a JSON Schema document according to draft version 2020-12 JSON.SCHEMA.2020-12 or above. The schema of a Verifiable Credential MUST include all properties that are required by this specification and MUST NOT override their cardinality, JSON data type, or semantic intent. The following is a non-normative example of a JSON Schema document for the example in vc-sd-jwt-example requiring the presence of the claim in an SD-JWT VC presentation: Note that and are always required by this specification. 6.5.2. If a or property is present, a Consumer MUST validate the JSON document resulting from the SD-JWT verification algorithm (as defined in Section 8 of I-D.ietf-oauth-selective-disclosure-jwt) against the JSON Schema document provided by the or property. If an property is present, the schema of the extended type MUST also be validated in the same manner.  This process includes validating all subsequent extended types recursively until a type is encountered that does not contain an property in its Type Metadata.  Each schema in this chain MUST be evaluated for a specific Verifiable Credential. If the schema validation fails for any of the types in the chain, the Consumer MUST reject the Verifiable Credential. The following is a non-normative example of a result JSON document after executing the SD-JWT verification algorithm that is validated against the JSON Schema document in the example provided in schema- definition: Note, the example above does not contain any , , or claims. </ins> 7. Both the <del> claim in the SD-JWT VC and various URIs in the metadata document MAY </del> <ins> claim in the SD-JWT VC and the various URIs in the Type Metadata MAY </ins> be accompanied by a respective claim suffixed with , in particular: