Original text:
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>  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>  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>  6.1. All examples in this section are non-normative. <del> Type Metadata about the value of a claim value can be retrieved as described in retrieving-type- metadata. </del> Here, the type is . The Type Metadata is retrieved from the URL

Reviewer comments:
This PR includes the following: [x] Add schema type metadata [x] Add full schema type metadata examples [x] Describe base document for schema validation [x] Minor editorial fixes [x] Moved type metadata retrieval section for readability purposes [x] ~IANA considerations for , and ~ See preview here: URL Fixes URL
NAME NAME Do you think it makes sense to describe the base document for schema type metadata validation? For example, a verifier receiving an SD-JWT VC with Disclosures won't be able to validate the JSON schema against it before transforming the entire SD-JWT VC with Disclosures to expanded JSON document first.
NAME NAME Should we restrict schema to specific JSON schema versions?
I'm honestly not familiar with the intricacies of JSON schema. Is/are there a stable standard version(s) that can be referenced from a prospective RFC? The current content of the PR seems to have some normative statements but no reference. I'd think that's kind of a prerequisite to discussing version restrictions/requirements. A few minutes of looking around and I found this https://json-URL which at least suggests it's a bit messy. Any idea if/how other actual standards documents utilize JSON schema?
Well, statements like "MUST validate the Verifiable Credential against the provided JSON Schema document." probably need some more clarity about what part of the VC and at what stage of transformation/processing.
I suggest that we proceed with merging this PR nonetheless and have a separate discussion on JSON Schema versions in an issue.
Update: We don't need IANA registration for schema, schemauri and schemauri#integrity since type metadata is not a JWT.
NAME NAME Can you please check the examples I added.
I believe we will need to distinguish between presentation and issuance schemas -> see
I don't really speak JSON schema but it looks ok
Thanks a lot. I updated the PR. Will merge later on the editor's call.
Merging this since all comments were addressed.
Define how schemas can be included in type metadata. Requirement is that it should allow JSON schema.
left a couple of editorial remarks, but generally this looks good to me, thank you!

Revised text:
6.  <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  <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:  <ins> Type Metadata can be retrieved as described in retrieving-type- metadata. </ins> 6.1. All examples in this section are non-normative.  Here, the type is . The Type Metadata is retrieved from the URL