From 062e4b3d65b3f8587e203f929085991aaaf186ef Mon Sep 17 00:00:00 2001 From: Manu Sporny Date: Tue, 1 Oct 2024 00:44:49 -0400 Subject: [PATCH] Remove spaces at end of lines. --- index.html | 40 ++++++++++++++++++++-------------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/index.html b/index.html index e92195713..95f6b14b4 100644 --- a/index.html +++ b/index.html @@ -490,7 +490,7 @@

Ecosystem Overview

three parties can use information from a logical verifiable data registry">
- The roles and information flows forming the basis for this + The roles and information flows forming the basis for this specification.
@@ -956,7 +956,7 @@

Credentials

">
Information graphs associated with a basic verifiable credential, - using an [=enveloping proof=] based on [[[VC-JOSE-COSE]]] + using an [=enveloping proof=] based on [[[VC-JOSE-COSE]]] [[?VC-JOSE-COSE]].
@@ -2002,7 +2002,7 @@

Validity Period

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 point in time that is temporally the same or +`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
@@ -4112,18 +4112,18 @@

Securing Mechanism Specifications

A securing mechanism specification that creates a new type of [=embedded proof=] -MUST specify a [=property=] that relates the [=verifiable credential=] or +MUST specify a [=property=] that relates the [=verifiable credential=] or [=verifiable presentation=] to a [=proof graph=]. The requirements on the securing mechanism are as follow:

-The last requirement means that the securing mechanism secures the [=default -graph=] and, for [=verifiable presentations=], each [=verifiable credential=] +The last requirement means that the securing mechanism secures the [=default +graph=] and, for [=verifiable presentations=], each [=verifiable credential=] of the presentation, together with their respective [=proof graphs=]. See also [[[#info-graph-vp]]] or [[[#info-graph-vp-mult-creds]]].

@@ -4288,9 +4288,9 @@

Restrictions on JSON-LD

keywords in the `@context` value are used to globally affect values in a [=verifiable credential=] or [=verifiable presentation=], such as by setting either or both of the `@base` or `@vocab` keywords. For example, setting -these values might trigger a failure in a mis-implemented JSON Schema test of -the `@context` value in an implementation that is performing [=type-specific -credential processing=] and not expecting the `@base` and/or `@vocab` value to +these values might trigger a failure in a mis-implemented JSON Schema test of +the `@context` value in an implementation that is performing [=type-specific +credential processing=] and not expecting the `@base` and/or `@vocab` value to be expressed in the `@context` value.

@@ -5805,8 +5805,8 @@

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, +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. @@ -5850,7 +5850,7 @@

Issuer Cooperation Impacts on Privacy

Security Considerations

-[=Issuers=], [=holders=], and [=verifiers=] should be aware of a number of +[=Issuers=], [=holders=], and [=verifiers=] should be aware of a number of security considerations when processing data described by this specification. Ignoring or not understanding the implications of this section can result in security vulnerabilities. @@ -5893,7 +5893,7 @@

Key Management

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 +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 @@ -5924,7 +5924,7 @@

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

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

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

Man-in-the-Middle (MITM) Attack

@@ -5994,7 +5994,7 @@

Man-in-the-Middle (MITM) Attack

Replay Attack

-A [=verifier=] might wish to limit the number of times that +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 @@ -6076,7 +6076,7 @@

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 +acquires unauthorized access to systems using the victim's [=verifiable credentials=]. Ways to mitigate this type of attack include:

@@ -6109,7 +6109,7 @@

Device Theft and Impersonation

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