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: (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.