w3c / vc-json-schema Goto Github PK

Now that VCs can have a credential schema, its time to describe how it is used.

I think its natural to validate an incoming payload against the schema before issuing it, this is similar to the use of JSON Schema as middleware in http servers.

For credentials that are not planning on using JSON-LD, this schema checking should probably happen before emitting the credential and before consuming it. This use case is less clear to me.

Should the mardown file be renamed index.md / README.md so we can use built in github pages hosting?

https://w3c-ccg.github.io/vc-json-schemas/

• add language around drawbacks being a false sense of security on whether a VC is actually valid
• JSON Schema versions...
• probably more

The spec requires specifying a version for schemas. I'd like to propose to remove versioning.

Here's how the approach would work:

• Schemas may mutate.
• Mutation to schemas must be backwards compatible (e.g. adding a new field).
• Changes that break backwards compatibility must create a new schema.

The main advantages of a versionless schema spec are:

• Removes the need of a required field.
• No need to do dependency resolution during implementation. (e.g. the question of "is 1.0.3 allowed in the specified 1.0.* ? ")

There are some disadvantages as well:

• You won't be able to specify things like "All schemas of type x between 0.0.1 and 3.0.1 are allowed". I argue that such a disadvantage isn't that bad, because you can have a new schema for all major revisions. In the previous example, it would be "Accept the following schemas: schema_x_v0, schema_x_v1, schema_x_v2, schema_x_v3".

This is similar to approaches taken with REST apis, where the whole api is versioned, but the request schemas aren't.

Would love to hear thoughts. I admit I'm not clear on what the use cases of versioning look like so far, so feedback is more than welcome.

At the moment, these terms are defined as

• https://www.w3.org/ns/credentials/issuer-dependent#JsonSchema2023
• https://www.w3.org/ns/credentials/issuer-dependent#CredentialSchema2023

In my view, that is wrong. The issuer-dependent namespace (resulting from the @vocab introduced in the VCDM @context as a "fall-back") was not meant to express core properties.

This specification is on standard track, and therefore the terms should be placed as terms (to be more precise, RDF Classes, because they are instances of type statements) alongside the VCDM terms. This means the correct URL-s should be

• https://www.w3.org/2018/credentials#JsonSchema2023
• https://www.w3.org/2018/credentials#CredentialSchema2023

And both terms should be properly added to the VCDM Vocabulary

To be clear: this issue should not necessary delay the FPWD publication of the spec. This type of change can be done on new versions later.

cc @msporny @dlongley

Since the linked data context for the vc and the json schema for the vc serve similar purposes, how should we describe the decision to support both?

Which is more authoritative?

May be worth investigating some of the type transformation that JSON Schema supports that JSON-LD does not.

See #12 (comment)

We should add some of the learnings from the aries community on this topic to the spec, and allow for https uris, it will be easier to validate while the spec evolves, and of course any https uri can be converted to did uri using the service endpoint.

https://transmute-industries.github.io/vc-json-schema/#jsonschema

This [term definition](https://www.w3.org/TR/json-ld/#dfn-term-definition) is https://www.w3.org/ns/credentials/issuer-dependent#JsonSchema.

JsonSchema is used for validation of W3C Verifiable Credentials, based on the latest version of the living standard.

An [issuer](https://www.w3.org/TR/did-core/#identifiers) MAY include a [credentialSchema](https://www.w3.org/TR/vc-data-model/#data-schemas) of [type](https://www.w3.org/TR/json-ld/#specifying-the-type) [JsonSchema](https://transmute-industries.github.io/vc-json-schema/#dfn-jsonschema).

Could add a json schema for each supported / referenced schema version

We're on the W3C Recommendation Track.

This issue serves as a place to plan to get from our current state (ED) to a REC.

Action Items

• Progress the spec to maturity (all other open issues)
  • Move to FPWD. As of today (May 3 2023) we are close, and probably 1-2 PRs away
  • Move CR and CRD. After some time (let's say a month) at FPWD we can try to move to CR.
  • Move to PR. This step requires formal review from the W3C AC.
  • Move to REC
• Have two independent implementations. We have one at TBD. Another is being built by Transmute, so we're good here.
• Have a test suite. Need work here: #134
• We need to be able to normatively reference JSON Schema #133

This review is a Security and Privacy Self-Review for the following specifications:

• VC JSON Schema

When reviewing the Security and Privacy considerations, it is important to first be aware of the Security and Privacy Considerations for Verifiable Credentials:

• Verifiable Credential Security Considerations
• Verifiable Credential Privacy Considerations

2.1 What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?

The information epxosed to web sites or other parties includes all information in the JSON Schema, and the wrapping verifiable credential, if the type CredentialSchema2023 is used. The JSON schema and its optional associated credential are necessary to be exposed so that any recipient of a verifiable credential using VC JSON Schema can accurately validate that the credential is conformant with the data shape defined by the schema. If the schema is packaged as a credential, that credential's data is necessary to be exposed for integrity verification, and the communication of other data such as authorship information, and credential status.

What information does your spec expose to the first party that the first party cannot currently easily determine.

To the first party the spec exposes a JSON Schema and optionally a Verifiable Credential if the CredentialSchema2023 type is used. Neither of these values could be determined without their inclusion in the credentialSchema property of a verifiable credential.

Without exposure of a VC JSON Schema the first party (a verifiable credential holder) will not be able to perform a static validity check on any given verifiable credential. This static validity check is useful in enforcing that certain properties are present and of a certain shape (e.g. match a regular expression, are of a correct JSON data type). A first party such as a verifiable credential holder has an interest in determining whether the data they recieve will be considered valid by any third party.

What information does your spec expose to third parties that third parties cannot currently easily determine.

To the third party the spec exposes a JSON Schema and optionally a Verifiable Credential if the CredentialSchema2023 type is used. Neither of these values could be determined without their inclusion in the credentialSchema property of a verifiable credential.

Without exposure of a VC JSON Schema the third party (a verifiable credential verifier) will not be able to perform a static validity check on any given verifiable credential. This static validity check is useful in enforcing that certain properties are present and of a certain shape (e.g. match a regular expression, are of a correct JSON data type). A third party such as a verifiable credential verifier has an interest in determining whether the data they recieve is considered valid.

What potentially identifying information does your spec expose to the first party that the first party can already access (i.e., what identifying information does your spec duplicate or mirror).

No information is duplicated to the first party.

What potentially identifying information does your spec expose to third parties that third parties can already access.

No information is duplicated to the third party except for in the case of collusion between third parties, where VC JSON Schema values could be shared.

2.2 Do features in your specification expose the minimum amount of information necessary to enable their intended uses?

Yes. Data schemas are encouraged to use the additionalProperties feature of JSON Schemas, as noted in our specification. This encourages putting a minimal amount of data in each JSON Schema.

2.3 How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?

Any time there is an opportunity for a document's inclusion there is a risk for exposure of PII. There is nothing prohibiting a JSON Schema from including PII whilst still maintaining compliance with a given JSON Schema specification. The concerns here match those outlined in the VC Data Model itself. We have an issue open to track improving our language in this area.

2.4 How do the features in your specification deal with sensitive information?

Any time there is an opportunity for a document's inclusion there is a risk for exposure of sensitive information. There is nothing prohibiting a JSON Schema from including PII whilst still maintaining compliance with a given JSON Schema specification. The concerns here match those outlined in the VC Data Model itself. We have an issue open to track improving our language in this area.

2.5 Do the features in your specification introduce new state for an origin that persists across browsing sessions?

No.

2.6 Do the features in your specification expose information about the underlying platform to origins?

No.

2.7 Does this specification allow an origin to send data to the underlying platform?

No.

2.8 Do features in this specification enable access to device sensors?

No.

2.9 Do features in this specification enable new script execution/loading mechanisms?

No.

2.10 Do features in this specification allow an origin to access other devices?

No.

2.11 Do features in this specification allow an origin some measure of control over a user agent’s native UI?

No.

2.12 What temporary identifiers do the features in this specification create or expose to the web?

Each VC JSON Schema is identified with an id or $id property as per the associated JSON Schema specification. If the type CredentialSchema2023 is used, a new identifier for the given verifiable credential will be create. Exposure of these identifiers to the web is entirely dependent on any recipient of the document(s) publishing or making them available on the web.

2.13 How does this specification distinguish between behavior in first-party and third-party contexts?

No.

2.14 How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?

The features do not work any differently in Private Browsing or Incognito modes.

2.15 Does this specification have both "Security Considerations" and "Privacy Considerations" sections?

We have an issue open to track improving our language in this area.

2.16 Do features in your specification enable origins to downgrade default security protections?

No.

2.17 How does your feature handle non-"fully active" documents?

No.

2.18 What should this questionnaire have asked?

The questionnaire focuses on the browser security model as well as interactive user agents for the Web. While it asks important questions related to that context, it is difficult to map these questions to the usage of data schemas for a data model such as the VC Data Model.

Need language in the spec which speaks to the interoperability story around using JSON Schemas with VCs.

• Create a new directory to house the old CCG work
• Create a directory to house current version spec text
• Remove any CCG references/branding
• Change the github.io reference on the "About" part of the github home page to point at W3C
• Add some common tags, some of them (namely vc-wg) is used by some of the tools
• Add a bunch of groups on the contact list of the repo
• Update the document to note that the spec is now an "ED" (Editor's Draft)

Problem: two schemas with the same properties in different order, with all other properties constant, shouldn't be seen as different schemas. Can we canonicalize the schema?

Simply, at Workday, we've forced the alphabetization of the schema. Looking to hear what other's think.

As the title states...

• add language around how signed schemas should be handled, relation to processing logic

"type": "https://credentials.workday.com/docs/credential-schema.json"

This should point to this repo and resolve to something.

The DID Spec and the VC Data Model both have mandatory @context fields, which make it clear that these documents may support JSON-LD.

It seems likely that we should do the same thing here.

However, I have started with the assumption that those wishing to use these vc-json-schema documents do not understand JSON-LD nor will they tolerate extra parameters that are only required for JSON-LD interop.

Since we provide a demonstration of both ways to do things, its clearly possible to signal your intent to use JSON-LD by using the @context version, or not.

It would be helpful to include an example of a full verifiable credential that uses the example schema.

https://digitalbazaar.github.io/citizenship-vocab

This use case defines a context similar to the hypothetical trade-certificates context.

We could adopt a similar documentation pattern to get better alignment.

Processing may break if the credential is signed as a ZKP or is selectively disclosed.

See https://github.com/w3c/vc-data-model/pull/1112/files#r1184372781 for more information.

Our largest hurdle for this work item is being able to normatively reference JSON Schema.
JSON Schema has broad usage and industry adoption but isn't a standard in the eyes of the W3C, yet.

The latest draft of JSON Schema is being standardized in the IETF, though this make take some time, too much time for us to hit our REC goal. We can non-normatively refer to older versions of the spec. But I believe we need to normatively refer to at least one version of JSON Schema (@msporny @OR13 correct me if I'm wrong).

I believe our first step should be reaching out to contacts at the W3C and seeing if we can gain an exception for normatively referencing JSON Schema. I'm not certain how this process works. @iherman can you please advise sensible next steps?

Similar to https://w3c.github.io/vc-data-model/#personally-identifiable-information and more broadly https://w3c.github.io/vc-data-model/#privacy-considerations

• is this still active?
• is there a latest rendered draft for JSON schema validation publish?
• why is the JSON schema validation only applied to the credentialSubject rather than the top-level VC object--note, one could extend the top-level VC object as well.

From https://w3c-ccg.github.io/vc-json-schemas/#standards_compliance

W3C specification is under active development and is subject to change, we have diverged from that model with several "forks" that are fully outlined in this specification.

Is there a summary of these "forks"? I wasn't entirely sure of the "fork" list after reading the document.

Show how existing schemas can be extended using $refs: https://json-schema.org/understanding-json-schema/structuring.html

also consider a derivedFrom property

The non JSON-LD example relies on a signature suite that should be hosted and documented somewhere else.

Its also worth noting that the the signature suite approach taken for the non jsonld version is entirely custom, and not well documented or supported by existing VC libraries.

I LOVE how the specification contains DID URLs with matrix parameters, e.g.:

did:example:abcdefghi;id=17de181feb67447da4e78259d92d0240;version=1.0

Unfortunately, the DID WG decided to not support them in DID URL syntax for now, only reserve them for future use: https://www.w3.org/TR/did-core/#did-url-syntax

Therefore, the DID URLs in the specification should probably be updated to use query and/or fragment instead.

https://github.com/w3c-ccg/vc-json-schemas/blob/de387ff4d6eb1aaf3880684dad566b911b12f7fa/spec/index.bs#L97

Generic DID Parameter Name link is broken. Is it https://w3c.github.io/did-core/#did-syntax ?

Regards,

See Comments on: #1

We need to construct an example which does not use JSON-LD, and document the necessary steps for other signatures to be created.

We also need to do the same for JSON-LD... I feel it may be easier to do the JSON-LD version first, since its basically an issue of just using an off the shelf library.

The following is an Accessibility Self-Review for VC JSON Schema, namely the following specification:

• VC JSON Schema

The specification listed above is a method to define a JSON Schema for static validation of a verifiable credential. A JSON Schema and its validation are intended to be machine-readable, though they are also constructed and used by human beings.

JSON Schemas, by design, are not intended to be internationalizable, since they are used for strict static validation of data. An implementer may choose to translate a JSON Schema, or make it available in a variety of languages; however, these would be considered distinct JSON Schemas. When packaging VC JSON Schemas as verifiable credentials, implementers are encouraged to follow the guidance listed in the VC Data Model.

We believe that these specifications, in general, do not create accessibility concerns, but are curious to know if we have overlooked some aspect of how these technologies will be used that will create accessibility issues.

The following self-review question categories were analyzed and resulted in the following answers:

• The technology DO NOT allow for visual rendering of content
• The technology DO NOT provide author control over color
• The technologies DO NOT provide features to accept user input
• The technologies DO NOT provide user interaction features
• The technologies DO NOT define document semantics
• The technologies DO NOT provide time-based visual media
• The technologies DO NOT provide audio
• The technologies DO NOT allow time limits
• The technologies DO allow text content
• The technologies DO NOT create objects that don't have an inherent text representation
• The technologies DO NOT provide content fallback mechanisms, whether text or other formats
• The technologies DO NOT provide visual graphics
• The technologies DO NOT provide internationalization support
• The technologies DO NOT define accessible alternative features
• The technologies DO NOT provide content directly for end-users
• The technologies DO NOT define an API
• The technologies DO NOT define a transmission protocol

The spec currently reads "Credential Schemas are created and made available as immutable objects on a distributed ledger".

That section should be updated to reflect that schemas can be stored anywhere.

Metadata removed. If you care about those properties, wrap it in a VC.

Consider adding reserved properties to the json schema spec for additional properties. could use $id, and possibly reserve $vc.

Based on a slack conversation regarding media types for JSON Schema.

We should recommend:

application/schema+json

Or

application/schema+json; schema="http://json-schema.org/draft-07/schema#

When schemas are dereferenced via http (cover both accept and content-type headers).

Related comments:

• https://github.com/orgs/json-schema-org/discussions/198
• https://github.com/ietf-wg-httpapi/mediatypes/blob/main/draft-ietf-httpapi-rest-api-mediatypes.md#json-schema-media-types
• https://json-schema.org/draft/2020-12/json-schema-core.html#name-iana-considerations

If you use allOf there could be conflicting properties between the schemas, which would be an issue. Add guidance around this.

Which version(s) of JSON Schema are supported?
Should it be left up to implementers?
Should we call out specific versions?

see https://transmute-industries.github.io/vc-json-schema/

As a followup to #9, it would also be helpful to briefly summarize how the schema document was fetched.

In Example 11, the following is shown:

"credentialSchema": {
    "id": "did:work:MDP8AsFhHzhwUvGNuYkX7T;id=06e126d1-fa44-4882-a243-1e326fbe21db;version=1.0",
    "type": "JsonSchemaValidator2018"
  },

It would also be helpful to the reader to see how
did:work:MDP8AsFhHzhwUvGNuYkX7T;id=06e126d1-fa44-4882-a243-1e326fbe21db;version=1.0
resolved to the schema in Example 10.

• add an optional reference property to the metadata
• the property may link to a resource describing the schema, the meaning of each field, and its intended usage

This review is for the following specifications:

• VC JSON Schema

1. If the spec (or its implementation) contains any natural language text that will be read by a human (this includes error messages or other UI text, JSON strings, etc, etc), ensure that there’s metadata about and support for basic things such as language and text direction. Also check the detailed guidance for Language and Text direction.

• Not applicable

JSON Schemas are JSON text intended primarily for machines to read, since they are used for strict static validation of data. Language and text direction concerns are addressed by the noted specification documents for JSON Schema itself. When packaging VC JSON Schemas as verifiable credentials, implementers are encouraged to follow the guidance listed in the VC Data Model.

2. If the spec (or its implementation) allows content authors to produce typographically appealing text, either in its own right, or in association with graphics. take into account the different typographic styles used around the world (for things such as line-breaking, text justification, emphasis or other text decorations, text selection and units, etc.) Also check the detailed guidance for Typographic support.

• Not applicable

This specification is for machine-readable JSON processing without transformation and thus does not provide the features described in the paragraph above.

3. If the spec (or its implementation) allows the user to point into text, creates text fragments, concatenates text, allows the user to select or step through text (using a cursor or other methods), etc. make allowances for the ways different scripts handle units of text. Also check the detailed guidance for Text-processing.

• Not applicable

This specification is for machine-readable JSON processing without transformation and thus does not provide the features described in the paragraph above.

4. If the spec (or its implementation) allows searching or matching of text, including syntax and identifiers understand the implications of normalisation, case folding, etc. Also check the detailed guidance for Text-processing.

• Not applicable

Text searching and matching is the primary feature which JSON Schema provides. The documents provided in the specification note JSON Schema language which states this according to a specific version of a JSON Schema specification.

5. If the spec (or its implementation) sorts text ensure that it does so in locally relevant ways. Also check the detailed guidance for Text-processing.

• Not applicable

This specification is for machine-readable JSON processing without transformation and thus does not provide the features described in the paragraph above.

6. If the spec (or its implementation) captures user input ensure that it also captures metadata about language and text direction, and that it accommodates locale-specific input methods.

• Not applicable

This specification is for machine-readable JSON processing without transformation and thus does not provide the features described in the paragraph above.

7. If the spec (or its implementation) deals with time in any way that will be read by humans and/or crosses time zone boundaries ensure that it will represent time as expected in locales around the world, and manage the relationship between local and global/absolute time. Also check the detailed guidance for Local dates, times and formats.

• Not applicable

This specification is for machine-readable JSON processing without transformation and thus does not provide the features described in the paragraph above.

8. If the spec (or its implementation) allows any character encoding other than UTF-8. make sure you have a convincing argument as to why, and then ensure that the character encoding model is correct. Also check the detailed guidance for Characters.

• Not applicable

All character encoding for all JSON Schemas, which utilize JSON, use UTF-8 for text encoding.

9. If the spec (or its implementation) defines markup ensure support for internationalisation features and avoid putting human-readable text in attribute values or plain-text elements. Also check the detailed guidance for Markup & syntax.

• Not applicable

This specification is for machine-readable JSON processing without transformation and thus does not provide the features described in the paragraph above.

10. If the spec (or its implementation) deals with names, addresses, time & date formats, etc ensure that the model is flexible enough to cope with wide variations in format, levels of data, etc. Also check the detailed guidance for Local dates, times and formats.

• Not applicable

This specification is for machine-readable JSON processing without transformation and thus does not provide the features described in the paragraph above.

11. If the spec (or its implementation) describes a format or data that is likely to need localization. ensure that there’s an approach in place which allows effective storage and labelling of, and access to localised alternatives for strings, text, images, etc.

• Not applicable

JSON Schemas, by design, are not intended to be internationalizable, since they are used for strict static validation of data. An implementer may choose to translate a JSON Schema, or make it available in a variety of languages; however, these would be considered distinct JSON Schemas. When packaging VC JSON Schemas as verifiable credentials, implementers are encouraged to follow the guidance listed in the VC Data Model.

12. If the spec (or its implementation) makes any reference to or relies on any cultural norms ensure that it can be adapted to suit different cultural norms around the world (ranging from depictions of people or gestures, to expectations about gender roles, to approaches to work and life, etc).

• Not applicable

This specification is for machine-readable JSON processing without transformation and thus does not provide the features described in the paragraph above.

Consider a credential pointing to a single VC JSON Schema identified https://example.org/examples/verifiable-credential-schema.json

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "issuer": "https://example.edu/issuers/14",
  "issuanceDate": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "credentialSchema": {
    "id": "https://example.org/examples/verifiable-credential-schema.json",
    "type": "CredentialSchema2022"
  }
}

This schema resolves to a document such as

{
    "type": "https://w3c-ccg.github.io/vc-json-schemas/schema/2.0/schema.json",
    "version": "1.0",
    "id": "did:example:MDP8AsFhHzhwUvGNuYkX7T/06e126d1-fa44-4882-a243-1e326fbe21db?version=1.0",
    "name": "Email",
    "author": "did:example:MDP8AsFhHzhwUvGNuYkX7T",
    "authored": "2022-05-05T00:00:00+00:00",
    "path": "$.credentialSubject",
    "schemas":
    [
        {
            "path": "$.credentialSubject",
            "schema":
            {
                "$id": "name-schema-1.0",
                "$schema": "https://json-schema.org/draft/2019-09/schema",
                "description": "Name",
                "type": "object",
                "properties":
                {
                    "firstName":
                    {
                        "type": "string"
                    },
                    "lastName":
                    {
                        "type": "string"
                    }
                },
                "required":
                [
                    "firstName",
                    "lastName"
                ],
                "additionalProperties": false
            }
        },
        {
            "path": "$.credentialSubject",
            "schema":
            {
                "$id": "email-schema-1.0",
                "$schema": "https://json-schema.org/draft/2019-09/schema",
                "description": "Email",
                "type": "object",
                "properties":
                {
                    "emailAddress":
                    {
                        "type": "string",
                        "format": "email"
                    }
                },
                "required":
                [
                    "emailAddress"
                ],
                "additionalProperties": false
            }
        }
    ]
}

In this way a single VC JSON Schema can embed multiple schemas in a single document which apply to the same (or perhaps different) part(s) of a credential.

The spec does not yet provide guidance on nesting, which could pose an issue during validation.

Consider a credential representing a CredentialSchema2023. That credential could have a credentialSchema property where the type is also CredentialSchema2023, and so on, and so on... This could lead to an endless validation loop.

I propose adding language to specify that when using CredentialSchema2023 the associated VC must not have a credentialSchema property.

JSON-LD is completely orthogonal to JSON Schema:

• JSON-LD cannot validate, JSON Schema can
• JSON-LD explicates JSON terms to URLs, and can add conveniences like datatype info, name graph, container (set/list), etc. JSON Schema doesn't

In addition, while the use of credentialSchema (in particular JSON Schema) is optional in VC, JSON-LD is necessary.

So I'm puzzled by these statements:

• https://w3c-ccg.github.io/vc-json-schemas/v2/index.html#drawbacks

A new version could be introduced that supports [JSON-LD] and removes support for [JSON_SCHEMA].

• https://w3c-ccg.github.io/vc-json-schemas/v2/index.html#alternatives

[JSON-LD] is the most prominent alternative, though it does not provide the same functionality in regards to strict data validation

In particular, the latter should be changed to refer to the RDF Shape languages (SHACL and SHEX), which provide data validation features comparable to JSON Schema

Closely related to #16

Two parts:

1. The section should outline how schemas are valid (using the provided JSON Schema), along with code examples on schema building and validation.

2. Outline how Verifiable Credentials should be validated against the provided schema. Code examples provided too.

To be discussed. Examples needed on how to use both together in a VC, and why one would want to do this.

We need a test suite! There are some examples in the VCWG.

We likely need the VC verification/validation process to do a schema check according to a current draft.

Example test suites

• https://github.com/w3c-ccg/di-ed25519-test-suite/
• https://github.com/digitalbazaar/vc-data-model-2-test-suite

I'm not certain how we reference the test suite. We can likely start it alongside the code in this repository, but we may have reasons for separating it out.

Add text to provide options and guidance on how to make use of this specification with VCs.

• Single schema
• Multiple schema
• Applying to specific sections of a credential

See title

such as the $id and $schema properties

add comments on inlining and relative de-referencing ($ref) - provide guidance on using inlining