index.html

<!DOCTYPE html>
<html>
  <head>
    <title>Verifiable Credentials Data Model v2.0</title>
    <meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
    <!--
      === NOTA BENE ===
      For the three scripts below, if your spec resides on dev.w3 you can check them
      out in the same tree and use relative links so that they'll work offline,
     -->
    <script src='https://www.w3.org/Tools/respec/respec-w3c' class='remove'></script>
    <script src="./common.js" class="remove"></script>
    <script class="remove"
      src="https://cdn.jsdelivr.net/gh/digitalbazaar/respec-vc@1.0.1/dist/main.js"></script>

    <script type="text/javascript" class="remove">
      var respecConfig = {
        group: "vc",

        // specification status (e.g., WD, LCWD, NOTE, etc.). If in doubt use ED.
        specStatus: "ED",

        // the specification's short name, as in http://www.w3.org/TR/short-name/
        shortName: "vc-data-model-2.0",

        // subtitle for the spec
        //subtitle: "Expressing information with verifiable provenance",

        // if you wish the publication date to be other than today, set this
        publishDate: "2022-08-11",
        //crEnd: "2019-08-21",
        //prEnd: "2019-10-01",
        //implementationReportURI: "https://w3c.github.io/vc-test-suite/implementations/",
        //errata: "https://w3c.github.io/vc-data-model/errata.html",
        previousMaturity: "REC",
        previousPublishDate: "2022-03-03",

        // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
        // and its maturity status
        // previousPublishDate:  "1977-03-15",
        // previousMaturity:  "WD",

        // extend the bibliography entries
        localBiblio: vcwg.localBiblio,
        doJsonLd: true,

        // Uncomment these to use the respec extension that generates a list of
        //   normative statements:
        preProcess: [/*prepare_reqlist*/],
        postProcess: [
          restrictRefs,
          window.respecVc.createVcExamples
          /*add_reqlist_button*/
        ],

        github: "https://github.com/w3c/vc-data-model/",
        includePermalinks: false,

        // if there a publicly available Editor's Draft, this is the link
        edDraftURI: "https://w3c.github.io/vc-data-model/",

        // if this is a LCWD, uncomment and set the end of its review period
        // lcEnd: "2009-08-05",

        // editors, add as many as you like
        // only "name" is required
        editors: [
          { name: "Manu Sporny", url: "https://www.linkedin.com/in/manusporny/",
            company: "Digital Bazaar", companyURL: "https://digitalbazaar.com/",
            note: "v1.0, v1.1, v2.0", w3cid: 41758},
          { name: "Orie Steele", url: "https://github.com/OR13",
            company: "Transmute",
            companyURL: "https://www.transmute.industries/",
            note: "v2.0", w3cid: 109171},
          { name: "Michael B. Jones", url: "https://self-issued.info/",
            company: "Microsoft", companyURL: "https://www.microsoft.com",
            note: "v2.0", w3cid: 38745},
          { name: "Gabe Cohen", url: "https://github.com/decentralgabe",
            company: "Block", companyURL: "https://block.xyz/",
            note: "v2.0", w3cid: 116851},
          { name: "Oliver Terbu", url: "https://github.com/awoie",
            company: "Spruce Systems, Inc.", companyURL: "https://spruceid.com/",
            note: "v2.0", w3cid: 110059}
        ],
        formerEditors: [
          { name: "Grant Noble", url: "https://www.linkedin.com/in/grant-noble-8253994a/",
            company: "ConsenSys", companyURL: "https://consensys.net/",
            note: "v1.0", w3cid: 110600},
          { name: "Dave Longley", url: "https://github.com/dlongley",
            company: "Digital Bazaar", companyURL: "https://digitalbazaar.com/",
            note: "v1.0", w3cid: 48025},
          { name: "Daniel C. Burnett", url: "https://www.linkedin.com/in/daburnett/",
            company: "ConsenSys", companyURL: "https://consensys.net/",
            note: "v1.0", w3cid: 37473},
          { name: "Brent Zundel", url: "https://www.linkedin.com/in/bzundel/",
            company: "Evernym", companyURL: "https://www.evernym.com/",
            note: "v1.0", w3cid: 102128},
          { name: "Kyle Den Hartog", url: "https://www.linkedin.com/in/kyledenhartog/",
            company: "MATTR", companyURL: "https://mattr.global/",
            note: "v1.1", w3cid: 103517}
        ],
        // authors, add as many as you like.
        // This is optional, uncomment if you have authors as well as editors.
        // only "name" is required. Same format as editors.
        authors:
        [
          { name: "Manu Sporny", url: "https://digitalbazaar.com/",
            company: "Digital Bazaar", companyURL: "https://digitalbazaar.com/",
            w3cid: 41758
          },
          { name: "Dave Longley", url: "https://digitalbazaar.com/",
            company: "Digital Bazaar", companyURL: "https://digitalbazaar.com/",
            w3cid: 48025
          },
          { name: "David Chadwick",
            url: "https://www.linkedin.com/in/david-chadwick-36816395/",
            company: "University of Kent",
            companyURL: "https://www.kent.ac.uk/",
            w3cid: 46156
          }
        ],

        maxTocLevel: 2,
        inlineCSS: true
      };
    </script>
    <style>
pre .highlight {
  font-weight: bold;
  color: Green;
}
pre .subject {
  font-weight: bold;
  color: RoyalBlue;
}
pre .property {
  font-weight: bold;
  color: DarkGoldenrod;
}
pre .comment {
  font-weight: bold;
  color: SteelBlue;
  -webkit-user-select: none;
  -moz-user-select: none;
  -ms-user-select: none;
  user-select: none;
}
    </style>
  </head>
  <body>
    <section id='abstract'>
      <p>
<a>Credentials</a> are a part of our daily lives; driver's licenses are used to
assert that we are capable of operating a motor vehicle, university degrees
can be used to assert our level of education, and government-issued passports
enable us to travel between countries. This specification provides a mechanism
to express these sorts of <a>credentials</a> on the Web in a way that is
cryptographically secure, privacy respecting, and machine-verifiable.
      </p>
    </section>

    <section id='sotd'>
      <p>
Comments regarding this specification are welcome at any time.
Please file issues directly on
<a href="https://github.com/w3c/vc-data-model/issues/">GitHub</a>,
or send them to
<a href="mailto:public-vc-comments@w3.org">public-vc-comments@w3.org</a>
(<a href="mailto:public-vc-comments-request@w3.org?subject=subscribe">subscribe</a>,
<a href="https://lists.w3.org/Archives/Public/public-vc-comments/">archives</a>).
      </p>

    </section>

    <section class="informative">
      <h2>Introduction</h2>

      <p>
<a>Credentials</a> are a part of our daily lives; driver's licenses are used to
assert that we are capable of operating a motor vehicle, university degrees
can be used to assert our level of education, and government-issued passports
enable us to travel between countries. These <a>credentials</a> provide
benefits to us when used in the physical world, but their use on the Web
continues to be elusive.
      </p>

      <p>
Currently it is difficult to express education qualifications, healthcare
data, financial account details, and other sorts of third-party <a>verified</a>
machine-readable personal information on the Web. The difficulty of expressing
digital <a>credentials</a> on the Web makes it challenging to receive the same
benefits through the Web that physical <a>credentials</a> provide us in the
physical world.
      </p>

      <p>
This specification provides a standard way to express <a>credentials</a> on the
Web in a way that is cryptographically secure, privacy respecting, and
machine-verifiable.
      </p>

      <p>
For those unfamiliar with the concepts related to
<a>verifiable credentials</a>, the following sections provide an overview of:
      </p>

      <ul>
        <li>
The components that constitute a <a>verifiable credential</a>
        </li>
        <li>
The components that constitute a <a>verifiable presentation</a>
        </li>
        <li>
An ecosystem where <a>verifiable credentials</a> and
<a>verifiable presentations</a> are expected to be useful
        </li>
        <li>
The use cases and requirements that informed this specification.
        </li>
      </ul>

      <section class="informative">
        <h3>What is a Verifiable Credential?</h3>

        <p>
In the physical world, a <a>credential</a> might consist of:
        </p>

        <ul>
          <li>
Information related to identifying the <a>subject</a> of the <a>credential</a>
(for example, a photo, name, or identification number)
          </li>
          <li>
Information related to the issuing authority (for example, a city government,
national agency, or certification body)
          </li>
          <li>
Information related to the type of <a>credential</a> this is (for example, a
Dutch passport, an American driving license, or a health insurance card)
          </li>
          <li>
Information related to specific attributes or properties being asserted by
the issuing authority about the <a>subject</a> (for example, nationality,
the classes of vehicle entitled to drive, or date of birth)
          </li>
          <li>
Evidence related to how the <a>credential</a> was derived
          </li>
          <li>
Information related to constraints on the credential (for example, expiration
date, or terms of use).
          </li>
        </ul>

        <p>
A <a>verifiable credential</a> can represent all of the same information that a
physical <a>credential</a> represents. The addition of technologies, such as
digital signatures, makes <a>verifiable credentials</a> more tamper-evident and
more trustworthy than their physical counterparts.
        </p>

        <p>
<a>Holders</a> of <a>verifiable credentials</a> can generate
<a>verifiable presentations</a> and then share these
<a>verifiable presentations</a> with <a>verifiers</a> to prove they possess
<a>verifiable credentials</a> with certain characteristics.
        </p>

        <p>
Both <a>verifiable credentials</a> and <a>verifiable presentations</a> can be
transmitted rapidly, making them more convenient than their physical
counterparts when trying to establish trust at a distance.
        </p>

        <p>
While this specification attempts to improve the ease of expressing digital
<a>credentials</a>, it also attempts to balance this goal with a number of
privacy-preserving goals. The persistence of digital information, and the ease
with which disparate sources of digital data can be collected and correlated,
comprise a privacy concern that the use of <a>verifiable</a> and easily
machine-readable <a>credentials</a> threatens to make worse. This document
outlines and attempts to address a number of these issues in Section
<a href="#privacy-considerations"></a>. Examples of how to use this data model
using privacy-enhancing technologies, such as zero-knowledge proofs, are also
provided throughout this document.
        </p>

        <p>
The word "verifiable" in the terms
<a>verifiable credential</a> and <a>verifiable presentation</a>
refers to the characteristic of a <a>credential</a> or <a>presentation</a>
as being able to be <a>verified</a> by a <a>verifier</a>,
as defined in this document. Verifiability of a credential does not imply
that the truth of <a>claims</a> encoded therein can be evaluated; however,
the issuer can include values in the <a>evidence</a> property to help the verifier
apply their business logic to determine whether the claims have sufficient
veracity for their needs.
        </p>
      </section>

      <section class="informative">
        <h3>Ecosystem Overview</h3>

        <p>
This section describes the roles of the core actors and the relationships
between them in an ecosystem where <a>verifiable credentials</a> are expected
to be useful. A role is an abstraction that might be implemented in many
different ways. The separation of roles suggests likely interfaces and
protocols for standardization. The following roles are introduced in this
specification:
        </p>

        <dl>
          <dt><a>holder</a></dt>
          <dd>
A role an <a>entity</a> might perform by possessing one or more
<a>verifiable credentials</a> and generating <a>verifiable presentations</a>
from them. Example holders include students, employees, and customers.
          </dd>
          <dt><a>issuer</a></dt>
          <dd>
A role an <a>entity</a> performs by asserting <a>claims</a> about one or
more <a>subjects</a>, creating a <a>verifiable credential</a> from these
<a>claims</a>, and transmitting the <a>verifiable credential</a> to a
<a>holder</a>. Example issuers include corporations, non-profit organizations,
trade associations, governments, and individuals.
          </dd>
          <dt><a>subject</a></dt>
          <dd>
An <a>entity</a> about which <a>claims</a> are made. Example subjects include
human beings, animals, and things. In many cases the <a>holder</a> of a
<a>verifiable credential</a> is the subject, but in certain cases it is not. For
example, a parent (the <a>holder</a>) might hold the
<a>verifiable credentials</a> of a child (the <a>subject</a>), or a pet owner
(the <a>holder</a>) might hold the <a>verifiable credentials</a> of their pet
(the <a>subject</a>). For more information about these special cases, see the
<a href="https://www.w3.org/TR/vc-imp-guide/#subject-holder-relationships">
Subject-Holder Relationships</a> section in the Verifiable Credentials
Implementation Guide [[VC-IMP-GUIDE]].
          </dd>
          <dt><a>verifier</a></dt>
          <dd>
A role an <a>entity</a> performs by receiving one or more
<a>verifiable credentials</a>, optionally inside a
<a>verifiable presentation</a>, for processing. Example verifiers include
employers, security personnel, and websites.
          </dd>
          <dt><a>verifiable data registry</a></dt>
          <dd>
A role a system might perform by mediating the creation and <a>verification</a>
of identifiers, keys, and other relevant data, such as
<a>verifiable credential</a> schemas, revocation registries, issuer public keys,
and so on, which might be required to use <a>verifiable credentials</a>. Some
configurations might require correlatable identifiers for <a>subjects</a>.
Example verifiable data registries include trusted databases, decentralized
databases, government ID databases, and distributed ledgers. Often
there is more than one type of verifiable data registry utilized in an
ecosystem.
          </dd>
        </dl>

        <figure id="roles">
          <img style="margin: auto; display: block; width: 75%;"
               src="diagrams/ecosystem.svg" alt="diagram showing how
               credentials flow from issuer to holder and
               presentations flow from holder to verifier where all
               three parties can use information from a logical
               verifiable data registry">
          <figcaption style="text-align: center;">
            The roles and information flows forming the basis for this specification.
          </figcaption>
        </figure>

        <p class="note">
<a href="#roles"></a> above provides an example ecosystem in which to ground the
rest of the concepts in this specification. Other ecosystems exist, such as
protected environments or proprietary systems, where
<a>verifiable credentials</a> also provide benefit.
        </p>
      </section>

      <section class="informative">
        <h3>Use Cases and Requirements</h3>

        <p>
The Verifiable Credentials Use Cases document [[VC-USE-CASES]] outlines a number
of key topics that readers might find useful, including:
        </p>

        <ul>
          <li>
A more thorough explanation of the
<a href="https://www.w3.org/TR/vc-use-cases/#user-roles">roles</a>
introduced above
          </li>
          <li>
The
<a href="https://www.w3.org/TR/vc-use-cases/#user-needs">needs</a>
identified in market verticals, such as education, finance, healthcare, retail,
professional licensing, and government
          </li>
          <li>
Common
<a href="https://www.w3.org/TR/vc-use-cases/#user-tasks">tasks</a>
performed by the roles in the ecosystem, as well as their associated
requirements
          </li>
          <li>
Common
<a href="https://www.w3.org/TR/vc-use-cases/#user-sequences">sequences
and flows</a> identified by the Working Group.
          </li>
        </ul>

        <p>
As a result of documenting and analyzing the use cases document, the following
desirable ecosystem characteristics were identified for this specification:
        </p>
<!-- requirement list start -->
        <ul>
          <li>
<a>Credentials</a> represent statements made by an <a>issuer</a>.
          </li>
          <li>
<a>Verifiable credentials</a> represent statements made by an <a>issuer</a> in
a tamper-evident and privacy-respecting manner.
          </li>
          <li>
<a>Holders</a> assemble collections of <a>credentials</a> and/or
<a>verifiable credentials</a> from different <a>issuers</a> into a single
artifact, a <a>presentation</a>.
          </li>
          <li>
Holders transform <a>presentations</a> into <a>verifiable presentations</a>
to render them tamper-evident.
          </li>
          <li>
<a>Issuers</a> can issue <a>verifiable credentials</a> about any <a>subject</a>.
          </li>
          <li>
Acting as <a>issuer</a>, <a>holder</a>, or <a>verifier</a> requires neither
registration nor approval by any authority, as the trust involved is bilateral
between parties.
          </li>
          <li>
<a>Verifiable presentations</a> allow any <a>verifier</a> to <a>verify</a> the
authenticity of <a>verifiable credentials</a> from any <a>issuer</a>.
          </li>
          <li>
<a>Holders</a> can receive <a>verifiable credentials</a> from anyone.
          </li>
          <li>
<a>Holders</a> can interact with any <a>issuer</a> and any <a>verifier</a>
through any user agent.
          </li>
          <li>
<a>Holders</a> can share <a>verifiable presentations</a>, which can then be
<a>verified</a> without revealing the identity of the <a>verifier</a> to the
<a>issuer</a>.
          </li>
          <li>
<a>Holders</a> can store <a>verifiable credentials</a> in any location, without
affecting their <a>verifiability</a> and without the <a>issuer</a> knowing
anything about where they are stored or when they are accessed.
          </li>
          <li>
<a>Holders</a> can present <a>verifiable presentations</a> to any
<a>verifier</a> without affecting authenticity of the claims and without
revealing that action to the <a>issuer</a>.
          </li>
          <li>
A <a>verifier</a> can <a>verify</a> <a>verifiable presentations</a> from any
<a>holder</a>, containing proofs of <a>claims</a> from any <a>issuer</a>.
          </li>
          <li>
<a>Verification</a> should not depend on direct interactions between
<a>issuers</a> and <a>verifiers</a>.
          </li>
          <li>
<a>Verification</a> should not reveal the identity of the <a>verifier</a> to
any <a>issuer</a>.
          </li>
          <li>
The specification must provide a means for <a>issuers</a> to issue
<a>verifiable credentials</a> that support selective disclosure, without
requiring all conformant software to support that feature.
          </li>
          <li>
<a>Issuers</a> can issue <a>verifiable credentials</a> that support
selective disclosure.
          </li>
          <li>
If a single <a>verifiable credential</a> supports selective disclosure, then
<a>holders</a> can present proofs of <a>claims</a> without revealing the entire
<a>verifiable credential</a>.
          </li>
          <li>
<a>Verifiable presentations</a> can either disclose the attributes of a
<a>verifiable credential</a>, or satisfy <a>derived predicates</a> requested by
the <a>verifier</a>. <a>Derived predicates</a> are Boolean conditions, such as
greater than, less than, equal to, is in set, and so on.
          </li>
          <li>
<a>Issuers</a> can issue revocable <a>verifiable credentials</a>.
          </li>
          <li>
The processes of cryptographically protecting <a>credentials</a> and
<a>presentations</a>, and verifying <a>verifiable credentials</a> and
<a>verifiable presentations</a>, have to be deterministic, bi-directional, and
lossless. Any verification of a <a>verifiable credential</a> or
<a>verifiable presentation</a> has to be transformable to the generic data model
defined in this document in a deterministic process, such that the resulting
<a>credential</a> or <a>presentation</a> is semantically and syntactically
equivalent to the original construct, so that it can be processed in an
interoperable fashion.
          </li>
          <li>
<a>Verifiable credentials</a> and <a>verifiable presentations</a> have to be
serializable in one or more machine-readable data formats. The process of
serialization and/or de-serialization has to be deterministic, bi-directional,
and lossless. Any serialization of a <a>verifiable credential</a> or
<a>verifiable presentation</a> needs to be transformable to the generic data
model defined in this document in a deterministic process such that the
resulting <a>verifiable credential</a> can be processed in an interoperable
fashion. The serialized form also needs to be able to be generated from the data
model without loss of data or content.
          </li>
          <li>
The data model and serialization must be extendable with minimal coordination.
          </li>
          <li>
Revocation by the <a>issuer</a> should not reveal any identifying information
about the <a>subject</a>, the <a>holder</a>, the specific
<a>verifiable credential</a>, or the <a>verifier</a>.
          </li>
          <li>
<a>Issuers</a> can disclose the revocation reason.
          </li>
          <li>
<a>Issuers</a> revoking <a>verifiable credentials</a> should distinguish between
revocation for cryptographic integrity (for example, the signing key is
compromised) versus revocation for a status change (for example, the driver’s
license is suspended).
          </li>
          <li>
<a>Issuers</a> can provide a service for refreshing a
<a>verifiable credential</a>.
          </li>
        </ul>
      </section>

      <section id="conformance" class="normative">
        <p>
A <dfn>conforming document</dfn> is any concrete expression of the data model
that complies with the normative statements in this specification.
Specifically, all relevant normative statements in Sections
<a href="#basic-concepts"></a>, <a href="#advanced-concepts"></a>, and
<a href="#syntaxes"></a> of this document MUST be enforced. A serialization
format for the conforming document MUST be deterministic, bi-directional,
and lossless as described in Section <a href="#syntaxes"></a>.
The <a>conforming document</a> MAY be transmitted or stored in any such
serialization format.
        </p>

        <p>
A <dfn class="lint-ignore">conforming processor</dfn> is any algorithm realized
as software and/or hardware that generates or consumes a <a>conforming
document</a>. Conforming processors MUST produce errors when non-conforming
documents are consumed.
        </p>

        <p>
This specification makes no normative statements with regard to the
conformance of roles in the ecosystem, such as <a>issuers</a>, <a>holders</a>,
or <a>verifiers</a>, because the conformance of ecosystem roles are highly
application, use case, and market vertical specific.
        </p>

        <p>
Digital proof mechanisms, a subset of which are digital signatures, are required
to ensure the protection of a <a>verifiable credential</a>. Having and
validating proofs, which may be dependent on the syntax of the proof
(for example, using the JSON Web Signature of a JSON Web Token for proofing a
key holder), are an essential part of processing a <a>verifiable credential</a>.
At the time of publication, Working Group members had implemented
<a>verifiable credentials</a> using at least three proof mechanisms:
        </p>

        <ul>
          <li>
JSON Web Tokens [[RFC7519]] secured using JSON Web Signatures [[RFC7515]]
          </li>
          <li>
Data Integrity Proofs [[?VC-DATA-INTEGRITY]]
          </li>
          <li>
Camenisch-Lysyanskaya Zero-Knowledge Proofs [[?CL-SIGNATURES]].
          </li>
        </ul>

        <p>
Implementers are advised to note that not all proof mechanisms are standardized
as of the publication date of this specification. The group expects some of
these mechanisms, as well as new ones, to mature independently and become
standardized in time. Given there are multiple valid proof mechanisms, this
specification does not standardize on any single digital signature mechanism.
One of the goals of this specification is to provide a data model that can be
protected by a variety of current and future digital proof mechanisms.
Conformance to this specification does not depend on the details of a particular
proof mechanism; it requires clearly identifying the mechanism a
<a>verifiable credential</a> uses.
        </p>

        <p>
This document also contains examples that contain JSON and JSON-LD content.
Some of these examples contain characters that are invalid JSON, such as
inline comments (<code>//</code>) and the use of ellipsis (<code>...</code>)
to denote information that adds little value to the example. Implementers are
cautioned to remove this content if they desire to use the information as
valid JSON or JSON-LD.
        </p>
      </section>

    </section>

    <section class="informative">
      <h2>Terminology</h2>

      <div data-include="./terms.html"></div>
    </section>

    <section class="informative">
      <h2>Core Data Model</h2>

      <p>
The following sections outline core data model concepts, such as <a>claims</a>,
<a>credentials</a>, and <a>presentations</a>, which form the foundation of this
specification.
      </p>

      <section class="informative">
        <h3>Claims</h3>

        <p>
A <a>claim</a> is a statement about a <a>subject</a>. A <a>subject</a> is a
thing about which <a>claims</a> can be made. <a>Claims</a> are expressed using
<strong><em>subject</em></strong>-<dfn data-lt="property|properties">
property</dfn>-<dfn class="lint-ignore">value</dfn> relationships.
        </p>

        <figure id="basic-structure">
          <img style="margin: auto; display: block; width: 50%;"
            src="diagrams/claim.svg" alt="subject has a property which
            has a value">
          <figcaption style="text-align: center;">
The basic structure of a claim.
          </figcaption>
        </figure>

        <p>
The data model for <a>claims</a>, illustrated in <a href="#basic-structure"></a>
above, is powerful and can be used to express a large variety of statements. For
example, whether someone graduated from a particular university can be expressed
as shown in <a href="#basic-example"></a> below.
        </p>

        <figure id="basic-example">
          <img style="margin: auto; display: block; width: 60%;"
            src="diagrams/claim-example.svg" alt="Pat has an alumniOf
            property whose value is Example University">
          <figcaption style="text-align: center;">
A basic claim expressing that Pat is an alumni of "Example University".
          </figcaption>
        </figure>

        <p>
Individual <a>claims</a> can be merged together to express a <a>graph</a> of
information about a <a>subject</a>. The example shown in
<a href="#multiple-claims"></a> below extends the previous <a>claim</a> by
adding the <a>claims</a> that Pat knows Sam and that Sam is employed as a
professor.
        </p>

        <figure id="multiple-claims">
          <img style="margin: auto; display: block; width: 75%;"
            src="diagrams/claim-extended.svg" alt="extends previous
            diagram with another property called knows whose value is
            Sam, and Sam has a property jobTitle whose value is Professor">
          <figcaption style="text-align: center;">
Multiple claims can be combined to express a graph of information.
          </figcaption>
        </figure>

        <p>
To this point, the concepts of a <a>claim</a> and a <a>graph</a> of information
are introduced. To be able to trust <a>claims</a>, more information is
expected to be added to the graph.
        </p>
      </section>

      <section class="informative">
        <h3>Credentials</h3>

        <p>
A <a>credential</a> is a set of one or more <a>claims</a> made by the same
<a>entity</a>. <a>Credentials</a> might also include an identifier and
metadata to describe properties of the <a>credential</a>, such as the
<a>issuer</a>, the expiry date and time, a representative image, a public key
to use for <a>verification</a> purposes, the revocation mechanism, and so on.
The metadata might be signed by the <a>issuer</a>. A
<a>verifiable credential</a> is a set of tamper-evident <a>claims</a> and
metadata that cryptographically prove who issued it.
        </p>

        <figure id="basic-vc">
          <img style="margin: auto; display: block; width: 50%;"
               src="diagrams/credential.svg" alt="a Verifible
               Credential contains Credential Metadata, Claim(s), and
               Proof(s)">
          <figcaption style="text-align: center;">
Basic components of a verifiable credential.
          </figcaption>
        </figure>

        <p>
Examples of <a>verifiable credentials</a> include digital employee
identification cards, digital birth certificates, and digital educational
certificates.
        </p>

        <p class="note">
<a>Credential</a> identifiers are often used to identify specific instances
of a <a>credential</a>. These identifiers can also be used for correlation. A
<a>holder</a> wanting to minimize correlation is advised to use a selective
disclosure scheme that does not reveal the <a>credential</a> identifier.
        </p>

        <p>
<a href="#basic-vc"></a> above shows the basic components of a
<a>verifiable credential</a>, but abstracts the details about how <a>claims</a>
are organized into information <a>graphs</a>, which are then organized into
<a>verifiable credentials</a>. <a href="#info-graph-vc"></a> below shows a
more complete depiction of a <a>verifiable credential</a>, which is normally
composed of at least two information <a>graphs</a>. The first <a>graph</a>
expresses the <a>verifiable credential</a> itself, which contains credential
metadata and <a>claims</a>. The second <a>graph</a> expresses the digital proof,
which is usually a digital signature.
        </p>

        <figure id="info-graph-vc">
          <img style="margin: auto; display: block; width: 100%;"
               src="diagrams/credential-graph.svg" alt="diagram with a
               Credential Graph on top connected via a proof to a
               Proof Graph on the bottom.  The Credental Graph has
               Credential 123 with 4 properties: 'type' of value
               AlumniCredential, 'issuer' of Example University,
               'issuanceDate' of 2010-01-01T19:23:24Z, and
               credentialSubject of Pat, who has an alumniOf property
               with value of Example University.  The Proof Graph has
               Signature 456 with 5 properties: 'type' of
               RsaSignature2018, 'verificationMethod' of Example University
               Public Key 7, 'created' of 2017-06-18T21:19:10Z, and 'jws'
               of 'BavEll0...3JT24='">
          <figcaption style="text-align: center;">
Information graphs associated with a basic verifiable credential.
          </figcaption>
        </figure>

        <p class="note">
It is possible to have a <a>credential</a>, such as a marriage certificate,
containing multiple <a>claims</a> about different <a>subjects</a> that are not
required to be related.
        </p>
        <p class="note">
It is possible to have a <a>credential</a> that does not contain any
<a>claims</a> about the <a>entity</a> to which the <a>credential</a> was issued.
For example, a <a>credential</a> that only contains <a>claims</a> about a
specific dog, but is issued to its owner.
        </p>
      </section>

      <section class="informative">
        <h3>Presentations</h3>

        <p>
Enhancing privacy is a key design feature of this specification. Therefore, it
is important for <a>entities</a> using this technology to be able to express
only the portions of their persona that are appropriate for a given situation.
The expression of a subset of one's persona is called a
<a>verifiable presentation</a>. Examples of different personas include a
person's professional persona, their online gaming persona, their
family persona, or an incognito persona.
        </p>

        <p>
A <a>verifiable presentation</a> expresses data from one or more
<a>verifiable credentials</a>, and is packaged in such a way that the
authorship of the data is <a>verifiable</a>. If <a>verifiable credentials</a>
are presented directly, they become <a>verifiable presentations</a>. Data
formats derived from <a>verifiable credentials</a> that are cryptographically
<a>verifiable</a>, but do not of themselves contain
<a>verifiable credentials</a>, might also be <a>verifiable presentations</a>.
        </p>

        <p>
The data in a <a>presentation</a> is often about the same <a>subject</a>, but
might have been issued by multiple <a>issuers</a>. The aggregation of this
information typically expresses an aspect of a person, organization, or
<a>entity</a>.
        </p>

        <figure id="basic-vp">
          <img style="margin: auto; display: block; width: 50%;"
            src="diagrams/presentation.svg" alt="A Verifiable
            Presentation contains Presentation Metadata, Verifiable
            Credential(s), and Proof(s)">
          <figcaption style="text-align: center;">
Basic components of a verifiable presentation.
          </figcaption>
        </figure>

        <p>
<a href="#basic-vp"></a> above shows the components of a
<a>verifiable presentation</a>, but abstracts the details about how
<a>verifiable credentials</a> are organized into information <a>graphs</a>,
which are then organized into <a>verifiable presentations</a>.
        </p>
        <p>
<a href="#info-graph-vp"></a> below shows a more complete depiction of a
<a>verifiable presentation</a>, which is normally composed of at least four
information <a>graphs</a>. The first of these information <a>graphs</a>, the
Presentation <a>Graph</a>, expresses the <a>verifiable presentation</a>
itself, which contains presentation metadata. The
<code>verifiableCredential</code> property in the Presentation <a>Graph</a>
refers to one or more <a>verifiable credentials</a>, each being one of the
second information <a>graphs</a>, i.e., a self-contained Credential
<a>Graph</a>, which in turn contains credential metadata and claims. The
third information <a>graph</a>, the Credential Proof <a>Graph</a>, expresses
the credential graph proof, which is usually a digital signature. The fourth
information <a>graph</a>, the Presentation Proof <a>Graph</a>, expresses the
presentation graph proof, which is usually a digital signature.
        </p>

        <figure id="info-graph-vp">
          <img style="margin: auto; display: block; width: 75%;"
               src="diagrams/presentation-graph.svg" alt="diagram with
               a Presentation Graph on top connected via a proof to a
               Presentation Proof Graph on the bottom.  The
               Presentation Graph has Presentation ABC with 3
               properties: 'type' of value VerifiablePresentation,
               'termsOfUse' of value Do Not Archive, and
               'verifiableCredential' whose value is Figure 6.  The
               Presentation Proof Graph has Signature 8910 with 5
               properties: 'type' of RsaSignature2018, 'verificationMethod'
               of Example Presenter Public Key 11, 'created' of
               2018-01-15T12:43:56Z, 'challenge' of d28348djsj3239, and
               'jws' of 'p2KaZ...8Fj3K='">
          <figcaption style="text-align: center;">
Information graphs associated with a basic verifiable presentation.
          </figcaption>
        </figure>

        <p class="note">
It is possible to have a <a>presentation</a>, such as a business persona, which
draws on multiple <a>credentials</a> about different <a>subjects</a> that are
often, but not required to be, related.
        </p>

      </section>

      <section class="informative">
        <h3>Concrete Lifecycle Example</h3>

        <p>
The previous sections introduced the concepts of <a>claims</a>,
<a>verifiable credentials</a>, and <a>verifiable presentations</a> using
graphical depictions. This section provides a concrete set of simple but
complete lifecycle examples of the data model expressed in one of the concrete
syntaxes supported by this specification. The lifecycle of <a>credentials</a>
and <a>presentations</a> in the
<a href="#ecosystem-overview">Verifiable Credentials Ecosystem</a> often
take a common path:
        </p>

        <ol>
          <li>
Issuance of one or more <a>verifiable credentials</a>.
          </li>
          <li>
Storage of <a>verifiable credentials</a> in a <a>credential repository</a>
(such as a digital wallet).
          </li>
          <li>
Composition of <a>verifiable credentials</a> into a
<a>verifiable presentation</a> for <a>verifiers</a>.
          </li>
          <li>
<a>Verification</a> of the <a>verifiable presentation</a> by the
<a>verifier</a>.
          </li>
        </ol>

        <p>
To illustrate this lifecycle, we will use the example of redeeming an alumni
discount from a university. In the example below, Pat receives an alumni
<a>verifiable credential</a> from a university, and Pat stores the
<a>verifiable credential</a> in a digital wallet.
        </p>

        <pre class="example nohighlight" title="A simple example of a verifiable credential">
{
  <span class='comment'>// set the context, which establishes the special terms we will be using
  // such as 'issuer' and 'alumniOf'.</span>
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  <span class='comment'>// specify the identifier for the credential</span>
  "id": "http://example.edu/credentials/1872",
  <span class='comment'>// the credential types, which declare what data to expect in the credential</span>
  "type": ["VerifiableCredential", "AlumniCredential"],
  <span class='comment'>// the entity that issued the credential</span>
  "issuer": "https://example.edu/issuers/565049",
  <span class='comment'>// when the credential was issued</span>
  "issuanceDate": "2010-01-01T19:23:24Z",
  <span class='comment'>// claims about the subjects of the credential</span>
  "credentialSubject": {
    <span class='comment'>// identifier for the only subject of the credential</span>
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    <span class='comment'>// assertion about the only subject of the credential</span>
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": [{
        "value": "Example University",
        "lang": "en"
      }, {
        "value": "Exemple d'Université",
        "lang": "fr"
      }]
    }
  },
  <span class='comment'>// digital proof that makes the credential tamper-evident</span>
  <span class='comment'>// see the NOTE at end of this section for more detail</span>
  "proof": {
    <span class='comment'>// the cryptographic signature suite that was used to generate the signature</span>
    "type": "RsaSignature2018",
    <span class='comment'>// the date the signature was created</span>
    "created": "2017-06-18T21:19:10Z",
    <span class='comment'>// purpose of this proof</span>
    "proofPurpose": "assertionMethod",
    <span class='comment'>// the identifier of the public key that can verify the signature</span>
    "verificationMethod": "https://example.edu/issuers/565049#key-1",
    <span class='comment'>// the digital signature value</span>
    "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X
      sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc
      X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj
      PAYuNzVBAh4vGHSrQyHUdBBPM"
  }
}
        </pre>

        <p>
Pat then attempts to redeem the alumni discount. The <a>verifier</a>, a ticket
sales system, states that any alumni of "Example University" receives a discount
on season tickets to sporting events. Using a mobile device, Pat starts the
process of purchasing a season ticket. A step in this process requests an alumni
<a>verifiable credential</a>, and this request is routed to Pat's digital wallet.
The digital wallet asks Pat if they would like to provide a previously issued
<a>verifiable credential</a>. Pat selects the alumni
<a>verifiable credential</a>, which is then composed into a
<a>verifiable presentation</a>. The <a>verifiable presentation</a> is sent to
the <a>verifier</a> and <a>verified</a>.
        </p>
        <pre class="example nohighlight" title="A simple example of a verifiable presentation">
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "type": "VerifiablePresentation",
  <span class='comment'>// the verifiable credential issued in the previous example</span>
  "verifiableCredential": [{
    "@context": [
      "https://www.w3.org/2018/credentials/v1",
      "https://www.w3.org/2018/credentials/examples/v1"
    ],
    "id": "http://example.edu/credentials/1872",
    "type": ["VerifiableCredential", "AlumniCredential"],
    "issuer": "https://example.edu/issuers/565049",
    "issuanceDate": "2010-01-01T19:23:24Z",
    "credentialSubject": {
      "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
      "alumniOf": {
        "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
        "name": [{
          "value": "Example University",
          "lang": "en"
        }, {
          "value": "Exemple d'Université",
          "lang": "fr"
        }]
      }
    },
    "proof": {
      "type": "RsaSignature2018",
      "created": "2017-06-18T21:19:10Z",
      "proofPurpose": "assertionMethod",
      "verificationMethod": "https://example.edu/issuers/565049#key-1",
      "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X
        sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc
        X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj
        PAYuNzVBAh4vGHSrQyHUdBBPM"
    }
  }],
  <span class='comment'>// digital signature by Pat on the presentation
  // protects against replay attacks</span>
  "proof": {
    "type": "RsaSignature2018",
    "created": "2018-09-14T21:19:10Z",
    "proofPurpose": "authentication",
    "verificationMethod": "did:example:ebfeb1f712ebc6f1c276e12ec21#keys-1",
    <span class='comment'>// 'challenge' and 'domain' protect against replay attacks</span>
    "challenge": "1f44d55f-f161-4938-a659-f8026467f126",
    "domain": "4jt78h47fh47",
    "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..kTCYt5
      XsITJX1CxPCT8yAV-TVIw5WEuts01mq-pQy7UJiN5mgREEMGlv50aqzpqh4Qq_PbChOMqs
      LfRoPsnsgxD-WUcX16dUOqV0G_zS245-kronKb78cPktb3rk-BuQy72IFLN25DYuNzVBAh
      4vGHSrQyHUGlcTwLtjPAnKb78"
  }
}
        </pre>

        <p class="note">
Implementers that are interested in understanding more about the
<code>proof</code> mechanism used above can learn more in Section <a
href="#proofs-signatures"></a> and by reading the following specifications:
Data Integrity [[?VC-DATA-INTEGRITY]], Linked Data Cryptographic Suites
Registry [[?LDP-REGISTRY]], and JSON Web Signature (JWS) Unencoded Payload Option
[[RFC7797]]. A list of proof mechanisms is available in the Verifiable
Credentials Extension Registry [[VC-EXTENSION-REGISTRY]].
        </p>
      </section>
    </section>

    <section class="normative">
      <h2>Basic Concepts</h2>

      <p>
This section introduces some basic concepts for the specification, in
preparation for Section <a href="#advanced-concepts"></a> later in the
document.
      </p>

      <section>
        <h3>Contexts</h3>

        <p>
When two software systems need to exchange data, they need to use terminology
that both systems understand. As an analogy, consider how two people
communicate. Both people must use the same language and the words they use must
mean the same thing to each other. This might be referred to as
<em>the context of a conversation</em>.
        </p>
        <p>
<a>Verifiable credentials</a> and <a>verifiable presentations</a> have many
attributes and values that are identified by <a>URIs</a> [[RFC3986]]. However,
those <a>URIs</a> can be long and not very human-friendly. In such cases,
short-form human-friendly aliases can be more helpful. This specification uses
the <code>@context</code> <a>property</a> to map such short-form aliases to the
<a>URIs</a> required by specific <a>verifiable credentials</a> and <a>verifiable
presentations</a>.
       </p>
  <p class="note">
In JSON-LD, the <code>@context</code> <a>property</a> can also be used to
communicate other details, such as datatype information, language information,
transformation rules, and so on, which are beyond the needs of this
specification, but might be useful in the future or to related work. For more
information, see
<a href="https://www.w3.org/TR/json-ld11/#the-context">Section 3.1: The Context</a>
of the [[JSON-LD]] specification.
        </p>
        <p>
<a>Verifiable credentials</a> and <a>verifiable presentations</a> MUST include a
<code>@context</code> <a>property</a>.
        </p>

        <dl>
          <dt><dfn class="lint-ignore">@context</dfn></dt>
          <dd>
The value of the <code>@context</code> <a>property</a> MUST be an ordered set
where the first item is a <a>URI</a> with the value
<code>https://www.w3.org/2018/credentials/v1</code>. For reference, a copy of
the base context is provided in Appendix <a href="#base-context"></a>.
Subsequent items in the array MUST express context information and be composed
of any combination of <a>URIs</a> or objects. It is RECOMMENDED that each
<a>URI</a> in the <code>@context</code> be one which, if dereferenced, results
in a document containing machine-readable information about the
<code>@context</code>.
          </dd>
        </dl>
        <p class="note">
Though this specification requires that a <code>@context</code> <a>property</a>
be present, it is not required that the value of the <code>@context</code>
<a>property</a> be processed using JSON-LD. This is to support processing using
plain JSON libraries, such as those that might be used when the
<a>verifiable credential</a> is encoded as a JWT. All libraries or processors
MUST ensure that the order of the values in the <code>@context</code>
<a>property</a> is what is expected for the specific application. Libraries or
processors that support JSON-LD can process the <code>@context</code>
<a>property</a> using full JSON-LD processing as expected.
        </p>
        <pre class="example nohighlight" title="Usage of the @context property">
{
  <span class="highlight">"@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ]</span>,
  "id": "http://example.edu/credentials/58473",
  "type": ["VerifiableCredential", "AlumniCredential"],
  "issuer": "https://example.edu/issuers/565049",
  "issuanceDate": "2010-01-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": [{
        "value": "Example University",
        "lang": "en"
      }, {
        "value": "Exemple d'Université",
        "lang": "fr"
      }]
    }
  },
  "proof": { <span class="comment">...</span> }
}
        </pre>

        <p>
The example above uses the base context <a>URI</a>
(<code>https://www.w3.org/2018/credentials/v1</code>) to establish that the
conversation is about a <a>verifiable credential</a>. The second <a>URI</a>
(<code>https://www.w3.org/2018/credentials/examples/v1</code>) establishes that
the conversation is about examples.
        </p>

        <p class="note">
This document uses the example context <a>URI</a>
(<code>https://www.w3.org/2018/credentials/examples/v1</code>) for the purpose
of demonstrating examples. Implementations are expected to not use this
<a>URI</a> for any other purpose, such as in pilot or production systems.
        </p>

        <p>
The data available at <code>https://www.w3.org/2018/credentials/v1</code> is a
static document that is never updated and SHOULD be downloaded and cached. The
associated human-readable vocabulary document for the Verifiable Credentials
Data Model is available at
<a href="https://www.w3.org/2018/credentials/">https://www.w3.org/2018/credentials/</a>.
This concept is further expanded on in Section <a href="#extensibility"></a>.
        </p>

      </section>

      <section>
        <h3>Identifiers</h3>

        <p>
When expressing statements about a specific thing, such as a person, product,
or organization, it is often useful to use some kind of identifier so that
others can express statements about the same thing. This specification defines
the optional <code>id</code> <a>property</a> for such identifiers. The
<code>id</code> <a>property</a> is intended to unambiguously refer to an object,
such as a person, product, or organization. Using the <code>id</code>
<a>property</a> allows for the expression of statements about specific things in
the <a>verifiable credential</a>.
        </p>

        <p>
<em>If</em> the <code>id</code> <a>property</a> is present:
        </p>

        <ul>
          <li>
The <code>id</code> <a>property</a> MUST express an identifier that others are
expected to use when expressing statements about a specific thing identified
by that identifier.
          </li>
          <li>
The <code>id</code> <a>property</a> MUST NOT have more than one value.
          </li>
          <li>
The value of the <code>id</code> <a>property</a> MUST be a <a>URI</a>.
          </li>
        </ul>

        <p class="note">
Developers should remember that identifiers might be harmful in scenarios
where pseudonymity is required. Developers are encouraged to read Section
<a href="#identifier-based-correlation"></a> carefully when considering such
scenarios. There are also other types of correlation mechanisms documented in
Section <a href="#privacy-considerations"></a> that create privacy concerns.
Where privacy is a strong consideration, the <code>id</code> <a>property</a>
MAY be omitted.
        </p>

        <dl>
          <dt><dfn class="lint-ignore">id</dfn></dt>
          <dd>
The value of the <code>id</code> <a>property</a> MUST be a single <a>URI</a>.
It is RECOMMENDED that the <a>URI</a> in the <code>id</code> be one which, if
dereferenced, results in a document containing machine-readable information
about the <code>id</code>.
          </dd>
        </dl>

        <pre class="example nohighlight vc" title="Usage of the id property"
          data-vc-vm="https://example.edu/issuers/565049#key-1">
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  <span class="highlight">"id": "http://example.edu/credentials/3732"</span>,
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "issuer": "https://example.edu/issuers/565049",
  "issuanceDate": "2010-01-01T00:00:00Z",
  "credentialSubject": {
    <span class="highlight">"id": "did:example:ebfeb1f712ebc6f1c276e12ec21"</span>,
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  }
}
        </pre>

        <p>
The example above uses two types of identifiers. The first identifier is for
the <a>verifiable credential</a> and uses an HTTP-based URL. The second
identifier is for the <a>subject</a> of the <a>verifiable credential</a> (the
thing the <a>claims</a> are about) and uses a <a>decentralized identifier</a>,
also known as a <a>DID</a>.
        </p>

        <p class="note">
As of this publication, <a>DIDs</a> are a new type of identifier that are not
necessary for <a>verifiable credentials</a> to be useful. Specifically,
<a>verifiable credentials</a> do not depend on <a>DIDs</a> and <a>DIDs</a> do
not depend on <a>verifiable credentials</a>. However, it is expected that many
<a>verifiable credentials</a> will use <a>DIDs</a> and that software libraries
implementing this specification will probably need to resolve <a>DIDs</a>.
<a>DID</a>-based URLs are used for expressing identifiers associated with
<a>subjects</a>, <a>issuers</a>, <a>holders</a>, credential status lists,
cryptographic keys, and other machine-readable information associated with a
<a>verifiable credential</a>.
        </p>
      </section>

      <section>
        <h3>Types</h3>

        <p>
Software systems that process the kinds of objects specified in this document
use type information to determine whether or not a provided
<a>verifiable credential</a> or <a>verifiable presentation</a> is appropriate.
This specification defines a <code>type</code> <a>property</a> for the
expression of type information.
        </p>

        <p>
<a>Verifiable credentials</a> and <a>verifiable presentations</a> MUST have a
<code>type</code> <a>property</a>. That is, any <a>credential</a> or
<a>presentation</a> that does not have <code>type</code> <a>property</a>
<em>is not <a>verifiable</a></em>, so is neither a <a>verifiable credential</a>
nor a <a>verifiable presentation</a>.
        </p>

        <dl>
          <dt><dfn data-lt="type|types">type</dfn></dt>
          <dd>
The value of the <code>type</code> <a>property</a> MUST be, or map to (through
interpretation of the <code>@context</code> property), one or more <a>URIs</a>.
If more than one <a>URI</a> is provided, the <a>URIs</a> MUST be interpreted
as an unordered set. Syntactic conveniences SHOULD be used to ease developer
usage. Such conveniences might include JSON-LD terms. It is RECOMMENDED that
each <a>URI</a> in the <code>type</code> be one which, if dereferenced, results
in a document containing machine-readable information about the
<code>type</code>.
          </dd>
        </dl>

        <pre class="example nohighlight vc" title="Usage of the type property"
          data-vc-vm="https://example.edu/issuers/565049#key-1">
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.edu/credentials/3732",
  <span class="highlight">"type": ["VerifiableCredential", "UniversityDegreeCredential"]</span>,
  "issuer": "https://example.edu/issuers/565049",
  "issuanceDate": "2010-01-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  }
}
        </pre>

        <p>
With respect to this specification, the following table lists the objects that
MUST have a <a>type</a> specified.
        </p>

        <table class="simple">
          <thead>
            <tr>
              <th>Object</th>
              <th>Type</th>
            </tr>
          </thead>

          <tbody>
            <tr>
              <td>
<a>Verifiable credential</a>&nbsp;object <br />(a subclass of a
<a href="#credentials">credential</a>&nbsp;object)
              </td>
              <td>
<code>VerifiableCredential</code> and, optionally, a more specific
<a>verifiable credential</a> <a>type</a>. For example,<br>
<code>"type": ["VerifiableCredential", "UniversityDegreeCredential"]</code>
              </td>
            </tr>

            <tr>
              <td>
<a href="#credentials">Credential</a>&nbsp;object
              </td>
              <td>
<code>VerifiableCredential</code> and, optionally, a more specific
<a>verifiable credential</a> <a>type</a>. For example,<br>
<code>"type": ["VerifiableCredential", "UniversityDegreeCredential"]</code>
              </td>
            </tr>

            <tr>
              <td>
<a>Verifiable presentation</a>&nbsp;object <br />(a subclass of a
<a href="#presentations">presentation</a>&nbsp;object)
              </td>
              <td>
<code>VerifiablePresentation</code> and, optionally, a more specific
<a>verifiable presentation</a> <a>type</a>. For example,<br>
<code>"type": ["VerifiablePresentation", "CredentialManagerPresentation"]</code>
              </td>
            </tr>

            <tr>
              <td>
<a href="#presentations">Presentation</a>&nbsp;object
              </td>
              <td>
<code>VerifiablePresentation</code> and, optionally, a more specific
<a>verifiable presentation</a> <a>type</a>. For example,<br>
<code>"type": ["VerifiablePresentation", "CredentialManagerPresentation"]</code>
              </td>
            </tr>

            <tr>
              <td>
<a href="#proofs-signatures">Proof</a>&nbsp;object
              </td>
              <td>
A valid proof <a>type</a>. For example,<br>
<code>"type": "RsaSignature2018"</code>
              </td>
            </tr>

            <tr>
              <td>
<a href="#status">credentialStatus</a>&nbsp;object
              </td>
              <td>
A valid <a>credential</a> status <a>type</a>. For example,<br>
<code>"type": "CredentialStatusList2017"</code>
              </td>
            </tr>

            <tr>
              <td>
<a href="#terms-of-use">termsOfUse</a>&nbsp;object
              </td>
              <td>
A valid terms of use <a>type</a>. For example,<br>
<code>"type": "OdrlPolicy2017"</code>)
              </td>
            </tr>

            <tr>
              <td>
<a href="#evidence">evidence</a>&nbsp;object
              </td>
              <td>
A valid evidence <a>type</a>. For example,<br>
<code>"type": "DocumentVerification2018"</code>
              </td>
            </tr>

          </tbody>
        </table>

        <p class="note">
The <a>type</a> system for the Verifiable Credentials Data Model is the same as
for [[JSON-LD]] and is detailed in
<a href="https://www.w3.org/TR/json-ld/#specifying-the-type">Section 3.5:
Specifying the Type</a> and
<a href="https://www.w3.org/TR/json-ld/#json-ld-grammar">Section 9: JSON-LD
Grammar</a>. When using a JSON-LD context (see Section
<a href="#extensibility"></a>), this specification aliases the
<code>@type</code> keyword to <code>type</code> to make the JSON-LD documents
more easily understood. While application developers and document authors do
not need to understand the specifics of the JSON-LD type system, implementers
of this specification who want to support interoperable extensibility, do.
        </p>

        <p>
All <a>credentials</a>, <a>presentations</a>, and encapsulated objects MUST
specify, or be associated with, additional more narrow <a>types</a> (like
<code>UniversityDegreeCredential</code>, for example) so software systems can
process this additional information.
        </p>

        <p>
When processing encapsulated objects defined in this specification, (for
example, objects associated with the <code>credentialSubject</code> object or
deeply nested therein), software systems SHOULD use the <a>type</a> information
specified in encapsulating objects higher in the hierarchy. Specifically, an
encapsulating object, such as a <a>credential</a>, SHOULD convey the associated
object <a>types</a> so that <a>verifiers</a> can quickly determine the contents
of an associated object based on the encapsulating object <a>type</a>.
        </p>

        <p>
For example, a <a>credential</a> object with the <code>type</code> of
<code>UniversityDegreeCredential</code>, signals to a <a>verifier</a> that the
object associated with the <code>credentialSubject</code> property contains the
identifier for the:
        </p>

        <ul>
          <li>
<a>Subject</a> in the <code>id</code> property.
          </li>
          <li>
Type of degree in the <code>type</code> property.
          </li>
          <li>
Title of the degree in the <code>name</code> property.
          </li>
        </ul>

        <p>
This enables implementers to rely on values associated with the
<code>type</code> property for <a>verification</a> purposes. The expectation of
<a>types</a> and their associated properties should be documented in at least a
human-readable specification, and preferably, in an additional machine-readable
representation.
        </p>

        <p class="note">
The type system used in the data model described in this specification allows
for multiple ways to associate types with data. Implementers and authors are
urged to read the section on typing in the Verifiable Credentials
Implementation Guidelines [[?VC-IMP-GUIDE]].
        </p>

      </section>

      <section>
        <h3>Credential Subject</h3>

        <p>
A <a>verifiable credential</a> contains <a>claims</a> about one or more
<a>subjects</a>. This specification defines a <code>credentialSubject</code>
<a>property</a> for the expression of <a>claims</a> about one or more
<a>subjects</a>.
        </p>

        <p>
A <a>verifiable credential</a> MUST have a <code>credentialSubject</code>
<a>property</a>.
        </p>

        <dl>
          <dt>credentialSubject</dt>
          <dd>
The value of the <code>credentialSubject</code> <a>property</a> is defined as
a set of objects that MUST contain one or more claims that are each related to a
<a>subject</a> of the <a>verifiable credential</a>. Each object MAY contain an
<code>id</code>, as described in Section <a href="#identifiers"></a>.
          </dd>
        </dl>

        <pre class="example nohighlight vc"
          title="Usage of the credentialSubject property"
          data-vc-vm="https://example.edu/issuers/565049#key-1">
{
  "@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/565049",
  "issuanceDate": "2010-01-01T00:00:00Z",
  <span class="highlight">"credentialSubject"</span>: {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  }
}
        </pre>

        <p>
It is possible to express information related to multiple <a>subjects</a> in a
<a>verifiable credential</a>. The example below specifies two <a>subjects</a>
who are spouses. Note the use of array notation to associate multiple
<a>subjects</a> with the <code>credentialSubject</code> property.
        </p>

        <pre class="example nohighlight"
          title="Specifying multiple subjects in a verifiable credential">
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": ["VerifiableCredential", "RelationshipCredential"],
  "issuer": "https://example.com/issuer/123",
  "issuanceDate": "2010-01-01T00:00:00Z",
  "credentialSubject": <span class="highlight">[{
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "name": "Jayden Doe",
    "spouse": "did:example:c276e12ec21ebfeb1f712ebc6f1"
  }, {
    "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
    "name": "Morgan Doe",
    "spouse": "did:example:ebfeb1f712ebc6f1c276e12ec21"
  }]</span>
}
        </pre>

      </section>

      <section>
        <h3>Issuer</h3>

        <p>
This specification defines a property for expressing the <a>issuer</a> of
a <a>verifiable credential</a>.
        </p>

        <p>
A <a>verifiable credential</a> MUST have an <code>issuer</code> <a>property</a>.
        </p>

        <dl>
          <dt><var>issuer</var></dt>
          <dd>
The value of the <code>issuer</code> <a>property</a> MUST be either a
<a>URI</a> or an object containing an <code>id</code> <a>property</a>. It is
RECOMMENDED that the <a>URI</a> in the <code>issuer</code> or its
<code>id</code> be one which, if dereferenced, results in a document containing
machine-readable information about the <a>issuer</a> that can be used to
<a>verify</a> the information expressed in the <a>credential</a>.
          </dd>
        </dl>

        <pre class="example nohighlight vc" title="Usage of issuer property"
          data-vc-vm="https://example.edu/issuers/14#key-1">
{
  "@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"],
  <span class="highlight">"issuer": "https://example.edu/issuers/14"</span>,
  "issuanceDate": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  }
}
        </pre>

        <p>
It is also possible to express additional information about the issuer by
associating an object with the issuer property:
        </p>

        <pre class="example nohighlight vc"
          title="Usage of issuer expanded property"
          data-vc-vm="did:example:76e12ec712ebc6f1c221ebfeb1f#key-1">
{
  "@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"],
  <span class="highlight">"issuer": {
    "id": "did:example:76e12ec712ebc6f1c221ebfeb1f",
    "name": "Example University"
  }</span>,
  "issuanceDate": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  }
}
        </pre>

        <p class="note">
The value of the <code>issuer</code> <a>property</a> can also be a JWK (for
example, <code>"https://example.com/keys/foo.jwk"</code>) or a <a>DID</a> (for
example, <code>"did:example:abfe13f712120431c276e12ecab"</code>).
        </p>

      </section>

      <section>
        <h3>Issuance Date</h3>

        <p>
This specification defines the <code>issuanceDate</code> <a>property</a> for
expressing the date and time when a <a>credential</a> becomes valid.
        </p>

        <dl>
          <dt><var>issuanceDate</var></dt>
          <dd>
A <a>credential</a> MUST have an <code>issuanceDate</code> <a>property</a>. The
value of the <code>issuanceDate</code> <a>property</a> MUST be a string value of
an [<a data-cite="XMLSCHEMA11-2#dateTime">XMLSCHEMA11-2</a>] combined
<code>date-time</code> string representing the date and time the
<a>credential</a> becomes valid, which could be a date and time in the future.
Note that this value represents the earliest point in time
at which the information associated with the <code>credentialSubject</code>
<a>property</a> becomes valid.
          </dd>
        </dl>

        <pre class="example nohighlight vc"
          title="Usage of issuanceDate property"
          data-vc-vm="https://example.edu/issuers/14#key-1">
{
  "@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",
  <span class="highlight">"issuanceDate": "2010-01-01T19:23:24Z"</span>,
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  }
}
        </pre>

        <p class="note">
It is expected that the next version of this specification will add the
<code>validFrom</code> <a>property</a> and will deprecate the
<code>issuanceDate</code> <a>property</a> in favor of a new <code>issued</code>
<a>property</a>. The range of values for both properties are expected to remain
as [<a data-cite="XMLSCHEMA11-2#dateTime">XMLSCHEMA11-2</a>] combined
<code>date-time</code> strings. Implementers are advised that the
<code>validFrom</code> and <code>issued</code> <a>properties</a> are reserved
and use for any other purpose is discouraged.
        </p>

      </section>

      <section>
        <h3>Proofs (Signatures)</h3>

        <p>
At least one proof mechanism, and the details necessary to evaluate that proof,
MUST be expressed for a <a>credential</a> or <a>presentation</a> to be a
<a>verifiable credential</a> or <a>verifiable presentation</a>; that is, to be
<a>verifiable</a>.
        </p>

        <p>
This specification identifies two classes of proof mechanisms: external proofs
and embedded proofs. An <dfn class="lint-ignore">external proof</dfn> is one
that wraps an expression of this data model, such as a JSON Web Token, which is
elaborated on in the Securing Verifiable Credentials using JSON Web Tokens
[[?VC-JWT]] specification. An <dfn>embedded proof</dfn> is a mechanism where
the proof is included in the data, such as a Data Integrity Proof, which is
elaborated upon in Verifiable Credential Data Integrity [[?VC-DATA-INTEGRITY]].
        </p>

        <p>
When embedding a proof, the <code>proof</code> <a>property</a> MUST be used.
        </p>

        <dl>
          <dt><var>proof</var></dt>
          <dd>
One or more cryptographic proofs that can be used to detect tampering and
verify the authorship of a <a>credential</a> or <a>presentation</a>. The
specific method used for an <a>embedded proof</a> MUST be included using the
<code>type</code> <a>property</a>.
          </dd>
        </dl>

        <p>
Because the method used for a mathematical proof varies by representation
language and the technology used, the set of name-value pairs that is expected
as the value of the <code>proof</code> <a>property</a> will vary accordingly.
For example, if digital signatures are used for the proof mechanism, the
<code>proof</code> <a>property</a> is expected to have name-value pairs that
include a signature, a reference to the signing entity, and a representation of
the signing date. The example below uses Ed25519 digital signatures.
        </p>

        <pre class="example nohighlight"
          title="Usage of the proof property on a verifiable credential">
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.gov/credentials/3732",
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "issuer": "https://example.edu",
  "issuanceDate": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  <span class="highlight">"proof": {
    "type": "Ed25519Signature2020",
    "created": "2021-11-13T18:19:39Z",
    "verificationMethod": "https://example.edu/issuers/14#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z58DAdFfa9SkqZMVPxAQpic7ndSayn1PzZs6ZjWp1CktyGesjuTSwRdo
                   WhAfGFCF5bppETSTojQCrfFPP2oumHKtz"
  }</span>
}
        </pre>

        <p class="note">
As discussed in Section <a href="#conformance"></a>, there are multiple viable
proof mechanisms, and this specification does not standardize nor recommend any
single proof mechanism for use with <a>verifiable credentials</a>. For more
information about the <code>proof</code> mechanism, see the following
specifications: Data Integrity [[?VC-DATA-INTEGRITY]], Linked Data Cryptographic
Suites Registries [[?LDP-REGISTRY]], and JSON Web Signature (JWS) Unencoded
Payload Option [[RFC7797]]. A list of proof mechanisms is available in the
Verifiable Credentials Extension Registry [[VC-EXTENSION-REGISTRY]].
        </p>

      </section>

      <section>
        <h3>Expiration</h3>

        <p>
This specification defines the <code>expirationDate</code> <a>property</a> for
the expression of <a>credential</a> expiration information.
        </p>

        <dl>
          <dt><var>expirationDate</var></dt>
          <dd>
If present, the value of the <code>expirationDate</code> <a>property</a> MUST be
a string value of an [<a data-cite="XMLSCHEMA11-2#dateTime">XMLSCHEMA11-2</a>]
<code>date-time</code> representing the date and time the <a>credential</a>
ceases to be valid.
          </dd>
        </dl>

        <pre class="example nohighlight vc"
          title="Usage of the expirationDate property"
          data-vc-vm="https://example.edu/issuers/14#key-1">
{
  "@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",
  <span class="highlight">"expirationDate": "2020-01-01T19:23:24Z"</span>,
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  }
}
        </pre>

        <p class="note">
It is expected that the next version of this specification will add the
<code>validUntil</code> <a>property</a> in a way that deprecates, but
preserves backwards compatibility with the <code>expirationDate</code>
<a>property</a>. Implementers are advised that the <code>validUntil</code>
<a>property</a> is reserved and its use for any other purpose is discouraged.
        </p>

      </section>

      <section>
        <h3>Status</h3>

        <p>
This specification defines the following <code>credentialStatus</code>
<a>property</a> for the discovery of information about the current status of a
<a>verifiable credential</a>, such as whether it is suspended or revoked.
        </p>

        <dl>
          <dt><var>credentialStatus</var></dt>
          <dd>
If present, the value of the <code>credentialStatus</code> <a>property</a> MUST
include the following:

            <ul>
              <li>
<code>id</code> <a>property</a>, which MUST be a <a>URI</a>.
              </li>
              <li>
<code>type</code> <a>property</a>, which expresses the <a>credential</a> status
type (also referred to as the <a>credential</a> status method).
              </li>
            </ul>
          </dd>
        </dl>

        <p>
The precise contents of the <a>credential</a> status information is determined
by the specific <code>credentialStatus</code> <a>type</a> definition, and varies
depending on factors such as whether it is simple to implement or if it is
privacy-enhancing.
It is expected that the value will provide enough information to determine the
current status of the <a>credential</a> and that machine readable information
needs to be retrievable from the URI. For example, the object could contain a
link to an external document noting whether or not the <a>credential</a> is
suspended or revoked.
        </p>

        <pre class="example nohighlight vc"
          title="Usage of the status property"
          data-vc-vm="https://example.edu/issuers/14#key-1">
{
  "@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"
    }
  },
  <span class="highlight">"credentialStatus": {
    "id": "https://example.edu/status/24",
    "type": "CredentialStatusList2017"
  }</span>
}
        </pre>

        <p>
Defining the data model, formats, and protocols for status schemes are out of
scope for this specification. A Verifiable Credential Extension Registry
[[?VC-EXTENSION-REGISTRY]] exists that contains available status schemes
for implementers who want to implement <a>verifiable credential</a>
status checking.
        </p>
      </section>

      <section>
        <h3>Presentations</h3>

        <p>
<a>Presentations</a> MAY be used to combine and present <a>credentials</a>.
They can be packaged in such a way that the authorship of the data is
<a>verifiable</a>. The data in a <a>presentation</a> is often all about the same
<a>subject</a>, but there is no limit to the number of <a>subjects</a> or
<a>issuers</a> in the data. The aggregation of information from multiple
<a>verifiable credentials</a> is a typical use of
<a>verifiable presentations</a>.
        </p>

        <p>
A <a>verifiable presentation</a> is typically composed of the following
properties:
        </p>

        <dl>
          <dt><var>id</var></dt>
          <dd>
The <code>id</code> <a>property</a> is optional and MAY be used to provide a
unique identifier for the <a>presentation</a>. For details related to the use of
this property, see Section <a href="#identifiers"></a>.
          </dd>
          <dt><var>type</var></dt>
          <dd>
The <code>type</code> <a>property</a> is required and expresses the
type of <a>presentation</a>, such as <code>VerifiablePresentation</code>. For
details related to the use of this property, see Section <a href="#types"></a>.
          </dd>
          <dt><var>verifiableCredential</var></dt>
          <dd>
If present, the value of the <code>verifiableCredential</code> <a>property</a>
MUST be constructed from one or more <a>verifiable credentials</a>, or of data
derived from <a>verifiable credentials</a> in a cryptographically
<a>verifiable</a> format.
          </dd>
          <dt><var>holder</var></dt>
          <dd>
If present, the value of the <code>holder</code> <a>property</a>
is expected to be a <a>URI</a> for the entity that is generating the
<a>presentation</a>.
          </dd>
          <dt><var>proof</var></dt>
          <dd>
If present, the value of the <code>proof</code> <a>property</a> ensures that
the <a>presentation</a> is <a>verifiable</a>. For details related to the use of
this property, see Section <a href="#proofs-signatures"></a>.
          </dd>
        </dl>

        <p>
The example below shows a <a>verifiable presentation</a> that embeds
<a>verifiable credentials</a>.
        </p>

        <pre class="example nohighlight" title="Basic structure of a presentation">
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5",
  "type": ["VerifiablePresentation", "CredentialManagerPresentation"],
  <span class="highlight">"verifiableCredential": [{ <span class="comment">...</span> }],
  "proof": [{ <span class="comment">...</span> }]</span>
}
        </pre>

        <p>
The contents of the <code>verifiableCredential</code> <a>property</a> shown
above are <a>verifiable credentials</a>, as described by this specification. The
contents of the <code>proof</code> <a>property</a> are proofs, as described by
the Data Integrity [[?VC-DATA-INTEGRITY]] specification. An example of a
<a>verifiable presentation</a> using the JWT proof mechanism is
provided in the Securing Verifiable Credentials using JSON Web Tokens
[[?VC-JWT]] specification.
        </p>

        <section>
          <h4>Presentations Using Derived Credentials</h4>

          <p>
Some zero-knowledge cryptography schemes might enable <a>holders</a> to
indirectly prove they hold <a>claims</a> from a <a>verifiable credential</a>
without revealing the <a>verifiable credential</a> itself. In these schemes, a
<a>claim</a> from a <a>verifiable credential</a> might be used to derive a
presented value, which is cryptographically asserted such that a <a>verifier</a>
can trust the value if they trust the <a>issuer</a>.
          </p>

          <p>
For example, a <a>verifiable credential</a> containing the <a>claim</a>
<code>date of birth</code> might be used to derive the presented value
<code>over the age of 15</code> in a manner that is cryptographically
<a>verifiable</a>. That is, a <a>verifier</a> can still trust the derived value
if they trust the <a>issuer</a>.
          </p>

          <p class="note">
For an example of a ZKP-style <a>verifiable presentation</a> containing
derived data instead of directly embedded <a>verifiable credentials</a>, see
Section <a href="#zero-knowledge-proofs"></a>.
          </p>

          <p>
Selective disclosure schemes using zero-knowledge proofs can use <a>claims</a>
expressed in this model to prove additional statements about those <a>claims</a>.
For example, a <a>claim</a> specifying a <a>subject's</a> date of birth can be
used as a predicate to prove the <a>subject's</a> age is within a given range,
and therefore prove the <a>subject</a> qualifies for age-related discounts,
without actually revealing the <a>subject's</a> birthdate. The <a>holder</a>
has the flexibility to use the <a>claim</a> in any way that is applicable to
the desired <a>verifiable presentation</a>.
          </p>

          <figure>
            <img style="margin: auto; display: block; width: 50%;"
                 src="diagrams/claim-example-2.svg" alt="Pat has a property
                 dateOfBirth whose value is 2010-01-01">
            <figcaption style="text-align: center;">
A basic claim expressing that Pat's date of birth is January 1, 2010. Date
encoding would be determined by the schema.
            </figcaption>
          </figure>
        </section>
      </section>
    </section>

    <section>
      <h2>Advanced Concepts</h2>

      <p>
Building on the concepts introduced in Section <a href="#basic-concepts"></a>,
this section explores more complex topics about <a>verifiable credentials</a>.
      </p>

      <section class="informative">
        <h3>Lifecycle Details</h3>

        <p>
Section <a href="#ecosystem-overview"></a> provided an overview of the
<a>verifiable credential</a> ecosystem. This section provides more detail about
how the ecosystem is envisaged to operate.
        </p>

        <figure id="life-cycle-details">
          <img style="margin: auto; display: block; width: 85%;"
         src="diagrams/ecosystemdetail.svg" alt="diagram showing how
         credentials flow from issuer to holder, and optionally
         from one holder to another; and how
         presentations flow from holder to verifier, where
         all parties can use information from a logical
         verifiable data registry">
          <figcaption style="text-align: center;">
            The roles and information flows for this specification.
          </figcaption>
        </figure>

        <p>
The roles and information flows in the <a>verifiable credential</a> ecosystem
are as follows:
        </p>

        <ul>
          <li>
An <a>issuer</a> <dfn class="lint-ignore" data-lt="issue">issues</dfn> a
<a>verifiable credential</a> to a <a>holder</a>. Issuance always occurs before
any other actions involving a <a>credential</a>.
          </li>
          <li>
A <a>holder</a> might <dfn class="lint-ignore"
data-lt="transfers">transfer</dfn> one or more of its <a>verifiable
credentials</a> to another <a>holder</a>.
          </li>
          <li>
A <a>holder</a> <dfn class="lint-ignore" data-lt="present">presents</dfn> one or
more of its <a>verifiable credentials</a> to a <a>verifier</a>, optionally
inside a <a>verifiable presentation</a>.
          </li>
          <li>
A <a>verifier</a> <a>verifies</a> the authenticity of the presented
<a>verifiable presentation</a> and <a>verifiable credentials</a>. This should
include checking the <a href="#status">credential status</a> for revocation
of the <a>verifiable credentials</a>.
          </li>
         <li>
An <a>issuer</a> might <dfn class="lint-ignore" data-lt="revoke">revoke</dfn> a
<a>verifiable credential</a>.
          </li>
          <li>
A <a>holder</a> might <dfn class="lint-ignore" data-lt="delete">delete</dfn> a
<a>verifiable credential</a>.
          </li>
        </ul>

        <p class="note">
The order of the actions above is not fixed, and some actions might be taken
more than once. Such action-recurrence might be immediate or at any later
point.
        </p>

        <p>
The most common sequence of actions is envisioned to be:
        </p>

        <ol>
          <li>
An <a>issuer</a> <a href="#lifecycle-details">issues</a> to a <a>holder</a>.
          </li>
          <li>
The <a>holder</a> <a href="#lifecycle-details">presents</a> to a <a>verifier</a>.
          </li>
          <li>
The <a>verifier</a> <a href="#lifecycle-details">verifies</a>.
          </li>
        </ol>

        <p>
This specification does not define any protocol for transferring
<a>verifiable credentials</a> or <a>verifiable presentations</a>, but assuming
other specifications do specify how they are transferred between entities, then
this Verifiable Credential Data Model is directly applicable.
        </p>

        <p>
This specification also does not define an authorization framework nor the
decisions that a <a>verifier</a> might make after <a>verifying</a> a
<a>verifiable credential</a> or <a>verifiable presentation</a>,
taking into account the <a>holder</a>, the <a>issuers</a> of the
<a>verifiable credentials</a>, the contents of the
<a>verifiable credentials</a>, and its own policies.
        </p>

        <p>
In particular, Sections <a href="#terms-of-use"></a> and
the <a href="https://www.w3.org/TR/vc-imp-guide/#subject-holder-relationships">
Subject-Holder Relationships</a> section in the Verifiable Credentials
Implementation Guide [[VC-IMP-GUIDE]] specify how a <a>verifier</a> can
determine:
        </p>

        <ul>
          <li>
Whether the <a>holder</a> is a <a>subject</a> of a <a>verifiable credential</a>.
          </li>
          <li>
The relationship between the <a>subject</a> and the <a>holder</a>.
          </li>
          <li>
Whether the original <a>holder</a> passed a <a>verifiable credential</a> to a
subsequent <a>holder</a>.
          </li>
          <li>
Any restrictions using the <a>verifiable credentials</a> by the <a>holder</a>
or <a>verifier</a>.
          </li>
        </ul>
      </section>

      <section class="informative">
        <h3>Trust Model</h3>

        <p>
The <a>verifiable credentials</a> trust model is as follows:
        </p>

        <ul>
          <li>
The <a>verifier</a> trusts the <a>issuer</a> to issue the <a>credential</a> that
it received. To establish this trust, a <a>credential</a> is expected to either:
            <ul>
              <li>
Include a <a href="#proofs-signatures">proof</a> establishing that the
<a>issuer</a> generated the <a>credential</a> (that is, it is a
<a>verifiable credential</a>), or
              </li>
              <li>
Have been transmitted in a way clearly establishing that the <a>issuer</a>
generated the <a>verifiable credential</a> and that the
<a>verifiable credential</a> was not tampered with in transit or storage. This
trust could be weakened depending on the risk assessment of the <a>verifier</a>.
              </li>
            </ul>
          </li>
          <li>
All <a>entities</a> trust the <a>verifiable data registry</a> to be
tamper-evident and to be a correct record of which data is controlled by which
<a>entities</a>.
          </li>
          <li>
The <a>holder</a> and <a>verifier</a> trust the <a>issuer</a> to issue
true (that is, not false) <a>credentials</a> about the <a>subject</a>, and to
revoke them quickly when appropriate.
          </li>
          <li>
The <a>holder</a> trusts the <a>repository</a> to store <a>credentials</a>
securely, to not release them to anyone other than the <a>holder</a>, and to not
corrupt or lose them while they are in its care.
          </li>
        </ul>

        <p>
This trust model differentiates itself from other trust models by ensuring
the:
        </p>

        <ul>
          <li>
<a>Issuer</a> and the <a>verifier</a> do not need to trust the
<a>repository</a>
          </li>
          <li>
<a>Issuer</a> does not need to know or trust the <a>verifier</a>.
          </li>
        </ul>

        <p>
By decoupling the trust between the <a>identity provider</a> and the
<a>relying party</a> a more flexible and dynamic trust model is created such
that market competition and customer choice is increased.
        </p>

        <p>
For more information about how this trust model interacts with various threat
models studied by the Working Group, see the Verifiable Credentials Use Cases
document [[VC-USE-CASES]].
        </p>

        <p class="note">
The data model detailed in this specification does not imply a transitive trust
model, such as that provided by more traditional Certificate Authority trust
models. In the Verifiable Credentials Data Model, a <a>verifier</a> either
directly trusts or does not trust an <a>issuer</a>. While it is possible to
build transitive trust models using the Verifiable Credentials Data Model,
implementers are urged to
<a href="https://datatracker.ietf.org/doc/draft-iab-web-pki-problems/">learn
about the security weaknesses</a> introduced by
<a href="https://www.usenix.org/conference/imc-05/perils-transitive-trust-domain-name-system">broadly
delegating trust</a> in the manner adopted by Certificate Authority systems.
        </p>
      </section>

      <section>
        <h3>Extensibility</h3>

        <p>
One of the goals of the Verifiable Credentials Data Model is to enable
permissionless innovation. To achieve this, the data model needs to be
extensible in a number of different ways. The data model is required to:
        </p>

        <ul>
          <li>
Model complex multi-entity relationships through the use of a <a>graph</a>-based
data model.
          </li>
          <li>
Extend the machine-readable vocabularies used to describe information in the
data model, without the use of a centralized system for doing so, through the
use of [[?LINKED-DATA]].
          </li>
          <li>
Support multiple types of cryptographic proof formats through the use of
Data Integrity Proofs [[?VC-DATA-INTEGRITY]] and a variety of signature suites
listed in the Linked Data Cryptographic Suites Registry [[?LDP-REGISTRY]]
          </li>
          <li>
Provide all of the extensibility mechanisms outlined above in a data format that
is popular with software developers and web page authors, and is enabled through
the use of [[JSON-LD]].
          </li>
        </ul>

        <p>
This approach to data modeling is often called an
<em>open world assumption</em>, meaning that any entity can say anything about
any other entity. While this approach seems to conflict with building simple and
predictable software systems, balancing extensibility with program correctness
is always more challenging with an open world assumption than with closed
software systems.
        </p>

        <p>
The rest of this section describes, through a series of examples, how both
extensibility and program correctness are achieved.
        </p>

        <p>
Let us assume we start with the <a>verifiable credential</a> shown below.
        </p>

        <pre class="example nohighlight vc"
          title="A simple credential"
          data-vc-vm="https://example.edu/issuers/14#keys-1">
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.com/credentials/4643",
  "type": ["VerifiableCredential"],
  "issuer": "https://example.com/issuers/14",
  "issuanceDate": "2018-02-24T05:28:04Z",
  "credentialSubject": {
    "id": "did:example:abcdef1234567",
    "name": "Jane Doe"
  }
}
        </pre>

        <p>
This <a>verifiable credential</a> states that the <a>entity</a> associated with
<code>did:example:abcdef1234567</code> has a <code>name</code> with a value of
<code>Jane Doe</code>.
        </p>

        <p>
Now let us assume a developer wants to extend the <a>verifiable credential</a>
to store two additional pieces of information: an internal corporate reference
number, and Jane's favorite food.
        </p>

        <p>
The first thing to do is to create a JSON-LD context containing two new terms,
as shown below.
        </p>

        <pre class="example nohighlight" title="A JSON-LD context">
{
  "@context": {
    "referenceNumber": "https://example.com/vocab#referenceNumber",
    "favoriteFood": "https://example.com/vocab#favoriteFood"
  }
}
        </pre>

        <p>
After this JSON-LD context is created, the developer publishes it somewhere so
it is accessible to <a>verifiers</a> who will be processing the
<a>verifiable credential</a>. Assuming the above JSON-LD context is published at
<code>https://example.com/contexts/mycontext.jsonld</code>, we can extend this
example by including the context and adding the new <a>properties</a> and
<a>credential</a> <a>type</a> to the <a>verifiable credential</a>.
        </p>

        <pre class="example nohighlight"
          title="A verifiable credential with a custom extension">
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    <span class="highlight">"https://example.com/contexts/mycontext.jsonld"</span>
  ],
  "id": "http://example.com/credentials/4643",
  "type": ["VerifiableCredential", "CustomExt12"],
  "issuer": "https://example.com/issuers/14",
  "issuanceDate": "2018-02-24T05:28:04Z",
  <span class="highlight">"referenceNumber": 83294847,</span>
  "credentialSubject": {
    "id": "did:example:abcdef1234567",
    "name": "Jane Doe",
    <span class="highlight">"favoriteFood": "Papaya"</span>
  }
}
        </pre>

        <p>
This example demonstrates extending the Verifiable Credentials Data Model in a
permissionless and decentralized way. The mechanism shown also ensures that
<a>verifiable credentials</a> created in this way provide a mechanism to prevent
namespace conflicts and semantic ambiguity.
        </p>

        <p>
A dynamic extensibility model such as this does increase the implementation
burden. Software written for such a system has to determine whether
<a>verifiable credentials</a> with extensions are acceptable based on the risk
profile of the application. Some applications might accept only certain
extensions while highly secure environments might not accept any extensions.
These decisions are up to the developers of these applications and are
specifically not the domain of this specification.
        </p>

        <p>
Developers are urged to ensure that extension JSON-LD contexts are highly
available. Implementations that cannot fetch a context will produce an error.
Strategies for ensuring that extension JSON-LD contexts are always available
include using content-addressed URLs for contexts, bundling context documents
with implementations, or enabling aggressive caching of contexts.
        </p>

        <p>
Implementers are advised to pay close attention to the extension points in this
specification, such as in Sections <a href="#proofs-signatures"></a>,
<a href="#status"></a>, <a href="#data-schemas"></a>,<a href="#refreshing"></a>,
<a href="#terms-of-use"></a>, and <a href="#evidence"></a>. While this
specification does not define concrete implementations for those extension
points, the Verifiable Credentials Extension Registry [[?VC-EXTENSION-REGISTRY]]
provides an unofficial, curated list of extensions that developers can use from
these extension points.
        </p>

        <section>
          <h4>Semantic Interoperability</h4>

          <p>
This specification ensures that "plain" JSON and JSON-LD syntaxes are
semantically compatible without requiring JSON implementations to use a JSON-LD
processor. To achieve this, the specification imposes the following additional
requirements on both syntaxes:
          </p>

          <ul>
            <li>
JSON-based processors MUST process the <code>@context</code> key, ensuring the
expected values exist in the expected order for the <a>credential</a> type being
processed. The order is important because keys used in a <a>credential</a>,
which are defined using the values associated with <code>@context</code>, are
defined using a "first defined wins" mechanism and changing the order might
result in a different key definition "winning".
            </li>
            <li>
JSON-LD-based processors MUST produce an error when a JSON-LD context redefines
any term in the
<a href="https://www.w3.org/TR/json-ld/#dfn-active-context">active context</a>.
The only way to change the definition of existing terms is to introduce a new
term that clears the active context within the scope of that new term. Authors
that are interested in this feature should read about the
<code>@protected</code> feature in the JSON-LD 1.1 specification.
            </li>
          </ul>

          <p>
A human-readable document describing the expected order of values for the
<code>@context</code> <a>property</a> is expected to be published by any
implementer seeking interoperability. A machine-readable description
(that is, a normal JSON-LD Context document) is expected to be published
at the URL specified in the <code>@context</code> <a>property</a> by
JSON-LD implementers seeking interoperability.
          </p>

          <p>
The requirements above guarantee semantic interoperability between JSON and
JSON-LD for terms defined by the <code>@context</code> mechanism. While JSON-LD
processors will use the specific mechanism provided and can verify that all
terms are correctly specified, JSON-based processors implicitly accept the same
set of terms without testing that they are correct. In other words, the context
in which the data exchange happens is explicitly stated for both JSON and
JSON-LD by using the same mechanism. With respect to JSON-based processors, this
is achieved in a lightweight manner, without having to use JSON-LD processing
libraries.
        </section>
      </section>

      <section>
        <h3>Data Schemas</h3>

        <p>
Data schemas are useful when enforcing a specific structure on a given
collection of data. There are at least two types of data schemas that this
specification considers:
        </p>

        <ul>
          <li>
Data verification schemas, which are used to <a>verify</a> that the structure
and contents of a <a>credential</a> or <a>verifiable credential</a> conform to a
published schema.
          </li>
          <li>
Data encoding schemas, which are used to map the contents of a
<a>verifiable credential</a> to an alternative representation format, such as a
binary format used in a zero-knowledge proof.
          </li>
        </ul>

        <p>
It is important to understand that data schemas serve a different purpose from
the <code>@context</code> property, which neither enforces data structure or
data syntax, nor enables the definition of arbitrary encodings to alternate
representation formats.
        </p>
        <p>
This specification defines the following <a>property</a> for the expression of a
data schema, which can be included by an <a>issuer</a> in
the <a>verifiable credentials</a> that it issues:
        </p>

        <dl>
          <dt><var>credentialSchema</var></dt>
          <dd>
The value of the <code>credentialSchema</code> <a>property</a> MUST be one or
more data schemas that provide <a>verifiers</a> with enough information to
determine if the provided data conforms to the provided schema. Each
<code>credentialSchema</code> MUST specify its <code>type</code> (for example,
<code>JsonSchemaValidator2018</code>), and an <code>id</code> <a>property</a>
that MUST be a <a>URI</a> identifying the schema file. The precise contents of
each data schema is determined by the specific type definition.
          </dd>
        </dl>

        <p class="note">
The <code>credentialSchema</code> <a>property</a> provides an opportunity to
annotate type definitions or lock them to specific versions of the vocabulary.
Authors of <a>verifiable credentials</a> can include a static version of their
vocabulary using <code>credentialSchema</code> that is locked to some content
integrity protection mechanism. The <code>credentialSchema</code>
<a>property</a> also makes it possible to perform syntactic checking on the
<a>credential</a> and to use <a>verification</a> mechanisms such as JSON Schema
[[JSON-SCHEMA-2018]] validation.
        </p>

        <pre class="example nohighlight vc"
          title="Usage of the credentialSchema property to perform JSON schema validation"
          data-vc-vm="https://example.edu/issuers/14#keys-1">
{
  "@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"
    }
  },
  <span class="highlight">"credentialSchema": {
    "id": "https://example.org/examples/degree.json",
    "type": "JsonSchemaValidator2018"
  }</span>
}
        </pre>

        <p>
In the example above, the <a>issuer</a> is specifying a
<code>credentialSchema</code>, which points to a [[?JSON-SCHEMA-2018]] file that
can be used by a <a>verifier</a> to determine if the
<a>verifiable credential</a> is well formed.
        </p>

        <p class="note" >
For information about linkages to JSON Schema [[JSON-SCHEMA-2018]] or other
optional <a>verification</a> mechanisms, see the Verifiable Credentials
Implementation Guidelines [[VC-IMP-GUIDE]] document.
        </p>

        <p>
Data schemas can also be used to specify mappings to other binary formats, such
as those used to perform zero-knowledge proofs. For more information on using
the <code>credentialSchema</code> <a>property</a> with zero-knowledge proofs,
see Section <a href="#zero-knowledge-proofs"></a>.
        </p>

        <pre class="example nohighlight" title="Usage of the credentialSchema property to perform zero-knowledge validation">
{
  "@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"
    }
  },
  <span class="highlight">"credentialSchema": {
    "id": "https://example.org/examples/degree.zkp",
    "type": "ZkpExampleSchema2018"
  }</span>,
  "proof": { <span class="comment">...</span> }
}
        </pre>

        <p>
In the example above, the <a>issuer</a> is specifying a
<code>credentialSchema</code> pointing to a zero-knowledge packed binary data
format that is capable of transforming the input data into a format, which can
then be used by a <a>verifier</a> to determine if the proof provided with the
<a>verifiable credential</a> is valid.
        </p>

      </section>

      <section>
        <h3>Refreshing</h3>

        <p>
It is useful for systems to enable the manual or automatic refresh of an
expired <a>verifiable credential</a>. For more information about expired
<a>verifiable credentials</a>, see Section <a href="#expiration"></a>. This
specification defines a <code>refreshService</code> <a>property</a>, which
enables an <a>issuer</a> to include a link to a refresh service.
        </p>
        <p>
The <a>issuer</a> can include the refresh service as an element inside the
<a>verifiable credential</a> if it is intended for either the <a>verifier</a> or
the <a>holder</a> (or both), or inside the <a>verifiable presentation</a> if it
is intended for the <a>holder</a> only. In the latter case, this enables the
<a>holder</a> to refresh the <a>verifiable credential</a> before creating a
<a>verifiable presentation</a> to share with a <a>verifier</a>. In the former
case, including the refresh service inside the <a>verifiable credential</a>
enables either the <a>holder</a> or the <a>verifier</a> to perform future
updates of the <a>credential</a>.
        </p>
        <p>
The refresh service is only expected to be used when either the
<a>credential</a> has expired or the <a>issuer</a> does not publish
<a>credential</a> status information. <a>Issuers</a> are advised not to put the
<code>refreshService</code> <a>property</a> in a <a>verifiable credential</a>
that does not contain public information or whose refresh service is not
protected in some way.
        </p>
        <p class="note">
Placing a <code>refreshService</code> <a>property</a> in a
<a>verifiable credential</a> so that it is available to <a>verifiers</a> can
remove control and consent from the <a>holder</a> and allow the
<a>verifiable credential</a> to be issued directly to the <a>verifier</a>,
thereby bypassing the <a>holder</a>.
        </p>

        <dl>
          <dt><var>refreshService</var></dt>
          <dd>
The value of the <code>refreshService</code> <a>property</a> MUST be one or more
refresh services that provides enough information to the recipient's software
such that the recipient can refresh the <a>verifiable credential</a>. Each
<code>refreshService</code> value MUST specify its <code>type</code> (for
example, <code>ManualRefreshService2018</code>) and its <code>id</code>, which
is the <a>URI</a> of the service. There is an expectation that machine readable
information needs to be retrievable from the URI. The precise content of
each refresh service is determined by the specific <code>refreshService</code>
<a>type</a> definition.
          </dd>
        </dl>

        <pre class="example nohighlight"
          title="Usage of the refreshService property by an issuer">
{
  "@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"
    }
  },
  <span class="highlight">"refreshService": {
    "id": "https://example.edu/refresh/3732",
    "type": "ManualRefreshService2018"
  }</span>
}
        </pre>

        <p>
In the example above, the <a>issuer</a> specifies a manual
<code>refreshService</code> that can be used by directing the <a>holder</a> or
the <a>verifier</a> to <code>https://example.edu/refresh/3732</code>.
        </p>

      </section>

      <section>
        <h3>Terms of Use</h3>

        <p>
Terms of use can be utilized by an <a>issuer</a> or a <a>holder</a> to
communicate the terms under which a <a>verifiable credential</a> or
<a>verifiable presentation</a> was issued. The <a>issuer</a> places their terms
of use inside the <a>verifiable credential</a>. The <a>holder</a> places their
terms of use inside a <a>verifiable presentation</a>. This specification defines
a <code>termsOfUse</code> <a>property</a> for expressing terms of use
information.
        </p>

        <p>
The value of the <code>termsOfUse</code> <a>property</a> tells the
<a>verifier</a> what actions it is required to perform (an <em>obligation</em>),
not allowed to perform (a <em>prohibition</em>), or allowed to perform (a
<em>permission</em>) if it is to accept the <a>verifiable credential</a> or
<a>verifiable presentation</a>.
        </p>

        <p class="note">
Further study is required to determine how a <a>subject</a> who is not a
<a>holder</a> places terms of use on their <a>verifiable credentials</a>. One
way could be for the <a>subject</a> to request the <a>issuer</a> to place the
terms of use inside the issued <a>verifiable credentials</a>. Another way
could be for the <a>subject</a> to delegate a <a>verifiable credential</a> to a
<a>holder</a> and place terms of use restrictions on the delegated
<a>verifiable credential</a>.
        </p>

        <dl>
          <dt><var>termsOfUse</var></dt>
          <dd>
The value of the <code>termsOfUse</code> <a>property</a> MUST specify one or
more terms of use policies under which the creator issued the <a>credential</a>
or <a>presentation</a>. If the recipient (a <a>holder</a> or
<a>verifier</a>) is not willing to adhere to the specified terms of use, then
they do so on their own responsibility and might incur legal liability if they
violate the stated terms of use. Each <code>termsOfUse</code> value MUST specify
its <a>type</a>, for example, <code>IssuerPolicy</code>, and MAY specify its
instance <code>id</code>. The precise contents of each term of use is determined
by the specific <code>termsOfUse</code> <a>type</a> definition.
          </dd>
        </dl>

        <pre class="example nohighlight vc"
          title="Usage of the termsOfUse property by an issuer"
          data-vc-vm="https://example.edu/issuers/14#keys-1">
{
  "@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"
    }
  },
  <span class="highlight">"termsOfUse": [{
    "type": "IssuerPolicy",
    "id": "http://example.com/policies/credential/4",
    "profile": "http://example.com/profiles/credential",
    "prohibition": [{
      "assigner": "https://example.edu/issuers/14",
      "assignee": "AllVerifiers",
      "target": "http://example.edu/credentials/3732",
      "action": ["Archival"]
    }]
  }]
  </span>
}
        </pre>

        <p>
In the example above, the <a>issuer</a> (the <code>assigner</code>) is
prohibiting <a>verifiers</a> (the <code>assignee</code>) from storing the data
in an archive.
        </p>

        <pre class="example nohighlight" title="Usage of the termsOfUse property by a holder">
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1",
    {
        "@protected": true,
        "VerifiablePresentationTermsOfUseExtension": {
          "@id": "https://www.w3.org/2018/credentials/examples#VerifiablePresentationExtension",
          "@context": {
            "@protected": true,
            "termsOfUse": {
              "@id": "https://www.w3.org/2018/credentials#termsOfUse",
              "@type": "@id"
            }
          }
        }
    }
  ],
  "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
  "type": ["VerifiablePresentation", "VerifiablePresentationTermsOfUseExtension"],
  "verifiableCredential": [{
    "@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"
    }
    },
    "proof": { <span class="comment">...</span> }
  }],
  <span class="highlight">"termsOfUse": [{
    "type": "HolderPolicy",
    "id": "http://example.com/policies/credential/6",
    "profile": "http://example.com/profiles/credential",
    "prohibition": [{
      "assigner": "did:example:ebfeb1f712ebc6f1c276e12ec21",
      "assignee": "https://wineonline.example.org/",
      "target": "http://example.edu/credentials/3732",
      "action": ["3rdPartyCorrelation"]
    }]
  }]</span>,
  "proof": [ ... ]
}
        </pre>

        <p class="note">
Warning: The <code>termsOfUse</code> property is improperly defined within the
<code>VerifiablePresentation</code> scoped context. This is a bug with the
version 1 context and will be fixed in the version 2 context. In the meantime,
implementors who wish to use this feature will be required to extend the context
of their <a>verifiable presentation</a> with an additional term that defines the
<code>termsOfUse</code> property, which can then be used alongside the
<a>verifiable presentation</a> type property, in order for the term to be
semantically recognized in a JSON-LD processor.
        </p>

        <p>
In the example above, the <a>holder</a> (the <code>assigner</code>), who is
also the <a>subject</a>, expressed a term of use prohibiting the <a>verifier</a>
(the <code>assignee</code>, <code>https://wineonline.example.org</code>) from
using the information provided to correlate the <a>holder</a> or <a>subject</a>
using a third-party service. If the <a>verifier</a> were to use a third-party
service for correlation, they would violate the terms under which the
<a>holder</a> created the <a>presentation</a>.
        </p>

        <p>
This feature is also expected to be used by government-issued
<a>verifiable credentials</a> to instruct digital wallets to limit their use to
similar government organizations in an attempt to protect citizens from
unexpected usage of sensitive data. Similarly, some
<a>verifiable credentials</a> issued by private industry are expected to limit
usage to within departments inside the organization, or during business hours.
Implementers are urged to read more about this rapidly evolving feature in the
appropriate section of the Verifiable Credentials Implementation Guidelines
[[?VC-IMP-GUIDE]] document.
        </p>

      </section>

      <section>
        <h3>Evidence</h3>

        <p>
Evidence can be included by an <a>issuer</a> to provide the <a>verifier</a> with
additional supporting information in a <a>verifiable credential</a>. This could
be used by the <a>verifier</a> to establish the confidence with which it relies
on the claims in the <a>verifiable credential</a>.
        </p>
        <p>
For example, an <a>issuer</a> could check physical documentation provided by the
<a>subject</a> or perform a set of background checks before issuing the
<a>credential</a>. In certain scenarios, this information is useful to the
<a>verifier</a> when determining the risk associated with relying on a given
<a>credential</a>.
        </p>

        <p>
This specification defines the <code>evidence</code> <a>property</a> for
expressing evidence information.
        </p>

        <dl>
          <dt><dfn>evidence</dfn></dt>
          <dd>
The value of the <code>evidence</code> <a>property</a> MUST be one or more
evidence schemes providing enough information for a <a>verifier</a> to determine
whether the evidence gathered by the <a>issuer</a> meets its confidence
requirements for relying on the <a>credential</a>. Each evidence scheme is
identified by its <a>type</a>. The <code>id</code> <a>property</a> is optional,
but if present, SHOULD contain a URL that points to where more information about
this instance of evidence can be found. The precise content of each evidence
scheme is determined by the specific <code>evidence</code> <a>type</a>
definition.
          </dd>
        </dl>

        <p class="note">
For information about how attachments and references to <a>credentials</a> and
non-credential data might be supported by the specification, see the
Verifiable Credentials Implementation Guidelines [[VC-IMP-GUIDE]] document.
        </p>

        <pre class="example nohighlight"
          title="Usage of the evidence property">
{
  "@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"
    }
  },
  <span class="highlight">"evidence": [{
    "id": "https://example.edu/evidence/f2aeec97-fc0d-42bf-8ca7-0548192d4231",
    "type": ["DocumentVerification"],
    "verifier": "https://example.edu/issuers/14",
    "evidenceDocument": "DriversLicense",
    "subjectPresence": "Physical",
    "documentPresence": "Physical",
    "licenseNumber": "123AB4567"
  }]</span>,
  "proof": { <span class="comment">...</span> }
}
        </pre>

        <p class="note">
In this <code>evidence</code> example, the <a>issuer</a> is asserting that they
physically matched the <a>subject</a> of the <a>credential</a> to a physical
copy of a driver's license with the stated license number. This driver's license
was used in the issuance process to verify that "Example University" verified
the subject before issuance of the credential and how they did so (physical
verification).
        </p>

        <p class="note">
The <code>evidence</code> <a>property</a> provides different and complementary
information to the <code>proof</code> <a>property</a>. The <code>evidence</code>
<a>property</a> is used to express supporting information, such as documentary
evidence, related to the integrity of the <a>verifiable credential</a>. In
contrast, the <code>proof</code> <a>property</a> is used to express
machine-verifiable mathematical proofs related to the authenticity of the
<a>issuer</a> and integrity of the <a>verifiable credential</a>. For more
information about the <code>proof</code> <a>property</a>, see Section
<a href="#proofs-signatures"></a>.
        </p>

      </section>

      <section>
        <h3>Zero-Knowledge Proofs</h3>

        <p>
A zero-knowledge proof is a cryptographic method where an entity can prove to
another entity that they know a certain value without disclosing the actual
value. A real-world example is proving that an accredited university has
granted a degree to you without revealing your identity or any other personally
identifiable information contained on the degree.
        </p>
        <p>
The key capabilities introduced by zero-knowledge proof mechanisms are the
ability of a <a>holder</a> to:
        </p>

        <ul>
          <li>
Combine multiple <a>verifiable credentials</a> from multiple <a>issuers</a> into
a single <a>verifiable presentation</a> without revealing
<a>verifiable credential</a> or <a>subject</a> identifiers to the
<a>verifier</a>. This makes it more difficult for the <a>verifier</a> to collude
with any of the issuers regarding the issued <a>verifiable credentials</a>.
          </li>
          <li>
Selectively disclose the <a>claims</a> in a <a>verifiable credential</a> to a
<a>verifier</a> without requiring the issuance of multiple atomic
<a>verifiable credentials</a>. This allows a <a>holder</a> to provide a
<a>verifier</a> with precisely the information they need and nothing more.
          </li>
          <li>
Produce a derived <a>verifiable credential</a> that is formatted according to
the <a>verifier's</a> data schema instead of the <a>issuer's</a>, without
needing to involve the <a>issuer</a> after <a>verifiable credential</a>
issuance. This provides a great deal of flexibility for <a>holders</a> to use
their issued <a>verifiable credentials</a>.
          </li>
        </ul>

        <p>
This specification describes a data model that supports selective disclosure
with the use of zero-knowledge proof mechanisms. The examples below highlight
how the data model can be used to issue, present, and verify zero-knowledge
<a>verifiable credentials</a>.
        </p>

        <p>
For a <a>holder</a> to use a zero-knowledge <a>verifiable presentation</a>,
they need an <a>issuer</a> to have issued a <a>verifiable credential</a> in a manner
that enables the <a>holder</a> to derive a proof from the originally issued
<a>verifiable credential</a>, so that the <a>holder</a> can present the
information to a <a>verifier</a> in a privacy-enhancing manner.
This implies that the <a>holder</a> can prove the validity of the
<a>issuer's</a> signature without revealing the values that were signed, or when
only revealing certain selected values. The standard practice is to do so by
proving knowledge of the signature, without revealing the signature itself.
There are two requirements for <a>verifiable credentials</a> when they are to be
used in zero-knowledge proof systems.
        </p>

        <ul>
          <li>
The <a>verifiable credential</a> MUST contain a Proof, using the
<code>proof</code> <a>property</a>, so that the <a>holder</a> can derive a
<a>verifiable presentation</a> that reveals only the information than the
<a>holder</a> intends to reveal.
          </li>
          <li>
If a <a>credential</a> definition is being used, the <a>credential</a>
definition MUST be defined in the <code>credentialSchema</code> <a>property</a>,
so that it can be used by all parties to perform various cryptographic
operations in zero-knowledge.
          </li>
        </ul>

        <p>
The following example shows one method of using <a>verifiable credentials</a> in
zero-knowledge. It makes use of a Camenisch-Lysyanskaya Signature
[[?CL-SIGNATURES]], which allows the presentation of the <a>verifiable
credential</a> in a way that supports the privacy of the
<a>holder</a> and <a>subject</a> through the use of selective disclosure of the
<a>verifiable credential</a> values. Some other cryptographic systems which rely
upon zero-knowledge proofs to selectively disclose attributes can be found in the
[[?LDP-REGISTRY]] as well.
        </p>

        <pre class="example nohighlight" title="A verifiable credential that supports CL Signatures">
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  <span class="highlight">"credentialSchema": {
    "id": "did:example:cdf:35LB7w9ueWbagPL94T9bMLtyXDj9pX5o",
    "type": "did:example:schema:22KpkXgecryx9k7N6XN1QoN3gXwBkSU8SfyyYQG"
  }</span>,
  "issuer": "did:example:Wz4eUg7SetGfaUVCn8U9d62oDYrUJLuUtcy619",
  "credentialSubject": {
    "givenName": "Jane",
    "familyName": "Doe",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts",
      "college": "College of Engineering"
    }
  },
  <span class="highlight">"proof": {
    "type": "CLSignature2019",
    "issuerData": "5NQ4TgzNfSQxoLzf2d5AV3JNiCdMaTgm...BXiX5UggB381QU7ZCgqWivUmy4D",
    "attributes": "pPYmqDvwwWBDPNykXVrBtKdsJDeZUGFA...tTERiLqsZ5oxCoCSodPQaggkDJy",
    "signature": "8eGWSiTiWtEA8WnBwX4T259STpxpRKuk...kpFnikqqSP3GMW7mVxC4chxFhVs",
    "signatureCorrectnessProof": "SNQbW3u1QV5q89qhxA1xyVqFa6jCrKwv...dsRypyuGGK3RhhBUvH1tPEL8orH"
  }</span>
}
        </pre>
        <p>
The example above provides the <a>verifiable credential</a> definition by using
the <code>credentialSchema</code> <a>property</a> and a specific proof that is
usable in the Camenisch-Lysyanskaya Zero-Knowledge Proof system.
        </p>

        <p>
The next example utilizes the <a>verifiable credential</a> above to generate a
new derived <a>verifiable credential</a> with a privacy-preserving proof. The
derived <a>verifiable credential</a> is then placed in a
<a>verifiable presentation</a>, so that the <a>verifiable credential</a>
discloses only the <a>claims</a> and additional credential metadata that the
<a>holder</a> intended. To do this, all of the following requirements are
expected to be met:
        </p>

        <ul>
          <li>
Each derived <a>verifiable credential</a> within a <a>verifiable
presentation</a> MUST contain all information necessary to verify the
<a>verifiable credential</a>, either by including it directly within the
credential, or by referencing the necessary information.
          </li>
          <li>
A <a>verifiable presentation</a> MUST NOT leak information that would enable
the <a>verifier</a> to correlate the <a>holder</a> across multiple
<a>verifiable presentations</a>.
          </li>
          <li>
The <a>verifiable presentation</a> SHOULD contain a <code>proof</code>
<a>property</a> to enable the <a>verifier</a> to check that all derived
<a>verifiable credentials</a> in the <a>verifiable presentation</a> were issued
to the same <a>holder</a> without leaking personally identifiable information
that the <a>holder</a> did not intend to share.
          </li>
        </ul>

        <pre class="example nohighlight" title="A verifiable presentation that supports CL Signatures">
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "type": "VerifiablePresentation",
  "verifiableCredential": [
    {
      "@context": [
        "https://www.w3.org/2018/credentials/v1",
        "https://www.w3.org/2018/credentials/examples/v1"
      ],
      "type": ["VerifiableCredential", "UniversityDegreeCredential"],
      <span class="highlight">"credentialSchema": {
        "id": "did:example:cdf:35LB7w9ueWbagPL94T9bMLtyXDj9pX5o",
        "type": "did:example:schema:22KpkXgecryx9k7N6XN1QoN3gXwBkSU8SfyyYQG"
      }</span>,
      "issuer": "did:example:Wz4eUg7SetGfaUVCn8U9d62oDYrUJLuUtcy619",
      "credentialSubject": {
        "degreeType": "BachelorDegree",
        "degreeSchool": "College of Engineering"
      },
      <span class="highlight">"proof": {
        "type": "AnonCredDerivedCredentialv1",
        "primaryProof": "cg7wLNSi48K5qNyAVMwdYqVHSMv1Ur8i...Fg2ZvWF6zGvcSAsym2sgSk737",
        "nonRevocationProof": "mu6fg24MfJPU1HvSXsf3ybzKARib4WxG...RSce53M6UwQCxYshCuS3d2h"
      }</span>
  }],
  <span class="highlight">"proof": {
    "type": "AnonCredPresentationProofv1",
    "proofValue": "DgYdYMUYHURJLD7xdnWRinqWCEY5u5fK...j915Lt3hMzLHoPiPQ9sSVfRrs1D"
  }</span>
}
        </pre>
        <figure>
          <img style="margin: auto; display: block; width: 75%;"
            src="diagrams/zkp-cred-pres.svg" alt="Verifiable
            Credential 1 and Verifiable Credential 2 on the left map
            to Derived Credential 1 and Derived Credential 2 inside a
            Presentation on the right.  Verifiable Credential 1
            contains Context, Type, ID, Issuer, Issue Date, Expiration
            Date, CredentialSubject, and Proof, where
            CredentialSubject contains GivenName, FamilyName, and
            Birthdate and Proof contains Signature, Proof of
            Correctness, and Attributes.  Verifiable Credential 2
            contains Context, Type, ID, Issuer, Issue Date, Expiration
            Date, CredentialSubject, and Proof, where
            CredentialSubject contains University, which contains
            Department, which contains DegreeAwarded, and Proof contains Signature, Proof of
            Correctness, and Attributes.  The Presentation diagram on
            the right contains Context, Type, ID,
            VerifiableCredential, and Proof, where
            VerifiableCredential contains Derived Credential 1 and
            Derived Credential 2 and Proof contains Common Link
            Secret.  Derived Credential 1 contains Context, Type, ID,
            Issuer, Issue Date, CredentialSubject, and Proof, where
            CredentialSubject contains AgeOver18 and Proof contains
            Knowledge of Signature.  Derived Credential 2 contains
            Context, Type, ID, Issuer, Issue Date, CredentialSubject,
            and Proof, where CredentialSubject contains Degree and
            Proof contains Knowledge of Signature.  A line links
            Birthdate in Verifiable Credential 1 to AgeOver18 in
            Derived Credential 1.  A line links DegreeAwarded in
            Verifiable Credential 2 to Degree in Derived Credential 2.">
          <figcaption style="text-align: center;">
A visual example of the relationship between credentials and derived
credentials in a ZKP <a>presentation</a>.
          </figcaption>
        </figure>

        <p class="note">
Important details regarding the format for the <a>credential</a> definition and
of the proofs are omitted on purpose because they are outside of the scope of
this document. The purpose of this section is to guide implementers who want to
extend <a>verifiable credentials</a> and <a>verifiable presentations</a> to
support zero-knowledge proof systems.
        </p>

      </section>

      <section>
        <h3>Disputes</h3>

        <p>
There are at least two different cases to consider for an <a>entity</a>
wanting to dispute a <a>credential</a> issued by an <a>issuer</a>:
        </p>

        <ul>
          <li>
A <a>subject</a> disputes a claim made by the <a>issuer</a>. For example, the
<code>address</code> <a>property</a> is incorrect or out of date.
          </li>
          <li>
An <a>entity</a> disputes a potentially false claim made by the <a>issuer</a>
about a different <a>subject</a>. For example, an imposter claims the social
security number for an <a>entity</a>.
          </li>
        </ul>

        <p>
The mechanism for issuing a <code>DisputeCredential</code> is the same as
for a regular <a>credential</a> except that the <code>credentialSubject</code>
identifier in the <code>DisputeCredential</code> <a>property</a> is the
identifier of the disputed <a>credential</a>.
        </p>

        <p>
For example, if a <a>credential</a> with an identifier of
<code>https://example.org/credentials/245</code> is disputed, the <a>subject</a>
can issue the <a>credential</a> shown below and present it to the
<a>verifier</a> along with the disputed <a>credential</a>.
        </p>

        <pre class="example nohighlight" title="A subject disputes a credential">
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.com/credentials/123",
  "type": ["VerifiableCredential", "DisputeCredential"],
  <span class="highlight">"credentialSubject": {
    "id": "http://example.com/credentials/245",
    "currentStatus": "Disputed",
    "statusReason": {
      "value": "Address is out of date.",
      "lang": "en"
    },
  }</span>,
  "issuer": "https://example.com/people#me",
  "issuanceDate": "2017-12-05T14:27:42Z",
  "proof": { <span class="comment">...</span> }
}
        </pre>

        <p>
In the above <a>verifiable credential</a> the <a>issuer</a> is claiming that
the address in the disputed <a>verifiable credential</a> is wrong.
       </p>

        <p class="note">
If a <a>credential</a> does not have an identifier, a content-addressed
identifier can be used to identify the disputed <a>credential</a>. Similarly,
content-addressed identifiers can be used to uniquely identify individual
claims.
        </p>

        <p class="note">
This area of study is rapidly evolving and developers that are interested in
publishing <a>credentials</a> that dispute the veracity of other
<a>credentials</a> are urged to read the section related to disputes in the
Verifiable Credentials Implementation Guidelines [[VC-IMP-GUIDE]] document.
       </p>

      </section>

      <section class="informative">
        <h3>Authorization</h3>

        <p>
<a>Verifiable credentials</a> are intended as a means of reliably identifying
<a>subjects</a>. While it is recognized that Role Based Access Controls (RBACs)
and Attribute Based Access Controls (ABACs) rely on this identification as a
means of authorizing <a>subjects</a> to access resources, this specification
does not provide a complete solution for RBAC or ABAC. Authorization is not an
appropriate use for this specification without an accompanying authorization
framework.
        </p>

        <p>
The Working Group did consider authorization use cases during the creation of
this specification and is pursuing that work as an architectural layer built
on top of this specification.
        </p>
      </section>
    </section>

    <section>
      <h2>Syntaxes</h2>

      <p>
The data model as described in Sections
<a href="#core-data-model"></a>, <a href="#basic-concepts"></a>, and
<a href="#advanced-concepts"></a> is the canonical structural representation of
a <a>verifiable credential</a> or <a>verifiable presentation</a>. All
serializations are representations of that data model in a specific format. This
section specifies how the data model is realized in JSON-LD and plain JSON.
Although syntactic mappings are provided for only these two syntaxes,
applications and services can use any other data representation syntax (such as
XML, YAML, or CBOR) that is capable of expressing the data model. As the
<a>verification</a> and <a>validation</a> requirements are defined in terms of
the data model, all serialization syntaxes have to be deterministically
translated to the data model for processing, <a>validation</a>, or comparison.
This specification makes no requirements for support of any specific
serialization format.
      </p>

      <p>
The expected arity of the property values in this specification, and the
resulting datatype which holds those values, can vary depending on the property.
If present, the following properties are represented as a single value:
      </p>

      <ul>
        <li>
<code>id</code> <a>property</a>
        </li>
        <li>
<code>issuer</code> <a>property</a>
        </li>
        <li>
<code>issuanceDate</code> <a>property</a>
        </li>
        <li>
<code>expirationDate</code> <a>property</a>.
        </li>
      </ul>

      <p>
All other properties, if present, are represented as either a single value
or an array of values.
      </p>

      <section>
        <h3>JSON</h3>

        <p>
The data model, as described in Section <a href="#core-data-model"></a>, can be
encoded in JavaScript Object Notation (JSON) [[!RFC8259]] by mapping property
values to JSON types as follows:
        </p>

        <ul>
          <li>
Numeric values representable as IEEE754 SHOULD be represented as a Number type.
          </li>
          <li>
Boolean values SHOULD be represented as a Boolean type.
          </li>
          <li>
Sequence value SHOULD be represented as an Array type.
          </li>
          <li>
Unordered sets of values SHOULD be represented as an Array type.
          </li>
          <li>
Sets of <a>properties</a> SHOULD be represented as an Object type.
          </li>
          <li>
Empty values SHOULD be represented as a null value.
          </li>
          <li>
Other values MUST be represented as a String type.
          </li>
        </ul>

        <p class="note">
As the transformations listed herein have potentially incompatible
interpretations, additional profiling of the JSON format is required to provide
a deterministic transformation to the data model.
        </p>

      </section>

      <section>
        <h3>JSON-LD</h3>

        <p>
[[!JSON-LD]] is a JSON-based format used to serialize
<a href="http://www.w3.org/TR/ld-glossary/#linked-data">Linked Data</a>. The
syntax is designed to easily integrate into deployed systems already using JSON,
and provides a smooth upgrade path from JSON to [[!JSON-LD]]. It is primarily
intended to be a way to use Linked Data in Web-based programming environments,
to build interoperable Web services, and to store Linked Data in JSON-based
storage engines.
        </p>

        <p>
[[!JSON-LD]] is useful when extending the data model described in this
specification. Instances of the data model are encoded in [[!JSON-LD]] in the
same way they are encoded in JSON (Section <a href="#json"></a>), with the
addition of the <code>@context</code> <a>property</a>. The
<a href="https://www.w3.org/TR/json-ld/#the-context">JSON-LD context</a>
is described in detail in the [[!JSON-LD]] specification and its use is
elaborated on in Section <a href="#extensibility"></a>.
        </p>

        <p>
Multiple contexts MAY be used or combined to express any arbitrary information
about <a>verifiable credentials</a> in idiomatic JSON. The
<a href="https://www.w3.org/TR/json-ld/#the-context">JSON-LD context</a>,
available at <code>https://www.w3.org/2018/credentials/v1</code>, is a static
document that is never updated and can therefore be downloaded and cached client
side. The associated vocabulary document for the Verifiable Credentials Data
Model is available at <code>https://www.w3.org/2018/credentials</code>.
        </p>

        <section>
          <h3>Syntactic Sugar</h3>

          <p>
In general, the data model and syntaxes described in this document are
designed such that developers can copy and paste examples to incorporate
<a>verifiable credentials</a> into their software systems. The design goal of
this approach is to provide a low barrier to entry while still ensuring global
interoperability between a heterogeneous set of software systems. This section
describes some of these approaches, which will likely go unnoticed by most
developers, but whose details will be of interest to implementers. The most
noteworthy syntactic sugars provided by [[!JSON-LD]] are:
          </p>

          <ul>
            <li>
The <code>@id</code> and <code>@type</code> keywords are aliased to
<code>id</code> and <code>type</code> respectively, enabling developers to use
this specification as idiomatic JSON.
            </li>
            <li>
Data types, such as integers, dates, units of measure, and URLs, are
automatically typed to provide stronger type guarantees for use cases that
require them.
            </li>
            <li>
The <code>verifiableCredential</code> and <code>proof</code> <a>properties</a>
are treated as <em>graph containers</em>. That is, mechanisms used to isolate
sets of data asserted by different entities. This ensures, for example, proper
cryptographic separation between the data graph provided by each <a>issuer</a>
and the one provided by the <a>holder</a> presenting the
<a>verifiable credential</a> to ensure the provenance of the information for
each graph is preserved.
            </li>
            <li>
The <code>@protected</code> properties feature of [[!JSON-LD]] 1.1 is used to
ensure that terms defined by this specification cannot be overridden. This means
that as long as the same <code>@context</code> declaration is made at the top of
a <a>verifiable credential</a> or <a>verifiable presentation</a>,
interoperability is guaranteed for all terms understood by users of the data
model whether or not they use a [[!JSON-LD]] processor.
            </li>
          </ul>
        </section>

      </section>

      <section>
        <h3>Proof Formats</h3>

        <p>
The data model described in this specification is designed to be proof format
agnostic. This specification does not normatively require any particular digital
proof or signature format. While the data model is the canonical representation
of a <a>credential</a> or <a>presentation</a>, the
proofing mechanisms for these are often tied to the syntax used in the
transmission of the document between parties. As such, each proofing mechanism
has to specify whether the verification of the proof is calculated against the
state of the document as transmitted, against the possibly transformed data model, or
against another form. At the time of publication, at least two proof formats
are being actively utilized by implementers and the Working Group felt
that documenting what these proof formats are and how they are being used would
be beneficial to implementers. The sections detailing the current proof formats
being actively utilized to issue <a>verifiable credentials</a> are:
        </p>

        <ul>
          <li>
Verifiable Credentials using JSON Web Tokens [[?VC-JWT]], and
          </li>
          <li>
Verifiable Credential Data Integrity [[?VC-DATA-INTEGRITY]].
          </li>
        </ul>

      </section>
    </section>

    <section class="informative">
      <h2>Privacy Considerations</h2>

      <p>
This section details the general privacy considerations and specific privacy
implications of deploying the Verifiable Credentials Data Model into production
environments.
      </p>

      <section class="informative">
        <h3>Spectrum of Privacy</h3>

        <p>
It is important to recognize there is a spectrum of privacy ranging from
pseudonymous to strongly identified. Depending on the use case, people have
different comfort levels about what information they are willing to provide
and what information can be derived from what is provided.
        </p>

        <figure>
          <img style="margin: auto; display: block; width: 80%;"
            src="diagrams/privacy-spectrum.svg" alt="Horizontal bar with
            red on the left, orange in the middle, and green on the
            right.  The red has the text 'Highly correlatable (global
            IDs), e.g., government ID, shipping address, credit card
            number'.  The orange has the text 'Correlatable ia collusion
            (personally identifiable info), e.g., name, birthday, zip
            code'.  The green has the text 'Non-correlatable
            (pseudonyms), e.g., age over 21'.">
          <figcaption style="text-align: center;">
Privacy spectrum ranging from pseudonymous to fully identified.
          </figcaption>
        </figure>

        <p>
For example, most people probably want to remain anonymous when purchasing
alcohol because the regulatory check required is solely based on whether a
person is above a specific age. Alternatively, for medical prescriptions
written by a doctor for a patient, the pharmacy fulfilling the prescription is
required to more strongly identify the medical professional and the patient.
Therefore there is not one approach to privacy that works for all use cases.
Privacy solutions are use case specific.
        </p>

        <p class="note">
Even for those wanting to remain anonymous when purchasing alcohol, photo
identification might still be required to provide appropriate assurance to the
merchant. The merchant might not need to know your name or other details (other
than that you are over a specific age), but in many cases just proof of age
might still be insufficient to meet regulations.
        </p>

        <p>
The Verifiable Credentials Data Model strives to support the full privacy
spectrum and does not take philosophical positions on the correct level of
anonymity for any specific transaction. The following sections provide guidance
for implementers who want to avoid specific scenarios that are hostile to
privacy.
        </p>
      </section>

      <section class="informative">
        <h3>Personally Identifiable Information</h3>

        <p>
Data associated with <a>verifiable credentials</a> stored in the
<code>credential.credentialSubject</code> field is susceptible to privacy
violations when shared with <a>verifiers</a>. Personally identifying data, such
as a government-issued identifier, shipping address, and full name, can be
easily used to determine, track, and correlate an <a>entity</a>. Even
information that does not seem personally identifiable, such as the
combination of a birthdate and a postal code, has very powerful correlation
and de-anonymizing capabilities.
        </p>

        <p>
Implementers are strongly advised to warn <a>holders</a> when they share data
with these kinds of characteristics. <a>Issuers</a> are strongly advised to
provide privacy-protecting <a>verifiable credentials</a> when possible. For
example, issuing <code>ageOver</code> <a>verifiable credentials</a> instead of
date of birth <a>verifiable credentials</a> when a <a>verifier</a> wants to
determine if an <a>entity</a> is over the age of 18.
        </p>

        <p>
Because a <a>verifiable credential</a> often contains personally identifiable
information (PII), 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. Mechanisms that could be considered include
Transport Layer Security (TLS) or other means of encrypting the data while in
transit, as well as encryption or data access control mechanisms to protect
the data in a <a>verifiable credential</a> while at rest.
        </p>
      </section>

      <section class="informative">
        <h3>Identifier-Based Correlation</h3>

        <p>
<a>Subjects</a> of <a>verifiable credentials</a> are identified using the
<code>credential.credentialSubject.id</code> field. The identifiers used to
identify a <a>subject</a> create a greater risk of correlation when the
identifiers are long-lived or used across more than one web domain.
        </p>

        <p>
Similarly, disclosing the <a>credential</a> identifier
(<code>credential.id</code>) leads to situations where multiple
<a>verifiers</a>, or an <a>issuer</a> and a <a>verifier</a>, can collude to
correlate the <a>holder</a>. If <a>holders</a> want to reduce correlation, they
should use <a>verifiable credential</a> schemes that allow hiding the
identifier during <a>verifiable presentation</a>. Such schemes expect the
<a>holder</a> to generate the identifier and might even allow hiding the
identifier from the <a>issuer</a>, while still keeping the identifier embedded
and signed in the <a>verifiable credential</a>.
        </p>

        <p>
If strong anti-correlation properties are a requirement in a
<a>verifiable credentials</a> system, it is strongly advised that identifiers
are either:
        </p>

        <ul>
          <li>
Bound to a single origin
          </li>
          <li>
Single-use
          </li>
          <li>
Not used at all, but instead replaced by short-lived, single-use bearer tokens.
          </li>
        </ul>
      </section>

      <section class="informative">
        <h3>Signature-Based Correlation</h3>

        <p>
The contents of <a>verifiable credentials</a> are secured using the
<code>credential.proof</code> field. The <a>properties</a> in this field
create a greater risk of correlation when the same values are used across more
than one session or domain and the value does not change. Examples include the
<code>verificationMethod</code>, <code>created</code>,
<code>proofPurpose</code>, and <code>jws</code> fields.
        </p>

        <p>
If strong anti-correlation properties are required, it is advised that
signature values and metadata are regenerated each time using technologies like
third-party pairwise signatures, zero-knowledge proofs, or group signatures.
        </p>

        <p class="note">
Even when using anti-correlation signatures, information might still be
contained in a <a>verifiable credential</a> that defeats the anti-correlation
properties of the cryptography used.
        </p>
      </section>

      <section class="informative">
        <h3>Long-Lived Identifier-Based Correlation</h3>

        <p>
<a>Verifiable credentials</a> might contain long-lived identifiers that could
be used to correlate individuals. These types of identifiers include
<a>subject</a> identifiers, email addresses, government-issued identifiers,
organization-issued identifiers, addresses, healthcare vitals,
<a>verifiable credential</a>-specific JSON-LD contexts, and many other sorts of
long-lived identifiers.
        </p>

        <p>
Organizations providing software to <a>holders</a> should strive to identify
fields in <a>verifiable credentials</a> containing information that could be
used to correlate individuals and warn <a>holders</a> when this information is
shared.
        </p>
      </section>

      <section class="informative">
        <h3>Device Fingerprinting</h3>

        <p>
There are mechanisms external to <a>verifiable credentials</a> that are used to
track and correlate individuals on the Internet and the Web. Some of these
mechanisms include Internet protocol (IP) address tracking, web browser
fingerprinting, evercookies, advertising network trackers, mobile network
position information, and in-application Global Positioning System (GPS) APIs.
Using <a>verifiable credentials</a> cannot prevent the use of these other
tracking technologies. Also, when these technologies are used in conjunction
with <a>verifiable credentials</a>, new correlatable information could be
discovered. For example, a birthday coupled with a GPS position can be used to
strongly correlate an individual across multiple websites.
        </p>

        <p>
It is recommended that privacy-respecting systems prevent the use of these
other tracking technologies when <a>verifiable credentials</a> are being used.
In some cases, tracking technologies might need to be disabled on devices that
transmit <a>verifiable credentials</a> on behalf of a <a>holder</a>.
        </p>
      </section>

      <section class="informative">
        <h3>Favor Abstract Claims</h3>

        <p>
To enable recipients of <a>verifiable credentials</a> to use them in a variety
of circumstances without revealing more PII than necessary for transactions,
<a>issuers</a> should consider limiting the information published in a
<a>credential</a> to a minimal set needed for the expected purposes. One way to
avoid placing PII in a <a>credential</a> is to use an abstract <a>property</a>
that meets the needs of <a>verifiers</a> without providing specific information
about a <a>subject</a>.
        </p>
        <p>
For example, this document uses the <code>ageOver</code> <a>property</a>
instead of a specific birthdate, which constitutes much stronger PII. If
retailers in a specific market commonly require purchasers to be older than a
certain age, an <a>issuer</a> trusted in that market might choose to offer a
<a>verifiable credential</a> claiming that <a>subjects</a> have met that
requirement instead of offering <a>verifiable credentials</a> containing
<a>claims</a> about specific birthdates. This enables individual customers to
make purchases without revealing specific PII.
        </p>
      </section>

      <section class="informative">
        <h3>The Principle of Data Minimization</h3>

        <p>
Privacy violations occur when information divulged in one context leaks into
another. Accepted best practice for preventing such violations is to limit the
information requested, and received, to the absolute minimum necessary. This
data minimization approach is required by regulation in multiple jurisdictions,
including the Health Insurance Portability and Accountability Act (HIPAA) in the
United States and the General Data Protection Regulation (GDPR) in the European
Union.
        </p>
        <p>
With <a>verifiable credentials</a>, data minimization for <a>issuers</a> means
limiting the content of a <a>verifiable credential</a> to the minimum required
by potential <a>verifiers</a> for expected use. For <a>verifiers</a>, data
minimization means limiting the scope of the information requested or
required for accessing services.
        </p>
        <p>
For example, a driver's license containing a driver's ID number, height, weight,
birthday, and home address is a <a>credential</a> containing more information
than is necessary to establish that the person is above a certain age.
        </p>

        <p>
It is considered best practice for <a>issuers</a> to atomize information or use
a signature scheme that allows for <a>selective disclosure</a>. For example, an
<a>issuer</a> of driver's licenses could issue a <a>verifiable credential</a>
containing every attribute that appears on a driver's license, as well as a set
of <a>verifiable credentials</a> where every <a>verifiable credential</a>
contains only a single attribute, such as a person's birthday. It could also
issue more abstract <a>verifiable credentials</a> (for example, a
<a>verifiable credential</a> containing only an <code>ageOver</code> attribute).
One possible adaptation would be for <a>issuers</a> to provide secure HTTP
endpoints for retrieving single-use <a>bearer credentials</a> that promote the
pseudonymous usage of <a>verifiable credentials</a>. Implementers that find this
impractical or unsafe, should consider using <a>selective disclosure</a> schemes
that eliminate dependence on <a>issuers</a> at proving time and reduce temporal
correlation risk from <a>issuers</a>.
        </p>

        <p>
<a>Verifiers</a> are urged to only request information that is absolutely
necessary for a specific transaction to occur. This is important for at least
two reasons. It:
        </p>

        <ul>
          <li>
Reduces the liability on the <a>verifier</a> for handling highly sensitive
information that it does not need to.
          </li>
          <li>
Enhances the privacy of the individual by only asking for information required
for a specific transaction.
          </li>
        </ul>

        <p class="note">
While it is possible to practice the principle of minimum disclosure, it might
be impossible to avoid the strong identification of an individual for
specific use cases during a single session or over multiple sessions. The
authors of this document cannot stress how difficult it is to meet this
principle in real-world scenarios.
        </p>
      </section>

      <section class="informative">
        <h3>Bearer Credentials</h3>

        <p>
A <dfn data-lt="bearer credentials">bearer credential</dfn> is a
privacy-enhancing piece of information, such as a concert ticket, which entitles
the <a>holder</a> of the bearer credential to a specific resource without
divulging sensitive information about the <a>holder</a>. Bearer credentials are
often used in low-risk use cases where the sharing of the bearer credential is
not a concern or would not result in large economic or reputational losses.
        </p>

        <p>
<a>Verifiable credentials</a> that are <a>bearer credentials</a> are made
possible by not specifying the <a>subject</a> identifier, expressed using the
<code>id</code> <a>property</a>, which is nested in the
<code>credentialSubject</code> <a>property</a>. For example, the following
<a>verifiable credential</a> is a <a>bearer credential</a>:
        </p>

        <pre class="example nohighlight vc"
          title="Usage of issuer properties"
          data-vc-vm="https://example.edu/issuers/14#keys-1">
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.edu/credentials/temporary/28934792387492384",
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "issuer": "https://example.edu/issuers/14",
  "issuanceDate": "2017-10-22T12:23:48Z",
  "credentialSubject": {
    <span class="comment">// note that the 'id' property is not specified for bearer credentials</span>
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  }
}
        </pre>

        <p>
While <a>bearer credentials</a> can be privacy-enhancing, they must be carefully
crafted so as not accidentally divulge more information than the <a>holder</a>
of the <a>bearer credential</a> expects. For example, repeated use of the same
<a>bearer credential</a> across multiple sites enables these sites to
potentially collude to unduly track or correlate the <a>holder</a>. Likewise,
information that might seem non-identifying, such as a birthdate and postal
code, can be used to statistically identify an individual when used together in
the same <a>bearer credential</a> or session.
        </p>

        <p>
<a>Issuers</a> of <a>bearer credentials</a> should ensure that the
<a>bearer credentials</a> provide privacy-enhancing benefits that:
        </p>

        <ul>
          <li>
Are single-use, where possible.
          </li>
          <li>
Do not contain personally identifying information.
          </li>
          <li>
Are not unduly correlatable.
          </li>
        </ul>

        <p>
<a>Holders</a> should be warned by their software if <a>bearer credentials</a>
containing sensitive information are issued or requested, or if there is a
correlation risk when combining two or more <a>bearer credentials</a> across one
or more sessions. While it might be impossible to detect all correlation risks,
some might certainly be detectable.
        </p>

        <p>
<a>Verifiers</a> should not request <a>bearer credentials</a> that can be used
to unduly correlate the <a>holder</a>.
        </p>
      </section>

      <section class="informative">
        <h3>Validity Checks</h3>

        <p>
When processing <a>verifiable credentials</a>, <a>verifiers</a> are expected to
perform many of the checks listed in Appendix <a href="#validation"></a> as
well as a variety of specific business process checks. Validity checks might
include checking:
        </p>

        <ul>
          <li>
The professional licensure status of the <a>holder</a>.
          </li>
          <li>
A date of license renewal or revocation.
          </li>
          <li>
The sub-qualifications of an individual.
          </li>
          <li>
If a relationship exists between the <a>holder</a> and the <a>entity</a>
with whom the <a>holder</a> is attempting to interact.
          </li>
          <li>
The geolocation information associated with the <a>holder</a>.
          </li>
        </ul>

        <p>
The process of performing these checks might result in information leakage that
leads to a privacy violation of the <a>holder</a>. For example, a simple
operation such as checking a revocation list can notify the <a>issuer</a> that a
specific business is likely interacting with the <a>holder</a>. This could
enable <a>issuers</a> to collude and correlate individuals without their
knowledge.
        </p>

        <p>
<a>Issuers</a> are urged to not use mechanisms, such as <a>credential</a>
revocation lists that are unique per <a>credential</a>, during the
<a>verification</a> process that could lead to privacy violations. Organizations
providing software to <a>holders</a> should warn when <a>credentials</a> include
information that could lead to privacy violations during the verification
process. <a>Verifiers</a> should consider rejecting <a>credentials</a> that
produce privacy violations or that enable bad privacy practices.
        </p>
      </section>

      <section class="informative">
        <h3>Storage Providers and Data Mining</h3>

        <p>
When a <a>holder</a> receives a <a>verifiable credential</a> from an
<a>issuer</a>, the <a>verifiable credential</a> needs to be stored somewhere
(for example, in a <a>credential</a> repository). <a>Holders</a> are warned that
the information in a <a>verifiable credential</a> is sensitive in nature and
highly individualized, making it a high value target for data mining. Services
that advertise free storage of <a>verifiable credentials</a> might in fact be
mining personal data and selling it to organizations wanting to build
individualized profiles on people and organizations.
        </p>
        <p>
<a>Holders</a> need to be aware of the terms of service for their
<a>credential</a> repository, specifically the correlation and data mining
protections in place for those who store their <a>verifiable credentials</a>
with the service provider.
        </p>
        <p>
Some effective mitigations for data mining and profiling include using:
        </p>

        <ul>
          <li>
Service providers that do not sell your information to third parties.
          </li>
          <li>
Software that encrypts <a>verifiable credentials</a> such that a service
provider cannot view the contents of the <a>credential</a>.
          </li>
          <li>
Software that stores <a>verifiable credentials</a> locally on a device that you
control and that does not upload or analyze your information beyond your
expectations.
          </li>
        </ul>
      </section>

      <section class="informative">
        <h3>Aggregation of Credentials</h3>

        <p>
Holding two pieces of information about the same <a>subject</a> almost always
reveals more about the <a>subject</a> than just the sum of the two pieces, even
when the information is delivered through different channels. The aggregation of
<a>verifiable credentials</a> is a privacy risk and all participants in
the ecosystem need to be aware of the risks of data aggregation.
        </p>

        <p>
For example, if two <a>bearer credentials</a>, one for an email address and then
one stating the <a>holder</a> is over the age of 21, are provided across
multiple sessions, the <a>verifier</a> of the information now has a unique
identifier as well as age-related information for that individual. It is now
easy to create and build a profile for the <a>holder</a> such that more and more
information is leaked over time. Aggregation of <a>credentials</a> can also be
performed across multiple sites in collusion with each other, leading to privacy
violations.
        </p>

        <p>
From a technological perspective, preventing aggregation of information is a
very difficult privacy problem to address. While new cryptographic techniques,
such as zero-knowledge proofs, are being proposed as solutions to the problem
of aggregation and correlation, the existence of long-lived identifiers and
browser tracking techniques defeats even the most modern cryptographic
techniques.
        </p>

        <p>
The solution to the privacy implications of correlation or aggregation tends not
to be technological in nature, but policy driven instead. Therefore, if a
<a>holder</a> does not want information about them to be aggregated, they must
express this in the <a>verifiable presentations</a> they transmit.
        </p>
      </section>

      <section class="informative">
        <h3>Usage Patterns</h3>

        <p>
Despite the best efforts to assure privacy, actually using
<a>verifiable credentials</a> can potentially lead to de-anonymization and a
loss of privacy. This correlation can occur when:
        </p>

        <ul>
          <li>
The same <a>verifiable credential</a> is presented to the same <a>verifier</a>
more than once. The <a>verifier</a> could infer that the <a>holder</a> is the
same individual.
          </li>
          <li>
The same <a>verifiable credential</a> is presented to different
<a>verifiers</a>, and either those <a>verifiers</a> collude or a third party
has access to transaction records from both <a>verifiers</a>. An observant
party could infer that the individual presenting the
<a>verifiable credential</a> is the same person at both services. That is, the
accounts are controlled by the same person.
          </li>
          <li>
A <a>subject</a> identifier of a <a>credential</a> refers to the same
<a>subject</a> across multiple <a>presentations</a> or <a>verifiers</a>. Even
when different <a>credentials</a> are presented, if the <a>subject</a>
identifier is the same, <a>verifiers</a> (and those with access to
<a>verifier</a> logs) could infer that the <a>holder</a> of the
<a>credential</a> is the same person.
          </li>
          <li>
The underlying information in a <a>credential</a> can be used to identify an
individual across services. In this case, using information from other sources
(including information provided directly by the <a>holder</a>), <a>verifiers</a>
can use information inside the <a>credential</a> to correlate the individual
with an existing profile. For example, if a <a>holder</a> presents
<a>credentials</a> that include postal code, age, and gender, a <a>verifier</a>
can potentially correlate the <a>subject</a> of that <a>credential</a> with an
established profile. For more information, see [[DEMOGRAPHICS]].
          </li>
          <li>
Passing the identifier of a <a>credential</a> to a centralized revocation
server. The centralized server can correlate the <a>credential</a> usage across
interactions. For example, if a <a>credential</a> is used for proof of age in
this manner, the centralized service could know everywhere that
<a>credential</a> was presented (all liquor stores, bars, adult stores, lottery
purchases, and so on).
          </li>
        </ul>

        <p>
In part, it is possible to mitigate this de-anonymization and loss of privacy
by:
        </p>

        <ul>
          <li>
Using a globally-unique identifier as the <a>subject</a> for any given
<a>credential</a> and never re-use that <a>credential</a>.
          </li>
          <li>
If the <a>credential</a> supports revocation, using a globally-distributed
service for revocation.
          </li>
          <li>
Designing revocation APIs that do not depend on submitting the ID of the
<a>credential</a>. For example, use a revocation list instead of a query.
          </li>
          <li>
Avoiding the association of personally identifiable information with any
specific long-lived <a>subject</a> identifier.
          </li>
        </ul>

        <p>
It is understood that these mitigation techniques are not always practical
or even compatible with necessary usage. Sometimes correlation is a
requirement.
        </p>
        <p>
For example, in some prescription drug monitoring programs, usage monitoring is
a requirement. Enforcement entities need to be able to confirm that individuals
are not cheating the system to get multiple prescriptions for controlled
substances. This statutory or regulatory need to correlate usage overrides
individual privacy concerns.
        </p>

        <p>
<a>Verifiable credentials</a> will also be used to intentionally correlate
individuals across services, for example, when using a common persona to log in
to multiple services, so all activity on each of those services is
intentionally linked to the same individual. This is not a privacy issue as
long as each of those services uses the correlation in the expected manner.
        </p>

        <p>
Privacy risks of <a>credential</a> usage occur when unintended or unexpected
correlation arises from the presentation of <a>credentials</a>.
        </p>
      </section>

      <section class="informative">
        <h3>Sharing Information with the Wrong Party</h3>

        <p>
When a <a>holder</a> chooses to share information with a <a>verifier</a>, it
might be the case that the <a>verifier</a> is acting in bad faith and requests
information that could be used to harm the <a>holder</a>. For example, a
<a>verifier</a> might ask for a bank account number, which could then be used
with other information to defraud the <a>holder</a> or the bank.
        </p>

        <p>
<a>Issuers</a> should strive to tokenize as much information as possible such
that if a <a>holder</a> accidentally transmits <a>credentials</a> to the wrong
<a>verifier</a>, the situation is not catastrophic.
        </p>

        <p>
For example, instead of including a bank account number for the purpose of
checking an individual's bank balance, provide a token that enables the
<a>verifier</a> to check if the balance is above a certain amount. In this
case, the bank could issue a <a>verifiable credential</a> containing a balance
checking token to a <a>holder</a>. The <a>holder</a> would then include the
<a>verifiable credential</a> in a <a>verifiable presentation</a> and bind the
token to a credit checking agency using a digital signature. The
<a>verifier</a> could then wrap the <a>verifiable presentation</a> in their
digital signature, and hand it back to the issuer to dynamically check the
account balance.
        </p>

        <p>
Using this approach, even if a <a>holder</a> shares the account balance token
with the wrong party, an attacker cannot discover the bank account number, nor
the exact value in the account. And given the validity period for the
counter-signature, does not gain access to the token for more than a few
minutes.
        </p>
      </section>

      <section class="informative">
        <h3>Frequency of Claim Issuance</h3>

        <p>
As detailed in Section <a href="#usage-patterns"></a>, usage patterns can be
correlated into certain types of behavior. Part of this correlation is
mitigated when a <a>holder</a> uses a <a>verifiable credential</a> without the
knowledge of the <a>issuer</a>. <a>Issuers</a> can defeat this protection
however, by making their <a>verifiable credentials</a> short lived and renewal
automatic.
        </p>

        <p>
For example, an <code>ageOver</code> <a>verifiable credential</a> is useful for
gaining access to a bar. If an <a>issuer</a> issues such a
<a>verifiable credential</a> with a very short expiration date and an automatic
renewal mechanism, then the <a>issuer</a> could possibly correlate the behavior
of the <a>holder</a> in a way that negatively impacts the <a>holder</a>.
        </p>

        <p>
Organizations providing software to <a>holders</a> should warn them if they
repeatedly use <a>credentials</a> with short lifespans, which could result in
behavior correlation. <a>Issuers</a> should avoid issuing <a>credentials</a> in
a way that enables them to correlate usage patterns.
        </p>
      </section>

      <section class="informative">
        <h3>Prefer Single-Use Credentials</h3>

        <p>
An ideal privacy-respecting system would require only the information necessary
for interaction with the <a>verifier</a> to be disclosed by the <a>holder</a>.
The <a>verifier</a> would then record that the disclosure requirement was met
and forget any sensitive information that was disclosed. In many cases,
competing priorities, such as regulatory burden, prevent this ideal system from
being employed. In other cases, long-lived identifiers prevent single use. The
design of any <a>verifiable credentials</a> ecosystem, however, should strive
to be as privacy-respecting as possible by preferring single-use
<a>verifiable credentials</a> whenever possible.
        </p>

        <p>
Using single-use <a>verifiable credentials</a> provides several benefits. The
first benefit is to <a>verifiers</a> who can be sure that the data in a
<a>verifiable credential</a> is fresh. The second benefit is to <a>holders</a>,
who know that if there are no long-lived identifiers in the
<a>verifiable credential</a>, the <a>verifiable credential</a> itself cannot be
used to track or correlate them online. Finally, there is nothing for attackers
to steal, making the entire ecosystem safer to operate within.
        </p>
      </section>

      <section class="informative">
        <h3>Private Browsing</h3>

        <p>
In an ideal private browsing scenario, no PII will be revealed. Because many
<a>credentials</a> include PII, organizations providing software to
<a>holders</a> should warn them about the possibility of revealing this
information if they wish to use <a>credentials</a> and <a>presentations</a>
while in private browsing mode. As each browser vendor handles private browsing
differently, and some browsers might not have this feature at all, it is
important for implementers to be aware of these differences and implement
solutions accordingly.
        </p>
      </section>

      <section class="informative">
        <h3>Issuer Cooperation Impacts on Privacy</h3>

        <p>
It cannot be overstated that <a>verifiable credentials</a> rely on a high
degree of trust in <a>issuers</a>. The degree to which a <a>holder</a> might take
advantage of possible privacy protections often depends strongly on the support
an <a>issuer</a> provides for such features. In many cases, privacy protections
which make use of zero-knowledge proofs, data minimization techniques, bearer
credentials, abstract claims, and protections against signature-based
correlation, require the <a>issuer</a> to actively support such capabilities and
incorporate them into the <a>verifiable credentials</a> they issue.
        </p>
        <p>
It should also be noted that, in addition to a reliance on <a>issuer</a>
participation to provide <a>verifiable credential</a> capabilities that help
preserve <a>holder</a> and <a>subject</a> privacy, <a>holders</a> rely on
<a>issuers</a> to not deliberately subvert privacy protections. For example, an
<a>issuer</a> might sign <a>verifiable credentials</a> using a signature scheme
that protects against signature-based correlation. This would protect the
<a>holder</a> from being correlated by the signature value as it is shared among
<a>verifiers</a>. However, if the <a>issuer</a> creates a unique key for each
issued <a>credential</a>, it might be possible for the <a>issuer</a> to track
<a>presentations</a> of the <a>credential</a>, regardless of a <a>verifier</a>'s
inability to do so.
        </p>
      </section>
    </section>

    <section class="informative">
      <h2>Security Considerations</h2>

      <p>
There are a number of security considerations that <a>issuers</a>,
<a>holders</a>, and <a>verifiers</a> 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>
While this section attempts to highlight a broad set of security considerations,
it is not a complete list. Implementers are urged to seek the advice of security
and cryptography professionals when implementing mission critical systems using
the technology outlined in this specification.
      </p>

      <section class="informative">
        <h3>Cryptography Suites and Libraries</h3>

        <p>
Some aspects of the data model described in this specification can be
protected through the use of cryptography. It is important for implementers to
understand the cryptography suites and libraries used to create and process
<a>credentials</a> and <a>presentations</a>. Implementing and auditing
cryptography systems generally requires substantial experience. Effective
<a href="https://en.wikipedia.org/wiki/Red_team">red teaming</a> can also
help remove bias from security reviews.
        </p>

        <p>
Cryptography suites and libraries have a shelf life and eventually fall to
new attacks and technology advances. Production quality systems need to take
this into account and ensure mechanisms exist to easily and proactively upgrade
expired or broken cryptography suites and libraries, and to invalidate
and replace existing <a>credentials</a>. Regular monitoring is important to
ensure the long term viability of systems processing <a>credentials</a>.
        </p>
      </section>

      <section class="informative">
        <h3>Content Integrity Protection</h3>

        <p>
<a>Verifiable credentials</a> often contain URLs to data that resides outside of
the <a>verifiable credential</a> itself. Linked content that exists outside a
<a>verifiable credential</a>, such as images, JSON-LD Contexts, and other
machine-readable data, are often not protected against tampering because the
data resides outside of the protection of the
<a href="#proofs-signatures">proof</a> on the <a>verifiable credential</a>. For
example, the following highlighted links are not content-integrity protected but
probably should be:
        </p>

        <pre class="example nohighlight"
          title="Non-content-integrity protected links">
{
  "@context": [
    <span class="highlight">"https://www.w3.org/2018/credentials/v1"</span>,
    <span class="highlight">"https://www.w3.org/2018/credentials/examples/v1"</span>
  ],
  "id": "http://example.edu/credentials/58473",
  "type": ["VerifiableCredential", "AlumniCredential"],
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "image": <span class="highlight">"https://example.edu/images/58473"</span>,
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": [{
        "value": "Example University",
        "lang": "en"
      }, {
        "value": "Exemple d'Université",
        "lang": "fr"
      }]
    }
  },
  "proof": { <span class="comment">...</span> }
}
        </pre>

        <p>
While this specification does not recommend any specific content integrity
protection, document authors who want to ensure links to content are integrity
protected are advised to use URL schemes that enforce content integrity. Two
such schemes are the [[HASHLINK]] specification and the [[IPFS]]. The example
below transforms the previous example and adds content integrity protection to
the JSON-LD Contexts using the [[HASHLINK]] specification, and content integrity
protection to the image by using an [[IPFS]] link.
        </p>

        <pre class="example nohighlight" title="Content-integrity protection for links to external data">
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1<span class="highlight">?hl=z3aq31uzgnZBuWNzUB</span>",
    "https://www.w3.org/2018/credentials/examples/v1<span class="highlight">?hl=z8guWNzUBnZBu3aq31</span>"
  ],
  "id": "http://example.edu/credentials/58473",
  "type": ["VerifiableCredential", "AlumniCredential"],
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "image": <span class="highlight">"ipfs:/ipfs/QmXfrS3pHerg44zzK6QKQj6JDk8H6cMtQS7pdXbohwNQfK/image"</span>,
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": [{
        "value": "Example University",
        "lang": "en"
      }, {
        "value": "Exemple d'Université",
        "lang": "fr"
      }]
    }
  },
  "proof": { <span class="comment">...</span> }
}
        </pre>

        <p class="note">
It is debatable whether the JSON-LD Contexts above need protection because
production implementations are expected to ship with static copies of important
JSON-LD Contexts.
        </p>

        <p>
While the example above is one way to achieve content integrity protection,
there are other solutions that might be better suited for certain applications.
Implementers are urged to understand how links to external machine-readable
content that are not content-integrity protected could result in successful
attacks against their applications.
        </p>

      </section>

      <section class="informative">
        <h3>Unsigned Claims</h3>

        <p>
This specification allows <a>credentials</a> to be produced that do not contain
signatures or proofs of any kind. These types of <a>credentials</a> are often
useful for intermediate storage, or self-asserted information, which is
analogous to filling out a form on a web page. Implementers should be aware that
these types of <a>credentials</a> are not <a>verifiable</a> because the
authorship either is not known or cannot be trusted.
        </p>
      </section>

      <section class="informative">
        <h3>Token Binding</h3>

        <p>
A <a>verifier</a> might need to ensure it is the intended recipient of a
<a>verifiable presentation</a> and not the target of a
<a href="https://en.wikipedia.org/wiki/Man-in-the-middle_attack">man-in-the-middle attack</a>.
Approaches such as token binding [[RFC8471]], which ties the request for a
<a>verifiable presentation</a> to the response, can secure the protocol.
Any unsecured protocol is susceptible to man-in-the-middle attacks.
        </p>
      </section>

      <section class="informative">
        <h3>Bundling Dependent Claims</h3>

        <p>
It is considered best practice for <a>issuers</a> to atomize information in a
<a>credential</a>, or use a signature scheme that allows for selective
disclosure. In the case of atomization, if it is not done securely by the
<a>issuer</a>, the <a>holder</a> might bundle together different
<a>credentials</a> in a way that was not intended by the <a>issuer</a>.
        </p>

        <p>
For example, a university might issue two <a>verifiable credentials</a> to a
person, each containing two <a>properties</a>, which must be taken together to
to designate the "role" of that person in a given "department", such as "Staff
Member" in the "Department of Computing", or "Post Graduate Student" in the
"Department of Economics". If these <a>verifiable credentials</a> are atomized
to put only one of these <a>properties</a> into each <a>credential</a> , then
the university would issue four <a>credentials</a> to the person, each
containing one of the following designations: "Staff Member", "Post Graduate
Student", "Department of Computing", and "Department of Economics". The
<a>holder</a> might then transfer the "Staff Member" and "Department of
Economics" <a>verifiable credentials</a> to a <a>verifier</a>, which together
would comprise a false <a>claim</a>.
        </p>
      </section>

      <section class="informative">
        <h3>Highly Dynamic Information</h3>

        <p>
When <a>verifiable credentials</a> are issued for highly dynamic information,
implementers should ensure the expiration times are set appropriately.
Expiration periods longer than the timeframe where the
<a>verifiable credential</a> is valid might create exploitable security
vulnerabilities. Expiration periods shorter than the timeframe where the
information expressed by the <a>verifiable credential</a> is valid creates a
burden on <a>holders</a> and <a>verifiers</a>. It is therefore important to set
validity periods for <a>verifiable credentials</a> that are appropriate to the
use case and the expected lifetime for the information contained in the
<a>verifiable credential</a>.
        </p>
      </section>

      <section class="informative">
        <h3>Device Theft and Impersonation</h3>

        <p>
When <a>verifiable credentials</a> are stored on a device and that
device is lost or stolen, it might be possible for an attacker to gain access
to systems using the victim's <a>verifiable credentials</a>. Ways to mitigate
this type of attack include:
        </p>

        <ul>
          <li>
Enabling password, pin, pattern, or biometric screen unlock protection on the
device.
          </li>
          <li>
Enabling password, biometric, or multi-factor authentication for the
<a>credential</a> <a>repository</a>.
          </li>
          <li>
Enabling password, biometric, or multi-factor authentication when accessing
cryptographic keys.
          </li>
          <li>
Using a separate hardware-based signature device.
          </li>
          <li>
All or any combination of the above.
          </li>
        </ul>
      </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
implementation of any web standard or protocol, ignoring accessibility issues
makes this information unusable by a large subset of the population. It is
important to follow accessibility guidelines and standards, such as [[WCAG21]],
to ensure that 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>
This section details the general accessibility considerations to take into
account when utilizing this data model.
      </p>

      <section class="informative">
        <h3>Data First Approaches</h3>

        <p>
Many physical <a>credentials</a> in use today, such as government identification
cards, have poor accessibility characteristics, including, but not limited to,
small print, reliance on small and high-resolution images, and no affordances
for people with vision impairments.
        </p>

        <p>
When utilizing this data model to create <a>verifiable credentials</a>, it is
suggested that data model designers use a <em>data first</em> approach. For
example, given the choice of using data or a graphical image to depict a
<a>credential</a>, designers should express every element of the image, such as
the name of an institution or the professional <a>credential</a>, in a
machine-readable way instead of relying on a viewer's interpretation of the
image to convey this information. Using a data first approach is preferred
because it provides the foundational elements of building different interfaces
for people with varying abilities.
        </p>
      </section>
    </section>

    <section class="informative">
      <h2>Internationalization Considerations</h2>

      <p>
Implementers are advised to be aware of a number of internationalization
considerations when publishing data described in this specification.
As with any web standards or protocols implementation, ignoring
internationalization makes it difficult for data to be produced and consumed
across a disparate set of languages and societies, which limits the
applicability of the specification and significantly diminishes its value as a
standard.
      </p>

      <p>
Implementers are strongly advised to read the
<em>Strings on the Web: Language and Direction Metadata</em> document
[[STRING-META]], published by the W3C Internationalization Activity, which
elaborates on the need to provide reliable metadata about text to support
internationalization. For the latest information on internationalization
considerations, implementers are also urged to read the Verifiable Credentials
Implementation Guidelines [[VC-IMP-GUIDE]] document.
      </p>

      <p>
This section outlines general internationalization considerations to take into
account when utilizing this data model and is intended to highlight specific
parts of the <em>Strings on the Web: Language and Direction Metadata</em>
document [[STRING-META]] that implementers might be interested in reading.
      </p>

      <section class="informative">
        <h3>Language and Base Direction</h3>

        <p>
Data publishers are strongly encouraged to read the section on
Cross-Syntax Expression in the <em>Strings on the Web: Language and Direction
Metadata</em> document [[STRING-META]] to ensure that the expression of
language and base direction information is possible across multiple expression
syntaxes, such as [[JSON-LD]], [[JSON]], and CBOR [[?RFC7049]].
        </p>

        <p>
The general design pattern is to use the following markup template when
expressing a text string that is tagged with a language and, optionally, a
specific base direction.
        </p>

        <pre class="example nohighlight" title="Design pattern for natural language strings">
"<a>property</a>": {
  "value": "<span class="highlight">The string value</span>",
  "lang": "<code>LANGUAGE</code>"
  "dir": "<code>DIRECTION</code>"
}
        </pre>

        <p>
Using the design pattern above, the following example expresses the title of a
book in the English language without specifying a text direction.
        </p>

        <pre class="example nohighlight" title="Expressing natural language text as English">
"title": {
  "value": "<span class="highlight">HTML and CSS: Designing and Creating Websites</span>",
  "lang": "<code>en</code>"
}
        </pre>

        <p>
The next example uses a similar title expressed in the Arabic language with a
base direction of right-to-left.
        </p>

        <pre class="example nohighlight" title="Arabic text with a base direction of right-to-left">
"title": {
  "value": "<span class="highlight">HTML و CSS: تصميم و إنشاء مواقع الويب</span>",
  "lang": "<code>ar</code>"
  "dir": "<code>rtl</code>"
}
        </pre>

        <p class="note">
The text above would most likely be rendered incorrectly as left-to-right
without the explicit expression of language and direction because many systems
use the first character of a text string to determine text direction.
        </p>

        <p>
Implementers utilizing JSON-LD are strongly urged to
<a href="#extensibility">extend</a> the JSON-LD Context defining the
internationalized <a>property</a> and use the Scoped Context feature of JSON-LD
to alias the <code>@value</code>, <code>@language</code>, and
<code>@direction</code> keywords to <code>value</code>, <code>lang</code>,
and <code>dir</code>, respectively. An example of a JSON-LD Context snippet
doing this is shown below.
        </p>

        <pre class="example nohighlight" title="Specifying scoped aliasing for language information">
"title": {
  <span class="highlight">"@context": {"value": "@value", "lang": "@language", "dir": "@direction"}</span>,
  "@id": "https://www.w3.org/2018/credentials/examples#title"
}
        </pre>

      </section>

      <section class="informative">
        <h3>Complex Language Markup</h3>

        <p>
When multiple languages, base directions, and annotations are used in a single
natural language string, more complex mechanisms are typically required. It is
possible to use markup languages, such as HTML, to encode text with multiple
languages and base directions. It is also possible to use the
<code>rdf:HTML</code> datatype to encode such values accurately in JSON-LD.
        </p>

        <p>
Despite the ability to encode information as HTML, implementers are strongly
discouraged from doing this because it:
        </p>

        <ul>
          <li>
Requires some version of an HTML processor, which increases the burden of
processing language and base direction information.
          </li>
          <li>
Increases the security attack surface when utilizing this data model because
blindly processing HTML could result in executing a <code>script</code> tag that
an attacker injected at some point during the data production process.
          </li>
        </ul>

        <p>
If implementers feel they must use HTML, or other markup languages capable of
containing executable scripts, to address a specific use case, they are advised
to analyze how an attacker would use the markup to mount injection attacks
against a consumer of the markup and then deploy mitigations against the
identified attacks.
        </p>
      </section>

    </section>

    <section class="appendix informative">
      <h2>Validation</h2>

      <p>
While this specification does not provide conformance criteria for the process
of the <a>validation</a> of <a>verifiable credentials</a> or
<a>verifiable presentations</a>, readers might be curious about how the
information in this data model is expected to be utilized by <a>verifiers</a>
during the process of <a>validation</a>. This section captures a selection of
conversations held by the Working Group related to the expected usage of the
data fields in this specification by <a>verifiers</a>.
      </p>

      <section class="informative">
        <h3>Credential Subject</h3>

        <p>
In the <a>verifiable credentials</a> presented by a <a>holder</a>, the value
associated with the <code>id</code> <a>property</a> for each
<code>credentialSubject</code> is expected to identify a <a>subject</a> to the
<a>verifier</a>. If the <a>holder</a> is also the <a>subject</a>, then
the <a>verifier</a> could authenticate the <a>holder</a> if they have
public key metadata related to the <a>holder</a>. The <a>verifier</a> could then
authenticate the <a>holder</a> using a signature generated by the <a>holder</a>
contained in the <a>verifiable presentation</a>. The <code>id</code>
<a>property</a> is optional. <a>Verifiers</a> could use other <a>properties</a>
in a <a>verifiable credential</a> to uniquely identify a <a>subject</a>.
        </p>

        <p class="note">
For information on how authentication and WebAuthn might work with
<a>verifiable credentials</a>, see the Verifiable Credentials Implementation
Guidelines [[VC-IMP-GUIDE]] document.
        </p>

      </section>

      <section class="informative">
        <h3>Issuer</h3>

        <p>
The value associated with the <code>issuer</code> <a>property</a> is expected
to identify an <a>issuer</a> that is known to and trusted by the
<a>verifier</a>.
        </p>

        <p>
Relevant metadata about the <code>issuer</code> <a>property</a> is expected
to be available to the <a>verifier</a>. For example, an <a>issuer</a> can
publish information containing the public keys it uses to digitally sign
<a>verifiable credentials</a> that it issued. This metadata is relevant when
checking the proofs on the <a>verifiable credentials</a>.
        </p>
      </section>

      <section class="informative">
        <h3>Issuance Date</h3>

        <p>
The <code>issuanceDate</code> is expected to be within an expected range for the
<a>verifier</a>. For example, a <a>verifier</a> can check that the issuance date
of a <a>verifiable credential</a> is not in the future.
        </p>
      </section>

      <section class="informative">
        <h3>Proofs (Signatures)</h3>

        <p>
The cryptographic mechanism used to prove that the information in a
<a>verifiable credential</a> or <a>verifiable presentation</a> was not
tampered with is called a <em>proof</em>. There are many types of cryptographic
proofs including, but not limited to, digital signatures, zero-knowledge proofs,
Proofs of Work, and Proofs of Stake. In general, when verifying proofs,
implementations are expected to ensure:
        </p>

        <ul>
          <li>
The proof is available in the form of a known proof suite.
          </li>
          <li>
All required proof suite <a>properties</a> are present.
          </li>
          <li>
The proof suite <a>verification</a> algorithm, when applied to the data, results
in an acceptable proof.
          </li>
        </ul>

        <p>
Some proofs are digital signatures. In general, when verifying digital
signatures, implementations are expected to ensure:
        </p>

        <ul>
          <li>
Acceptably recent metadata regarding the public key associated with the
signature is available. For example, the metadata might include
<a>properties</a> related to expiration, key owner, or key purpose.
          </li>
          <li>
The key is not suspended, revoked, or expired.
          </li>
          <li>
The cryptographic signature is expected to verify.
          </li>
          <li>
If the cryptographic suite expects a <code>proofPurpose</code> <a>property</a>,
it is expected to exist and be a valid value, such as
<code>assertionMethod</code>.
          </li>
        </ul>

        <p class="note">
The digital signature provides a number of protections, other than tamper
resistance, which are not immediately obvious. For example, a Linked Data
Signature <code>created</code> <a>property</a> establishes a date and time
before which the <a>credential</a> should not be considered <a>verified</a>. The
<code>verificationMethod</code> <a>property</a> specifies, for example, the
public key that can be used to verify the digital signature. Dereferencing a
public key URL reveals information about the controller of the key, which can
be checked against the issuer of the <a>credential</a>. The
<code>proofPurpose</code> <a>property</a> clearly expresses the purpose for
the proof and ensures this information is protected by the signature. A proof is
typically attached to a <a>verifiable presentation</a> for authentication
purposes and to a <a>verifiable credential</a> as a method of assertion.
        </p>
      </section>

      <section class="informative">
        <h3>Expiration</h3>

        <p>
The <code>expirationDate</code> is expected to be within an expected range
for the <a>verifier</a>. For example, a <a>verifier</a> can check that the
expiration date of a <a>verifiable credential</a> is not in the past.
        </p>
      </section>

      <section class="informative">
        <h3>Status</h3>

        <p>
If the <code>credentialStatus</code> property is available, the status of a
<a>verifiable credential</a> is expected to be evaluated by the <a>verifier</a>
according to the <code>credentialStatus</code> <a>type</a> definition for the
<a>verifiable credential</a> and the <a>verifier's</a> own status evaluation
criteria. For example, a <a>verifier</a> can ensure the status of the
<a>verifiable credential</a> is not "withdrawn for cause by the <a>issuer</a>".
        </p>
      </section>

      <section class="informative">
        <h3>Fitness for Purpose</h3>

        <p>
Fitness for purpose is about whether the custom <a>properties</a> in the
<a>verifiable credential</a> are appropriate for the <a>verifier's</a> purpose.
For example, if a <a>verifier</a> needs to determine whether a <a>subject</a> is
older than 21 years of age, they might rely on a specific <code>birthdate</code>
<a>property</a>, or on more abstract <a>properties</a>, such as
<code>ageOver</code>.
        </p>

        <p>
The <a>issuer</a> is trusted by the <a>verifier</a> to make the <a>claims</a> at
hand. For example, a franchised fast food restaurant location trusts the
discount coupon <a>claims</a> made by the corporate headquarters of the
franchise. Policy information expressed by the <a>issuer</a> in the
<a>verifiable credential</a> should be respected by <a>holders</a> and
<a>verifiers</a> unless they accept the liability of ignoring the policy.
        </p>
      </section>
    </section>

    <section class="appendix informative">
      <h2>Contexts, Types, and Credential Schemas</h2>

      <section class="informative">
        <h3>Base Context</h3>
          <p>
The base context, located at
<code>https://www.w3.org/2018/credentials/v1</code> with a SHA-256 digest of
<strong><code>ab4ddd9a531758807a79a5b450510d61ae8d147eab966cc9a200c07095b0cdcc</code></strong>,
can be used to implement a local cached copy. For convenience, the base context
is also provided in this section.
          </p>

<pre class="informative">
{
  "@context": {
    "@version": 1.1,
    "@protected": true,

    "id": "@id",
    "type": "@type",

    "VerifiableCredential": {
      "@id": "https://www.w3.org/2018/credentials#VerifiableCredential",
      "@context": {
        "@version": 1.1,
        "@protected": true,

        "id": "@id",
        "type": "@type",

        "cred": "https://www.w3.org/2018/credentials#",
        "sec": "https://w3id.org/security#",
        "xsd": "http://www.w3.org/2001/XMLSchema#",

        "credentialSchema": {
          "@id": "cred:credentialSchema",
          "@type": "@id",
          "@context": {
            "@version": 1.1,
            "@protected": true,

            "id": "@id",
            "type": "@type",

            "cred": "https://www.w3.org/2018/credentials#",

            "JsonSchemaValidator2018": "cred:JsonSchemaValidator2018"
          }
        },
        "credentialStatus": {"@id": "cred:credentialStatus", "@type": "@id"},
        "credentialSubject": {"@id": "cred:credentialSubject", "@type": "@id"},
        "evidence": {"@id": "cred:evidence", "@type": "@id"},
        "expirationDate": {"@id": "cred:expirationDate", "@type": "xsd:dateTime"},
        "holder": {"@id": "cred:holder", "@type": "@id"},
        "issued": {"@id": "cred:issued", "@type": "xsd:dateTime"},
        "issuer": {"@id": "cred:issuer", "@type": "@id"},
        "issuanceDate": {"@id": "cred:issuanceDate", "@type": "xsd:dateTime"},
        "proof": {"@id": "sec:proof", "@type": "@id", "@container": "@graph"},
        "refreshService": {
          "@id": "cred:refreshService",
          "@type": "@id",
          "@context": {
            "@version": 1.1,
            "@protected": true,

            "id": "@id",
            "type": "@type",

            "cred": "https://www.w3.org/2018/credentials#",

            "ManualRefreshService2018": "cred:ManualRefreshService2018"
          }
        },
        "termsOfUse": {"@id": "cred:termsOfUse", "@type": "@id"},
        "validFrom": {"@id": "cred:validFrom", "@type": "xsd:dateTime"},
        "validUntil": {"@id": "cred:validUntil", "@type": "xsd:dateTime"}
      }
    },

    "VerifiablePresentation": {
      "@id": "https://www.w3.org/2018/credentials#VerifiablePresentation",
      "@context": {
        "@version": 1.1,
        "@protected": true,

        "id": "@id",
        "type": "@type",

        "cred": "https://www.w3.org/2018/credentials#",
        "sec": "https://w3id.org/security#",

        "holder": {"@id": "cred:holder", "@type": "@id"},
        "proof": {"@id": "sec:proof", "@type": "@id", "@container": "@graph"},
        "verifiableCredential": {"@id": "cred:verifiableCredential", "@type": "@id", "@container": "@graph"}
      }
    },

    "EcdsaSecp256k1Signature2019": {
      "@id": "https://w3id.org/security#EcdsaSecp256k1Signature2019",
      "@context": {
        "@version": 1.1,
        "@protected": true,

        "id": "@id",
        "type": "@type",

        "sec": "https://w3id.org/security#",
        "xsd": "http://www.w3.org/2001/XMLSchema#",

        "challenge": "sec:challenge",
        "created": {"@id": "http://purl.org/dc/terms/created", "@type": "xsd:dateTime"},
        "domain": "sec:domain",
        "expires": {"@id": "sec:expiration", "@type": "xsd:dateTime"},
        "jws": "sec:jws",
        "nonce": "sec:nonce",
        "proofPurpose": {
          "@id": "sec:proofPurpose",
          "@type": "@vocab",
          "@context": {
            "@version": 1.1,
            "@protected": true,

            "id": "@id",
            "type": "@type",

            "sec": "https://w3id.org/security#",

            "assertionMethod": {"@id": "sec:assertionMethod", "@type": "@id", "@container": "@set"},
            "authentication": {"@id": "sec:authenticationMethod", "@type": "@id", "@container": "@set"}
          }
        },
        "proofValue": "sec:proofValue",
        "verificationMethod": {"@id": "sec:verificationMethod", "@type": "@id"}
      }
    },

    "EcdsaSecp256r1Signature2019": {
      "@id": "https://w3id.org/security#EcdsaSecp256r1Signature2019",
      "@context": {
        "@version": 1.1,
        "@protected": true,

        "id": "@id",
        "type": "@type",

        "sec": "https://w3id.org/security#",
        "xsd": "http://www.w3.org/2001/XMLSchema#",

        "challenge": "sec:challenge",
        "created": {"@id": "http://purl.org/dc/terms/created", "@type": "xsd:dateTime"},
        "domain": "sec:domain",
        "expires": {"@id": "sec:expiration", "@type": "xsd:dateTime"},
        "jws": "sec:jws",
        "nonce": "sec:nonce",
        "proofPurpose": {
          "@id": "sec:proofPurpose",
          "@type": "@vocab",
          "@context": {
            "@version": 1.1,
            "@protected": true,

            "id": "@id",
            "type": "@type",

            "sec": "https://w3id.org/security#",

            "assertionMethod": {"@id": "sec:assertionMethod", "@type": "@id", "@container": "@set"},
            "authentication": {"@id": "sec:authenticationMethod", "@type": "@id", "@container": "@set"}
          }
        },
        "proofValue": "sec:proofValue",
        "verificationMethod": {"@id": "sec:verificationMethod", "@type": "@id"}
      }
    },

    "Ed25519Signature2018": {
      "@id": "https://w3id.org/security#Ed25519Signature2018",
      "@context": {
        "@version": 1.1,
        "@protected": true,

        "id": "@id",
        "type": "@type",

        "sec": "https://w3id.org/security#",
        "xsd": "http://www.w3.org/2001/XMLSchema#",

        "challenge": "sec:challenge",
        "created": {"@id": "http://purl.org/dc/terms/created", "@type": "xsd:dateTime"},
        "domain": "sec:domain",
        "expires": {"@id": "sec:expiration", "@type": "xsd:dateTime"},
        "jws": "sec:jws",
        "nonce": "sec:nonce",
        "proofPurpose": {
          "@id": "sec:proofPurpose",
          "@type": "@vocab",
          "@context": {
            "@version": 1.1,
            "@protected": true,

            "id": "@id",
            "type": "@type",

            "sec": "https://w3id.org/security#",

            "assertionMethod": {"@id": "sec:assertionMethod", "@type": "@id", "@container": "@set"},
            "authentication": {"@id": "sec:authenticationMethod", "@type": "@id", "@container": "@set"}
          }
        },
        "proofValue": "sec:proofValue",
        "verificationMethod": {"@id": "sec:verificationMethod", "@type": "@id"}
      }
    },

    "RsaSignature2018": {
      "@id": "https://w3id.org/security#RsaSignature2018",
      "@context": {
        "@version": 1.1,
        "@protected": true,

        "challenge": "sec:challenge",
        "created": {"@id": "http://purl.org/dc/terms/created", "@type": "xsd:dateTime"},
        "domain": "sec:domain",
        "expires": {"@id": "sec:expiration", "@type": "xsd:dateTime"},
        "jws": "sec:jws",
        "nonce": "sec:nonce",
        "proofPurpose": {
          "@id": "sec:proofPurpose",
          "@type": "@vocab",
          "@context": {
            "@version": 1.1,
            "@protected": true,

            "id": "@id",
            "type": "@type",

            "sec": "https://w3id.org/security#",

            "assertionMethod": {"@id": "sec:assertionMethod", "@type": "@id", "@container": "@set"},
            "authentication": {"@id": "sec:authenticationMethod", "@type": "@id", "@container": "@set"}
          }
        },
        "proofValue": "sec:proofValue",
        "verificationMethod": {"@id": "sec:verificationMethod", "@type": "@id"}
      }
    },

    "proof": {"@id": "https://w3id.org/security#proof", "@type": "@id", "@container": "@graph"}
  }
}
</pre>
      </section>

      <section class="informative">
        <h3>Differences between Contexts, Types, and CredentialSchemas</h3>

        <p>
The <a>verifiable credential</a> and <a>verifiable presentation</a> data models
leverage a variety of underlying technologies including [[JSON-LD]] and
[[JSON-SCHEMA-2018]]. This section will provide a comparison of the
<code>@context</code>, <code>type</code>, and <code>credentialSchema</code>
properties, and cover some of the more specific use cases where it is possible
to use these features of the data model.
        </p>

        <p>
The <code>type</code> property is used to uniquely identify
the type of the <a>verifiable credential</a> in which it appears, i.e., to
indicate which set of claims the <a>verifiable credential</a> contains.
This property, and the value <code>VerifiableCredential</code> within the set of
its values, are mandatory. Whilst it is good practice to include one additional
value depicting the unique subtype of this <a>verifiable credential</a>, it is permitted
to either omit or include additional type values in the array. Many
verifiers will request a <a>verifiable credential</a> of a specific subtype, then
omitting the subtype value could make it more difficult for verifiers to inform
the holder which <a>verifiable credential</a> they require. When a <a>verifiable
credential</a> has multiple subtypes, listing all of them in the <code>type</code>
property is sensible. While the semantics are the same in both a [[JSON]] and
[[JSON-LD]] representation, the usage of the <code>type</code> property in a
[[JSON-LD]] representation of a <a>verifiable credential</a> is able to enforce the semantics of the
<a>verifiable credential</a> better than a [[JSON]] representation of the same
credential because the machine is able to check the semantics. With [[JSON-LD]],
the technology is not only describing the categorization of the set of claims,
the technology is also conveying the structure and semantics of the sub-graph of
the properties in the graph. In [[JSON-LD]], this represents the type of the node
in the graph which is why some [[JSON-LD]] representations of a <a>verifiable
credential</a> will use the <code>type</code> property on many objects in the
<a>verifiable credential</a>.
        </p>

        <p>
The primary purpose of the <code>@context</code> property, from a [[JSON-LD]]
perspective, is to convey the meaning of the data and term definitions of the
data in a <a>verifiable credential</a>, in a machine readable way. When encoding a pure
[[JSON]] representation, the <code>@context</code> property remains mandatory and
provides some basic support for global semantics. The <code>@context</code>
property is used to map the globally unique URIs for properties in <a>verifiable
credentials</a> and <a>verifiable presentations</a> into short-form alias names,
making both the [[JSON]] and [[JSON-LD]] representations more human-friendly
to read. From a [[JSON-LD]] perspective, this mapping also allows the data in
a <a>credential</a> to be modeled in a network of machine-readable data, by
enhancing how the data in the <a>verifiable credential</a> or <a>verifiable
presentation</a> relates to a larger machine-readable data graph. This is
useful for telling machines how to relate the meaning of data to
other data in an ecosystem where parties are unable to coordinate. This
property, with the first value in the set being
<code>https://www.w3.org/2018/credentials/v1</code>, is mandatory.
        </p>

        <p>
Since the <code>@context</code> property is used to map data to a graph
data model, and the <code>type</code> property in [[JSON-LD]] is used to
describe nodes within the graph, the <code>type</code> property becomes
even more important when using the two properties in combination. For example,
if the <code>type</code> property is not included within the resolved
<code>@context</code> resource using [[JSON-LD]], it could lead to claims being
dropped and/or their integrity no longer being protected during production and
consumption of the <a>verifiable credential</a>. Alternatively, it could lead to
errors being raised during production or consumption of a <a>verifiable
credential</a>. This will depend on the design choices of the implementation and
both paths are used in implementations today, so it's important to pay attention
to these properties when using a [[JSON-LD]] representation of a <a>verifiable
credential</a> or <a>verifiable presentation</a>.
        </p>

        <p>
The primary purpose of the <code>credentialSchema</code> property is to
define the structure of the <a>verifiable credential</a>, and the datatypes for
the values of each property that appears. A <code>credentialSchema</code> is useful
for defining the contents and structure of a set of claims in a <a>verifiable
credential</a>, whereas [[JSON-LD]] and a <code>@context</code> in a <a>verifiable
credential</a> are best used only for conveying the semantics and term
definitions of the data, and can be used to define the structure of the
<a>verifiable credential</a> as well.
        </p>

        <p>
While it is possible to use some [[JSON-LD]] features to allude to the
contents of the <a>verifiable credential</a>, it's not generally
suggested to use <code>@context</code> to constrain the data types of the
data model. For example, <code>"@type": "@json"</code> is useful for leaving the
semantics open-ended and not strictly defined. This can be dangerous if
the implementer is looking to constrain the data type of the claims in the
<a>credential</a>, and is expected not to be used.
          </p>

        <p>
When the <code>credentialSchema</code> and <code>@context</code> properties
are used in combination, both producers and consumers can be more confident
about the expected contents and data types of the <a>verifiable credential</a>
and <a>verifiable presentation</a>.
        </p>
      </section>
    </section>

    <section class="appendix informative">
      <h2>IANA Considerations</h2>
      <p>
This section will be submitted to the Internet Engineering Steering Group
(IESG) for review, approval, and registration with IANA in the
"JSON Web Token Claims Registry".
      </p>

      <ul>
        <li>Claim Name: "vc"</li>
        <li>Claim Description: Verifiable Credential</li>
        <li>Change Controller: W3C</li>
        <li>Specification Document(s):
<a href="https://www.w3.org/TR/vc-data-model/">Section 6.3.1.2: JSON Web Token
Extensions of Verifiable Credentials Data Model 1.0</a>
        </li>
      </ul>

      <ul>
        <li>Claim Name: "vp"</li>
        <li>Claim Description: Verifiable Presentation</li>
        <li>Change Controller: W3C</li>
        <li>Specification Document(s):
<a href="https://www.w3.org/TR/vc-data-model/">Section 6.3.1.2: JSON Web Token
Extensions of Verifiable Credentials Data Model 1.0</a>
        </li>
      </ul>

    </section>

    <section>
      <h2>Revision History</h2>

      <p>
This section contains the substantive changes that have been made to this
specification over time.
      </p>

      <p>
Changes since the
<a href="https://www.w3.org/TR/2022/REC-vc-data-model-20220303/">
v1.1 Recommendation</a>:
      </p>
      <ul>
        <li>
Increment version number to v2.0 and remove prior REC-track comments.
        </li>
      </ul>

      <p>
Changes since the
<a href="https://www.w3.org/TR/2019/REC-vc-data-model-20191119/">
v1.0 Recommendation</a>:
      </p>
      <ul>
        <li>
Add this revision history section.
        </li>

        <li>
Update previous normative references that pointed to RFC3339 for datetime
details to now normatively reference the datetime details described in
XMLSCHEMA11-2 which more accurately reflects the usage in examples and
libraries.
        </li>

        <li>
Loosen the requirement to use URLs to use <a>URIs</a> in the <code>id</code>
property of the <code>credentialStatus</code> and <code>refreshService</code>
sections of the data model.
        </li>

        <li>
Loosen normative statements in the zero-knowledge proofs section to enable
compliance of new zero-knowledge proof schemes, such as BBS+, that have been
created since the v1.0 specification was published as a Recommendation.
        </li>

        <li>
Update all references to point to the latest version of the referenced
specifications. Fix broken links to papers that have become unavailable to
updated locations where the papers are available.
        </li>

        <li>
Increase accessibility of SVG diagrams.
        </li>

        <li>
Fix editorial bugs in a few examples related to `issuer`, `issuanceDate`,
`credentialStatus`, dates, dead links, and minor syntax errors.
        </li>

        <li>
Move acknowledgements from Status of the Document section into the
Acknowledgements appendix.
        </li>
      </ul>
    </section>

    <section class="appendix informative">
      <h2>Acknowledgements</h2>

      <p>
The Working Group thanks the following individuals not only for their
contributions toward the content of this document, but also for yeoman's work
in this standards community that drove changes, discussion, and consensus among
a sea of varied opinions: Matt Stone, Gregg Kellogg, Ted Thibodeau Jr, Oliver
Terbu, Joe Andrieu, David I. Lehn, Matthew Collier, and Adrian Gropper.
      </p>

      <p>
Work on this specification has been supported by the Rebooting the
Web of Trust community facilitated by Christopher Allen, Shannon Appelcline,
Kiara Robles, Brian Weller, Betty Dhamers, Kaliya Young, Manu Sporny,
Drummond Reed, Joe Andrieu, Heather Vescent, Kim Hamilton Duffy, Samantha Chase,
and Andrew Hughes. The participants in the Internet Identity Workshop,
facilitated by Phil Windley, Kaliya Young, Doc Searls, and Heidi Nobantu Saul,
also supported the refinement of this work through numerous working sessions
designed to educate about, debate on, and improve this specification.
      </p>

      <p>
The Working Group also thanks our Chairs, Dan Burnett, Matt Stone, Brent Zundel,
Wayne Chang, and Kristina Yasuda as well as our W3C Staff Contacts, Kazuyuki
Ashimura and Ivan Herman, for their expert management and steady guidance of the
group through the W3C standardization process.
      </p>

      <p>
Portions of the work on this specification have been funded by the
United States Department of Homeland Security's Science and Technology
Directorate under contract HSHQDC-17-C-00019. The content of this specification
does not necessarily reflect the position or the policy of the U.S. Government
and no official endorsement should be inferred.
      </p>

      <p>
The Working Group would like to thank the following individuals for reviewing
and providing feedback on the specification (in alphabetical order):
      </p>

      <p>
Christopher Allen, David Ammouial, Joe Andrieu, Bohdan Andriyiv, Ganesh
Annan, Kazuyuki Ashimura, Tim Bouma, Pelle Braendgaard, Dan Brickley,
Allen Brown, Jeff Burdges, Daniel Burnett, ckennedy422, David Chadwick,
Chaoxinhu, Kim (Hamilton) Duffy, Lautaro Dragan, enuoCM, Ken Ebert, Eric
Elliott, William Entriken, David Ezell, Nathan George, Reto Gmür, Ryan
Grant, glauserr, Adrian Gropper, Joel Gustafson, Amy Guy, Lovesh
Harchandani, Daniel Hardman, Dominique Hazael-Massieux, Jonathan Holt,
David Hyland-Wood, Iso5786, Renato Iannella, Richard Ishida, Ian Jacobs,
Anil John, Tom Jones, Rieks Joosten, Gregg Kellogg, Kevin, Eric Korb,
David I. Lehn, Michael Lodder, Dave Longley, Christian Lundkvist, Jim
Masloski, Pat McBennett, Adam C. Migus, Liam Missin, Alexander Mühle,
Anthony Nadalin, Clare Nelson, Mircea Nistor, Grant Noble, Darrell
O'Donnell, Nate Otto, Matt Peterson, Addison Phillips, Eric Prud'hommeaux,
Liam Quin, Rajesh Rathnam, Drummond Reed, Yancy Ribbens, Justin Richer,
Evstifeev Roman, RorschachRev, Steven Rowat, Pete Rowley, Markus
Sabadello, Kristijan Sedlak, Tzviya Seigman, Reza Soltani, Manu Sporny,
Orie Steele, Matt Stone, Oliver Terbu, Ted Thibodeau Jr, John Tibbetts,
Mike Varley, Richard Varn, Heather Vescent, Christopher Lemmer Webber,
Benjamin Young, Kaliya Young, Dmitri Zagidulin, and Brent Zundel.
      </p>
    </section>
  </body>
</html>