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: Let's imagine that Giuseppe Marco would be swapped to Marco Giuseppe and pass through a supervised verifier as Marco, while the credential is still valid and verified
I like the idea to define schema and display information in the context of the credential definition (in contrast to issuance protocol) as I believe this information should be consistent across issuers and needs to be available for verifier developers. I also believe some information could be useful at the level of individual credentials for visual customization in the wallet.
we may add: type of binding of the vc ,e.g. key-binding, claim-based-binding, none vct could be either URL linking to the resource directly or an identifier that links to e.g. an (ISO) specification to get the credential metdata IANA registry is probably not a good option versioning of the metadata protection against change e.g. put a hash of metadata in the vc It might be worth to consider reducing the credential format specific Issuer metadata defined in OpenID4VCI and define that in a credential format specific credential metadata resource: However, there will remain issuer-specific things e.g. cryptographic support that should stay in the Issuer Metadata. These would need to be defined in SD-JWT-VC.
Using the VC type metadata, one could also include an ecosystem-specific parameter that contains a that allows you to map to any data model one want. It would also allow automatic fetching and executing the transformation algorithm quite easily.
I prepared a first draft for the SD-JWT VC metadata. I wrote this as a separate draft for working on it, but of course we can consider integrating this into SD-JWT VC — whatever works best. I'm looking forward to your feedback. URL
NAME I like the document and think it's a great start. I think there's a lot more to do around JSON Schema, similar to the work we've put into . I'm happy to help here. Similarly, the display reminds me of , which could be a standalone thing. Perhaps the types document should be transformed to a 'hub' document?
For all these "human readable strings", please make sure to have an i18n story, and ideally reference PRECIS, or DisplayStrings, etc .