Code change:
array instead of retrieving the respective Type Metadata elsewhere as follows: <ins> 6.4. An SD-JWT VC 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.5. 6.5.1. Schemas for Verifiable Credentials are contained in the or retrieved via the Type Metadata parameters (as defined in type-metadata-format).  A Schema MUST be represented by a JSON Schema document according to draft version 2020-12 JSON.SCHEMA.2020-12, or above. The Schema of a Verifiable Credential MUST include all properties that are required by this specification and MUST NOT override their cardinality, JSON data type, or semantic intent. The following is a non-normative example of a JSON Schema document for the example in vc-sd-jwt-example requiring the presence of the claim in an SD-JWT VC presentation: Note, that and are always required by this specification. 6.5.2. If a or property is present, a Consumer MUST validate the JSON document resulting from the SD-JWT verification algorithm (as outlined in Section 8 of I-D.ietf-oauth-selective-disclosure-jwt) against the JSON Schema document provided by the or property. If an property is present, the Schema Type Metadata of the extended type MUST also be validated in the same manner.  This process includes validating all subsequent extended types recursively until a type is encountered that does not contain an property in its Type Metadata.  Each Schema Type Metadata in this chain MUST be evaluated for a specific Verifiable Credential. If the Schema Type Metadata validation fails for any of the types in the chain, the Consumer MUST reject the Verifiable Credential. The following is a non-normative example of a result JSON document after executing the SD-JWT verification algorithm that is validated against the JSON Schema document in the example provided in schema- definition: Note, the example above does not contain any , , or claims. </ins> 7. Both the <del> claim in the SD-JWT VC and various URIs in the metadata document MAY </del> <ins> claim in the SD-JWT VC and the various URIs in the Type Metadata MAY </ins> be accompanied by a respective claim suffixed with , in particular:

Related discussion:
text: 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!