Verifiable Credentials Data Model v2.0

This section is non-normative.

In the physical world, a credential might consist of:

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

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

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

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

While this specification attempts to improve the ease of expressing digital credentials, 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 verifiable and easily machine-readable credentials threatens to make worse. This document outlines and attempts to address a number of these issues in Section 8. Privacy Considerations. Examples of how to use this data model using privacy-enhancing technologies, such as zero-knowledge proofs, are also provided throughout this document.

The word "verifiable" in the terms verifiable credential and verifiable presentation refers to the characteristic of a credential or presentation as being able to be verified by a verifier, as defined in this document. Verifiability of a credential does not imply the truth of claims encoded therein. Rather, once the authenticity and currency of a verifiable credential or verifiable presentation are established, a verifier validates the included claims using their own business rules before relying on them. Such reliance only occurs after evaluating the issuer, the proof, the subject, and the claims, against one or more verifier policies.

This section is non-normative.

This section describes the roles of the core actors and the relationships between them in an ecosystem where verifiable credentials 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:

holder

A role an entity might perform by possessing one or more verifiable credentials and generating verifiable presentations from them. Example holders include students, employees, and customers.

issuer

A role an entity performs by asserting claims about one or more subjects, creating a verifiable credential from these claims, and transmitting the verifiable credential to a holder. Example issuers include corporations, non-profit organizations, trade associations, governments, and individuals.

subject

An entity about which claims are made. Example subjects include human beings, animals, and things. In many cases the holder of a verifiable credential is the subject, but in certain cases it is not. For example, a parent (the holder) might hold the verifiable credentials of a child (the subject), or a pet owner (the holder) might hold the verifiable credentials of their pet (the subject). For more information about these special cases, see the Subject-Holder Relationships section in the Verifiable Credentials Implementation Guide [VC-IMP-GUIDE].

verifier

A role an entity performs by receiving one or more verifiable credentials, optionally inside a verifiable presentation, for processing. Example verifiers include employers, security personnel, and websites.

verifiable data registry

A role a system might perform by mediating the creation and verification of identifiers, keys, and other relevant data, such as verifiable credential schemas, revocation registries, issuer public keys, and so on, which might be required to use verifiable credentials. Some configurations might require correlatable identifiers for subjects. 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.

This section is non-normative.

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

• A more thorough explanation of the roles introduced above
• The needs identified in market verticals, such as education, finance, healthcare, retail, professional licensing, and government
• Common tasks performed by the roles in the ecosystem, as well as their associated requirements
• Common sequences and flows identified by the Working Group.

As a result of documenting and analyzing the use cases document, the following desirable ecosystem characteristics were identified for this specification:

• Verifiable credentials represent statements made by an issuer in a tamper-evident and privacy-respecting manner.
• Holders can assemble collections of verifiable credentials from different issuers into a single artifact, a verifiable presentation.
• Issuers can issue verifiable credentials about any subject.
• Acting as issuer, holder, or verifier requires neither registration nor approval by any authority, as the trust involved is bilateral between parties.
• Verifiable presentations allow any verifier to verify the authenticity of verifiable credentials from any issuer.
• Holders can receive verifiable credentials from anyone.
• Holders can interact with any issuer and any verifier through any user agent.
• Holders can share verifiable presentations, which can then be verified without revealing the identity of the verifier to the issuer.
• Holders can store verifiable credentials in any location, without affecting their verifiability and without the issuer knowing anything about where they are stored or when they are accessed.
• Holders can present verifiable presentations to any verifier without affecting authenticity of the claims and without revealing that action to the issuer.
• A verifier can verify verifiable presentations from any holder, containing proofs of claims from any issuer.
• Verification should not depend on direct interactions between issuers and verifiers.
• Verification should not reveal the identity of the verifier to any issuer.
• The specification must provide a means for issuers to issue verifiable credentials that support selective disclosure, without requiring all conformant software to support that feature.
• Issuers can issue verifiable credentials that support selective disclosure.
• If a single verifiable credential supports selective disclosure, then holders can present proofs of claims without revealing the entire verifiable credential.
• Verifiable presentations can either disclose the attributes of a verifiable credential, or satisfy derived predicates requested by the verifier. Derived predicates are Boolean conditions, such as greater than, less than, equal to, is in set, and so on.
• Issuers can issue revocable verifiable credentials.
• The processes of cryptographically protecting and verifying verifiable credentials and verifiable presentations have to be deterministic, bi-directional, and lossless. Any verifiable credential or verifiable presentation has to be transformable to the JSON-LD data model defined in this document via a deterministic process so that its verification can be processed in an interoperable fashion.
• Verifiable credentials and verifiable presentations 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 verifiable credential or verifiable presentation needs to be transformable to the generic data model defined in this document in a deterministic process such that the resulting verifiable credential 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.
• The data model and serialization must be extendable with minimal coordination.
• Revocation by the issuer should not reveal any identifying information about the subject, the holder, the specific verifiable credential, or the verifier.
• Issuers can disclose the revocation reason.
• Issuers revoking verifiable credentials 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).
• Issuers can provide a service for refreshing a verifiable credential.

This section is non-normative.

A claim is a statement about a subject. A subject is a thing about which claims can be made. Claims are expressed using subject- property-value relationships.

The data model for claims, illustrated in Figure 2 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 Figure 3 below.

Individual claims can be merged together to express a graph of information about a subject. The example shown in Figure 4 below extends the previous claim by adding the claims that Pat knows Sam and that Sam is employed as a professor.

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

This section is non-normative.

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

Examples of verifiable credentials include digital employee identification cards, digital birth certificates, and digital educational certificates.

Figure 5 above shows the basic components of a verifiable credential, but abstracts the details about how claims are organized into information graphs, which are then organized into verifiable credentials.

Figure 6 below shows a more complete depiction of a verifiable credential using an embedded proof based on [VC-DATA-INTEGRITY]. It is composed of at least two information graphs. The first of these information graphs, the verifiable credential graph (which is the default graph), expresses the verifiable credential itself, through credential metadata and other claims. The second information graph, referred to by the proof property, is the proof graph of the verifiable credential, and is a separate named graph. The proof graph expresses the digital proof, which, in this case, is a digital signature.

Figure 7 below shows the same verifiable credential as Figure 6, but using JOSE based on [VC-JOSE-COSE]. The payload contains a single information graph, that being the verifiable credential graph containing credential metadata and other claims.

This section is non-normative.

Enhancing privacy is a key design feature of this specification. Therefore, it is important for entities 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 verifiable presentation. Examples of different personas include a person's professional persona, their online gaming persona, their family persona, or an incognito persona.

A verifiable presentation can express data from multiple verifiable credentials and contain arbitrary additional data encoded as JSON-LD. They are used by a holder to present claims to a verifier. It is also possible to present verifiable credentials directly.

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

Figure 8 above shows the components of a verifiable presentation, but abstracts the details about how verifiable credentials are organized into information graphs, which are then organized into verifiable presentations.

Figure 9 below shows a more complete depiction of a verifiable presentation using an embedded proof based on [VC-DATA-INTEGRITY]. It is composed of at least four information graphs. The first of these information graphs, the verifiable presentation graph (which is the default graph), expresses the verifiable presentation itself through presentation metadata. The verifiable presentation refers, via the verifiableCredential property, to a verifiable credential. This credential is a self-contained verifiable credential graph containing credential metadata and other claims. This credential refers to a verifiable credential proof graph via a proof property, expressing the proof (usually a digital signature) of the credential. This verifiable credential graph, and its linked proof graph, constitute the second and third information graphs, respectively, and each is a separate named graph. The presentation also refers, via the proof property, to the presentation's proof graph, which is the fourth information graph (another named graph). This presentation proof graph represents the digital signature of the verifiable presentation graph, the verifiable credential graph, and the proof graph linked from the verifiable credential graph.

Figure 10 below shows the same verifiable presentation as Figure 9, but using an enveloping proof based on [VC-JOSE-COSE]. The payload contains only two information graphs: the verifiable presentation graph expressing the verifiable presentation itself through presentation metadata; and the corresponding verifiable credential graph, referred to by the verifiableCredential property. The verifiable credential graph contains a single EnvelopedVerifiableCredential instance referring, via a data: URL [RFC2397], to the verifiable credential secured via an enveloping proof shown on Figure 7.

This section is non-normative.

The previous sections introduced the concepts of claims, verifiable credentials, and verifiable presentations 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 credentials and presentations in the Verifiable Credentials Ecosystem often take a common path:

1. Issuance of one or more verifiable credentials.
2. Storage of verifiable credentials in a credential repository (such as a digital wallet).
3. Composition of verifiable credentials into a verifiable presentation for verifiers.
4. Verification of the verifiable presentation by the verifier.
5. Validation by the verifier of relevant claims contained in the verifiable presentation.

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 verifiable credential from a university, and Pat stores the verifiable credential in a digital wallet.

{
  // set the context, which establishes the special terms we will be using
  // such as 'issuer' and 'alumniOf'.
  "@context": [
    "carview.php?tsp=https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  // specify the identifier for the credential
  "id": "https://university.example/credentials/1872",
  // the credential types, which declare what data to expect in the credential
  "type": ["VerifiableCredential", "ExampleAlumniCredential"],
  // the entity that issued the credential
  "issuer": "https://university.example/issuers/565049",
  // when the credential was issued
  "validFrom": "2010-01-01T19:23:24Z",
  // claims about the subjects of the credential
  "credentialSubject": {
    // identifier for the only subject of the credential
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    // assertion about the only subject of the credential
    "alumniOf": {
      // identifier for the university
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      // name of the university
      "name": "Example University"
    }
  }
}

Pat then attempts to redeem the alumni discount. The verifier, a ticket sales system, states that alumni of "Example University" receive 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 verifiable credential, and this request is routed to Pat's digital wallet. The digital wallet asks Pat if they would like to provide a previously issued verifiable credential. Pat selects the alumni verifiable credential, which is then composed into a verifiable presentation. The verifiable presentation is sent to the verifier and verified.

Once verified as authentic and current, the seller of the season ticket then validates that the issuer of the verifiable credential is recognized for the claim of alumni status — it is, as it was issued by Example University — and that today's date lies within the validity period defined by the values of the validFrom and validUntil properties. Since the holder is expected to be the subject of the verifiable credential, the verifier also confirms that the id for the alumni claim matches the id of the creator of the verifiable presentation.

Having verified the credential and the presentation, and validated the relevant claims, the ticket seller safely enables the alumni discount for Pat, confident that Pat is legitimately entitled to it.

{
  "@context": [
    "carview.php?tsp=https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "type": "VerifiablePresentation",
  // the verifiable credential issued in the previous example
  "verifiableCredential": [{
    "@context": [
      "carview.php?tsp=https://www.w3.org/ns/credentials/v2",
      "https://www.w3.org/ns/credentials/examples/v2"
    ],
    "id": "https://university.example/credentials/1872",
    "type": ["VerifiableCredential", "ExampleAlumniCredential"],
    "issuer": "https://university.example/issuers/565049",
    "validFrom": "2010-01-01T19:23:24Z",
    "credentialSubject": {
      "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
      "alumniOf": {
        "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
        "name": "Example University"
      }
    }
  }]
}

This section is non-normative.

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.

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.

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.

This section is non-normative.

A variety of trust relationships exist in the ecosystem described by this specification. An individual using a web browser trusts the web browser, also known as a user agent, to preserve that trust by not uploading their personal information to a data broker; similarly, entities filling the roles in the ecosystem described by this specification trust the software that operates on behalf of each of those roles. Examples include the following:

• An issuer's user agent (issuer software), such as an online education platform, is expected to only issue verifiable credentials to individuals that the issuer asserts have completed their educational program.
• A verifier's user agent (verification software), such as a hiring website, is expected to only allow access to individuals with a valid verification status for verifiable credentials and verifiable presentations provided to the platform by such individuals.
• A holder's user agent (holder software), such as a digital wallet, is expected to only divulge information to a verifier when the holder has consented to the release of that information.

The examples above are not exhaustive, and the users in these roles can also expect a variety of other things from the software they use to achieve their goals. In short, the software is expected to operate in the best interests of the user, and a violation of that expectation is a violation of trust that will result in the software being replaced by something that does not violate that trust. Implementers are strongly advised to write software that does not violate the trust of the users it will serve. Implementers are also advised to provide auditing features in the software that they create such that the users, or trusted third parties, can check whether the software is indeed behaving in their best interests.

Readers are advised that some software, such as a website that provides services to a single verifier and multiple holders, might operate as a user agent to both roles, but might not always be able to simultaneously operate in the best interests of all parties. For example, if that website detects an attempt at fraudulent verifiable credential use among multiple holders, it might report such an anomaly to the verifier, which might be considered to not be in the best interest of the holder committing the violation, but would be in the best interest of the verifier as well as any holders not committing such a violation. It is strongly advised that when software operates in this manner, that it is made clear in whose best interest the software is operating through mechanisms such as a website usage policy.

This section is non-normative.

Data associated with verifiable credentials stored in the credential.credentialSubject field is susceptible to privacy violations when shared with verifiers. Personally identifying data, such as a government-issued identifier, shipping address, and full name, can be easily used to determine, track, and correlate an entity. 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.

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

Because a verifiable credential often contains personally identifiable information (PII), implementers are strongly advised to use mechanisms while storing and transporting verifiable credentials 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 verifiable credential while at rest.

This section is non-normative.

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

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

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

• Bound to a single origin
• Single-use
• Not used at all, but instead replaced by short-lived, single-use bearer tokens.

This section is non-normative.

The contents of a credential are secured using a securing mechanism. Values used to represent the securing mechanism 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.

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.

This section is non-normative.

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

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

This section is non-normative.

The use of different extension points described in Section 4. Basic Concepts and Section 5. Advanced Concepts can serve as an unintentional or unwanted correlation mechanism if the number of issuers using a specific extension type or combination of types is relatively small. For example, the use of certain types of cryptography that are only used by particular nation states, or revocation formats used by specific jurisdictions, or credential types used by specific localities, can be used as a mechanism to reduce the pseudonymity that a holder might expect to have when performing a selective disclosure of information to a verifier.

Issuers are urged to reduce metadata-based correlation possibilities when issuing verifiable credentials that are expected to be used in a pseudonymous fashion by reducing the types of extensions that can be used to narrow the pseudonymity of the holder. Using credential types, extensions, and technology profiles that have global use is preferred over ones that have national use, which are preferred over ones that only have local use.

This section is non-normative.

There are mechanisms external to verifiable credentials 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 verifiable credentials cannot prevent the use of these other tracking technologies. Also, when these technologies are used in conjunction with verifiable credentials, 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.

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

The Oblivious HTTP protocol [OHTTP] is one mechanism that implementers might consider using when fetching external resources that are associated with a verifiable credential or a verifiable presentation. Oblivious HTTP allows a client to make multiple requests to an origin server without that server being able to link those requests to that client or even to identify those requests as having come from a single client, while placing only limited trust in the nodes used to forward the messages. Hence, Oblivious HTTP is one privacy-preserving mechanism that can be used to reduce the possibility of device tracking and fingerprinting. Concrete examples for how Oblivious HTTP can benefit ecosystem participants are included below.

• A holder using a digital wallet can reduce the chances that they will be tracked by a 3rd party when accessing external links within a verifiable credential stored in their digital wallet. For example, a digital wallet might fetch and render linked images, or check the validity of a verifiable credential by fetching an externally linked revocation list.
• A verifier can reduce signalling to an issuer that the verifier has received a specific verifiable credential. For example, a verifier might fetch an externally linked revocation list while performing status checks on a verifiable credential.

This section is non-normative.

To enable recipients of verifiable credentials to use them in a variety of circumstances without revealing more PII than necessary for transactions, issuers should consider limiting the information published in a credential to a minimal set needed for the expected purposes. One way to avoid placing PII in a credential is to use an abstract property that meets the needs of verifiers without providing specific information about a subject.

For example, this document uses the ageOver property 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 issuer trusted in that market might choose to offer a verifiable credential claiming that subjects have met that requirement instead of offering verifiable credentials containing claims about specific birthdates. This enables individual customers to make purchases without revealing specific PII.

This section is non-normative.

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.

With verifiable credentials, data minimization for issuers means limiting the content of a verifiable credential to the minimum required by potential verifiers for expected use. For verifiers, data minimization means limiting the scope of the information requested or required for accessing services.

For example, a driver's license containing a driver's ID number, height, weight, birthday, and home address is a credential containing more information than is necessary to establish that the person is above a certain age.

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

Verifiers 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:

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

This section is non-normative.

A bearer credential is a privacy-enhancing piece of information, such as a concert ticket, which entitles the holder of the bearer credential to a specific resource without divulging sensitive information about the holder. 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.

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

{
  "@context": [
    "carview.php?tsp=https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "https://university.example/credentials/temporary/28934792387492384",
  "type": ["VerifiableCredential", "ExampleDegreeCredential"],
  "issuer": "https://university.example/issuers/14",
  "validFrom": "2017-10-22T12:23:48Z",
  "credentialSubject": {
    // note that the 'id' property is not specified for bearer credentials
    "degree": {
      "type": "ExampleBachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  }
}

{
  "@context": [
    "carview.php?tsp=https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "https://university.example/credentials/temporary/28934792387492384"
,
  "type": [
    "VerifiableCredential",
    "ExampleDegreeCredential"
  ],
  "issuer": "https://university.example/issuers/14",
  "validFrom": "2017-10-22T12:23:48Z",
  "credentialSubject": {
    "degree": {
      "type": "ExampleBachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2024-01-26T14:43:46Z",
    "verificationMethod": "https://university.example/issuers/14#keys-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z27hFmModgTMh6r4qBc8pPM2snypGYA6qiJrCvRzqXoQEnj9HGBSiGm6
T9NXVd3z7iT68wBiKGyAT3rNGX83N4Rbn"
  }
}

---------------- JWT header ---------------
{
  "alg": "ES256",
  "typ": "JWT"
}
--------------- JWT payload ---------------
// NOTE: The example below uses a valid VC-JWT serialization
//       that duplicates the iss, nbf, jti, and sub fields in the
//       Verifiable Credential (vc) field.
{
  "vc": {
    "@context": [
      "carview.php?tsp=https://www.w3.org/ns/credentials/v2",
      "https://www.w3.org/ns/credentials/examples/v2"
    ],
    "id": "https://university.example/credentials/temporary/2893479238749238
4",
    "type": [
      "VerifiableCredential",
      "ExampleDegreeCredential"
    ],
    "issuer": "https://university.example/issuers/14",
    "validFrom": "2017-10-22T12:23:48Z",
    "credentialSubject": {
      "degree": {
        "type": "ExampleBachelorDegree",
        "name": "Bachelor of Science and Arts"
      }
    }
  },
  "iss": "https://university.example/issuers/14",
  "jti": "https://university.example/credentials/temporary/28934792387492384
"
}
--------------- JWT ---------------
eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJ2YyI6eyJAY29udGV4dCI6WyJodHRwczovL3
d3dy53My5vcmcvbnMvY3JlZGVudGlhbHMvdjIiLCJodHRwczovL3d3dy53My5vcmcvbnMvY3JlZ
GVudGlhbHMvZXhhbXBsZXMvdjIiXSwiaWQiOiJodHRwOi8vdW5pdmVyc2l0eS5leGFtcGxlL2Ny
ZWRlbnRpYWxzL3RlbXBvcmFyeS8yODkzNDc5MjM4NzQ5MjM4NCIsInR5cGUiOlsiVmVyaWZpYWJ
sZUNyZWRlbnRpYWwiLCJFeGFtcGxlRGVncmVlQ3JlZGVudGlhbCJdLCJpc3N1ZXIiOiJodHRwcz
ovL3VuaXZlcnNpdHkuZXhhbXBsZS9pc3N1ZXJzLzE0IiwidmFsaWRGcm9tIjoiMjAxNy0xMC0yM
lQxMjoyMzo0OFoiLCJjcmVkZW50aWFsU3ViamVjdCI6eyJkZWdyZWUiOnsidHlwZSI6IkV4YW1w
bGVCYWNoZWxvckRlZ3JlZSIsIm5hbWUiOiJCYWNoZWxvciBvZiBTY2llbmNlIGFuZCBBcnRzIn1
9fSwiaXNzIjoiaHR0cHM6Ly91bml2ZXJzaXR5LmV4YW1wbGUvaXNzdWVycy8xNCIsImp0aSI6Im
h0dHA6Ly91bml2ZXJzaXR5LmV4YW1wbGUvY3JlZGVudGlhbHMvdGVtcG9yYXJ5LzI4OTM0NzkyM
zg3NDkyMzg0In0.DoDbi2mWd2MP4yB3o0mwrXKnOoDbWQmqd65LktaqiniCkWpIsoVeNWin2gK-
ufYbBOvDEWC247_-O0MHo7PCbw

While bearer credentials can be privacy-enhancing, they must be carefully crafted so as not accidentally divulge more information than the holder of the bearer credential expects. For example, repeated use of the same bearer credential across multiple sites enables these sites to potentially collude to unduly track or correlate the holder. 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 bearer credential or session.

Issuers of bearer credentials should ensure that the bearer credentials provide privacy-enhancing benefits that:

• Are single-use, where possible.
• Do not contain personally identifying information.
• Are not unduly correlatable.

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

Verifiers should not request bearer credentials that can be used to unduly correlate the holder.

This section is non-normative.

When processing verifiable credentials, verifiers evaluate any relevant claims before relying upon them. This evaluation might be done in any manner desired, as long as it satisfies the requirements of the verifier doing the validation. Many verifiers will perform the checks listed in Appendix A. Validation as well as a variety of specific business process checks such as:

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

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

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

This section is non-normative.

When a holder receives a verifiable credential from an issuer, the verifiable credential needs to be stored somewhere (for example, in a credential repository). Holders are warned that the information in a verifiable credential is sensitive in nature and highly individualized, making it a high value target for data mining. Services that advertise free storage of verifiable credentials might in fact be mining personal data and selling it to organizations wanting to build individualized profiles on people and organizations.

Holders need to be aware of the terms of service for their credential repository, specifically the correlation and data mining protections in place for those who store their verifiable credentials with the service provider.

Some effective mitigations for data mining and profiling include using:

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

This section is non-normative.

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

For example, if two bearer credentials, one for an email address and then one stating the holder is over the age of 21, are provided across multiple sessions, the verifier 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 holder such that more and more information is leaked over time. Aggregation of credentials can also be performed across multiple sites in collusion with each other, leading to privacy violations.

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.

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

This section is non-normative.

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

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

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

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

It is understood that these mitigation techniques are not always practical or even compatible with necessary usage. Sometimes correlation is a requirement.

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.

Verifiable credentials 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.

Privacy risks of credential usage occur when unintended or unexpected correlation arises from the presentation of credentials.

This section is non-normative.

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

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

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 verifier to check if the balance is above a certain amount. In this case, the bank could issue a verifiable credential containing a balance checking token to a holder. The holder would then include the verifiable credential in a verifiable presentation and bind the token to a credit checking agency using a digital signature. The verifier could then wrap the verifiable presentation in their digital signature, and hand it back to the issuer to dynamically check the account balance.

Using this approach, even if a holder 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.

This section is non-normative.

The data expressed in verifiable credentials and verifiable presentations are valuable since they contain authentic statements made by trusted third parties, such as issuers, or individuals, such as holders and subjects. Storing this data can create honeypots of sensitive data that attackers are motivated to break into in order to acquire and exchange that data for financial gain.

Issuers are advised to retain the minimum amount of data necessary to issue verifiable credentials to holders and manage the status and revocation of those credentials.

Holders are advised to use implementations that appropriately encrypt their data both in transit and at rest, and protect sensitive material (such as cryptographic secrets) in ways that cannot be easily extracted from hardware devices. Furthermore, it is suggested that holders store and manipulate their data only on devices that they control, away from centralized systems, to reduce the likelihood of attack on their data, or large-scale theft if an attack is successful.

Verifiers are advised to only ask for data necessary for a particular transaction and to not retain any data beyond the needs of any particular transaction.

Regulators are advised to rethink audit requirements such that more privacy-preserving mechanisms can be used to achieve similar levels of enforcement and audit capabilities. For example, audit-focused regulations that insist on collection and long-term retention of personally identifiable information can cause harm to individuals and organizations if that same information is compromised and accessed by an attacker. The technologies described by this specification enable holders to more-readily prove attributes about themselves and others, reducing the need for long-term data retention by verifiers. Alternatives include keeping logs that the information was collected and checked, as well as random tests to ensure that compliance regimes are operating as expected.

This section is non-normative.

As detailed in Section 8.15 Usage Patterns, usage patterns can be correlated into certain types of behavior. Part of this correlation is mitigated when a holder uses a verifiable credential without the knowledge of the issuer. Issuers can defeat this protection however, by making their verifiable credentials short lived and renewal automatic.

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

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

This section is non-normative.

An ideal privacy-respecting system would require only the information necessary for interaction with the verifier to be disclosed by the holder. The verifier 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 verifiable credentials ecosystem, however, should strive to be as privacy-respecting as possible by preferring single-use verifiable credentials whenever possible.

Using single-use verifiable credentials provides several benefits. The first benefit is to verifiers who can be sure that the data in a verifiable credential is fresh. The second benefit is to holders, who know that if there are no long-lived identifiers in the verifiable credential, the verifiable credential 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.

This section is non-normative.

In an ideal private browsing scenario, no PII will be revealed. Because many credentials include PII, organizations providing software to holders should warn them about the possibility of revealing this information if they wish to use credentials and presentations 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.

This section is non-normative.

It cannot be overstated that verifiable credentials rely on a high degree of trust in issuers. The degree to which a holder might take advantage of possible privacy protections often depends strongly on the support an issuer 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 issuer to actively support such capabilities and incorporate them into the verifiable credentials they issue.

It should also be noted that, in addition to a reliance on issuer participation to provide verifiable credential capabilities that help preserve holder and subject privacy, holders rely on issuers to not deliberately subvert privacy protections. For example, an issuer might sign verifiable credentials using a signature scheme that protects against signature-based correlation. This would protect the holder from being correlated by the signature value as it is shared among verifiers. However, if the issuer creates a unique key for each issued credential, it might be possible for the issuer to track presentations of the credential, regardless of a verifier's inability to do so.

In addition to previously described privacy protections an issuer might use, issuers need to also be aware of data they leak associated with identifiers and claim types they use when issuing credentials. One example of this would be an issuer issuing drivers licenses which reveal both the location(s) in which they have jurisdiction and the location of the subject's residence. Verifiers might take advantage of this by requesting a credential to check that the subject is licensed to drive, when in fact they are interested in metadata about the credential, such as which issuer issued the credential, and tangential information that might have been leaked by the issuer, such as the subject's home address. To mitigate such leakage, issuers might choose to use common identifiers to mask specific location information or other sensitive metadata; for example, a shared issuer identifier at a state or nation level, instead of at the level of a county, city, town, or other smaller municipality. Further, holder attestation mechanisms can be used by verifiers to preserve privacy, by providing proofs that an issuer exists in a set of trusted entities, without needing to disclose the exact issuer.

This section is non-normative.

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 credentials and presentations. Implementing and auditing cryptography systems generally requires substantial experience. Effective red teaming can also help remove bias from security reviews.

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 credentials. Regular monitoring is important to ensure the long term viability of systems processing credentials.

This section is non-normative.

The security of most digital signature algorithms, which are used to secure verifiable credentials and verifiable presentations, is dependent on the quality and protection of their private signing keys. Guidance in the management of cryptographic keys is a large subject and the reader is referred to [NIST-SP-800-57-Part-1] for more extensive recommendations and discussion. As strongly recommended in both [FIPS-186-5] and [NIST-SP-800-57-Part-1], a private signing key is not to be used for multiple purposes, e.g., a private signing key is not to be used for encryption as well as signing.

[NIST-SP-800-57-Part-1] strongly advises that private signing keys and public verification keys have limited cryptoperiods, where a cryptoperiod is "the time span during which a specific key is authorized for use by legitimate entities or the keys for a given system will remain in effect." [NIST-SP-800-57-Part-1] gives extensive guidance on cryptoperiods for different key types under different situations, and generally recommends a 1-3 year cryptoperiod for a private signing key.

To deal with potential private key compromises, [NIST-SP-800-57-Part-1] provides recommendations for protective measures, harm reduction, and revocation. Although this section focuses primarily on the security of the private signing key, [NIST-SP-800-57-Part-1] also highly recommends confirmation of the validity of all public keys before using them.

This section is non-normative.

Verifiable credentials often contain URLs to data that resides outside of the verifiable credential itself. Linked content that exists outside a verifiable credential, such as images, JSON-LD Contexts, JSON Schemas, and other machine-readable data, are often not protected against tampering because the data resides outside of the protection of the securing mechanism on the verifiable credential. For example, the content retrievable by dereferencing the following highlighted links is not integrity protected, but probably ought to be:

{
  "@context": [
    "carview.php?tsp=https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "https://university.example/credentials/58473",
  "type": ["VerifiableCredential", "ExampleAlumniCredential"],
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "image": "https://university.example/images/58473",
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": "Example University"
    }
  }
}

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.

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2?hl=z3aq31uzgnZBuWNzUB",
    "https://www.w3.org/ns/credentials/examples/v2?hl=z8guWNzUBnZBu3aq31"
  ],
  "id": "https://university.example/credentials/58473",
  "type": ["VerifiableCredential", "ExampleAlumniCredential"],
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "image": "https://example.com/image",
    "alumniOf": {
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": "Example University"
    }
  }
}

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.

This section is non-normative.

This specification allows credentials to be produced that are not secured by signatures or proofs of any kind. These types of credentials 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 credentials are not verifiable because the authorship either is not known or cannot be trusted.

This section is non-normative.

The data model does not inherently prevent Man-in-the-Middle (MITM), replay, and spoofing attacks. Both online and offline use cases might be susceptible to these types of attacks, where an adversary intercepts, modifies, re-uses, and/or replicates the verifiable credential data during transmission or storage.

This section is non-normative.

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

For example, a university might issue two verifiable credentials to a person, each containing two properties, which must be taken together 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 verifiable credentials are atomized to put only one of these properties into each credential , then the university would issue four credentials to the person, each containing one of the following designations: "Staff Member", "Post Graduate Student", "Department of Computing", and "Department of Economics". The holder might then transfer the "Staff Member" and "Department of Economics" verifiable credentials to a verifier, which together would comprise a false claim.

This section is non-normative.

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

This section is non-normative.

When verifiable credentials 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 verifiable credentials. Ways to mitigate this type of attack include:

• Enabling password, pin, pattern, or biometric screen unlock protection on the device.
• Enabling password, biometric, or multi-factor authentication for the credential repository.
• Enabling password, biometric, or multi-factor authentication when accessing cryptographic keys.
• Using a separate hardware-based signature device.
• All or any combination of the above.

Furthermore, instances of impersonation can manifest in various forms, including situations where an entity attempts to disavow their actions. Elevating the level of trust and security within the realm of verifiable credentials entails more than just averting impersonation; it involves the implementation of non-repudiation mechanisms. These mechanisms solidify an entity's responsibility for their actions or transactions, thereby reinforcing accountability and deterring malicious behaviors. The attainment of non-repudiation is a multifaceted endeavor, encompassing an array of techniques ranging from securing mechanisms, proofs of possession, and authentication schemes in a variety of protocols designed to foster trust and reliability.

This section is non-normative.

Ensuring that there is alignment between an entity's actions, such as presentation, and the intended purpose of those actions, is of importance. It involves having the authorization to make use of verifiable credentials as well as using credentials in a manner that adheres to their designated scope(s) and objective(s). Two critical aspects that arise within this context are Unauthorized Use and Inappropriate Use.

This section is non-normative.

Many physical credentials 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.

When utilizing this data model to create verifiable credentials, it is suggested that data model designers use a data first approach. For example, given the choice of using data or a graphical image to depict a credential, designers should express every element of the image, such as the name of an institution or the professional credential, 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.

This section is non-normative.

When a single natural language string contains multiple languages or annotations, the contents of the string might require additional structure or markup in order to be presented correctly. It is possible to use markup languages, such as HTML, to label spans of text in different languages or to supply string-internal markup needed for proper display of bidirectional text. It is also possible to use the rdf:HTML datatype to encode such values accurately in JSON-LD.

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

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

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.