What is a Verifiable Credential?

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=] (for example, a Dutch passport, an American driving license, or a health insurance card)
• Information related to specific properties asserted by the issuing authority about the [=subject=] (for example, nationality, date of birth, or the classes of vehicle they're qualified to drive)
• Evidence by which a [=subject=] was demonstrated to have satisfied the qualifications required for issuance of the [=credential=] (for example, a measurement, proof of citizenship, or test result)
• Information related to constraints on the credential (for example, validity period, or terms of use).

A [=verifiable credential=] can represent all the same information that a physical [=credential=] represents. Adding technologies such as digital signatures can make [=verifiable credentials=] more tamper-evident and 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 specific characteristics.

Both [=verifiable credentials=] and [=verifiable presentations=] can be transmitted rapidly, making them more convenient than their physical counterparts when establishing trust at a distance.

While this specification attempts to improve the ease of expressing digital [=credentials=], it also aims to balance this goal with several 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 several of these issues in Section [[[#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. Instead, upon establishing the authenticity and currency of a [=verifiable credential=] or [=verifiable presentation=], 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.

Ecosystem Overview

This section describes the roles of the core actors and the relationships between them in an ecosystem where one expects [=verifiable credentials=] 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. This specification introduces the following roles:

[=holder=]

A role an [=entity=] might perform by possessing one or more [=verifiable credentials=] and generating [=verifiable presentations=] from them. A holder is often, but not always, a [=subject=] of the [=verifiable credentials=] they are holding. Holders store their [=credentials=] in [=credential repositories=]. Example holders include students, employees, and customers.

[=issuer=]

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

[=subject=]

A thing about which [=claims=] are made. Example subjects include human beings, animals, and things.

[=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, [=verification material=], and other relevant data, such as [=verifiable credential=] schemas, revocation registries, and so on, which might require using [=verifiable credentials=]. Some configurations might require correlatable identifiers for [=subjects=]. Some registries, such as ones for UUIDs and [=verification material=], might just act as namespaces for identifiers. Examples of verifiable data registries include trusted databases, decentralized databases, government ID databases, and distributed ledgers. Often, more than one type of verifiable data registry used in an ecosystem.

[[[#roles]]] above provides an example ecosystem to ground the rest of the concepts in this specification. Other ecosystems exist, such as protected environments or proprietary systems, where [=verifiable credentials=] also provide benefits.

This ecosystem contrasts with the typical two-party or federated identity provider models. An identity provider, sometimes abbreviated as IdP, is a system for creating, maintaining, and managing identity information for [=holders=] while providing authentication services to [=relying party=] applications within a federation or distributed network. In a federated identity model, the [=holder=] is tightly bound to the identity provider. This specification avoids using "identity provider," "federated identity," or "relying party" terminology, except when comparing or mapping these concepts to other specifications. This specification decouples the identity provider concept into two distinct concepts: the [=issuer=] and the [=holder=].

In many cases, the [=holder=] of a [=verifiable credential=] is the subject, but in some instances 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 exceptional cases, see the Subject-Holder Relationships section in the [[[VC-IMP-GUIDE]]].

For a deeper exploration of the [=verifiable credentials=] ecosystem and a concrete lifecycle example, please refer to [[[VC-USE-CASES]]] [[?VC-USE-CASES]].

Claims

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 [[[#basic-structure]]] 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 [[[#basic-example]]] below.

Individual [=claims=] can be merged together to express a [=graph=] of information about a [=subject=]. The example shown in [[[#multiple-claims]]] 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. More information is expected to be added to the graph in order to be able to trust [=claims=], more information is expected to be added to the graph.

Credentials

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, [=verification material=], status information, and so on. A [=verifiable credential=] is a set of tamper-evident [=claims=] and metadata that cryptographically prove who issued it. Examples of [=verifiable credentials=] include, but are not limited to, digital employee identification cards, digital driver's licenses, and digital educational certificates.

[[[#basic-vc]]] 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=].

[[[#info-graph-vc]]] 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=] (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. Readers who are interested in the need for multiple information graphs can refer to Section [[[#verifiable-credential-graphs]]].

[[[#info-graph-vc-jwt]]] below shows the same [=verifiable credential=] as [[[#info-graph-vc]]], but secured using JOSE [[?VC-JOSE-COSE]]. The payload contains a single information graph, which is the [=verifiable credential graph=] containing [=credential=] metadata and other [=claims=].

Presentations

Enhancing privacy is a key design feature of this specification. Therefore, it is crucial for [=entities=] using this technology to express only the portions of their personas that are appropriate for given situations. The expression of a subset of one's persona is called a [=verifiable presentation=]. Examples of different personas include a person's professional persona, online gaming persona, family persona, or incognito persona.

A [=verifiable presentation=] is created by a [=holder=], can express data from multiple [=verifiable credentials=], and can contain arbitrary additional data. They are used 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 expresses an aspect of a person, organization, or [=entity=].

[[[#basic-vp]]] 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=].

[[[#info-graph-vp]]] 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=] (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=], 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=].

[[[#info-graph-vp-jwt]]] below shows the same [=verifiable presentation=] as [[[#info-graph-vp]]], 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=] 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 in [[[#info-graph-vc-jwt]]].

It is possible to have a [=presentation=], such as a collection of university credentials, which draws on multiple [=credentials=] about different [=subjects=] that are often, but not required to be, related. This is achieved by using the `verifiableCredential` property to refer to multiple [=verifiable credentials=]. See Appendix [[[#additional-diagrams-for-verifiable-presentations]]] for more details.

As described in Section [[[#ecosystem-overview]]], an [=entity=] can take on one or more roles as they enter a particular credential exchange. While a [=holder=] is typically expected to generate [=presentations=], an [=issuer=] or [=verifier=] might generate a presentation to identify itself to a [=holder=]. This might occur if the [=holder=] needs higher assurance from the [=issuer=] or [=verifier=] before handing over sensitive information as part of a [=verifiable presentation=].

Spectrum of Privacy

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 the information they are willing to provide and the information that can be derived from it.

Privacy solutions are use case specific. For example, many people would prefer to remain anonymous when purchasing alcohol because the regulation is only to verify whether a purchaser is above a specific age. In contrast, when filling prescriptions written by a medical professional for a patient, the pharmacy is legally required to more strongly identify both the prescriber and the patient. No single approach to privacy works for all use cases.

Even those who want to remain anonymous when purchasing alcohol might need to provide photo identification to appropriately assure the merchant. The merchant might not need to know your name or any details other than that you are over a specific age, but in many cases, simple proof of age might be insufficient to meet regulations.

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 will guide implementers who want to avoid specific scenarios that are hostile to privacy.

Software Trust Boundaries

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 issue [=verifiable credentials=] only 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=] consents to releasing that information.

The examples above are not exhaustive, and the users in these roles can also expect various other things from the software they use to achieve their goals. In short, the user expects the software to operate in the user's best interests; any violations of this expectation breach trust and can lead to the software's replacement with a more trustworthy alternative. Implementers are strongly encouraged to create software that preserves user trust. Additionally, they are encouraged to include auditing features that enable users or trusted third parties to verify that the software is operating in alignment with their best interests.

Readers are advised that some software, like a website providing services to a single [=verifier=] and multiple [=holders=], might operate as a user agent to both roles but might not always be able to operate simultaneously in the best interests of all parties. For example, suppose a website detects an attempt at fraudulent [=verifiable credential=] use among multiple [=holders=]. In that case, it might report such an anomaly to the [=verifier=], which might be considered not to be in all [=holders'=] best interest, but would be in the best interest of the [=verifier=] and any [=holders=] not committing such a violation. It is imperative that when software operates in this manner, it is made clear in whose best interest(s) the software is operating, through mechanisms such as a website use policy.

Personally Identifiable Information

Data associated with [=verifiable credentials=] stored in the `credential.credentialSubject` property is susceptible to privacy violations when shared with [=verifiers=]. Personally identifying data, such as a government-issued identifier, shipping address, or 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 powerful correlation and de-anonymization capabilities.

Implementers of software used by [=holders=] 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, by issuing `ageOver` [=verifiable credentials=] instead of `dateOfBirth` [=verifiable credentials=] for use when a [=verifier=] wants to determine whether an [=entity=] is at least 18 years of age.

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 ought not have access to 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 access control mechanisms to protect the data in a [=verifiable credential=] when at rest.

Generally, individuals are advised to assume that a [=verifiable credential=], like most physical credentials, will leak personally identifiable information when shared. To combat such leakage, [=verifiable credentials=] and their securing mechanisms need to be carefully designed to prevent correlation. [=Verifiable credentials=] specifically designed to protect against leakage of personally identifiable information are available. Individuals and implementers are encouraged to choose these credential types over those not designed to protect personally identifiable information.

Identifier-Based Correlation

[=Verifiable credentials=] might contain long-lived identifiers that could be used to correlate individuals. These identifiers include [=subject=] identifiers, email addresses, government-issued identifiers, organization-issued identifiers, addresses, healthcare vitals, and many other long-lived identifiers. Implementers of software for [=holders=] are encouraged to detect identifiers in [=verifiable credentials=] that could be used to correlate individuals and to warn [=holders=] before they share this information. The rest of this section elaborates on guidance related to using long-lived identifiers.

[=Subjects=] of [=verifiable credentials=] are identified using the `id` property, as defined in Section [[[#identifiers]]] and used in places such as the `credentialSubject.id` property. The identifiers used to identify a [=subject=] create a greater correlation risk when the identifiers are long-lived or used across more than one web domain. Other types of identifiers that fall into this category are email addresses, government-issued identifiers, and organization-issued identifiers.

Similarly, disclosing the [=credential=] identifier (as in [[[#example-use-of-the-id-property]]]) can lead to situations where multiple [=verifiers=], or an [=issuer=] and a [=verifier=], can collude to correlate the [=holder=].

[=Holders=] aiming to reduce correlation are encouraged to use [=verifiable credentials=] from [=issuers=] that support selectively disclosing correlating identifiers in a [=verifiable presentation=]. Such approaches expect the [=holder=] to generate the identifier and might even allow hiding the identifier from the [=issuer=] through techniques like blind signatures, while still keeping the identifier embedded and signed in the [=verifiable credential=].

[=Securing mechanism=] specification authors are advised to avoid enabling identifier-based correlation by designing their technologies to avoid the use of correlating identifiers that cannot be selectively disclosed.

If strong anti-correlation properties are required in a [=verifiable credentials=] system, it is essential that identifiers meet one or more of the following criteria:

• Selectively disclosable
• Bound to a single origin
• Single-use
• Not used and instead replaced by short-lived, single-use bearer tokens.

Signature-Based Correlation

The contents of a [=verifiable credential=] are secured using a [=securing mechanism=]. Values representing the securing mechanism pose a greater risk of correlation when they remain the same across multiple sessions or domains. Examples of these include the following values:

• the binary value of the digital signature
• timestamp information associated with the creation of the digital signature
• cryptographic material associated with the digital signature, such as a public key identifier

When strong anti-correlation properties are required, [=issuers=] are encouraged to produce [=verifiable credentials=] where signature values and metadata can be regenerated for each [=verifiable presentation=]. This can be achieved using technologies that support unlinkable disclosure, such as the [[[?VC-DI-BBS]]] specification. When possible, [=verifiers=] are encouraged to prefer [=verifiable presentations=] that use this technology in order to enhance privacy for [=holders=] and [=subjects=].

Even with unlinkable signatures, a [=verifiable credential=] might contain other information that undermines the anti-correlation properties of the cryptography used. See Sections [[[#personally-identifiable-information]]], [[[#identifier-based-correlation]]], [[[#metadata-based-correlation]]], [[[#correlation-during-validation]]], and most other subsections of Section [[[#privacy-considerations]]].

Metadata-based Correlation

Different extension points, such as those described in Section [[[#basic-concepts]]] and Section [[[#advanced-concepts]]], can unintentionally or undesirably serve as a correlation mechanism, if relatively few [=issuers=] use a specific extension type or combination of types. For example, using certain cryptographic methods unique to particular nation-states, revocation formats specific to certain jurisdictions, or credential types employed by specific localities, can serve as mechanisms that reduce the pseudonymity a [=holder=] might expect when selectively disclosing information to a [=verifier=].

[=Issuers=] are encouraged to minimize metadata-based correlation risks when issuing [=verifiable credentials=] intended for pseudonymous use by limiting the types of extensions that could reduce the [=holder's=] pseudonymity. Credential types, extensions, and technology profiles with global adoption are most preferable, followed by those with national use; those with only local use are least preferable.

Device Tracking and Fingerprinting

There are mechanisms external to [=verifiable credentials=] that track and correlate individuals on the Internet and the Web. 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; rather, using these technologies alongside [=verifiable credentials=] can reveal new correlatable information. For instance, a birthdate combined with a GPS position can strongly correlate an individual across multiple websites.

Privacy-respecting systems ought to aim to prevent the combination of other tracking technologies with [=verifiable credentials=]. In some instances, tracking technologies might need to be disabled on devices that transmit [=verifiable credentials=] on behalf of a [=holder=].

The Oblivious HTTP protocol [[?RFC9458]] is one mechanism implementers might consider using when fetching external resources 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. Oblivious HTTP is one privacy-preserving mechanism that can reduce the possibility of device tracking and fingerprinting. Below are some concrete examples of ways that Oblivious HTTP can benefit ecosystem participants.

• 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 it might check the validity of a [=verifiable credential=] by fetching an externally linked revocation list.
• A [=verifier=] can reduce its likelihood of signaling 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=].

Favor Abstract Claims

[=Issuers=] are encouraged to limit the information included in a [=verifiable credential=] to the smallest set required for the intended purposes, so as to allow recipients to use them in various situations without disclosing more personally identifiable information (PII) than necessary. One way to avoid placing PII in a [=verifiable credential=] is to use an abstract [=property=] that meets the needs of [=verifiers=] without providing overly specific information about a [=subject=].

For example, this document uses the `ageOver` [=property=] instead of a specific birthdate, which would represent more sensitive PII. If retailers in a particular market commonly require purchasers to be older than a certain age, an [=issuer=] trusted in that market might choose to offer [=verifiable credentials=] that claim that [=subjects=] have met that requirement rather than offering [=verifiable credentials=] that contain [=claims=] about the customers' birthdays. This practice enables individual customers to make purchases without disclosing more PII than necessary.

The Principle of Data Minimization

Privacy violations occur when information divulged in one context leaks into another. One accepted best practice for preventing such a violation is for [=verifiers=] to limit the information requested and received, to the absolute minimum necessary for a particular transaction. Regulations 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, mandate this data minimization approach.

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 restricting the scope of 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 expressed as a [=verifiable credential=] contains 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 securing mechanism that allows for [=selective disclosure=]. For example, an [=issuer=] of driver's licenses could issue a [=verifiable credential=] containing every property that appears on a driver's license, and allow the [=holder=] to disclose each property selectively. It could also issue more abstract [=verifiable credentials=] (for example, a [=verifiable credential=] containing only an `ageOver` property). One possible adaptation would be for [=issuers=] to provide secure HTTP endpoints for retrieving single-use [=bearer credentials=] that promote the pseudonymous use of [=verifiable credentials=]. Implementers that find this impractical or unsafe might consider using [=selective disclosure=] schemes that eliminate dependence on [=issuers=] at proving time and reduce the risk of temporal correlation by [=issuers=].

[=Verifiers=] are urged to only request information that is strictly 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 handle.
• It enhances the [=subject's=] and/or [=holder's=] privacy by only asking for information that is necessary for a specific transaction.

Implementers of software used by [=holders=] are encouraged to disclose the information being requested by a [=verifier=], allowing the [=holder=] to decline to share specific information that is unnecessary for the transaction. Implementers of software used by [=holders=] are also advised to give [=holders=] access to logs of information shared with [=verifiers=], enabling the [=holders=] to provide this information to authorities if they believe that they have been subjected to information overreach or coerced to share more information than necessary for a particular transaction.

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.

Bearer Credentials

A bearer credential is a privacy-enhancing piece of information, such as a concert ticket, that entitles its [=holder=] to a specific resource without requiring the [=holder=] to divulge sensitive information. In low-risk scenarios, entities often use bearer credentials where multiple [=holders=] presenting the same [=verifiable 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": [
    "https://www.w3.org/ns/credentials/v2",
    "https://www.w3.org/ns/credentials/examples/v2"
  ],
  "id": "http://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"
    }
  }
}
        

While [=bearer credentials=] are privacy-enhancing, [=issuers=] still need to take care in their design to avoid unintentionally divulging more information than the [=holder=] of the [=bearer credential=] expects. For example, repeated use of the same [=bearer credential=] across multiple sites can enable these sites to collude in illicitly tracking or correlating the [=holder=]. Similarly, information that might seem non-identifying, such as a birthdate and postal code, can be used together to statistically identify an individual when used 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=] ought to be warned by their software if it detects that [=bearer credentials=] containing sensitive information have been issued or requested, or that a correlation risk is posed by the combination of two or more [=bearer credentials=] across one or more sessions. While detecting all correlation risks might be impossible, some might certainly be detectable.

[=Verifiers=] ought not request [=bearer credentials=] known to carry information which can be used to illicitly correlate the [=holder=].

Correlation During Validation

When processing [=verifiable credentials=], [=verifiers=] evaluate 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 [[[#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, which could lead to privacy violations. Organizations providing software to [=holders=] ought to warn when [=credentials=] include information that could lead to privacy violations during the verification process. [=Verifiers=] are urged to consider rejecting [=credentials=] that produce privacy violations or that enable substandard privacy practices.

Storage Providers and Data Mining

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=] need to be aware that the information in a [=verifiable credential=] can be sensitive and highly individualized, making it a prime target for data mining. Services offering "free of charge" storage of [=verifiable credentials=] might mine personal data and sell it to organizations interesting in building 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.

In addition to the mitigations above, civil society and regulatory participation in vendor analysis and auditing can help ensure that legal protections are enacted and enforced for individuals affected by practices that are not aligned with their best interests.

Aggregation of Credentials

Having two pieces of information about the same [=subject=] often reveals more about the [=subject=] than the combination of those two pieces, even when the pieces are delivered through different channels. Aggregating [=verifiable credentials=] poses a privacy risk, and all participants in the ecosystem need to be aware of the risks of data aggregation.

For example, suppose two [=bearer credentials=], one for an email address and one stating the [=holder=] is over 21, are provided to the same [=verifier=] across multiple sessions. The [=verifier=] of the information now has a unique identifier (the email address) along with age-related ("over 21") information for that individual. It is now easy to create a profile for the [=holder=], building it by adding more and more information as it leaks over time. Aggregation of such [=credentials=] can also be performed by multiple sites in collusion with each other, leading to privacy violations.

From a technological perspective, preventing information aggregation is a challenging privacy problem. While new cryptographic techniques, such as zero-knowledge proofs, are being proposed as solutions to aggregation and correlation issues, 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=] wishes to avoid the aggregation of their information, they need to express this in the [=verifiable presentations=] they transmit, and by the [=holders=] and [=verifiers=] to whom they transmit their [=verifiable presentations=].

Patterns of Use

Despite best efforts by all involved to assure privacy, using [=verifiable credentials=] can potentially lead to de-anonymization and a loss of privacy. This correlation can occur when any of the following occurs:

• 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 same person controls both accounts.
• 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 [=credentials=]' [=subjects=] are the same entity.
• 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 uses of the [=credential=] across interactions. For example, if a [=credential=] is used to prove age in this manner, the centralized service could know everywhere that [=credential=] was presented (all liquor stores, bars, adult stores, lottery sellers, and so on).

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

• The [=holder=] software providing a globally-unique identifier as the [=subject=] for any given [=verifiable credential=] and never reusing that [=verifiable credential=].
• The [=issuer=] using a globally-distributed service for revocation such that it is not contacted when revocation checks are performed.
• Specification authors designing revocation mechanisms that do not depend on submitting a unique identifier for a [=verifiable credential=] to a query API, and instead use, for example, a privacy-preserving revocation list.
• [=Issuers=] avoiding the association of personally identifiable information with any specific long-lived [=subject=] identifier.

Unfortunately, these mitigation techniques are only sometimes practical or even compatible with necessary use. Sometimes, correlation is a requirement.

For example, in some prescription drug monitoring programs, monitoring prescription use 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 prescription use 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, 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 violations related to the use of [=verifiable credentials=] occur when unintended or unexpected correlation arises from the presentation of those [=verifiable credentials=].

Legal Processes

Legal processes can compel [=issuers=], [=holders=], and [=verifiers=] to disclose private information to authorities, such as law enforcement. It is also possible for the same private information to be accidentally disclosed to an unauthorized party through a software bug or security failure. Authors of legal processes and compliance regimes are advised to draft guidelines that require notifying the [=subjects=] involved when their private information is intentionally or accidentally disclosed to a third party. Providers of software services are advised to be transparent about known circumstances that might cause such private information to be shared with a third party, as well as the identity of any such third party.

Sharing Information with the Wrong Party

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 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=] ought to strive to tokenize as much information as possible so 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 to check 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 check the account balance dynamically.

Using this approach, even if a [=holder=] shares the account balance token with the wrong party, an attacker cannot discover the bank account number or the exact value of the account. Also, given the validity period of the counter-signature, the attacker gains access to the token for only a few minutes.

Data Theft

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=] or [=subjects=]). The storage and accessibility of this data can inadvertently create honeypots of sensitive data for malicious actors. These adversaries often seek to exploit such reservoirs of sensitive information, aiming 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 to manage the status and revocation of those credentials. Similarly, [=issuers=] are advised to avoid creating publicly accessible credentials that include personally identifiable information (PII) or other sensitive data. Software implementers are advised to safeguard [=verifiable credentials=] using robust consent and access control measures, ensuring that they remain inaccessible to unauthorized entities.

[=Holders=] are advised to use implementations that appropriately encrypt their data in transit and at rest and protect sensitive material (such as cryptographic secrets) in ways that cannot be easily extracted from hardware or other devices. It is further suggested that [=holders=] store and manipulate their data only on devices they control, away from centralized systems, to reduce the likelihood of an attack on their data or inclusion in a large-scale theft if an attack is successful. Furthermore, [=holders=] are encouraged to rigorously control access to their credentials and presentations, allowing access only to those with explicit authorization.

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

Regulators are advised to reconsider existing audit requirements such that mechanisms that better preserve privacy can be used to achieve similar enforcement and audit capabilities. For example, audit-focused regulations that insist on the collection and long-term retention of personally identifiable information can cause harm to individuals and organizations if that same information is later compromised and accessed by an attacker. The technologies described by this specification enable [=holders=] to prove properties about themselves and others more readily, 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.

Frequency of Claim Issuance

As detailed in Section [[[#patterns-of-use]]], patterns of use can be correlated with certain types of behavior. This correlation is partially 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 helpful in 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 correlate the [=holder's=] behavior in a way that negatively impacts the [=holder=].

Organizations providing software to [=holders=] ought to warn them if they repeatedly use [=credentials=] with short lifespans, which could result in behavior correlation. [=Issuers=] ought to avoid issuing [=credentials=] that enable them to correlate patterns of use.

Prefer Single-Use Credentials

An ideal privacy-respecting system would require only the information necessary for interaction with the [=verifier=] to be disclosed by the [=holder=]. The [=verifier=] then records that the disclosure requirement has been met and discards any sensitive information disclosed. In many cases, competing priorities, such as regulatory burden, prevent this ideal system from being employed. In other instances, long-lived identifiers prevent single use. The designer of any [=verifiable credentials=] ecosystem ought to strive to make it 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.

Private Browsing

In an ideal private browsing scenario, no PII will be revealed. Because many [=credentials=] include PII, organizations providing software to [=holders=] ought to warn them about the possibility of this information being revealed if they 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, it is important that implementers not depend on private browsing mode to provide any privacy protections. Instead, implementers are advised to rely on tooling that directly usable by their software to provide privacy guarantees.

Issuer Cooperation Impacts on Privacy

[=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 active support by the [=issuer=], who need to incorporate those capabilities into the [=verifiable credentials=] they issue.

It is crucial to note that [=holders=] not only depend on [=issuer=] participation to provide [=verifiable credential=] capabilities that help preserve [=holder=] and [=subject=] privacy, but also rely on [=issuers=] to not deliberately subvert these 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 offer, [=issuers=] need to be aware of data they leak that is associated with identifiers and claim types they use when issuing [=credentials=]. One example of this would be an [=issuer=] issuing driver's 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 use common identifiers to mask specific location information or other sensitive metadata; for example, a shared [=issuer=] identifier at a state or national level instead of at the level of a county, city, town, or other smaller municipality. Further, [=verifiers=] can use [=holder=] attestation mechanisms to preserve privacy, by providing proof that an [=issuer=] exists in a set of trusted entities without needing to disclose the exact [=issuer=].

Cryptography Suites and Libraries

Cryptography can protect some aspects of the data model described in this specification. 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 succumb to new attacks and technological 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=].

Key Management

The security of most digital signature algorithms, used to secure [=verifiable credentials=] and [=verifiable presentations=], depends on the quality and protection of their private signing keys. The management of cryptographic keys encompasses a vast and complex field. For comprehensive recommendations and in-depth discussion, readers are directed to [[NIST-SP-800-57-Part-1]]. 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; for example, 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 various conditions and recommends a one to three 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 [=verification material=] before using it.

Content Integrity Protection

[=Verifiable credentials=] often contain URLs to data that resides outside the [=verifiable credential=]. Linked content that exists outside a [=verifiable credential=] — such as images, JSON-LD extension contexts, JSON Schemas, and other machine-readable data — is not protected against tampering because the data resides outside of the protection of the securing mechanism on the [=verifiable credential=].

Section [[[#integrity-of-related-resources]]] of this specification provides an optional mechanism for ensuring the integrity of the content of external resources. This mechanism is not necessary for external resources that do not impact the [=verifiable credential=]'s security. However, its implementation is crucial for external resources where content changes could potentially introduce security vulnerabilities.

Implementers need to recognize the potential security risks associated with unprotected URLs of external machine-readable content. Such vulnerabilities could lead to successful attacks on their applications. Where changes to external resources might compromise security, implementers will benefit by employing the content integrity protection mechanism outlined in this specification.

Unsigned Claims

This specification enables the creation of [=credentials=] without signatures or proofs. These [=credential=] classes are often useful for intermediate storage or self-asserted information, analogous to filling out a form on a web page. Implementers ought to be aware that these [=credential=] types are not [=verifiable=] because the authorship either is unknown or cannot be trusted.

Man-in-the-Middle (MITM), Replay, and Cloning Attacks

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 attacks, where an adversary intercepts, modifies, re-uses, and/or replicates the [=verifiable credential=] data during transmission or storage.

Man-in-the-Middle (MITM) Attack

A [=verifier=] might need to ensure it is the intended recipient of a [=verifiable presentation=] and not the target of a man-in-the-middle attack. Some securing mechanisms, like [[[VC-JOSE-COSE]]] [[VC-JOSE-COSE]] and [[[VC-DATA-INTEGRITY]]] [[VC-DATA-INTEGRITY]], provide an option to specify a [=presentation=]'s intended audience or domain, which can help reduce this risk.

Other approaches, such as token binding [[RFC8471]], which ties the request for a [=verifiable presentation=] to the response, can help secure the protocol. Any unsecured protocol is susceptible to man-in-the-middle attacks.

Replay Attack

A [=verifier=] might wish to limit the number of times that [=verifiable presentation=] can be used. For example, multiple individuals presenting the same [=verifiable credential=] representing an event ticket might be granted entry to the event, undermining the purpose of the ticket from the perspective of its [=issuer=]. To prevent such replay attacks, [=verifiers=] require [=holders=] to include additional security measures in their [=verifiable presentations=]. Examples include the following:

• A challenge provided by the [=verifier=], which the [=holder=] incorporates into a [=verifiable presentation=]. The [=verifier=] enforces challenge uniqueness to prevent replay attacks.
• A validity period, limiting the window during which the [=verifiable presentation=] is valid.

Spoofing Attack

[=Verifiers=] might have a vested interest in knowing that a [=holder=] is authorized to present the [=claims=] inside of a [=verifiable presentation=]. While the data model outlines the structure and data elements necessary for a [=verifiable credential=], it does not include a mechanism to ascertain the authorization of presented [=credentials=]. To address this concern, implementers might need to explore supplementary methods, such as binding [=verifiable credentials=] to strong authentication mechanisms or using additional properties in [=verifiable presentations=] to enable proof of control.

Bundling Dependent Claims

It is considered best practice for [=issuers=] to atomize information in a [=credential=] or use a signature scheme that allows for selective disclosure. When atomizing information, if it is not done securely by the [=issuers=], the [=holders=] might bundle together [=claims=] from different [=credentials=] in ways that the [=issuers=] did not intend.

Consider a university issuing two [=verifiable credentials=] to an individual. Each [=credential=] contains two properties that, when combined, indicate the person's "role" in a specific "department." For instance, one [=credential=] pair might designate "Staff Member" in the "Department of Computing," while another could signify "Post Graduate Student" in the "Department of Economics." Atomizing these [=verifiable credentials=] results in the university issuing four separate [=credentials=] to the individual. Each [=credential=] contains a single designation: "Staff Member", "Post Graduate Student", "Department of Computing", or "Department of Economics". The [=holder=] might then present the "Staff Member" and "Department of Economics" [=verifiable credentials=] to a [=verifier=], which, together, would comprise a false [=claim=].

Highly Dynamic Information

When [=verifiable credentials=] contain highly dynamic information, careful consideration of validity periods becomes crucial. Issuing [=verifiable credentials=] with validity periods that extend beyond their intended use creates potential security vulnerabilities that malicious actors could exploit. 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=] appropriate to the use case and the expected lifetime of the information contained in the [=verifiable credential=].

Device Theft and Impersonation

Storing [=verifiable credentials=] on a device poses risks if the device is lost or stolen. An attacker gaining possession of such a device potentially acquires unauthorized 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 its actions. Elevating trust and security within the realm of [=verifiable credentials=] entails more than averting impersonation; it also involves implementing non-repudiation mechanisms. These mechanisms solidify an [=entity's=] responsibility for its actions or transactions, reinforcing accountability and deterring malicious behavior. Attainment of non-repudiation is a multifaceted endeavor, encompassing an array of techniques including securing mechanisms, proofs of possession, and authentication schemes in various protocols designed to foster trust and reliability.

Acceptable Use

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

Unauthorized Use

Entities using [=verifiable credentials=] and [=verifiable presentations=] beyond their intended purpose are engaging in unauthorized activity. One class of unauthorized use is a confidentiality violation. Consider a [=holder=] that shares a [=verifiable presentation=] with a [=verifier=] to establish their age and residency status. If the [=verifier=] then proceeds to employ the [=holder's=] data without proper consent, such as by selling the data to a data broker, that would constitute an unauthorized use of the data, violating an expectation of privacy that the [=holder=] might have in the transaction.

Similarly, an [=issuer=] can employ a termsOfUse property to specify how and when a [=holder=] might be permitted and expected to use a [=credential=]. A [=holder=] using [=credentials=] outside of the scope(s) defined in the `termsOfUse` would be considered to be unauthorized.

Further study is required to determine how a [=holder=] can assert and enforce authorized use of their data after [=presentation=].

Inappropriate Use

While valid cryptographic signatures and successful status checks signify the reliability of [=credentials=], they do not signify that all [=credentials=] are interchangeable for all contexts. It is crucial that [=verifiers=] also validate any relevant [=claims=], considering the source and nature of the [=claim=] alongside the purpose for which the [=holder=] presents the [=credential=].

For instance, in scenarios where a certified medical diagnosis is required, a self-asserted [=credential=] carrying the necessary data might not suffice because it lacks validity from an authoritative medical source. To ensure proper [=credential=] use, stakeholders need to assess the credential's relevance and authority within the specific context of their intended application.

Code Injection

Data in [=verifiable credentials=] can include injectable code or code from scripting languages. Authors of [=verifiable credentials=] benefit from avoiding such inclusions unless necessary and only after mitigating associated risks to the fullest extent possible.

For example, a single natural language string containing multiple languages or annotations often requires additional structure or markup for correct presentation. Markup languages, such as HTML, can label text spans in different languages or supply string-internal markup needed to display [=bidirectional text=] properly. 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 so for the following reasons:

• It requires some version of an HTML processor, which increases the burden of processing language and base direction information.
• It increases the security attack surface when using this data model, because naively processing HTML could result in the execution of a `script` tag that an attacker injected at some point during the data production process.

If implementers feel they need to 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 could use the markup to mount injection attacks against a consumer of the markup. This analysis should be followed by the proactive deployment of mitigations against the identified attacks, such as running the HTML rendering engine in a sandbox with no ability to access the network.

Data First Approaches

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 using 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.