From 8cb3bcfeaaacb0c238f14288cf81d0c2d8e0a00c Mon Sep 17 00:00:00 2001 From: Gabe <7622243+decentralgabe@users.noreply.github.com> Date: Sat, 17 Aug 2024 09:26:26 -0700 Subject: [PATCH] Perform editorial pass for sections 1-4. Co-authored-by: Manu Sporny --- index.html | 501 +++++++++++++++++++++++++++-------------------------- 1 file changed, 251 insertions(+), 250 deletions(-) diff --git a/index.html b/index.html index 53dac34cc..f7066d0ac 100644 --- a/index.html +++ b/index.html @@ -267,12 +267,12 @@

-[=Credentials=] are a part of our daily lives; driver's licenses are used to -assert that we are capable of operating a motor vehicle, university degrees -can be used to assert our level of education, and government-issued passports -enable us to travel between countries. This specification provides a mechanism -to express these sorts of [=credentials=] on the Web in a way that is -cryptographically secure, privacy respecting, and machine-verifiable. +[=Credentials=] are integral to our daily lives; driver's licenses confirm +our capability to operate motor vehicles, university degrees assert our level +of education, and government-issued passports permit travel between countries. +This specification provides a mechanism to express these sorts of +[=credentials=] on the Web in cryptographically secure, privacy-respecting, +and machine-verifiable way.

@@ -290,8 +290,9 @@ Comments regarding this specification are welcome at any time. Please file issues directly on GitHub, -or, if that is not possible, send them to +or send them to public-vc-comments@w3.org +if that is not possible. (subscribe, archives).

@@ -302,26 +303,27 @@

Introduction

-[=Credentials=] are a part of our daily lives; driver's licenses are used to -assert that we are capable of operating a motor vehicle, university degrees -can be used to assert our level of education, and government-issued passports -enable us to travel between countries. These [=credentials=] provide +[=Credentials=] are integral to our daily lives; driver's licenses confirm +our capability to operate motor vehicles, university degrees assert our level +of education, and government-issued passports permit travel between countries. +This specification provides a mechanism to express these sorts of +[=credentials=] on the Web in cryptographically secure, privacy-respecting, +and machine-verifiable way. These [=credentials=] provide benefits to us when used in the physical world, but their use on the Web continues to be elusive.

-Currently it is difficult to express education qualifications, healthcare -data, financial account details, and other sorts of third-party [=verified=] -machine-readable personal information on the Web. The difficulty of expressing -digital [=credentials=] on the Web makes it challenging to receive the same -benefits through the Web that physical [=credentials=] provide us in the -physical world. +It is currently difficult to express education qualifications, healthcare +data, financial account details, and other third-party [=verified=] +machine-readable personal information on the Web. The challenge of expressing +digital [=credentials=] on the Web hinders our ability to receive the same +benefits physical [=credentials=] provide us in the real world.

-This specification provides a standard way to express [=credentials=] on the -Web in a way that is cryptographically secure, privacy respecting, and +This specification standardizes a way of expressing [=credentials=] on the +Web, ensuring they are cryptographically secure, privacy-respecting, and machine-verifiable.

@@ -338,8 +340,8 @@

Introduction

The components that constitute a [=verifiable presentation=]
  • -An ecosystem where [=verifiable credentials=] and -[=verifiable presentations=] are expected to be useful +An ecosystem where one [=verifiable credentials=] +and [=verifiable presentations=] are useful

    • @@ -368,14 +370,14 @@

    What is a Verifiable Credential?

    Dutch passport, an American driving license, or a health insurance card)
  • -Information related to specific properties being asserted by +Information related to specific properties 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 qualifications required for the [=credential=] -to be issued were met by the [=subject=] (for example, a measurement, -proof of citizenship, or test result) +Evidence demonstrating how the [=subject=] met the qualifications required +for issuing the [=credential=] (for example, a measurement, proof of +citizenship, or test result)
  • Information related to constraints on the credential (for example, @@ -384,49 +386,48 @@

    What is a Verifiable Credential?

    -A [=verifiable credential=] can represent all of the same information that a +A [=verifiable credential=] can represent all 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. +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. +[=verifiable credentials=] with specific 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. +counterparts when establishing 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 +[=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 a number of these issues in Section +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=], +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 +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 +evaluating the issuer, the proof, the subject, and the claims against one or more verifier policies.

    @@ -436,11 +437,11 @@

    Ecosystem Overview

    This section describes the roles of the core actors and the relationships -between them in an ecosystem where [=verifiable credentials=] are expected +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. The following roles are introduced in this -specification: +protocols for standardization. This specification introduces the following +roles:

    @@ -456,7 +457,7 @@

    Ecosystem Overview

    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=]. Example issuers +transmitting the [=verifiable credential=] to a [=holder=]. For example, issuers include corporations, non-profit organizations, trade associations, governments, and individuals.
    @@ -476,13 +477,12 @@

    Ecosystem Overview

    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 -be required to use [=verifiable credentials=]. Some configurations might require +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. 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. +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 utilized in an ecosystem.
    @@ -499,38 +499,37 @@

    Ecosystem Overview

    -[[[#roles]]] above provides an example ecosystem in which to ground the +[[[#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 benefit. +[=verifiable credentials=] also provide benefits.

    -The ecosystem provided in this specification is in contrast to a typical -two-party, or federated identity provider, model. 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 does not use the "identity -provider", "federated identity", or "relying party" terminology unless comparing -or mapping the concepts in this document to other specifications. This -specification decouples the identity provider concept into two distinct -concepts: the [=issuer=] and the [=holder=]. +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 certain cases it is not. For example, a parent (the [=holder=]) might hold +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 special cases, see 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, along with +For a deeper exploration of the [=verifiable credentials=] ecosystem and a concrete lifecycle example, please refer to [[[VC-USE-CASES]]] [[?VC-USE-CASES]].

    @@ -554,8 +553,8 @@

    Ecosystem Overview

    A conforming issuer implementation produces [=conforming documents=], MUST include all required properties in the -[=conforming documents=] that it produces, and MUST secure the [=conforming -documents=] it produces using a securing mechanism as described in Section +[=conforming documents=] it produces, and MUST secure the [=conforming +documents=] it produces using a securing mechanism described in Section [[[#securing-mechanisms]]].

    @@ -570,7 +569,7 @@

    Ecosystem Overview

    This specification includes both required and optional properties. Optional -properties MAY be ignored by [=conforming issuer implementations=] and/or +properties MAY be ignored by [=conforming issuer implementations=] and [=conforming verifier implementations=].

    @@ -586,7 +585,7 @@

    Ecosystem Overview

    Examples provided throughout this document include descriptive fields, such as `name` and `description`, with values in English to simplify the concepts in each example of the specification. These examples do not necessarily reflect the data -structures needed for international use, which is described in more detail in +structures needed for international use, described in more detail in Section [[[#internationalization-considerations]]].

    @@ -617,10 +616,10 @@

    Terminology

    decentralized identifier
    A portable URL-based identifier, also known as a DID, -associated with an [=entity=]. These identifiers are most often used in a +is associated with an [=entity=]. These identifiers are most often used in a [=verifiable credential=] and are associated with [=subjects=] such that a -[=verifiable credential=] itself can be easily ported from one -[=credential repository=] to another without the need to reissue the [=credential=]. +[=verifiable credential=] can be easily ported from one +[=credential repository=] to another without reissuing the [=credential=]. An example of a DID is `did:example:123456abcdef`.
    decentralized identifier document
    @@ -644,7 +643,7 @@

    Terminology

    Anything that can be referenced in statements as an abstract or concrete noun. Entities include but are not limited to people, organizations, physical things, documents, abstract concepts, fictional characters, and arbitrary text. Any -entity might perform roles in the ecosystem, if it is capable of doing so. Note +entity might perform roles in the ecosystem, if it can do so. Note that some entities fundamentally cannot take actions, e.g., the string "abc" cannot issue credentials. @@ -652,7 +651,7 @@

    Terminology

    A set of claims, forming a network of information composed of [=subjects=] and their relationship to other [=subjects=] or data. Each [=claim=] is -part of a graph; this is either explicit in the case of [=named graphs=], or +part of a graph; either explicit in the case of [=named graphs=], or implicit for the [=default graph=].
    holder
    @@ -679,8 +678,8 @@

    Terminology

    presentation
    -Data derived from one or more [=verifiable credentials=], issued by one or -more [=issuers=], that is shared with a specific [=verifier=]. +Data derived from one or more [=verifiable credentials=] issued by one or +more [=issuers=] that is shared with a specific [=verifier=].
    credential repository
    @@ -721,18 +720,18 @@

    Terminology

    verifiable credential
    -A tamper-evident [=credential=] that has authorship that can be -cryptographically verified. Verifiable credentials can be used to build -[=verifiable presentations=], which can also be cryptographically verified. +A tamper-evident [=credential=] whose authorship can be cryptographically +verified. Verifiable credentials can be used to build +[=verifiable presentations=], which can also be cryptographically verifiable.
    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 be required to use [=verifiable credentials=]. Some +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 +registries, such as ones for UUIDs and [=verification material=], might act as namespaces for identifiers.
    verifiable presentation
    @@ -740,15 +739,15 @@

    Terminology

    A tamper-evident presentation of information encoded in such a way that authorship of the data can be trusted after a process of cryptographic verification. Certain types of verifiable presentations might contain data that -is synthesized from, but do not contain, the original [=verifiable credentials=] +is synthesized from, but does not contain, the original [=verifiable credentials=] (for example, zero-knowledge proofs).
    verification
    The evaluation of whether a [=verifiable credential=] or [=verifiable presentation=] is an authentic and current statement of the issuer or presenter, -respectively. This includes checking that: the credential or presentation -conforms to the specification; the securing mechanism is satisfied; and, if +respectively. This includes checking that the credential or presentation +conforms to the specification, the securing mechanism is satisfied, and, if present, the status check succeeds. Verification of a credential does not imply evaluation of the truth of [=claims=] encoded in the credential.
    @@ -762,13 +761,13 @@

    Terminology

    verification material
    Information that is used to verify the security of cryptographically -protected information. For example, a cryptographic public key used to verify +protected information. For example, a cryptographic public key is used to verify a digital signature associated with a [=verifiable credential=].
    URL
    A Uniform Resource Locator, as defined by the [[[URL]]]. URLs can be -dereferenced such that they result in a resource, such as a document. The rules +dereferenced to result in a resource, such as a document. The rules for dereferencing, or fetching, a URL are defined by the URL [=url/scheme=]. This specification does not use the term URI or IRI because those terms have been deemed to be confusing to Web developers. @@ -789,14 +788,14 @@

    Core Data Model

    Readers might note that some concepts described in this section, such as -[=credential=] and [=presentation=], do not have media types defined by +[=credentials=] and [=presentations=], do not have media types defined by this specification. However, the concepts of a [=verifiable credential=] or a -[=verifiable presentation=] are defined as [=conforming documents=] and do +[=verifiable presentation=] are defined as [=conforming documents=] and have associated media types. The concrete difference between these concepts — between [=credential=] and [=presentation=] vs. [=verifiable credential=] and [=verifiable presentation=] — is simply the fact -that the "verifiable" objects are secured in a way that is cryptographically -verifiable, and the others are not. For more details, see Section +that the "verifiable" objects are secured in a cryptographic +way, and the others are not. For more details, see Section [[[#securing-mechanisms]]].

    @@ -831,7 +830,7 @@

    Claims

    src="diagrams/claim-example.svg" alt="Pat has an alumniOf property whose value is Example University">
    -A basic claim expressing that Pat is an alumni of "Example University". +A basic claim expressing that Pat is an alum of "Example University".
    @@ -855,7 +854,8 @@

    Claims

    To this point, the concepts of a [=claim=] and a [=graph=] of information -are introduced. To be able to trust [=claims=], more information is +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.

    @@ -896,12 +896,12 @@

    Credentials

    [=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 +(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 +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 that are interested in the need for +case, is a digital signature. Readers who are interested in the need for multiple information graphs can refer to Section [[[#verifiable-credential-graphs]]].

    @@ -931,7 +931,7 @@

    Credentials

    [[[#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, that being the [=verifiable +payload contains a single information graph, which is the [=verifiable credential graph=] containing [=credential=] metadata and other [=claims=].

    @@ -969,11 +969,11 @@

    Presentations

    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 +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, their -online gaming persona, their family persona, or an incognito persona. +Examples of different personas include a person's professional persona, +online gaming persona, family persona, or incognito persona.

    @@ -985,7 +985,7 @@

    Presentations

    -The data in a [=presentation=] is often about the same [=subject=], but might +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=].

    @@ -1002,7 +1002,7 @@

    Presentations

    [[[#basic-vp]]] above shows the components of a -[=verifiable presentation=], but abstracts the details about how +[=verifiable presentation=] but abstracts the details about how [=verifiable credentials=] are organized into information [=graphs=], which are then organized into [=verifiable presentations=].

    @@ -1012,19 +1012,22 @@

    Presentations

    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=] +(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, +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=]. +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=].

    @@ -1039,14 +1042,14 @@

    Presentations

    which is identical to Figure 6, except that the verifiable credential graph is annotated to be a named graph instead of a default graph. The verifiable presentation proof graph has an object with 'Signature 8910' -with 5 properties: 'type' with value 'DataIntegrityProof'; 'verificationMethod' with value 'Example -Presenter Public Key 11'; 'created' with value '2018-01-15T12:43:56Z'; -'nonce' with value 'd28348djsj3239'; and 'proofValue' with value -'zp2KaZ...8Fj3K='. This graph is annotated with the parenthetical remark '(a -named graph)'"> +with 5 properties: 'type' with value 'DataIntegrityProof'; 'verificationMethod' +with value 'Example Presenter Public Key 11'; 'created' with value +'2018-01-15T12:43:56Z'; 'nonce' with value 'd28348djsj3239'; and 'proofValue' +with value 'zp2KaZ...8Fj3K='. This graph is annotated with the parenthetical +remark '(a named graph)'">
    -Information [=graphs=] associated with a basic [=verifiable presentation=] that is using an [=embedded proof=] -based on [[[VC-DATA-INTEGRITY]]]. +Information [=graphs=] associated with a basic [=verifiable presentation=] that +uses an [=embedded proof=] based on [[[VC-DATA-INTEGRITY]]].
    @@ -1055,13 +1058,13 @@

    Presentations

    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=] itself through presentation metadata; and the corresponding +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 on [[[#info-graph-vc-jwt]]]. +secured via an [=enveloping proof=] shown in [[[#info-graph-vc-jwt]]].

    @@ -1091,7 +1094,7 @@

    Presentations

    Information graphs associated with a basic [=verifiable presentation=] that is using an [=enveloping proof=] based on [[[?VC-JOSE-COSE]]]. The `data:` URL -refers to the [=verifiable credential=] shown on +refers to the [=verifiable credential=] shown in [[[#info-graph-vc-jwt]]].
    @@ -1099,18 +1102,18 @@

    Presentations

    -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. +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 step through a particular credential exchange. +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 @@ -1126,7 +1129,7 @@

    Presentations

    Basic Concepts

    -This section introduces some basic concepts for the specification, in +This section introduces some basic concepts for the specification in preparation for Section [[[#advanced-concepts]]] later in the document.

    @@ -1136,7 +1139,7 @@

    Getting Started

    This specification is designed to ease the prototyping of new types of -[=verifiable credential=]. Developers can copy the template below and paste it +[=verifiable credentials=]. Developers can copy the template below and paste it into common [=verifiable credential=] tooling to start issuing, holding, and verifying prototype credentials.

    @@ -1167,11 +1170,10 @@

    Getting Started

    -Once a developer has prototyped their credential to a point where they believe -all of the credential properties are stable, it is advised that they generate -vocabulary and context files for their application and publish them at stable -URLs, so that other developers can use the same vocabulary and context to achieve -interoperability. The `https://www.w3.org/ns/credentials/examples/v2` URL above +After stabilizing all credential properties, developers are advised to generate +and publish vocabulary and context files at stable URLs to facilitate +interoperability with other developers. The +`https://www.w3.org/ns/credentials/examples/v2` URL above would then be replaced with the URL of a use-case-specific context. This process is covered in Section [[[#extensibility]]]. Alternatively, developers can reuse existing vocabulary and context files that happen to fit @@ -1261,25 +1263,25 @@

    Contexts

    When two software systems need to exchange data, they need to use terminology -that both systems understand. As an analogy, consider how two people -communicate effectively by using the same language where the words they use, -such as "name" and "website", mean the same thing to each individual. This is -sometimes referred to as the context of a conversation. This -specification uses a similar concept to achieve similar results for software -systems by establishing a context in which to communicate. +that both systems understand. Consider how two people communicate effectively +by using the same language, where the words they use, such as "name" and +"website," mean the same thing to each individual. This is sometimes referred +to as the context of a conversation. This specification uses a similar +concept to achieve similar results for software systems by establishing a +context in which to communicate.

    Software systems that process [=verifiable credentials=] and [=verifiable presentations=] identify terminology by using [=URLs=] for each term. However, those [=URLs=] can be long and not very human-friendly, while short-form, human-friendly aliases can be more helpful. This specification uses the -`@context` [=property=] to map such short-form aliases to the [=URLs=]. +`@context` [=property=] to map short-form aliases to the [=URLs=].

    [=Verifiable credentials=] and [=verifiable presentations=] MUST include a `@context` [=property=]. Application developers MUST understand every JSON-LD context used by their application, at least to the extent that it affects the -meaning of the terms that are used by their application. One mechanism for +meaning of the terms used by their application. One mechanism for doing so is described in the Section on Validating Contexts in the [[[VC-DATA-INTEGRITY]]] specification. Other specifications that build @@ -1295,7 +1297,7 @@

    Contexts

    where the first item is a [=URL=] with the value `https://www.w3.org/ns/credentials/v2`. Subsequent items in the [=ordered set=] MUST be composed of any combination of -[=URLs=] and/or objects, where each is processable as a +[=URLs=] and objects, where each is processable as a JSON-LD Context.
    @@ -1323,7 +1325,7 @@

    Contexts

    The example above uses the base context [=URL=] (`https://www.w3.org/ns/credentials/v2`) to establish that the data exchange is -about a [=verifiable credential=]. This concept is further expanded on in +about a [=verifiable credential=]. This concept is further detailed in Section [[[#extensibility]]]. The data available at `https://www.w3.org/ns/credentials/v2` is a permanently cacheable static document with instructions for processing it provided in Appendix @@ -1333,8 +1335,8 @@

    Contexts

    -The second [=URL=] (`https://www.w3.org/ns/credentials/examples/v2`) is used for -the purpose of demonstrating examples. Implementations are expected to not use +The second [=URL=] (`https://www.w3.org/ns/credentials/examples/v2`) is used to +demonstrate examples. Implementations are expected to not use this [=URL=] for any other purpose, such as in pilot or production systems.

    @@ -1352,11 +1354,11 @@

    Identifiers

    When expressing statements about a specific thing, such as a person, product, or -organization, it can be useful to use a globally unique identifier for that thing. +organization, using a globally unique identifier for that thing can be useful. Globally unique identifiers enable others to express statements about the same thing. This specification defines the optional `id` [=property=] for such identifiers. The `id` [=property=] -allows for the expression of statements about specific things in the +allows for expressing statements about specific things in the [=verifiable credential=] and is set by an [=issuer=] when expressing objects in a [=verifiable credential=] or a [=holder=] when expressing objects in a [=verifiable presentation=]. The `id` [=property=] expresses an @@ -1368,13 +1370,13 @@

    Identifiers

    -Developers should remember that identifiers might be harmful in scenarios -where pseudonymity is required. Developers are encouraged to read Section -[[[#identifier-based-correlation]]] carefully when considering such -scenarios. There are also other types of access and correlation mechanisms documented +Developers are reminded that identifiers might be harmful +when pseudonymity is required. When considering such scenarios, developers are +encouraged to read Section [[[#identifier-based-correlation]]] carefully +There are also other types of access and correlation mechanisms documented in Section [[[#privacy-considerations]]] that create privacy concerns. -Where privacy is a strong consideration, it is permissible to omit the -`id` [=property=]. Some use cases do not need, or explicitly need to omit, +Where privacy is a vital consideration, it is permissible to omit the +`id` [=property=]. Some use cases do not need or explicitly need to omit, the `id` [=property=]. Similarly, special attention is to be given to the choice between publicly resolvable URLs and other forms of identifiers. Publicly resolvable URLs can facilitate ease of verification and interoperability, yet they might also inadvertently @@ -1383,8 +1385,8 @@

    Identifiers

    id
    -The `id` [=property=] is OPTIONAL. If present, the value of the `id` -[=property=] MUST be a single [=URL=], which MAY be dereferenceable. It is +The `id` [=property=] is OPTIONAL. If present, `id` [=property=]'s value +MUST be a single [=URL=], which MAY be dereferenceable. It is RECOMMENDED that the [=URL=] in the `id` be one which, if dereferenceable, results in a document containing machine-readable information about the `id`.
    @@ -1421,12 +1423,12 @@

    Identifiers

    -[=DIDs=] are type of identifier that are not necessary for [=verifiable +[=DIDs=] are a type of identifier which are not necessary for [=verifiable credentials=] to be useful. Specifically, [=verifiable credentials=] do not depend on [=DIDs=] and [=DIDs=] do not depend on [=verifiable credentials=]. -However, many [=verifiable credentials=] will use [=DIDs=] and software +However, many [=verifiable credentials=] will use [=DIDs=], and software libraries implementing this specification will need to resolve [=DIDs=]. -[=DID=]-based URLs are used for expressing identifiers associated with +[=DID=]-based URLs are used to express identifiers associated with [=subjects=], [=issuers=], [=holders=], credential status lists, cryptographic keys, and other machine-readable information associated with a [=verifiable credential=]. @@ -1440,8 +1442,8 @@

    Types

    Software systems that process the kinds of objects specified in this document use type information to determine whether or not a provided [=verifiable credential=] or [=verifiable presentation=] is appropriate -for the intended use case. This specification defines a `type` -[=property=] for the expression of object type information. This type +for the intended use-case. This specification defines a `type` +[=property=] for expressing object type information. This type information can be used during [=validation=] processes, as described in Appendix [[[#validation]]].

    @@ -1455,7 +1457,7 @@

    Types

    type
    The value of the `type` [=property=] MUST be one or more -terms and/or +terms and absolute URL strings. If more than one value is provided, the order does not matter.
    @@ -1483,7 +1485,7 @@

    Types

    -With respect to this specification, the following table lists the objects that +Concerning this specification, the following table lists the objects that MUST have a [=type=] specified.

    @@ -1583,12 +1585,12 @@

    Types

    `@type` keyword to `type` to make the JSON-LD documents more easily understood. While application developers and document authors do not need to understand the specifics of the JSON-LD type system, implementers -of this specification who want to support interoperable extensibility, do. +of this specification who want to support interoperable extensibility do.

    All [=credentials=], [=presentations=], and encapsulated objects SHOULD -specify, or be associated with, additional more narrow [=types=] (like +specify, or be associated with, additional, more narrow [=types=] (like `ExampleDegreeCredential`, for example) so software systems can more easily detect and process this additional information.

    @@ -1624,7 +1626,7 @@

    Types

    This enables implementers to rely on values associated with the `type` property -for [=verification=] purposes. Object types, and their associated values, are +for [=verification=]. Object types and their associated values are expected to be documented in at least a human-readable specification that can be found at the [=URL=] for the type. For example, the human-readable definition for the `BitstringStatusList` type can be found at @@ -1632,17 +1634,17 @@

    Types

    https://www.w3.org/ns/credentials/status/#BitstringStatusList. It is also suggested that a -machine-readable version be provided, through HTTP content negotiation, at +machine-readable version be provided through HTTP content negotiation at the same URL.

    Explaining how to create a new type of [=verifiable credential=] is beyond -the scope of this specification. Readers that are interested in doing so are -advised to read the section on +the scope of this specification. Readers interested in doing so are +advised to read the -Creating New Credential Types in the [[[?VC-IMP-GUIDE]]]. +Creating New Credential Types section in the [[[?VC-IMP-GUIDE]]].

    @@ -1651,11 +1653,11 @@

    Types

    Names and Descriptions

    -When displaying a [=credential=], it can be useful to have +When displaying a [=credential=], it can be helpful to have text provided by the [=issuer=] that furnishes the -[=credential=] with a name as well as a short description of its +[=credential=] with a name and a short description of its purpose. The `name` and `description` [=properties=] -are meant to serve these purposes. +serve these purposes.

    @@ -1667,7 +1669,7 @@

    Names and Descriptions

    [[[#language-and-base-direction]]]. Ideally, the name of a [=credential=] is concise, human-readable, and could enable an individual to quickly differentiate one [=credential=] from any other [=credentials=] -that they might hold. +they might hold.
    description
    @@ -1677,7 +1679,7 @@

    Names and Descriptions

    [[[#language-and-base-direction]]]. Ideally, the description of a [=credential=] is no more than a few sentences in length and conveys enough information about the [=credential=] to remind an individual of its contents -without their having to look through the entirety of the [=claims=]. +without having to look through the entirety of the [=claims=].
    @@ -1723,7 +1725,7 @@

    Names and Descriptions

    The `@direction` property in the examples below is not required for the associated single-language strings, as their default directions are the same as those set by the `@direction` value. We include the `@direction` property here -for clarity of demonstration, and to make copy+paste+edit deliver functional +for clarity of demonstration and to make copy+paste+edit deliver functional results. Implementers are encouraged to read the section on String Internationalization in the [[[JSON-LD11]]] specification. @@ -1823,7 +1825,7 @@

    Issuer

    issuer
    The value of the `issuer` [=property=] MUST be either a -[=URL=], or an object containing an `id` [=property=] +[=URL=] or an object containing an `id` [=property=] whose value is a [=URL=]; in either case, the issuer selects this [=URL=] to identify itself in a globally unambiguous way. It is RECOMMENDED that the [=URL=] be one which, if dereferenced, results @@ -1941,10 +1943,10 @@

    Credential Subject

    -It is possible to express information related to multiple [=subjects=] in a -[=verifiable credential=]. The example below specifies two [=subjects=] -who are spouses. Note the use of array notation to associate multiple -[=subjects=] with the `credentialSubject` property. +Expressing information related to multiple [=subjects=] in a +[=verifiable credential=] is possible. The example below specifies two +[=subjects=] who are spouses. Note the use of array notation to associate +multiple [=subjects=] with the `credentialSubject` property. 

    Validity Period
         
    
 This specification defines the `validFrom` [=property=] to help an
 issuer to express the date and time when a [=credential=] becomes valid and
-the `validUntil` [=property=] for expressing the date and time
+the `validUntil` [=property=] to express the date and time
 when a [=credential=] ceases to be valid.
         
    
 
         
    
-When comparing dates and times, the calculation is done "temporally", which
-means that the string value is converted to a "temporal value" which exists
+When comparing dates and times, the calculation is done "temporally",
+meaning that the string value is converted to a "temporal value" which exists
 as a point on a timeline. Temporal comparisons are then performed by checking
-to see where the date and time being compared is in relation to
+to see where the date and time being compared are in relation to
 a particular point on the timeline.
         
    
 
         
    
           
    validFrom
    
           
    
-If present, the value of the `validFrom` [=property=] MUST be an
+If present, the value of the `validFrom` [=property=] MUST be a
 [XMLSCHEMA11-2]
 `dateTimeStamp` string value representing the date and time the
 [=credential=] becomes valid, which could be a date and time in the future or
-in the past. Note that this value represents the earliest point in time at which
+the past. Note that this value represents the earliest point in time at which
 the information associated with the `credentialSubject`
 [=property=] becomes valid. If a `validUntil` value also exists, the
-`validFrom` value MUST express a datetime that is temporally the same or earlier
-than the datetime expressed by the `validUntil` value.
+`validFrom` value MUST express a point in time that is temporally the same or earlier
+than the point in time expressed by the `validUntil` value.
           
    
           
    validUntil
    
           
    
-If present, the value of the `validUntil` [=property=] MUST be an
+If present, the value of the `validUntil` [=property=] MUST be a
 [XMLSCHEMA11-2]
 `dateTimeStamp` string value representing the date and time the
 [=credential=] ceases to be valid, which could be a date and time in the past
-or in the future. Note that this value represents the latest point in time at
+or the future. Note that this value represents the latest point in time at
 which the information associated with the `credentialSubject`
 [=property=] is valid. If a `validFrom` value also exists, the `validUntil`
-value MUST express a datetime that is temporally the same or later than the
-datetime expressed by the `validFrom` value.
+value MUST express a point in time that is temporally the same or later than the
+point in time expressed by the `validFrom` value.
           
    
         
    
 
@@ -2056,7 +2058,7 @@ 
    Status
    
         
    
 This specification defines the
 credentialStatus [=property=] for
-the discovery of information related to the status of a [=verifiable
+discovering information related to the status of a [=verifiable
 credential=], such as whether it is suspended or revoked.
         
    
 
@@ -2083,13 +2085,12 @@ 
    Status
    
 
         
    
 The precise content of the [=credential=] status information is determined by
-the specific `credentialStatus` [=type=] definition, and varies
+the specific `credentialStatus` [=type=] definition and varies
 depending on factors such as whether it is simple to implement or if it is
 privacy-enhancing. The value will provide enough information to determine the
-current status of the [=credential=] and whether machine readable information will
+current status of the [=credential=] and whether machine-readable information will
 be retrievable from the URL. For example, the object could contain a link to an
-external document which notes whether or not the [=credential=] is suspended or
-revoked.
+external document that notes whether the [=credential=] is suspended or revoked.
         
    
 
         
    Status
         
    
 
         
    
-It is possible for a [=credential=] to have more than one status associated
+A [=credential=] can have more than one status associated
 with it, such as whether it has been revoked or suspended.
         
    
 
@@ -2167,9 +2168,9 @@ 
    Status
    
         
    
 
         
    
-Defining the data model, formats, and protocols for status schemes are out of
-scope for this specification. A Verifiable Credential Specifications Directory
-[[?VC-SPECS]] exists that contains available status schemes
+Defining the data model, formats, and protocols for status schemes is out of
+the scope of this specification. A Verifiable Credential Specifications Directory
+[[?VC-SPECS]] contains available status schemes
 for implementers who want to implement [=verifiable credential=]
 status checking.
         
    
@@ -2180,8 +2181,8 @@ 
    Status
    
 [=verifier=] is interested in a specific [=holder=] or [=subject=]. Unacceptable
 approaches include "phoning home," such that every use of a credential contacts
 the [=issuer=] of the credential to check the status for a specific individual,
-or "pseudonymity reduction", such that every use of the credential causes a
-request for information from the [=issuer=] that can be used by the [=issuer=]
+or "pseudonymity reduction," such that every use of the credential causes a
+request for information from the [=issuer=] that the [=issuer=] can use
 to deduce [=verifier=] interest in a specific individual.
         
    
 
@@ -2192,7 +2193,7 @@ 
    Data Schemas
    
 
         
    
 Data schemas are useful when enforcing a specific structure on a given
-collection of data. There are at least two types of data schemas that this
+data collection. There are at least two types of data schemas that this
 specification considers:
         
    
 
@@ -2212,13 +2213,13 @@ 
    Data Schemas
    
         
    
 It is important to understand that data schemas serve a different purpose from
 the `@context` property, which neither enforces data structure or
-data syntax, nor enables the definition of arbitrary encodings to alternate
+data syntax nor enables the definition of arbitrary encodings to alternate
 representation formats.
         
    
         
    
-This specification defines the following [=property=] for the expression of a
-data schema, which can be included by an [=issuer=] in
-the [=verifiable credentials=] that it issues:
+This specification defines the following [=property=] for expressing a
+data schema, which an [=issuer=] can include in the [=verifiable credentials=]
+that it issues:
         
    
 
         
    
@@ -2229,9 +2230,9 @@ 
    Data Schemas
    
 more data schemas that provide [=verifiers=] with enough information to
 determine whether the provided data conforms to the provided schema(s). Each
 `credentialSchema` MUST specify its `type` (for example,
-`JsonSchema`), and an `id` [=property=]
-that MUST be a [=URL=] identifying the schema file. The precise contents of
-each data schema is determined by the specific type definition.
+`JsonSchema`) and an `id` [=property=]
+that MUST be a [=URL=] identifying the schema file. The specific type
+definition determines the precise contents of each data schema.
             
    
             
    
 If multiple schemas are present, validity is determined according to the
@@ -2242,10 +2243,10 @@ 
    Data Schemas
    
 
         
    
-The `credentialSchema` [=property=] provides an opportunity to
+The `credentialSchema` [=property=] allows one to
 annotate type definitions or lock them to specific versions of the vocabulary.
 Authors of [=verifiable credentials=] can include a static version of their
-vocabulary using `credentialSchema` that is locked to some content
+vocabulary using `credentialSchema` that is secured by some content
 integrity protection mechanism. The `credentialSchema`
 [=property=] also makes it possible to perform syntactic checking on the
 [=credential=] and to use [=verification=] mechanisms such as JSON Schema
@@ -2286,8 +2287,8 @@ 
    Data Schemas
    
 
         
    
 In the example above, the [=issuer=] is specifying two `credentialSchema`
-objects, each of which point to a JSON Schema [[?VC-JSON-SCHEMA]] file that can
-be used by a [=verifier=] to determine whether the [=verifiable credential=] is
+objects, each of which point to a JSON Schema [[?VC-JSON-SCHEMA]] file that a
+[=verifier=] can use to determine whether the [=verifiable credential=] is
 well-formed.
         
    
 
@@ -2303,7 +2304,7 @@ 
    Securing Mechanisms
    
         
    
 
         
    
-An enveloping proof is one that wraps a serialization
+An enveloping proof wraps a serialization
 of this data model. One such RECOMMENDED enveloping proof mechanism is defined
 in [[[VC-JOSE-COSE]]] [[VC-JOSE-COSE]].
         
    
@@ -2351,9 +2352,9 @@ 
    Securing Mechanisms
    
 
         
    
 The [=embedded proof=] above secures the original [=credential=] by decorating
-the original data with a digital signature via the `proof` property, resulting
-in a [=verifiable credential=] that is easy to manage in modern programming
-environments and database systems.
+the original data with a digital signature via the `proof` property. This
+results in a [=verifiable credential=] that is easy to manage in modern
+programming environments and database systems.
         
    
 
         
    Verifiable Presentations
 multiple [=verifiable credentials=].
         
    
         
    
-[=Verifiable presentations=] SHOULD be extremely short-lived, and bound to a
+[=Verifiable presentations=] SHOULD be extremely short-lived and bound to a
 challenge provided by a [=verifier=]. Details for accomplishing this depend
 on the securing mechanism, the transport protocol, and [=verifier=] policies.
 Unless additional requirements are defined by the particular securing mechanism
 or embedding protocol, a [=verifier=] cannot generally assume that the
-[=verifiable presentation=] has any correlation with the presented
+[=verifiable presentation=] correlates with the presented
 [=verifiable credentials=].
         
    
 
@@ -2452,7 +2453,7 @@ 
    Verifiable Presentations
    
 MUST be one or more [=verifiable credential=] and/or
 enveloped verifiable credential
 objects (the values MUST NOT be non-object values such as
-numbers, strings, or URLs). These types of objects are called
+numbers, strings, or URLs). These objects are called
 verifiable credential graphs and
 MUST express information that is secured using a
 securing mechanism.
@@ -2468,7 +2469,7 @@ 
    Verifiable Presentations
    
 about the [=holder=] that can be used to [=verify=] the information
 expressed in the [=verifiable presentation=].
 If the `holder` [=property=] is absent, information about the
-[=holder=] either is obtained via the securing mechanism, or
+[=holder=] is obtained either via the securing mechanism or
 does not pertain to the [=validation=] of the [=verifiable presentation=].
    @@ -2509,14 +2510,14 @@

    Enveloped Verifiable Credentials

    EnvelopedVerifiableCredential
    -Used to associate an object containing an enveloped [=verifiable credential=] -with the `verifiableCredential` property in a [=verifiable presentation=]. -The `@context` property of the object MUST be present and include a context, -such as the base context for this specification, -that defines at least the `id`, `type`, and `EnvelopedVerifiableCredential` -terms as defined by the base context provided by this specification. The `id` -value of the object MUST be a `data:` URL [[RFC2397]] that expresses a secured -[=verifiable credential=] using an +They are used to associate an object containing an enveloped +[=verifiable credential=] with the `verifiableCredential` property in a +[=verifiable presentation=]. The `@context` property of the object MUST be +present and include a context, such as the base context +for this specification, that defines at least the `id`, `type`, and +`EnvelopedVerifiableCredential` terms as defined by the base context provided +by this specification. The `id` value of the object MUST be a `data:` URL +[[RFC2397]] that expresses a secured [=verifiable credential=] using an enveloping security scheme, such as [[[VC-JOSE-COSE]]] [[VC-JOSE-COSE]]. The `type` value of the object MUST be `EnvelopedVerifiableCredential`. @@ -2546,7 +2547,7 @@

    Enveloped Verifiable Credentials

    It is possible that an implementer might want to process the object described in -this section, and the enveloped presentation expressed by the `id` value, in an +this section and the enveloped presentation expressed by the `id` value in an RDF environment and create linkages between the objects that are relevant to RDF. The desire and mechanisms for doing so are use case dependent and will, thus, be implementation dependent. @@ -2633,7 +2634,7 @@

    Presentations Including Holder Claims

    a [=verifiable presentation=] to include [=verifiable credentials=] from any [=issuer=], including themselves. When the [=issuer=] of a [=verifiable credential=] is the [=holder=], the [=claims=] in that -[=verifiable credential=] are considered to be self-asserted. +[=verifiable credential=] are considered self-asserted. Such self-asserted claims can be secured by the same mechanism that secures the [=verifiable presentation=] in which they are included or by any mechanism usable for other [=verifiable credentials=]. @@ -2641,7 +2642,7 @@

    Presentations Including Holder Claims

    The subject(s) of these self-asserted [=claims=] are not limited, so these [=claims=] can include statements about the -[=holder=], one of the other included [=verifiable credentials=], or even +[=holder=], one of the other included [=verifiable credentials=] or even the [=verifiable presentation=] in which the self-asserted [=verifiable credential=] is included. In each case, the `id` [=property=] is used to identify the specific [=subject=], in the object where the @@ -2650,8 +2651,8 @@

    Presentations Including Holder Claims

    A [=verifiable presentation=] that includes a self-asserted -[=verifiable credential=] that is only secured using the same mechanism as -the [=verifiable presentation=] MUST include a `holder` +[=verifiable credential=], which is secured only using the same mechanism as +the [=verifiable presentation=], MUST include a `holder` [=property=].

    @@ -2693,7 +2694,7 @@

    Presentations Including Holder Claims

    The example below shows a [=verifiable presentation=] that embeds a -self-asserted [=verifiable credential=] that holds [=claims=] about the +self-asserted [=verifiable credential=] holding [=claims=] about the [=verifiable presentation=]. It is secured using the same mechanism as the [=verifiable presentation=].

    @@ -4768,7 +4769,7 @@

    Problem Details

    When an implementation detects an anomaly while processing a document, a ProblemDetails object can be used to report the issue to other -software systems. The interface for these types of objects follows [[RFC9457]] +software systems. The interface for these objects follow [[RFC9457]] to encode the data. A [=ProblemDetails=] object consists of the following properties:

    @@ -5023,7 +5024,7 @@

    Personally Identifiable Information

    securing mechanism, need to be specifically designed to avoid correlation. [=Verifiable credentials=] that are specifically designed to prevent the leakage of personally identifiable information do exist. Individuals and implementers -are urged to prefer these types of credentials over ones that are not designed +are urged to prefer these credential types over ones that are not designed to protect personally identifiable information.

    @@ -5033,7 +5034,7 @@

    Identifier-Based Correlation

    [=Verifiable credentials=] might contain long-lived identifiers that could be -used to correlate individuals. These types of identifiers include [=subject=] +used to correlate individuals. These identifiers include [=subject=] identifiers, email addresses, government-issued identifiers, organization-issued identifiers, addresses, healthcare vitals, and many other sorts of long-lived identifiers. Implementers of software used by [=holders=] are advised to strive @@ -5688,8 +5689,8 @@

    Sharing Information with the Wrong Party

    -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 +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 @@ -5992,10 +5993,10 @@

    Unsigned Claims

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

    @@ -6325,7 +6326,7 @@

    Language and Base Direction

    Data publishers are strongly encouraged to read the section on Cross-Syntax Expression in the Strings on the Web: Language and Direction -Metadata document [[STRING-META]] to ensure that the expression of +Metadata document [[STRING-META]] to ensure that expressing language and base direction information is possible across multiple expression syntaxes, such as [[JSON-LD11]], [[JSON]], and CBOR [[?RFC7049]]. @@ -7100,7 +7101,7 @@

    Differences between Contexts, Types, and CredentialSchemas

    The primary purpose of the `@context` property, from a [[JSON-LD11]] perspective, is to convey the meaning of the data and term definitions of the -data in a [=verifiable credential=], in a machine readable way. The +data in a [=verifiable credential=], in a machine-readable way. The `@context` property is used to map the globally unique URLs for properties in [=verifiable credentials=] and [=verifiable presentations=] into short-form alias names, making [[JSON-LD11]] representations more @@ -7584,8 +7585,8 @@

    Revision History

  • -Update previous normative references that pointed to RFC3339 for datetime -details to now normatively reference the datetime details described in +Update previous normative references that pointed to RFC3339 for date-time +details to now normatively reference the date-time details described in XMLSCHEMA11-2 which more accurately reflects the usage in examples and libraries.