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: Add general SD-JWT VC Type Metadata framework based on NAME work: URL See preview here: URL
Yep, good point. I18N is definitely needed although I'm not too sure about name/description since those are intended for developers only, not for end-users. I'll create a ticket to consider I18N, and also discuss whether this is needed for dev-only fields. I18N is definitely something we should add to metadata but needed some PR to start with first.
We have 3 approvals and no new comments coming in after 2 weeks. I propose to merge this PR NAME NAME . PR was created 1 month ago.
We should define more clearly what a credential type (identified by the claim) actually means. The current description is a bit handwavy and that may be a sign that we have not yet defined the concept well. I think that there is a set of metadata usually associated with each SD-JWT VC type, for example Display information for the whole credential A schema for the JSON structure (may or may not be defined in JSON schema) Information about the claims, including Display information Type information Status information (self-attested vs. verified etc.) Maybe: What kind of binding is supported/usually used for this credential type Maybe: What issuers are allowed to issue this credential type Such metadata would help Wallets (e.g., for displaying the credential to the user) and Verifiers (e.g., for determining the status of claims). It would also help developers of Verifiers, as they would get structured information about the credential they can expect. The need for such metadata has been discussed in Issue and similar approaches have shown up in . The metadata may or may not be embedded into the credential itself, or provided externally. Assuming we allow for registered values (e.g., ), this metadata could go into the registry. It could also be distributed manually. But it can also be made discoverable, e.g., by providing it at a .well-known URI derived from the URL in . Here is a completely made-up example of what this metadata could look like: Important: This mechanism will not be format-agnostic, but defined only for SD-JWT VC for now.