Code change:
6. <ins> 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. This section defines Type Metadata that can be associated with a type of a SD-JWT VC as well as a method for retrieving the Type Metadata and processing rules.  This Type Metadata is intended to be used, among other things, for the following purposes: Applications using Type Metadata defined in this specification are called "Consumers" in the following.  This typically includes Issuers, Verifiers, and Wallets. 6.1. All examples in this section are non-normative. Type Metadata about the value of a claim value can be retrieved as described in retrieving-type- metadata. Here, the type is . The Type Metadata is retrieved from the URL . The following is an example for a Type Metadata document: 6.2. The Type Metadata document MUST be a JSON object.  The following properties are defined: 6.3. A 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.4. 6.4.1. A URI in the claim can be used to express a type.  If the type is a URL using the HTTPS scheme, Type Metadata can be retrieved from the URL , i.e., by inserting after the authority part of the URL. The Type Metadata is retrieved using the HTTP GET method.  The response MUST be a JSON object as defined in type-metadata-format. If the claim is present in the SD-JWT VC, its value MUST be an "integrity metadata" string as defined in Section document-integrity. 6.4.2. A Consumer MAY use a registry to retrieve Type Metadata for a type, e.g., if the type is not a HTTPS URL or if the Consumer does not have access to the URL.  The registry MUST be a trusted registry, i.e., the Consumer MUST trust the registry to provide correct Type Metadata for the type. The registry MUST provide the Type Metadata in the same format as described in type-metadata-format. 6.4.3. Ecosystems MAY define additional methods for retrieving Type Metadata.  For example, a standardization body or a community MAY define a service which has to be used to retrieve Type Metadata based on a URN in the claim. 6.4.4. A Consumer MAY cache Type metadata for a type.  If a hash for integrity protection is present in the Type Metadata as defined in document-integrity, the Consumer MAY assume that the Type Metadata is static and can be cached indefinitely.  Otherwise, the Consumer MUST use the header of the HTTP response to determine how long the metadata can be cached. 6.4.5. Credentials MAY encode Type Metadata directly, providing it as "glue information" to the consumer. For JSON-serialized JWS-based credentials, such Type Metadata documents MAY be included in the unprotected header of the JWS.  In this case, the key MUST be used in the unprotected header and its value MUST be an array of base64url-encoded Type Metadata documents as defined in this specification.  Multiple documents MAY be included for providing a whole chain of types to the Consumer (see extending-type-metadata). A Consumer of a credential MAY use the documents in the array instead of retrieving the respective Type Metadata elsewhere as follows: 7. Both the claim in the SD-JWT VC and various URIs in the metadata document MAY be accompanied by a respective claim suffixed with , in particular: The value MUST be an "integrity metadata" string as defined in Section 3 of W3C.SRI.  A Consumer of the respective documents MUST verify the integrity of the retrieved document as defined in Section 3.3.5 of W3C.SRI. 8. </ins> The Security Considerations in the SD-JWT specification I-D.ietf- oauth-selective-disclosure-jwt apply to this specification. Additionally, the following security considerations need to be taken into account when using SD-JWT VCs: <del> 6.1. </del> <ins> 8.1. </ins> The JWT VC Issuer Metadata configuration is retrieved from the JWT VC Issuer by the Holder or Verifier.  Similar to other metadata

Related discussion:
text: There are overlaps with mechanisms defined in HAIP, for example, and part of this issue here is to figure out what data should go where and to avoid duplications by getting the concept right. I think that the element defined for the credential issuer metadata in could be replaced by just a identifier (the metadata could be discovered from there, or retrieved from the registry).
Interesting point, I have the following approach to satisfy the requirement of having the credential metadata along with a credential: using openid federation a trust chain is needed to attests the cryptographic keys of the issuer to verify the credential. Within the trust chain the openidcredentialissuer metadata is provided. in the openidcredentialissuer metadata there are the display information for all the credential types. Then, using this approach, the credential doesn't need any metadata. Fed trust chain can be made available in a static form, within the credential jws/MSO headers Let's see other points: I would not use , because its value seems more close to the concept of issuance type. I would say set(, ). Also the name may semantically collide with all about status lists It would be up to the trust model and the credential metadata or trust marks or attestations. We cannot allow an italian PID provider to issue a Polish PID, then the domestic italian credential identifier must be linked with one or more italian credential issuers. This information must be made available according to the infrastructure of trust, where the issued credentials are not involved yet. During a discovery phase the user/holder knows which are the credential issuers, which credential types they offers to users. Generally this is made available in the openidcredential_metadata and must be granted by an accreditation body. That's why I mentioned trusted lists or federation trust marks or X.509 custom extentions (for strong stomachs) or federation metadata policy. Without openid federation I would have to find a solution and the credential metadata sounds resonable but I use federation and this requirement is already satisfied. Another point of interest is that the credential metadata should be issued by credential issuer and bound to the credential. I would change this sentence we have in the current text: because the metadata should be issued by credential issuers and be tamper proof, otherwise a bogus implementation would use a valid credential with a fake presentation of the claims that may swaps some value and change the interpretation of the data to a verifier.