index.html

<!DOCTYPE html>
<html>
   <head>
      <meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
      <title>Verifiable Credentials JSON Schema Specification</title>
      <script
         src="https://www.w3.org/Tools/respec/respec-w3c"
         class="remove"
         defer
         ></script>
     <script class="remove"
             src="https://cdn.jsdelivr.net/gh/transmute-industries/respec-vc-jwt@5e316347f68a638e10539bb1655a2d2c7ee49ebf/dist/main.js"></script>
      <script src="./common.js" class="remove"></script>
      <script class="remove">
         var respecConfig = {
           specStatus: "CR",
           implementationReportURI: "https://w3c.github.io/vc-json-schema-test-suite/",
           crEnd: "2024-01-17",
           group: "vc",
           shortName: "vc-json-schema",
           subtitle: "JSON Schemas for Verifiable Credentials",
           previousMaturity: "FPWD",
           previousPublishDate: "2023-05-23",
           localBiblio: vcwg.localBiblio,
           doJsonLd: true,
           xref: true,
           github: "https://github.com/w3c/vc-json-schema/",
           includePermalinks: false,
           edDraftURI: "https://w3c.github.io/vc-json-schema/",
           testSuiteURI: "https://github.com/w3c/vc-json-schema-test-suite",
           editors: [{
             name: "Gabe Cohen",
             url: "https://github.com/decentralgabe",
             company: "Block",
             companyURL: "https://www.tbd.website",
             w3cid: 116851
           }, {
             name: 'Mike Prorock',
             url: 'https://github.com/mprorock',
             company: 'mesur.io',
             companyURL: 'https://mesur.io/',
             w3cid: 130636
           }, {
             name: 'Mahmoud Alkhraishi',
             url: 'https://github.com/mkhraisha',
             company: 'Mavennet',
             companyURL: 'https://www.mavennet.com/',
             w3cid: 121911
           }],
           authors: [{
             name: "Gabe Cohen",
             url: "https://github.com/decentralgabe",
             company: "Block",
             companyURL: "https://www.tbd.website",
             w3cid: 116851
           }],
           formerEditors: [{
             name: 'Andres Uribe',
             url: 'https://github.com/andresuribe',
             company: "Block",
             companyURL: "https://www.tbd.website",
             w3cid: 140850
           }, {
             name: "Orie Steele",
             company: "Transmute",
             companyURL: "https://transmute.industries",
             w3cid: 109171,
           }],
           lint: {
             "no-unused-dfns": false
           },
           // TODO(gabe): this is broken
           // postProcess: [restrictRefs],
           maxTocLevel: 2,
           inlineCSS: true,
           postProcess: [window.respecVc.createVcExamples],
           otherLinks: [{
             key: "Related Documents",
             data: [{
               value: "Verifiable Credentials Data Model",
               href: "https://www.w3.org/TR/vc-data-model/"
             }]
           }]
         };
      </script>
      <style>
         pre .highlight {
          font-weight: bold;
          color: green;
         }
         pre .comment {
          font-weight: bold;
          color: Gray;
         }
         .color-text {
          font-weight: bold;
          text-shadow: -1px 0 black, 0 1px black, 1px 0 black, 0 -1px black;
         }
         ol.algorithm {
          counter-reset: numsection;
          list-style-type: none;
         }
         ol.algorithm li {
          margin: 0.5em 0;
         }
         ol.algorithm li:before {
          font-weight: bold;
          counter-increment: numsection;
          content: counters(numsection, ".") ") ";
         }
      </style>
   </head>
   <body>
      <section id='abstract'>
        <h2>Abstract</h2>
        <p>
          Among other things, the [[VC-DATA-MODEL-2.0]] specifies the models used for Verifiable Credentials,
          Verifiable Presentations, and explains the relationships between three parties:
          <i>issuers</i>, <i>holders</i>, and <i>verifiers</i>. Verifiability, extensibility, and semantic
          interoperability are critical pieces of functionality referenced throughout
          the [[VC-DATA-MODEL-2.0]]. This specification provides a mechanism to make use of a Credential Schema in
          <a>Verifiable Credential</a>, leveraging the existing
          <a data-cite="VC-DATA-MODEL-2.0/#data-schemas">Data Schemas</a> concept.
        </p>
      </section>
      <section id='sotd'>
        <h2>Status of This Document</h2>
         <p>
            The Working Group is actively seeking implementation feedback for this
            specification. In order to exit the Candidate Recommendation phase, the
            Working Group has set the requirement of at least two independent
            implementations for each mandatory feature in the specification. For details
            on the conformance testing process, see the test suites listed in the
            <a href="https://w3c.github.io/vc-json-schema-test-suite/">
            implementation report</a>.
         </p>
      </section>
      <section class="informative">
         <h2>Introduction</h2>
         <p>
            This specification provides a mechanism for the use of <a>JSON Schemas</a> with
            <a>Verifiable Credentials</a>. A significant part of the integrity of a <a>Verifiable Credential</a>
            comes from the ability to structure its contents so that all three parties —
            issuer, holder, verifier — may have a consistent mechanism of trust in
            interpreting the data that they are provided with. We introducing a new data
            model for an object to facilitate backing Credentials with <a>JSON Schemas</a>
            that we call a <a>Credential Schema</a>.
         </p>
         <p>
            This specification provides a standardized way of creating <a>Credential Schemas</a>
            to be used in credentialing systems. Credential Schemas may apply to any portion
            of a Verifiable Credential. Multiple JSON Schemas may back a single Verifiable Credential,
            e.g. a schema for the `credentialSubject` and another for other credential properties.
         </p>
         <section class="informative">
            <h3>Terminology</h3>
            <div data-include="terms.html"></div>
         </section>
         <section id="conformance" class="normative">
         </section>
      </section>
      <section class="normative">
         <h2>Data Model</h2>
         <p>
            The following sections outline the data models for this document, of which there are two:
            <code>JsonSchema</code> for usage of a [[JSON-SCHEMA]] directly in a <code>credentialSchema</code>
            property, and <code>JsonSchemaCredential</code> for usage of a [[JSON-SCHEMA]] represented as a
            <a>verifiable credential</a>.
         </p>
         <p>
           Implementers MAY package a [[JSON-SCHEMA]] as a <a>verifiable credential</a> when they wish to
           leverage features of the [[VC-DATA-MODEL-2.0]], answering questions such as:
          </p>
            <ul>
               <li>Who is the author of this schema? (provided by the <code>issuer</code> property)</li>
               <li>Is it schema still valid? (provided by the <code>validFrom</code>, <code>validUntil</code>, and <code>credentialStatus</code> properties)</li>
               <li>Has the schema been tampered with? (provided by <a data-cite="VC-DATA-MODEL-2.0/#securing-verifiable-credentials">
            Securing Verifiable Credentials</a>)</li>
            </ul>
         <section class="normative">
            <h3>JsonSchema</h3>
            <p>
               This term is part of the 
               <a href="https://www.w3.org/2018/credentials/#JsonSchema">Verifiable Credentials Vocabulary v2.0</a>.
            </p>
            <p>
               <b>JsonSchema</b> is used for the validation of W3C Verifiable Credentials using
               JSON Schema. When dereferencing the <code>id</code> property associated with the
               <code>JsonSchema</code> <code>type</code> value the result is a valid JSON
               Schema document according to its specification version.
            <p>
               The specification version of [[JSON-SCHEMA]] can be any version noted in the section
               on <a href="#json-schema-specifications">JSON Schema Specifications</a>.
            </p>
            <table class="simple">
              <thead>
                  <tr>
                    <th>Property</th>
                    <th>Description</th>
                  </tr>
              </thead>
              <tbody>
                  <tr>
                    <td>id</td>
                    <td>The constraints on the <code>id</code> property are listed in the Verifiable Credentials
                    Data Model specification [[VC-DATA-MODEL-2.0]]. The value MUST be a URL that identifies
                    the schema associated with the <a>verifiable credential</a>.</td>
                  </tr>
                  <tr>
                    <td>type</td>
                    <td>The <code>type</code> property MUST be <code>JsonSchema</code>.</td>
                  </tr>
              </tbody>
            </table>
            <p class="note" title="Restriction on the use of the jsonSchema property">
               The <code><a href="#jsonschema-0">jsonSchema</a></code> property is only to be used
               when the <code>JsonSchema</code> class instance is the object of the <code>credentialSubject</code>
               property within a <code><a href="#jsonschemacredential">JsonSchemaCredential</a></code> instance.
            </p>
            <p>
               An example of utilizing the VC Data Model's <code>credentialSchema</code>
               is provided below:
            </p>
            <pre class="example vc-jose-cose-vc-example" title="Example JsonSchema">
              {
                "@context": [
                  "https://www.w3.org/ns/credentials/v2",
                  "https://www.w3.org/ns/credentials/examples/v2"
                ],
                "id": "https://example.com/credentials/3732",
                "type": ["VerifiableCredential", "EmailCredential"],
                "issuer": "https://example.com/issuers/14",
                "issuanceDate": "2010-01-01T19:23:24Z",
                "credentialSubject": {
                  "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
                  "emailAddress": "subject@example.com"
                },
                "credentialSchema": {
                  "id": "https://example.com/schemas/email.json",
                  "type": "JsonSchema"
                }
              }
            </pre>
            <p>
              Upon dereferencing the value of the <code>id</code> <code>https://example.com/schemas/email.json</code>,
              a process also be referred to as <a>schema resolution</a>, the following JSON Schema 
              document is returned:
            </p>
            <pre class="example" title="Example Email JSON Schema">
            {
              "$id": "https://example.com/schemas/email.json",
              "$schema": "https://json-schema.org/draft/2020-12/schema",
              "title": "EmailCredential",
              "description": "EmailCredential using JsonSchema",
              "type": "object",
              "properties": {
                "credentialSubject": {
                  "type": "object",
                  "properties": {
                    "emailAddress": {
                      "type": "string",
                      "format": "email"
                    }
                  },
                  "required": [
                    "emailAddress"
                  ]
                }
              }
            }
            </pre>
         </section>
         <section class="normative">
            <h3>JsonSchemaCredential</h3>
            <p>
               This term is part of the 
               <a href="https://www.w3.org/2018/credentials/#JsonSchemaCredential">Verifiable Credentials Vocabulary v2.0</a>.
            </p>
            <p>
               <b>JsonSchemaCredential</b> is used for the validation of W3C Verifiable Credentials using
               JSON Schema, where the JSON Schema is contained with a <a>verifiable credential</a>.
               When dereferencing the <code>id</code> property associated with the
               <code>credentialSchema</code> <code>type</code> value, the result is a valid
               <a>verifiable credential</a>. For the resulting <a>verifiable credential</a>:
            <p>
            <ul>
              <li>
                The <code>credentialSubject</code> property MUST contain two properties:
                <ul>
                  <li><code>type</code> – the value of which MUST be <code>JsonSchema</code></li>
                  <li><a href="#jsonschema-0"><code>jsonSchema</code></a> – an object which contains a valid JSON Schema</li>
                </ul>
              </li>
              <li>
                The value of the <code>credentialSchema</code> property MUST always be set to:
                <pre title="Value of a JsonSchemaCredential's credentialSchema property">
                {
                  "id": "https://www.w3.org/ns/credentials/json-schema/v2.json",
                  "type": "JsonSchema",
                  "digestSRI": "sha384-S57yQDg1MTzF56Oi9DbSQ14u7jBy0RDdx0YbeV7shwhCS88G8SCXeFq82PafhCrW"
                }
                </pre>
                <p class="issue" title="Hash values might change during Candidate Recommendation">
                  The hash value of the <code>digestSRI</code> property might change during the Candidate Recommendation
                  phase based on implementer feedback that requires the referenced files to be modified.
                </p>
              </li>
            </ul>
            <p>
               Any version of [[JSON-SCHEMA]] in the section on
               <a href="#json-schema-specifications">JSON Schema Specifications</a>
               can be used.
            </p>
            <table class="simple">
              <thead>
                  <tr>
                    <th>Property</th>
                    <th>Description</th>
                  </tr>
              </thead>
              <tbody>
                  <tr>
                    <td>id</td>
                    <td>The constraints on the <code>id</code> property are listed in the Verifiable Credentials
                    Data Model specification [[VC-DATA-MODEL-2.0]]. The value MUST be a URL that identifies
                    the <a>verifiable credential</a> which contains a credential schema.</td>
                  </tr>
                  <tr>
                    <td>type</td>
                    <td>The <code>type</code> property MUST be <code>JsonSchemaCredential</code>.</td>
                  </tr>
                  <tr>
                    <td>credentialSubject.id</td>
                    <td>The <code>credentialSubject</code>'s <code>id</code> property MUST follow the guidance
                      provided for <a data-cite="VC-DATA-MODEL-2.0/#identifiers">identifiers</a> in the [[VC-DATA-MODEL-2.0]] 
                      specification.</td>
                  </tr>
                  <tr>
                    <td>credentialSubject.type</td>
                    <td>The <code>credentialSubject</code>'s <code>type</code> property MUST be 
                      <a href="#jsonschema">JsonSchema</a>.</td>
                  </tr>
                  <tr>
                    <td>credentialSubject.jsonSchema</td>
                    <td>The <code>credentialSubject</code> MUST use the <code>jsonSchema</code> property to 
                      represent a valid [[JSON-SCHEMA]].</td>
                  </tr>
              </tbody>
              </table>
              <p>
                An example of utilizing the VC Data Model's <code>credentialSchema</code>
                is provided below:
              </p>
              <pre class="example vc-jose-cose-vc-example" title="Example JsonSchemaCredential">
              {
                "@context": [
                  "https://www.w3.org/ns/credentials/v2",
                  "https://www.w3.org/ns/credentials/examples/v2"
                ],
                "id": "https://example.com/credentials/3733",
                "type": ["VerifiableCredential", "ExampleEmailCredential"],
                "issuer": "https://example.com/issuers/14",
                "issuanceDate": "2010-01-01T19:23:24Z",
                "credentialSubject": {
                  "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
                  "emailAddress": "subject@example.com"
                },
                "credentialSchema": {
                  "id": "https://example.com/credentials/3734",
                  "type": "JsonSchemaCredential"
                }
              }
            </pre>
            <p>
              Upon dereferencing the value of the <code>id</code> <code>https://example.com/credentials/3734</code>,
              a process also be referred to as <a>schema resolution</a>, the following verifiable credential,
              representing a JSON Schema, is returned:
            </p>
            <pre class="example vc-jose-cose-vc-example" title="Example Email Credential Schema">
            {
              "@context": [
                  "https://www.w3.org/ns/credentials/v2",
                  "https://www.w3.org/ns/credentials/examples/v2"
              ],
              "id": "https://example.com/credentials/3734",
              "type": ["VerifiableCredential", "JsonSchemaCredential"],
              "issuer": "https://example.com/issuers/14",
              "issuanceDate": "2010-01-01T19:23:24Z",
              "credentialSchema": {
                "id": "https://www.w3.org/ns/credentials/json-schema/v2.json",
                "type": "JsonSchema",
                "digestSRI": "sha384-S57yQDg1MTzF56Oi9DbSQ14u7jBy0RDdx0YbeV7shwhCS88G8SCXeFq82PafhCrW"
              },
              "credentialSubject": {
                "id": "https://example.com/schemas/email-credential-schema.json",
                "type": "JsonSchema",
                "jsonSchema": {
                    "$id": "https://example.com/schemas/email-credential-schema.json",
                    "$schema": "https://json-schema.org/draft/2020-12/schema",
                    "title": "EmailCredential",
                    "description": "EmailCredential using JsonSchemaCredential",
                    "type": "object",
                    "properties": {
                      "credentialSubject": {
                        "type": "object",
                        "properties": {
                          "emailAddress": {
                            "type": "string",
                            "format": "email"
                          }
                        },
                        "required": ["emailAddress"]
                      }
                    }
                }
              }
            }
            </pre>
            <section class="normative">
               <h4>jsonSchema</h4>
               <p>
                  This term is part of the 
                  <a href="https://www.w3.org/2018/credentials/#jsonSchema">Verifiable Credentials Vocabulary v2.0</a>.
               </p>
               <p><b>jsonSchema</b> enables the use of the <code>jsonSchema</code> property
                  within the <code>credentialSubject</code> of a verifiable credential.  The term is
                  intended to be used with the <a href="#jsonschemacredential"></a> type only. The value of
                  the <code>jsonSchema</code> property MUST be a valid [[JSON-SCHEMA]].
               </p>
               <pre class="example jsonschemacredential-jsonschema nohighlight" title="Example JsonSchema Credential with jsonSchema">
                {
                  "@context": [
                      "https://www.w3.org/ns/credentials/v2",
                      "https://www.w3.org/ns/credentials/examples/v2"
                  ],
                  "id": "https://example.com/credentials/3734",
                  "type": ["VerifiableCredential", "JsonSchemaCredential"],
                  "issuer": "https://example.com/issuers/14",
                  "issuanceDate": "2010-01-01T19:23:24Z",
                  "credentialSchema": {
                    "id": "https://www.w3.org/ns/credentials/json-schema/v2.json",
                    "type": "JsonSchema",
                  },
                  "credentialSubject": {
                    "id": "https://example.com/schemas/favorite-color-schema.json",
                    "type": "JsonSchema",
                    <span class="highlight"> "jsonSchema": {
                      "$id": "https://example.com/schemas/favorite-color-schema.json",
                      "$schema": "https://json-schema.org/draft/2020-12/schema",
                      "title": "Favorite Color Schema",
                      "description": "Favorite Color using JsonSchemaCredential",
                      "type": "object",
                      "properties": {
                        "credentialSubject": {
                          "type": "object",
                          "properties": {
                            "favoriteColor": {
                              "type": "string"
                              "enum": ["red", "orange", "green", "blue", "yellow", "purple"]
                            }
                          },
                          "required": ["favoriteColor"]
                        }
                      }
                    }
                    </span>
                  }
                }
               </pre>
               <p>
                The <code>$ref</code> property can be used to reference another jsonSchema without redefining the JSON structure.
               </p>
               <pre class="example jsonschemacredential-jsonschema-ref nohighlight" title="Example JsonSchema Credential with ref">
                {
                  "@context": [
                      "https://www.w3.org/ns/credentials/v2",
                      "https://www.w3.org/ns/credentials/examples/v2"
                  ],
                  "id": "https://example.com/credentials/3734",
                  "type": ["VerifiableCredential", "JsonSchemaCredential"],
                  "issuer": "https://example.com/issuers/14",
                  "issuanceDate": "2010-01-01T19:23:24Z",
                  "credentialSchema": {
                    "id": "https://www.w3.org/ns/credentials/json-schema/v2.json",
                    "type": "JsonSchema",
                  },
                  "credentialSubject": {
                    "id": "https://example.com/schemas/favorite-color-schema.json",
                    "type": "JsonSchema",
                    <span class="highlight"> "jsonSchema": {
                      "$ref": "https://example.com/schemas/favorite-color-schema.json"
                    }
                    </span>
                  }
                }
               </pre>
            </section>
         </section>
      </section>
      <section class="normative">
        <h2>JSON Schema Specifications</h2>
          <p>
             The following section describes the allowed specifications for 
             using a [[JSON-SCHEMA]] with a <a>credential schema</a>.
          </p>
          <p>
            To promote conformance and enable interoperability, implementers MUST
            provide support for JSON Schema specifications where, in the following table,
            the <i>required</i> column's value is <b>yes</b>.
          </p>
          <table class="simple">
             <thead>
                <tr>
                   <th style="white-space: nowrap">JSON Schema Specification</th>
                   <th>Date of Publication</th>
                   <th>$schema URI</th>
                   <th>Required</th>
                </tr>
             </thead>
             <tbody>
                <tr>
                   <td>[[JSON-SCHEMA-2020-12]]</td>
                   <td>10 June 2022</td>
                   <td><a href="https://json-schema.org/draft/2020-12/schema">https://json-schema.org/draft/2020-12/schema</a></td>
                   <td>Yes</td>
                </tr>
             </tbody>
          </table>

          <p class="note" title="A stable JSON Schema specification is coming">
           <a href="https://json-schema.org/blog/posts/future-of-json-schema">A stable JSON Schema specification</a>
           is in the works. When it's released, we intend to update this table to require the stable version.
          </p>

          <section class="normative">
            <h3>Reserved Keywords</h3>
            <p>
               JSON Schema specifications reserve certain keywords that hold specific meanings and
               functions during the processing of JSON Schemas. It is crucial to avoid using conflicting
               keys when creating JSON Schemas. The specification document for each version of JSON Schema
               lists these reserved keywords, which can be found in the table provided above.
            </p>
            <p>
               In the upcoming sections we list <i>some</i> keywords that possess unique significance in
               [[JSON-SCHEMA]] documents and SHOULD NOT be used in conflicting ways, such as redefining
               these keywords, or using them in a manner other than as noted by [[JSON-SCHEMA]] specifications.
            </p>
            <p>
               Furthermore, we identify specific keywords, that are not explicitly defined by JSON Schema,
               but are emphasized in this specification to support widespread usage.
            </p>
            <section class="normative">
               <h4>$id</h4>
               <p>
                  Across JSON Schema specifications, the <code>$id</code> keyword identifies a schema resource 
                  with its canonical URI. The <code>$id</code> MUST be present, and its value MUST represent 
                  a valid URI-reference as specified by the associated [[JSON-SCHEMA]] version.
               </p>
               <p>
                  It is RECOMMENDED that the value of the <code>$id</code> property match the <code>id</code>
                  value in the <code>credentialSchema</code> object of a <a>verifiable credential</a>, and
                  that the value of the <code>$id</code> is a dereferenceable <a>URL</a>.
               </p>
            </section>
            <section class="normative">
               <h4>$schema</h4>
               <p>
                  Across JSON Schema specifications, the <code>$schema</code> keyword identifies a JSON Schema
                  providing the feature set for a given JSON Schema specification. This property MUST be present
                  in each schema. For example, when constructing a schema for <i>Draft 2020-12</i> the value of 
                  the <code>$schema</code> identifier MUST be <code>https://json-schema.org/draft/2020-12/schema</code>.
               </p>
            </section>
            <section class="normative">
               <h4><dfn>title</dfn></h4>
               <p>
                  It is RECOMMENDED that all JSON Schemas include the optional <code>title</code> property as defined in
                  [[JSON-SCHEMA]].
               </p>
            </section>
            <section class="normative">
               <h4><dfn>description</dfn></h4>
               <p>
                  It is RECOMMENDED that all JSON Schemas include the optional <code>description</code> property as
                  defined in [[JSON-SCHEMA]].
               </p>
            </section>
            <section class="normative">
              <h4>lang</h4>
              <p>
                JSON Schemas SHOULD choose to include an optional <code>lang</code> property that indicates the
                <a data-cite="i18n-glossary/#dfn-language-tag">language tag</a> for the values of the [=title=] and
                [=description=] properties defined in the JSON Schema. The value of this field MUST be a
                <a data-cite="i18n-glossary/#dfn-canonical-unicode-locale-identifier">canonical unicode locale identifier</a>.
                When absent, implementers MUST assume that the value of this property is `und`.
              </p>
            </section>
            <section class="normative">
               <h4>dir</h4>
               <p>
                  JSON Schemas SHOULD choose to include an optional <code>dir</code> property that indicates the
                  <a data-cite="i18n-glossary/#dfn-base-direction">base direction</a> for the values of the [=title=] and [=description=] properties defined in
                  the JSON Schema. The value of this property MUST be a <a>text-direction</a>. When absent, implementers
                  MUST assume that the value of this property is "[=text-direction/auto=]".
               </p>
              <p>
                The <dfn>text-directions</dfn> are the following:
              </p>
              <dl>
                <dt>
                  "<dfn data-dfn-for="text-direction">ltr</dfn>"
                </dt>
                <dd>
                  Left-to-right text.
                </dd>
                <dt>
                  "<dfn data-dfn-for="text-direction">rtl</dfn>"
                </dt>
                <dd>
                  Right-to-left text.
                </dd>
                <dt>
                  "<dfn data-dfn-for="text-direction">auto</dfn>" (default)
                </dt>
                <dd>
                  No explicit directionality.
                </dd>
              </dl>
            </section>
          </section>
          <section class="normative">
            <h3>Representations of JSON Schema</h3>
            <p>
               The standard representation of [[JSON-SCHEMA]] uses the [[RFC8259]] JSON data interchange
               syntax with <code>.json</code> as the file extension.
            </p>
            <p>
               Implementers MAY use OpenAPI Specification's [[[OPENAPIS-3.1.0]]] [[YAML]] representation
               of a [[JSON-SCHEMA]] with <code>.yaml</code> as the file extension. 
            </p>  
            <p class="note">
              YAML representations of JSON Schemas can only be used with credential schemas whose type is <a href="#jsonschema">JsonSchema</a>.
            </p>

            An example [[JSON-SCHEMA]] using [[YAML]] is provided below.
            <pre class="example" data-include="./example/yaml-json-schema.yaml" data-include-format="yaml"></pre>
          </section>
      </section>
      <section class="normative">
        <h2>Processing</h2>
        <p>
          This section details how to process Credential Schemas, which is commonly referred to
          as <i>JSON schema validation</i>.
        <p>
        <p>
         There are many open source implementations of [[JSON-SCHEMA]] validators across many common programming
         languages. The <a href="https://openjsf.org/">OpenJS Foundation</a> maintains a list of implementations
         as a part of the <a href="https://json-schema.org/implementations.html">JSON Schema official documentation</a>.
        </p>
        <p>
         A common feature of a JSON Schema validator is the ability to detect the version of a JSON Schema document
         and select the validator for that specific version of [[JSON-SCHEMA]]. This is done by switching on the
         schema's <code>$schema</code> property and picking the corresponding validator. Schemas without a 
         <code>$schema</code> property are not considered valid and MUST NOT be processed. Implementers
         SHOULD choose validators which possess this capability and are able to limit validation to the 
         <a href="#json-schema-specifications">JSON Schema specifications</a> supported by this document.
        </p>
        <p>
         Conformant implementers MUST support JSON Schema specification versions marked as <b>required</b>
         in the table defined in the <a href="#json-schema-specifications">JSON Schema specifications section</a>
         of this document. Implementers MAY support JSON Schema specification versions not marked as
         <b>required</b>.
        </p>
        <section class="normative">
          <h3>Integrity Validation</h3>
          <p>
            Credential Schemas MAY be packaged as <a>verifiable credentials</a> as defined
            by usage of the <a href="#jsonschemacredential">JsonSchemaCredential</a> type.
            The credential containing a <a>credential schema</a> MAY be secured by using either an
            embedded or external proof as defined in <a data-cite="VC-DATA-MODEL-2.0/#securing-verifiable-credentials">
            Securing Verifiable Credentials</a>.
          </p>
          <p>
            Secured credentials representing credential schemas SHOULD first be validated
            according to the rules set out in the aforementioned securing specifications
            before proceeding with additional processing.
          </p>
          <p class="issue" data-number="143">
            Provide examples for secured credential schemas.
          </p>
          <p>
            Credential Schemas of type <a href="#jsonschema">JsonSchema</a> MAY
            be annotated with integrity information by adding the `digestSRI` property to the `credentialSchema` value
            in the Verifiable Credential which contains the schema, using the method specified in
            <a data-cite="VC-DATA-MODEL-2.0/#integrity-of-related-resources">Integrity of Related Resources</a>.
            It is RECOMMENDED that validation of the integrity of the schema be done before evaluation.
          </p>
        <p>
          An example of such usage is provided below:
        </p>
        <pre class="example vc-jose-cose-vc-example nohighlight" title="Example Verifiable Credential JsonSchema with Integrity Information">
         {
           "@context": [
             "https://www.w3.org/ns/credentials/v2",
             "https://www.w3.org/ns/credentials/examples/v2"
           ],
           "id": "https://example.com/credentials/3733",
           "type": ["VerifiableCredential", "EmailCredential"],
           "issuer": "https://example.com/issuers/14",
           "issuanceDate": "2010-01-01T19:23:24Z",
           "credentialSubject": {
             "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
             "emailAddress": "subject@example.com"
           },
          <span class="highlight"> "credentialSchema": {
             "id": "https://example.com/schemas/email.json",
             "type": "JsonSchema",
             "digestSRI": "sha384-dNwyy/Zs/YjPor8aoOgnaCqb+PH24QcNFxbxM1XoBOxdbgnpQcVaGYH8QunXww2U"
           }</span>
         }
        </pre>
        </section>
        <section class="normative">
          <h3>Evaluation</h3>
          <p>
            Validation of a given credential against a schema is to be performed according
            to its associated [[JSON-SCHEMA]] specification. Validation MUST result in one of the following three possible
            outcomes:
          </p>
          <ul>
            <li><b>Success</b> – The credential is considered to be valid against the given <a>credential schema</a>.</li>
            <li><b>Failure</b> – The credential is not considedred to be valid against the given <a>credential schema</a>.</li>
            <li><b>Indeterminate</b> – The credential could not be validated. Implementers MUST return this outcome when they encounter a schema whose version they do not support.</li>
          </ul>
          <p>
            Examples for the Success and Failure possible outcomes are provided below.
          </p>
          <section class="normative">
            <h4>Success Result</h4>
            <pre class="example" title="Example Email JSON Schema">
            {
              "$id": "https://example.com/schemas/email.json",
              "$schema": "https://json-schema.org/draft/2020-12/schema",
              "title": "EmailCredential",
              "description": "EmailCredential using JsonSchema",
              "type": "object",
              "properties": {
                "credentialSubject": {
                  "type": "object",
                  "properties": {
                    "emailAddress": {
                      "type": "string",
                      "format": "email"
                    }
                  },
                  "required": ["emailAddress"]
                }
              }
            }
            </pre>
            <p>
              Validation according to the spec [[JSON-SCHEMA-2020-12]] yields a <i>Success</i> result
              when applying it to the VC below.
            </p>
            <pre class="example vc-jose-cose-vc-example" title="Example Verifiable Credential - validation Success">
            {
              "@context": [
                "https://www.w3.org/ns/credentials/v2",
                "https://www.w3.org/ns/credentials/examples/v2"
              ],
              "id": "https://example.com/credentials/3732",
              "type": ["VerifiableCredential", "EmailCredential"],
              "issuer": "https://example.com/issuers/14",
              "issuanceDate": "2010-01-01T19:23:24Z",
              "credentialSubject": {
                "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
                "emailAddress": "subject@example.com"
              },
              "credentialSchema": {
                "id": "https://example.com/schemas/email.json",
                "type": "JsonSchema"
              }
            }
            </pre>
         </section>
         <section>
            <h4>Failure Result</h4>
            <p>
               Validation according to the spec [[JSON-SCHEMA-2020-12]] yields a <i>Failure</i> result when 
               applying it to the VC below.
            </p>
            <pre class="illegal-example vc-jose-cose-vc-example" title="Example Verifiable Credential - validation Failure">
            {
              "@context": [
                "https://www.w3.org/ns/credentials/v2",
                "https://www.w3.org/ns/credentials/examples/v2"
              ],
              "id": "https://example.com/credentials/3732",
              "type": ["VerifiableCredential", "EmailCredential"],
              "issuer": "https://example.com/issuers/14",
              "issuanceDate": "2010-01-01T19:23:24Z",
              "credentialSubject": {
                "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
                "emailAddress": "not an email"
              },
              "credentialSchema": {
                "id": "https://example.com/schemas/email.json",
                "type": "JsonSchema"
              }
            }
            </pre>
         </section>
         <section>
            <h4>Indeterminate Result</h4>   
            <p>
               Assuming that the implementer does not support [[?JSON-SCHEMA-2019-09]], an example of an <i>Indeterminate</i>
               evaluation is provided below.
            </p>
            <pre class="example" title="Example Email JSON Schema using unsupported JSON Schema version">
            {
              "$id": "https://example.com/schemas/email.json",
              "$schema": "https://json-schema.org/draft/2019-09/schema",
              "title": "EmailCredential",
              "description": "EmailCredential using JsonSchema",
              "type": "object",
              "properties": {
                "credentialSubject": {
                  "type": "object",
                  "properties": {
                    "emailAddress": {
                      "type": "string",
                      "format": "email"
                    }
                  },
                  "required": [
                    "emailAddress"
                  ]
                }
              }
            }
            </pre>
             <pre class="example vc-jose-cose-vc-example" title="Example Verifiable Credential - validation Indeterminate">
             {
               "@context": [
                 "https://www.w3.org/ns/credentials/v2",
                 "https://www.w3.org/ns/credentials/examples/v2"
               ],
               "id": "https://example.com/credentials/3732",
               "type": ["VerifiableCredential", "EmailCredential"],
               "issuer": "https://example.com/issuers/14",
               "issuanceDate": "2010-01-01T19:23:24Z",
               "credentialSubject": {
                 "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
                 "emailAddress": "not an email"
               },
               "credentialSchema": {
                 "id": "https://example.com/schemas/email.json",
                 "type": "JsonSchema"
               }
             }
             </pre>
         </section>
        </section>
      </section>
      <section class="informative">
        <h2>Implementation Considerations</h2>
        <p>
          This section details some issues implementers of the specification
          may consider.
        </p>
        <section class="informative">
          <h3>Credential Property Validation</h3>
          <p>
            Implementers may wish to validate certain properties in a 
            <a>verifiable credential</a>. To do this, <a>credential schemas</a> can be 
            constructed to validate subsets of a credential's data.
          </p>
          <p>
            One example of such a construction would be to validate the presence of certain
            top-level properties in a <a>verifiable credential</a>. The following example
            demonstrates a schema which enforces that a credential issued against it
            has an <code>validUntil</code> property and includes <code>evidence</code>.
          </p>
          <pre class="example" title="ValidUntil and Evidence Credential Schema">
          {
            "$id": "validuntil-and-evidence-schema",
            "$schema": "https://json-schema.org/draft/2020-12/schema",
            "title": "Example validUntil and evidence schema",
            "description": "Schema requiring validUntil and evidence properties",
            "type": "object",
            "properties": {
              "validUntil": {
                "type": "object"
              },
              "evidence": {
                "type": "object"
              }
            },
            "required": ["validUntil", "evidence"]
          }
          </pre>
        </section>
        <section class="informative">
          <h3>Additional Properties</h3>
          <p>
            When using [[JSON-SCHEMA]], it is advised that implementers avoid
            setting the <code>additionalProperties</code> to <i>false</i>. Doing
            so could inadvertently exclude properties in a credential from passing
            validation.
          </p>
          <p>
            As an example, consider a credential schema that is intended to validate
            the <code>credentialSubject</code> property of a credential. It is common
            for the <code>credentialSubject</code> property to include an <code>id</code>,
            denoting the identifier the subject. Not including this <code>id</code> property
            in a given schema would result in validation failure. The simple alternative
            is to avoid setting <code>additionalProperties</code> to <i>false</i>.
          </p>
          <pre class="example" title="Example Name Credential Schema">
          {
            "$id": "name-schema",
            "$schema": "https://json-schema.org/draft/2020-12/schema",
            "title": "Name schema",
            "description": "A schema capturing a human name",
            "type": "object",
            "properties": {
              "credentialSubject": {
                "type": "object",
                "properties": {
                  "name": {
                    "type": "object",
                    "properties": {
                      "firstName": {
                        "type": "string"
                      },
                      "lastName": {
                        "type": "string"
                      },
                      "additionalProperties": false
                    },
                    "required": [
                      "firstName",
                      "lastName"
                    ]
                  }
                }
              }
            }
          }
          </pre>
        </section>
        <section class="informative">
          <h3>Versioning</h3>
          <p>
            Versioning is not provided as an explicit feature of this specification.
            Implementers are advised to make backwards compatabile changes to schemas, should
            they be adjusted. Otherwise, it is advised that new <a>credential schemas</a>
            be created with unique identifiers to avoid processing conflicts.
          </p>
        </section>
        <section class="informative">
         <h3>Content Integrity Protection</h3>
         <p>
            It is important to make sure that <a>credential schemas</a> have not been tampered with
            before processing. When making use of the <code>JsonSchemaCredential2023</code> representation
            of a schema, the credential's associated integrity protection mechanism can be used to detect mutations
            of a <a>credential schema</a> via its digital signature.
         </p>
         <p>
            As an alternative, the aforementioned <a data-cite="VC-DATA-MODEL-2.0/#integrity-of-related-resources">
            Integrity of Related Resources</a> scheme may be used to provide content integrity
            protection, ensuring that the underlying <a>credential schema</a> resource has not been tampered with.
         </p>
        </section>
        <section class="informative">
          <h3>Storage</h3>
          <p>
            Credential schemas can be stored on any number of storage media such as a distributed
            ledger, traditional database, or decentralized file storage. For more robust availability
            guarantees, the same schema could be replicated across multiple file stores.
          </p>
        </section>
        <section class="informative">
          <h3>Multiple Schemas</h3>
          <p>
            A common use case is to include multiple schemas to validate against a single
            <a>verifiable Credential</a>. One such use case is to use <a href="https://github.com/w3c/vc-data-model/blob/main/schema/verifiable-credential/verifiable-credential-schema.json">the JSON Schema defined by the</a> [[VC-DATA-MODEL-2.0]] in addition to a schema to validate a specific property in the credential, such as the <code>credentialSubject</code>. Multiple schemas MAY be combined using native constructs from the [[JSON-SCHEMA]] specification, through use of properties such as <code>oneOf</code>, <code>anyOf</code>, or <code>allOf</code>.
          </p>
          <p>
            An example of how to construct such a schema using the [[JSON-SCHEMA]] property
            <code>allOf</code> is provided below, combining schemas for a <a>verifiable credential</a>,
            name, and email address:
          </p>
          <pre class="example" title="Multiple Schema Credential Schema Example">
          {
            "allOf": [
              {
                "$ref": "https://raw.githubusercontent.com/w3c/vc-data-model/main/schema/verifiable-credential/verifiable-credential-schema.json"
              },
              {
                "$id": "name-schema",
                "$schema": "https://json-schema.org/draft/2020-12/schema",
                "title": "Name schema",
                "description": "A schema capturing a human name",
                "type": "object",
                "properties": {
                  "credentialSubject": {
                    "type": "object",
                    "properties": {
                      "name": {
                        "type": "object",
                        "properties": {
                          "firstName": {
                            "type": "string"
                          },
                          "lastName": {
                            "type": "string"
                          },
                          "additionalProperties": false
                        },
                        "required": [
                          "firstName",
                          "lastName"
                        ]
                      }
                    }
                  }
                }
              },
              {
                "$id": "email-schema-1.0",
                "$schema": "https://json-schema.org/draft/2020-12/schema",
                "title": "Email schema",
                "description": "A schema requiring an email address.",
                "type": "object",
                "properties": {
                  "credentialSubject": {
                    "type": "object",
                    "properties": {
                      "email": {
                        "type": "object",
                        "properties": {
                          "emailAddress": {
                            "type": "string",
                            "format": "email"
                          }
                        },
                        "required": ["emailAddress"]
                      }
                    }
                  }
                }
              }
            ]
          }
          </pre>
          <p>
            The example above is used to validate every property in the following 
            <a>verifiable credential</a>:
          </p>
          <pre class="example vc-jose-cose-vc-example" title="Multiple Schema Verifiable Credential Example">
          {
              "@context": ["https://www.w3.org/ns/credentials/v2"],
              "id": "4995c86c-851f-43a6-9dd2-03dc891091fd",
              "type": ["VerifiableCredential"],
              "issuer": "did:example:1234",
              "validFrom": "2023-01-01T05:05:05Z",
              "credentialSubject": {
                  "firstName": "Alice",
                  "lastName": "Bobertson",
                  "emailAddress": "alice@bobertson.com"
              },
              "credentialSchema": {
                  "id": "multiple-credential-schema-test",
                  "type": "JsonSchemaCredential"
              }
          }
          </pre>
          <p>
            Using `allOf` when composing a JSON Schema can easily result in a schema for which all JSON documents will fail to validate. Such a situation may happen when multiple schemas reference the same property. Implementers are advised to test their schemas against a set of sample input documents before introducing any real world usage. Including sample input that suceeds and fails is considered a good practice.
          </p>
        </section>
        <section class="informative">
          <h3>Validity of a Verifiable Credential</h3>
          <p>
            Validation against a [[JSON-SCHEMA]] may be confused with
            <a data-cite="VC-DATA-MODEL-2.0/#dfn-credential-validation">validation</a>
            or <a data-cite="VC-DATA-MODEL-2.0/#dfn-verify">verification</a>
            of a Verifiable Credential. A valid credential according to a [[JSON-SCHEMA]] refers
            only to the structure of the claims comprising a Verifiable Credential. This idea of
            validity does not imply anything about the validity of the Verifiable Credential itself.
            It's possible for a Verifiable Credential to be considered valid by one verifier,
            while another verifier would not consider it valid.
          </p>
        </section>
        <section class="informative">
          <h3>Relationship to Verifiable Credential Type Property</h3>
          <p>
            It is common to define a <code>credential schema</code> that will be set for 
            Verifiable Credentials whose <a data-cite="VC-DATA-MODEL-2.0/#dfn-type">type</a>
            property contains a specific <code>type</code>. In this scenario, it is advised to use the value
            of the specific <code>type</code> in the <code>id</code> or in a <code>name</code> or
            <code>description</code> property.
            of a [[JSON-SCHEMA]].
          </p>
          <p>
            The example below illustrates this for <code>EmailCredential</code>:
          </p>
          <pre class="example vc-jose-cose-vc-example" title="Verifiable Credential with Schema Type">
            {
              "@context": [
                "https://www.w3.org/ns/credentials/v2",
                "https://www.w3.org/ns/credentials/examples/v2"
              ],
              "id": "https://example.com/credentials/email-credential",
              "type": ["VerifiableCredential", "EmailCredential"],
              "issuer": "https://example.com/issuers/14",
              "issuanceDate": "2010-01-01T19:23:24Z",
              "credentialSubject": {
                "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
                "emailAddress": "tester@example.com"
              },
              "credentialSchema": {
                "id": "https://example.org/examples/email.json",
                "type": "JsonSchema"
              }
            }
          </pre>
          <pre class="example" title="Schema with Matching Type Name">
            {
              "$id": "https://example.com/schemas/email.json",
              "$schema": "https://json-schema.org/draft/2020-12/schema",
              "title": "Email Credential",
              "description": "Email Credential Schema for usage in JsonSchema",
              "type": "object",
              "properties": {
                "credentialSubject": {
                  "type": "object",
                  "properties": {
                    "emailAddress": {
                      "type": "string",
                      "format": "email"
                    }
                  },
                  "required": [
                    "emailAddress"
                  ]
                }
              }
            }
          </pre>
          <p>
            It is important to note that a <a>credential schema</a> enables issuers to communicate how to process
            the structure of data inside a verifiable credential, whereas the <code>type</code> property of a <a>verifiable credential</a>
            lets issuers communicate the semantics of the data. It is advised to associate all properties
            that have a semantic mapping with a property in a <a>credential schema</a>.
          </p>
        </section>
      </section>
      <section class="informative">
         <h2>Privacy Considerations</h2>
         <p>
            This section details the general privacy considerations and specific privacy
            implications of deploying this specification into production environments.
         </p>
         <p>
            When using the <code><a href="#jsonschemacredential">JsonSchemaCredential</a></code> 
            <code>type</code>, implementers are advised to review the <a data-cite="VC-DATA-MODEL-2.0/#privacy-considerations">
            Privacy Considerations</a> outlined in the [[VC-DATA-MODEL-2.0]].
         </p>
         <section class="informative">
            <h3>Personally Identifiable Information</h3>
            <p>
               Data associated with schemas and <a>verifiable credentials</a> are susceptible
               to privacy violations when shared. Personally identifying data, such as a
               government-issued identifier, address, or name, can be used to track and correlate
               entities. Even less overt personal data such as a birthdate or postal code has
               the ability to result in correlation and de-anonymization.
            </p>
            <p>
               Implementers are strongly advised to avoid constructing schemas with any personally
               identifiable information (PII).
            </p>
            <p>
               If such personally identifiable information is necessary in a schema, or a credential
               schema, implementers are strongly advised to use mechanisms while storing and
               transporting <a>verifiable credentials</a> that protect the data from those who should
               not access it such as Transportation Layer Security (TLS) or other means of encrypting
               the data whether in transit or at rest.
            </p>
         </section>
         <section class="informative">
            <h3>Verifier Caching</h3>
            <p>
               Since schemas are immutable, they are highly cachable.
               It is possible for <a>verifiers</a> to increase the privacy of the
               <a>holder</a> whose <a>verifiable credential</a> is being checked by caching
               schemas that have been fetched from remote servers. By caching the
               content locally, less correlatable information can be inferred from
               <a>verifier</a>-based access patterns on the schema. 
            </p>
         </section>
         <section class="informative">
            <h3>Schema Resolution</h3>
            <p>
             <a>Schema resolution</a> is the process of dereferencing a credential schema's identifier in order to fetch a
             <a>credential schema</a>.
            </p>
            <p>
               <a>Issuers</a> can increase the privacy of <a>holders</a> by using
               content distribution networks to reduce or eliminate requests for the
               schemas from the <a>issuer</a>. Often, a request for a schema
               will be served by an edge device and thus be faster and reduce the load
               on the server as well as cloaking <a>verifiers</a> and <a>holders</a>
               from <a>issuers</a>.
            </p>
            <p>
             Furthermore, the use of <a href="https://ietf-wg-ohai.github.io/oblivious-http/draft-ietf-ohai-ohttp.html">Oblivious HTTP</a>
             can prevent linkage of schema requests made by <a>holders</a>. Implementers are encouraged to allow configuration
             of an <a href="https://ietf-wg-ohai.github.io/oblivious-http/draft-ietf-ohai-ohttp.html#dfn-relay">Oblivious Relay Resource</a>
             for use during <a>schema resolution</a>.
            </p>
            <p>
             When using <a>credential schema</a> identifiers that are unique to the issued credential, it is possible
             to correlate <a>schema resolution</a> of a credential with an IP address. Implementers are encouraged to prevent such
             correlation by selecting identifiers which are shared among a class of credentials.
            </p>
         </section>
         <section>
            <h3>Data Minimization</h3>
            <p>
               Data minimization refers to the principle of sharing the minimum necessary data for any given data request, such
               as a <a>verifier</a> requesting one or more <a>verifiable credentials</a> from
               a <a>holder</a>.
            </p>
            <p>
               When using a <a>credential schema</a> with a credential that supports <a>selective disclosure</a>, it may be
               possible for a <a>verifier</a> to deduce additional attributes that would be available but were not presented
               when verifying a <a>credential</a> from a <a>holder</a>. To mitigate <i>data leakage</i>, <a>holders</a> may
               choose to reject verification requests that could disclose such additional attributes, or, if the capability is
               available, to selectively disclose properties in the associated <a>credential schema</a>. To enable this functionality,
               <a>issuers</a> can use <a>selective disclosure</a> schemes when creating <a>credential schemas</a> using
               the <code><a href="#jsonschemacredential">JsonCredentialSchema</a></code> <code>type</code>.
            </p>
         </section>
      </section>
      <section class="informative">
         <h2>Security Considerations</h2>
         <p>
            There are a number of security considerations that implementers should be
            aware of when processing data described by this specification. Ignoring or
            not understanding the implications of this section can result in
            security vulnerabilities.
         </p>
         <p>
            When using the <code><a href="#jsonschemacredential">JsonSchemaCredential</a></code> 
            <code>type</code>, implementers are advised to review the <a data-cite="VC-DATA-MODEL-2.0/#security-considerations">
            Security Considerations</a> outlined in the [[VC-DATA-MODEL-2.0]].
         </p>
         <section class="informative">
            <h3>Issuer Impersonation</h3>
            <p>
               It is possible for a schema to become authoritative, such as a schema
               provided by a recognized industry group like a consortium of financial
               companies. To avoid confusion as to the authorship of <a>credential schemas</a>,
               it is advised that they be packaged as <a>verifiable credentials</a> using the
               <code><a href="#jsonschemacredential">JsonSchemaCredential</a></code> <code>type</code>.
            </p>
         </section>
      </section>
      <section class="informative">
         <h2>Accessibility Considerations</h2>
         <p>
            There are a number of accessibility considerations implementers should be
            aware of when processing data described in this specification. As with any web
            standards or protocols implementation, ignoring accessibility issues makes
            this information unusable to a large subset of the population. It is important
            to follow accessibility guidelines and standards, such as [[WCAG21]], to ensure
            all people, regardless of ability, can make use of this data. This is
            especially important when establishing systems utilizing cryptography, which
            have historically created problems for assistive technologies.
         </p>
         <p>
            JSON Schemas are designed to be a machine-readable format which provides static
            validation. As such, human readability is a secondary concern. When using a
            <a>verifiable credential</a> to represent a schema, we recommend following the
            guidance in the <a data-cite="VC-DATA-MODEL-2.0/#accessibility-considerations">VC Data Model</a>.
         </p>
      </section>
      <section class="informative">
         <h2>Internationalization Considerations</h2>
         <p>
            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 <a href="#json-schema-specifications">noted specification documents</a>
            for JSON Schema itself.
         </p>
         <p>
            When using a <a>verifiable credential</a> to represent a schema, we recommend following the
            guidance in the <a data-cite="VC-DATA-MODEL-2.0/#internationalization-considerations">VC Data Model</a>.
         </p>
      </section>
      <section class="normative">
         <h2>IANA Considerations</h2>
         <section class="normative" id="media-types">
            <h3>Media Types</h3>
            <section id="media-types-for-jsonschema">
               <h2><code>JsonSchema</code></h2>
               <p>
                  The media type <code>application/schema+json</code>, as defined in 
                  [[JSON-SCHEMA]], SHOULD be used when transmitting a [[JSON-SCHEMA]] expressed
                  as JSON over HTTP. Clients receiving [[JSON-SCHEMA]] files over HTTP MAY accept content
                  using either the <code>application/schema+json</code> media type or the 
                  <code>application/json</code> media type as defined in [[JSON]].
               </p>
               <p>
                  When using the <a href="#jsonschema">JsonSchema</a> type with a [[YAML]]
                  representation of a [[JSON-SCHEMA]], defined by [[[OPENAPIS-3.1.0]]], the types 
                  <code>application/openapi+yaml</code> or <code>application/yaml</code> MAY be used.
               </p>
            </section>  
            <section class="normative" id="media-types-for-jsonschemacredential">
               <h2><code>JsonSchemaCredential</code></h2>
               <p>
                  The media types <code>application/vc</code>, <code>application/vc+jwt</code>, or 
                  <code>application/vc+sd-jwt</code>, as defined in the [[VC-DATA-MODEL-2.0]],
                  [[VC-JOSE-COSE]], or [[SD-JWT]] specification, respectively, SHOULD be used when
                  transmitting a [[JSON-SCHEMA]] represented as a <a>verifiable credential</a> with the
                  <a href="#jsonschema">JsonSchemaCredential</a> type. Clients receiving <a>credential schemas</a>
                  files over HTTP MAY accept content using any of these types.
               </p>
            </section>
         </section>
      </section>
      <section class="informative">
         <h2>Revision History</h2>
         <p>
            This section contains the substantive changes that have been made to
            this specification over time.
         </p>
         <section>
           <h3>
              Changes since the
              <a href="https://www.w3.org/TR/2023/WD-vc-json-schema-20230915/">
              First Public Working Draft</a>:
           </h3>
           <ul>
              <li>Renamed `JsonSchema2023` to `JsonSchema`</li>
              <li>Renamed `CredentialSchema2023` to `JsonSchemaCredential`</li>
              <li>Added the `jsonSchema` type for usage within a `credentialSubject`</li>
              <li>Provided guidance on which media types should be used</li>
              <li>Added section on addressing PII in schemas</li>
              <li>Added section on using Content Integrity Protection</li>
              <li>Added text on accessibility and internationalization</li>
              <li>Added guidance on processing JSON Schemas</li>
              <li>Required the use of [[JSON-SCHEMA-2020-12]]</li>
              <li>Aligned term and vocabulary definitions with the [[VC-DATA-MODEL-2.0]]</li>
              <li>Added support for YAML representations of JSON Schemas</li>
              <li>Addressed privacy review concerns, such as advocating for the usage of OHTTP, and encouraging data minimization</li>
              <li>Remove superfluous normative references</li>
           </ul>
         </section>
      </section>
   </body>
</html>