From b3cff2266c998a4e7c188c37f4cc0b872c975bff Mon Sep 17 00:00:00 2001 From: Ted Thibodeau Jr Date: Fri, 17 Nov 2023 09:58:27 -0500 Subject: [PATCH] Fix grammar, markup, source formatting across spec. --- index.html | 87 +++++++++++++++++++++++++++--------------------------- 1 file changed, 44 insertions(+), 43 deletions(-) diff --git a/index.html b/index.html index 6dfa4ae93..2f9fa88a2 100644 --- a/index.html +++ b/index.html @@ -305,7 +305,7 @@

What is a Verifiable Credential?

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 -that truth of claims encoded therein. Rather, once the authenticity and +the truth of claims encoded therein. Rather, once the authenticity and currency of a verifiable credential or verifiable presentation are established, a verifier validates the included claims using their own business rules before relying on them. Such reliance only occurs after @@ -979,7 +979,7 @@

Concrete Lifecycle Example

Pat then attempts to redeem the alumni discount. The verifier, a ticket -sales system, states that any alumni of "Example University" receives a discount +sales system, states that alumni of "Example University" receive a discount on season tickets to sporting events. Using a mobile device, Pat starts the process of purchasing a season ticket. A step in this process requests an alumni verifiable credential, and this request is routed to Pat's digital wallet. @@ -990,19 +990,19 @@

Concrete Lifecycle Example

the verifier and verified.

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

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

 {
@@ -1034,10 +1034,10 @@ 
Concrete Lifecycle Example

 
         

 The examples above are unsecured. Implementers that are interested in
-understanding more about securing Verifiable Credentials can see the
-specifications Securing Verifiable Credentials using JOSE and COSE
-[[VC-JOSE-COSE]] and Verifiable Credential Data Integrity [[VC-DATA-INTEGRITY]]
-and the "Proofs" section of the Verifiable Credential Specifications Directory
+understanding more about securing verifiable credentials can see the
+specifications [[[VC-JOSE-COSE]]]
+[[VC-JOSE-COSE]] and [[[VC-DATA-INTEGRITY]]] [[VC-DATA-INTEGRITY]]
+and the "Proofs" section of the [[[VC-SPECS]]]
 [[VC-SPECS]].
         

       
@@ -1090,8 +1090,8 @@ 
Getting Started

 so that other developers can use the same vocabulary and context to achieve
 interoperability. This process is covered in Section
 . Alternatively, developers can reuse existing vocabulary
-and context files that happen to fit their use case. They can explore the Verifiable
-Credential Specifications Directory [[VC-SPECS]] for reusable resources.
+and context files that happen to fit their use case. They can explore the
+[[[VC-SPECS]]] [[VC-SPECS]] for reusable resources.
         

 
       
@@ -1122,7 +1122,7 @@ 
Contexts

 specification, but might be useful in the future or to related work. For more
 information, see
 Section 3.1: The Context
-of the [[JSON-LD]] specification.
+of the [[[JSON-LD]]] [[JSON-LD]] specification.
         

         

 Verifiable credentials and verifiable presentations MUST include a
@@ -2473,7 +2473,7 @@ 
Data Schemas

             

 The value of the credentialSchema property MUST be one or
 more data schemas that provide verifiers with enough information to
-determine if the provided data conforms to the provided schema(s). Each
+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
@@ -2533,7 +2533,7 @@ 
Data Schemas

         

 In the example above, the issuer is specifying a
 credentialSchema, which points to a [[?VC-JSON-SCHEMA]] file that
-can be used by a verifier to determine if the
+can be used by a verifier to determine whether the
 verifiable credential is well-formed.
         

 
@@ -2578,7 +2578,7 @@ 
Data Schemas

         

 In the example above, the issuer is specifying a
 credentialSchema pointing to a means of transforming the input
-data into a format which can then be used by a verifier to determine if
+data into a format which can then be used by a verifier to determine whether
 the proof provided with the verifiable credential is well-formed.
         

 
@@ -2644,7 +2644,7 @@ 
Lifecycle Details

           
  • 
 A verifier verifies the authenticity of the presented
 verifiable presentation and verifiable credentials and
-checks any credential status
+checks any credential status (if present)
 of the verifiable credentials.
           
    • 
           
  • 
@@ -2702,12 +2702,12 @@ 
    Lifecycle Details
    
 This specification neither defines an authorization framework nor
 does it restrict the business decisions that a verifier might make
 after verifying a verifiable credential or verifiable
-  presentation. However, verifiers
-  apply their own business rules before treating any claims as valid,
-  taking into account the holder, the issuers of the
-  verifiable credentials, the claims of the
-  verifiable credentials, and its own policies.
- 
    
+presentation. Rather, verifiers
+apply their own business rules before treating any claim as valid,
+taking into account the holder, the issuer of the
+verifiable credential, the claims of the
+verifiable credential, and the verifier's own policies.
+        
    
 
         
    
 In particular, Sections  and
@@ -3041,7 +3041,7 @@ 
    Integrity of Related Resources
    
 Subresource Integrity.
         
    
         
    
-The Working Group is currently attempting to determine if cryptographic hash
+The Working Group is currently attempting to determine whether cryptographic hash
 expression formats can be unified across all of the VCWG core specifications.
 Candidates for this mechanism include `digestSRI` and `digestMultibase`. There
 are arguments for and against unification that the WG is currently debating.
@@ -3717,7 +3717,7 @@ 
    Reserved Extension Points
    
         
    
 The working group is discussing if additional extension points
 will be reserved in https://www.w3.org/ns/credentials/v2.
-
    
+

    
 The working group currently plans to only reserve extension points that
 have at least a draft specification that is being incubated in a community group.
         
    
@@ -4499,7 +4499,7 @@ 
    Personally Identifiable Information
    
 provide privacy-protecting verifiable credentials when possible. For
 example, issuing ageOver verifiable credentials instead of
 date of birth verifiable credentials when a verifier wants to
-determine if an entity is over the age of 18.
+determine whether an entity is over the age of 18.
         
    
 
         
    
@@ -4864,10 +4864,10 @@ 
    Validation
    
         
    
 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
+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 and correlate individuals without their
+enable issuers to collude to correlate individuals without their
 knowledge.
         
    
 
@@ -5558,9 +5558,9 @@ 
    Unauthorized Use
    
         
    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 for verifiers to
-also validate any claims which might be relevant, considering the source and
+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 claims which might be relevant, considering the source and
 nature of the claim as well as privilege or service for which the credential is
 presented.
         
    
@@ -5569,7 +5569,7 @@ 
    Inappropriate Use
    
 self-asserted credential carrying the necessary data might not suffice
 because it lacks validity from an authoritative medical source. To ensure the
 propriety of credential use, stakeholders are urged to assess the
-credentials' relevance and authority within the specific context of their
+credential's relevance and authority within the specific context of their
 intended application.
         
    
       
@@ -5979,9 +5979,10 @@ 
    Proofs (Signatures)
    
 resistance, which are not immediately obvious. For example, a Linked Data
 Signature created property establishes a date and time
 before which the credential should not be considered verified,
-separate from the validity period of the credential. This property describes the
-validity of the proof, not of the credential.
     The
-verificationMethod property specifies, for example, the
+distinct from the validity period of the credential. This property describes the
+validity of the proof, not of the credential.
+

    
+The verificationMethod property specifies, for example, the
 public key that can be used to verify the digital signature. Dereferencing a
 public key URL reveals information about the controller of the key, which can
 be checked against the issuer of the credential. The
@@ -5996,8 +5997,8 @@ 
    Proofs (Signatures)
    
         
    Validity Periods
    
 
         
    
-The validFrom and validUntil properties are expected
-to be within an expected range for the verifier. For example, a
+The verifier expects that the validFrom and
+validUntil properties will be within a certain range. For example, a
 verifier can check that the end of the validity period of a verifiable
 credential is not in the past. Because some credentials can be useful for
 secondary purposes even if their original validity period has expired, validity