Code change:
6. <del> A type is associated with metadata defining, for example, information about the type, a schema defining which claims MAY or MUST appear in the SD-JWT VC, and how they can be displayed. </del> <ins> A SD-JWT VC type, i.e., the value, is associated with Type Metadata defining, for example, information about the type or a schema defining (see schema- definition) which claims MAY or MUST appear in the SD-JWT VC. </ins> This section defines Type Metadata that can be associated with a type <del> of a SD-JWT VC as well as a method for retrieving the Type Metadata </del> <ins> of a SD-JWT VC, as well as a method for retrieving the Type Metadata </ins> and processing rules.  This Type Metadata is intended to be used, among other things, for the following purposes: <del> Applications using Type Metadata defined in this specification are called "Consumers" in the following.  This typically includes Issuers, Verifiers, and Wallets. </del> <ins> Type Metadata can be retrieved as described in retrieving-type- metadata. </ins> 6.1. All examples in this section are non-normative. <del> Type Metadata about the value of a </del> <ins> The following is an example of an SD-JWT VC payload, containing a </ins> <del> claim value can be retrieved as described in retrieving-type- metadata. </del> <ins> claim with the value </ins> <del> Here, the type is </del> <ins> : </ins> <del> . The Type Metadata is retrieved from the URL </del> <ins> Type Metadata for the type </ins> <del> . </del> <ins> can be retrieved using various mechanisms as described in retrieving- type-metadata.  For this example, the well-known URL as defined in retrieval-from-vct-claim is used and the following Type Metadata Document is retrieved from the URL : Note: The hash of the Type Metadata document shown in the second example must be equal to the one in the </ins> <del> The following is an example for a Type Metadata document: </del> <ins> claim in the SD-JWT VC payload, . </ins> 6.2.

Related discussion:
text: 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.