From 5abaeed4aa158ef4a42e798de7dba244f4f2d0eb Mon Sep 17 00:00:00 2001 From: Manu Sporny Date: Sat, 1 Jun 2024 14:14:50 -0400 Subject: [PATCH] Add missing titles for notes. --- index.html | 101 ++++++++++++++++++++++++++++++++--------------------- 1 file changed, 61 insertions(+), 40 deletions(-) diff --git a/index.html b/index.html index 432272b8f..a2a85bda8 100644 --- a/index.html +++ b/index.html @@ -478,7 +478,7 @@

Ecosystem Overview

-

+

above provides an example ecosystem in which to ground the rest of the concepts in this specification. Other ecosystems exist, such as protected environments or proprietary systems, where @@ -947,7 +947,8 @@

Credentials

-

+

[=Credential=] identifiers can be used to identify specific instances of a [=credential=]. These identifiers could also be used for unwanted correlation. A [=holder=] wanting to minimize correlation is advised @@ -955,12 +956,14 @@

Credentials

[=credential=] identifier.

-

+

It is possible to have a [=credential=], such as a marriage certificate, containing multiple [=claims=] about different [=subjects=] that are not required to be related.

-

+

It is possible to have a [=credential=] that does not contain any [=claims=] about the [=entity=] to which the [=credential=] was issued. For example, a [=credential=] that only contains [=claims=] about a @@ -1257,7 +1260,8 @@

Contexts

This concept is further expanded on in Section .

-

+

In JSON-LD, the `@context` [=property=] can also be used to communicate other details, such as datatype information, language information, transformation rules, and so on, which are beyond the needs of this @@ -1288,7 +1292,8 @@

Identifiers

(`https://id.example/things#123`), and DIDs (`did:example:1234abcd`).

-

+

Developers should remember that identifiers might be harmful in scenarios where pseudonymity is required. Developers are encouraged to read Section carefully when considering such @@ -1340,7 +1345,8 @@

Identifiers

also known as a [=DID=].

-

+

As of this publication, [=DIDs=] are a new type of identifier that are not necessary for [=verifiable credentials=] to be useful. Specifically, [=verifiable credentials=] do not depend on [=DIDs=] and [=DIDs=] do not depend @@ -1471,7 +1477,8 @@

Types

-

+

The [=type=] system for the Verifiable Credentials Data Model is the same as for [[JSON-LD11]] and is detailed in Section 3.5: @@ -1535,7 +1542,8 @@

Types

the same URL.

-

+

Explaining how to create new types of [=verifiable credentials=] is beyond the scope of this specification. Readers that are interested in doing so are advised to read the section on @@ -1616,7 +1624,8 @@

Names and Descriptions

 for further information.

-

+

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 @@ -1863,7 +1872,8 @@

Issuer

} -

+

The value of the `issuer` [=property=] can also be a JWK (for example, `"https://example.com/keys/foo.jwk"`) or a [=DID=] (for example, `"did:example:abfe13f712120431c276e12ecab"`). @@ -1939,7 +1949,8 @@

Validity Period

} -

+

If `validFrom` and `validUntil` are not present, the [=verifiable credential=] validity period is considered valid indefinitely. In such cases, the [=verifiable credential=] is assumed to be @@ -2554,7 +2565,8 @@

Presentations Using Derived Credentials

derived from a [=verifiable credential=].

-

+

For an example of a ZKP-style [=verifiable presentation=] containing derived data instead of directly embedded [=verifiable credentials=], see Section . @@ -2720,7 +2732,8 @@

Data Schemas

-

+

The `credentialSchema` [=property=] provides an opportunity to annotate type definitions or lock them to specific versions of the vocabulary. Authors of [=verifiable credentials=] can include a static version of their @@ -2770,10 +2783,10 @@

Data Schemas

[=verifiable credential=] is well-formed.

-

+

For information about linkages to JSON Schema [[?VC-JSON-SCHEMA]] or other -optional schema validation mechanisms, see the Verifiable Credentials -Implementation Guidelines [[VC-IMP-GUIDE]] document. +optional schema validation mechanisms, see the [[[VC-IMP-GUIDE]]] document.

@@ -2934,7 +2947,8 @@

Trust Model

models studied by the Working Group, see the [[[VC-USE-CASES]]] [[VC-USE-CASES]].

-

+

The data model detailed in this specification does not imply a transitive trust model, such as that provided by more traditional Certificate Authority trust models. In the Verifiable Credentials Data Model, a [=verifier=] either @@ -3153,7 +3167,8 @@

Semantic Interoperability

seeking interoperability.

-

+

When processing the active context defined by the base JSON-LD Context document defined in this specification, compliant JSON-LD-based @@ -3363,7 +3378,8 @@

Refreshing

that does not contain public information or whose refresh service is not protected in some way.

-

+

Placing a `refreshService` [=property=] in a [=verifiable credential=] so that it is available to [=verifiers=] can remove control and consent from the [=holder=] and allow the @@ -3635,10 +3651,11 @@

Evidence

-

+

For information about how attachments and references to [=credentials=] and non-credential data might be supported by the specification, see the -Verifiable Credentials Implementation Guidelines [[VC-IMP-GUIDE]] document. +[[[VC-IMP-GUIDE]]] document. 

Evidence
   ]
 }
-

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

+In the `evidence` example above, the [=issuer=] is asserting that they have +video of the [=subject=] of the [=credential=] demonstrating the achievement.

-

+

The `evidence` [=property=] provides information that is different from and information to the securing mechanism utilized. The `evidence` [=property=] is used to express supporting information, such as documentary @@ -3804,7 +3818,8 @@

Zero-Knowledge Proofs

do not define such a request schema in this specification, but an example of one method for doing so is [[?PRES-EX]].

-

+

`credentialSchema` implementers are encouraged to consider the implications of selective disclosure credentials and provide guidance for processing depending on the construction. If a schema is not formed with @@ -4451,7 +4466,8 @@

Lists and Arrays

In general, a JSON array is ordered, while a JSON-LD array is not ordered unless that array uses the `@list` keyword.

-

+

While it is possible to use this data model without any JSON-LD processing, those who do so and make use of arrays need to be aware that unless the above guidance is followed, the order of items in an array cannot be guaranteed in @@ -4981,7 +4997,8 @@

Spectrum of Privacy

Privacy solutions are use case specific.

-

+

Even for those wanting to remain anonymous when purchasing alcohol, photo identification might still be required to provide appropriate assurance to the merchant. The merchant might not need to know your name or other details (other @@ -5397,7 +5414,8 @@

The Principle of Data Minimization

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 @@ -6233,7 +6251,8 @@

Unauthorized Use

scopes defined in the `termsOfUse` would be considered unauthorized use.

-

+

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

@@ -6439,7 +6458,8 @@

Language and Base Direction

} -

+

The text above would most likely be rendered incorrectly as left-to-right without the explicit expression of language and direction because many systems use the first character of a text string to determine its [=base direction=]. @@ -6551,10 +6571,10 @@

Credential Subject

identify a [=subject=].

-

+

For information on how authentication and WebAuthn might work with -[=verifiable credentials=], see the Verifiable Credentials Implementation -Guidelines [[VC-IMP-GUIDE]] document. +[=verifiable credentials=], see the [[[VC-IMP-GUIDE]]] document.

@@ -6607,7 +6627,8 @@

Holder

[=subject=] and [=holder=].

-

+

Validation is the process by which verifiers apply business rules to evaluate the propriety of a particular use of a [=verifiable credential=].