Code change:
attacker to potentially manipulate the verification result to their advantage. <del> 7. </del> <ins> 8.3. A type MUST NOT extend another type that extends (either directly or with steps in-between) the first type.  This would result in a circular dependency that could lead to infinite recursion when retrieving and processing the metadata. Consumers MUST detect such circular dependencies and reject the credential. 8.4. In retrieving-type-metadata, various methods for distributing and retrieving metadata are described.  Methods relying on a network connection may fail due to network issues or unavailability of a network connection due to offline usage of credentials, temporary server outages, or denial of service attacks on the metadata server. Consumers SHOULD therefore implement a local cache as described in retrieval-from-local-cache if possible.  Such a cache MAY be populated with metadata before the credential is used. Issuers MAY provide glue documents as described in glue-documents to provide metadata directly with the credential and avoid the need for network requests. These measures allow the Consumders to continue to function even if the metadata server is temporarily unavailable and avoid privacy issues as described in privacy-preserving-retrieval-of-type-metadata. 9. </ins> The Privacy Considerations in the SD-JWT specification I-D.ietf- oauth-selective-disclosure-jwt apply to this specification. Additionally, the following privacy considerations need to be taken into account when using SD-JWT VCs. <del> 7.1. </del> <ins> 9.1. </ins> The Privacy Considerations in Section 12.5 of I-D.ietf-oauth- selective-disclosure-jwt apply especially to the claim. <del> 7.2. </del> <ins> 9.2. </ins> Issuers and Holders have to be aware that while this specification supports selective disclosure of claims of a given SD-JWT VC, the

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.