From 965fbbc1dd93770173e685c19f359e176ec230a9 Mon Sep 17 00:00:00 2001 From: Joe Andrieu Date: Wed, 6 Sep 2023 08:25:18 -0700 Subject: [PATCH 01/58] updated entity to include abstract nouns --- terms.html | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/terms.html b/terms.html index 4af9ad254..7e36de76d 100644 --- a/terms.html +++ b/terms.html @@ -51,9 +51,12 @@
entity
-A thing with distinct and independent existence, such as a person, -organization, or device that performs one or more roles in the ecosystem. -
+Any abstract or concrete noun that can be referenced in statements. +Entities include people, organizations, physical things, documents, +abstract concepts, numbers and strings. An entity may perform roles +in the ecosystem, if it is capable of doing so. Note that some +entities fundamentally cannot take actions, e.g., the string "abc" +cannot issue credentials.
graph
A network of information composed of subjects and their relationship @@ -62,7 +65,8 @@
holder
A role an entity might perform by possessing one or more -verifiable credentials and generating presentations from them. +verifiable credentials and generating presentations from +them. A holder is usually, but not always, a subject of the verifiable credentials they are holding. Holders store their credentials in credential repositories. From 0817aff2738c50ee28da74bbd6069730c9b7f58c Mon Sep 17 00:00:00 2001 From: Joe Andrieu Date: Thu, 14 Sep 2023 09:55:06 +0200 Subject: [PATCH 02/58] Apply suggestions from code review Thanks, TallTEd Co-authored-by: Ted Thibodeau Jr --- terms.html | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/terms.html b/terms.html index 7e36de76d..f628ecd21 100644 --- a/terms.html +++ b/terms.html @@ -51,9 +51,9 @@
entity
-Any abstract or concrete noun that can be referenced in statements. +Anything that can be referenced in statements as an abstract or concrete noun. Entities include people, organizations, physical things, documents, -abstract concepts, numbers and strings. An entity may perform roles +abstract concepts, numbers, and strings. Any entity may perform roles in the ecosystem, if it is capable of doing so. Note that some entities fundamentally cannot take actions, e.g., the string "abc" cannot issue credentials.
@@ -65,9 +65,9 @@
holder
A role an entity might perform by possessing one or more -verifiable credentials and generating presentations from +verifiable credentials and generating verifiable presentations from them. -A holder is usually, but not always, a subject of the verifiable +A holder is often, but not always, a subject of the verifiable credentials they are holding. Holders store their credentials in credential repositories.
From 941bda4e25d47989372c1e803ec70e31f5ffb202 Mon Sep 17 00:00:00 2001 From: Joe Andrieu Date: Thu, 14 Sep 2023 14:58:53 +0200 Subject: [PATCH 03/58] Update terms.html Co-authored-by: Ted Thibodeau Jr --- terms.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/terms.html b/terms.html index f628ecd21..d3dd54daf 100644 --- a/terms.html +++ b/terms.html @@ -52,7 +52,7 @@
entity
Anything that can be referenced in statements as an abstract or concrete noun. -Entities include people, organizations, physical things, documents, +Entities include but are not limited to people, organizations, physical things, documents, abstract concepts, numbers, and strings. Any entity may perform roles in the ecosystem, if it is capable of doing so. Note that some entities fundamentally cannot take actions, e.g., the string "abc" From bf6fa2cb8883eb53fa6e81c860891f164e3f89e4 Mon Sep 17 00:00:00 2001 From: Joe Andrieu Date: Sun, 1 Oct 2023 21:20:57 -0700 Subject: [PATCH 04/58] full text pass at updating validation/verification language --- index.html | 93 +++++++++++++++++++++++++++++++++++------------------- 1 file changed, 60 insertions(+), 33 deletions(-) diff --git a/index.html b/index.html index db34f17b9..889f180e0 100644 --- a/index.html +++ b/index.html @@ -305,10 +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 the truth of claims encoded therein can be evaluated; however, -the issuer can include values in the evidence property to help the verifier -apply their business logic to determine whether the claims have sufficient -veracity for their needs. +that truth of claims encoded therein. Rather, once the authenticity and currency of a Verifiable Credential or Verifiable Presentation are established, a verifier MUST validate included claims using their own business rules before relying on them. Such reliance SHOULD only occur after evaluating the issuer, the proof, the subject, and the claims, against verifier policy.

@@ -915,6 +912,9 @@

Concrete Lifecycle Example

Verification of the verifiable presentation by the verifier. +
  • + Validation by the verifier of relevant claims contained in the verifiable presentation. +

    • @@ -981,8 +981,19 @@

    Concrete Lifecycle Example

    verifiable credential. Pat selects the alumni verifiable credential, which is then composed into a verifiable presentation. The verifiable presentation is sent to -the verifier and verified. -

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

     {
   "@context": [
@@ -2371,7 +2382,7 @@ 
    Data Schemas
    
 
         
      
           
    • 
-Data verification schemas, which are used to verify that the structure
+Data verification schemas, which are used to establish that the structure
 and contents of a credential or verifiable credential conform to a
 published schema.
           
      • 
@@ -2461,12 +2472,12 @@ 
      Data Schemas
      
 In the example above, the issuer is specifying a
 credentialSchema, which points to a [[?VC-JSON-SCHEMA-2023]] file that
 can be used by a verifier to determine if the
-verifiable credential is well formed.
+verifiable credential is well-formed.
         
      
 
         
      
 For information about linkages to JSON Schema [[?VC-JSON-SCHEMA-2023]] or other
-optional verification mechanisms, see the Verifiable Credentials
+optional schema validation mechanisms, see the Verifiable Credentials
 Implementation Guidelines [[VC-IMP-GUIDE]] document.
         
      
 
@@ -2506,7 +2517,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
-the proof provided with the verifiable credential is valid.
+the proof provided with the verifiable credential is well-formed.
         
      
 
 
@@ -2541,6 +2552,7 @@ 
      Lifecycle Details
      
          verifiable data registry">
           
      
             The roles and information flows for this specification.
+            NEEDS VALIDATE
           
      
         
 
@@ -2567,10 +2579,12 @@ 
      Lifecycle Details
      
           
           
    • 
 A verifier verifies the authenticity of the presented
-verifiable presentation and verifiable credentials. This should
-include checking the credential status for revocation
+verifiable presentation and verifiable credentials and 
+checks any credential status
 of the verifiable credentials.
           
      • 
+          
    • 
+After verification, a verifier validates the relevant claims in presented verifiable credentials, using their own business logic to evaluate which issuers are appropriate for which claims and which subjects are appropriate for the requested use.
      • 
          
    • 
 An issuer might revoke a
 verifiable credential.
@@ -2593,7 +2607,7 @@ 
      Lifecycle Details
      
 
         
        
           
      1. 
-An issuer issues to a holder.
+An issuer issues a verifiable credential to a holder.
           
        2. 
           
      2. 
 The holder presents to a verifier.
@@ -2601,6 +2615,12 @@ 
        Lifecycle Details
        
           
      3. 
 The verifier verifies.
           
        4. 
+          
      4. 
+The verifier validates claims.
+          
        5. 
+          
      5. 
+The verifier applies valid claims.
+          
        6. 
         
      
 
         
      
@@ -2611,13 +2631,15 @@ 
      Lifecycle Details
      
         
      
 
         
      
-This specification also does not define an authorization framework nor the
-decisions that a verifier might make after verifying a
-verifiable credential or verifiable presentation,
-taking into account the holder, the issuers of the
-verifiable credentials, the contents of the
-verifiable credentials, and its own policies.
-        
      
+This specification also does not define an authorization framework nor 
+does it restrict the business decisions that a verifier might make
+after verifying a verifiable credential or verifiable 
+  presentation. However, it is required that verifiers MUST 
+  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.
+ 
      
 
         
      
 In particular, Sections  and
@@ -4629,14 +4651,15 @@ 
      Bearer Credentials
      
         
      
       
 
-      
      
-        
      Validity Checks
      
+      
      
+        
      Validation
      
 
         
      
-When processing verifiable credentials, verifiers are expected to
-perform many of the checks listed in Appendix  as
-well as a variety of specific business process checks. Validity checks might
-include checking:
+When processing verifiable credentials, verifiers MUST 
+evaluate any relevant claims before relying upon them. This 
+evaluation may 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  as well as a variety of specific business process checks such as:
         
      
 
         
        
@@ -4661,8 +4684,9 @@ 
        Validity Checks
        
         
        
 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 a revocation list can notify the issuer that a
-specific business is likely interacting with the holder. This could
+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
 knowledge.
         
        
@@ -5303,10 +5327,12 @@ 
        Unauthorized Use
        
         
        
         
        Inappropriate Use
        
         
        
-While valid cryptographic signatures and successful validity checks
+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. Toward the pursuit of appropriate use,
-it is crucial to consider the source and authenticity of the information. For
+are interchangeable for all contexts. It is crucial for verifiers to
+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. 
+
        
+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 the propriety of credential use,
@@ -5639,7 +5665,8 @@ 
        Proofs (Signatures)
        
 The digital signature provides a number of protections, other than tamper
 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. The
+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
 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
@@ -5658,7 +5685,7 @@ 
        Validity Periods
        
 The validFrom and validUntil properties are expected
 to be within an expected range for the verifier. For example, a
 verifier can check that the end of the validity period of a verifiable
-credential is not in the past.
+credential is not in the past. Because some credentials can be useful for secondary purposes even if their original validity period has expired, validity period, as expressed using the validFrom and validUntil properties, is always considered a component of validation, which is perforemed **after** verification.
         
        
       
      
 

From 2843e16da8278b2b7b518a1450593f2ea75997c6 Mon Sep 17 00:00:00 2001
From: Joe Andrieu 
Date: Sun, 1 Oct 2023 21:21:40 -0700
Subject: [PATCH 05/58] updated terms.html to use new validation langauge

---
 terms.html | 25 +++++++++++++++----------
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/terms.html b/terms.html
index d3dd54daf..68d3a59f0 100644
--- a/terms.html
+++ b/terms.html
@@ -127,14 +127,19 @@
 A program, such as a browser or other Web client, that mediates the
 communication between holders, issuers, and verifiers.
    -
    validation
    -
    -The assurance that a verifiable credential or a -verifiable presentation meets the needs of a verifier and other -dependent stakeholders. This specification is constrained to verifying -verifiable credentials and verifiable presentations regardless of -their usage. Validating verifiable credentials or -verifiable presentations is outside the scope of this specification. +
    validation
    +
    +The assurance that a claim from a specific issuer satisfies + the business requirements of a verifier + for a particular use. This specification defines how verifiers + verifyverifiable credentials and verifiable presentations. +
    + It also specifies that Verifiers MUST validate claims in VCs before + relying on them. However, the means for such validation vary widely and + are outside the scope of this specification. It is expected that + verifiers will trust certain issuers for certain claims and apply their + own rules to determine which claims in which credentials are suitable + for use by their systems.
    verifiable credential
    @@ -163,11 +168,11 @@
    verification
    The evaluation of whether a verifiable credential or verifiable presentation -is an authentic and timely statement of the issuer or presenter, respectively. +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 proof method 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.. +of claims encoded in the credential.
    verifier
    From f373e6cf7c85aed21afcc1a21629aaa04f2b238e Mon Sep 17 00:00:00 2001 From: gabe Date: Mon, 18 Sep 2023 09:56:16 +0200 Subject: [PATCH 06/58] address 1245 --- index.html | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/index.html b/index.html index ecb166a07..ad88dcb8c 100644 --- a/index.html +++ b/index.html @@ -5088,6 +5088,22 @@

    Issuer Cooperation Impacts on Privacy

    presentations of the credential, regardless of a verifier's inability to do so.

    +

    +In addition to aforementioned privacy protections an issuer may take, +issuers should be aware of data they leak associated with identifiers they +make use of, and claim types they use when issuing credentials. One +such example would be an issuer issuing drivers licenses, revealing which +location(s) they have jurisdiction in which in turn leaks ensitive location information +about where subjects resides. Verifiers may take advantage of this +information by requesting a credential when in fact they are interested in +which issuer your credential is associated with, and information that issuer +may have leaked. To mitigate such occurences, issuers might choose to leverage +common identifiers to mask specific location information or other sensitive metadata, +e.g. a shared issuer at a state or country level, instead of at a county, city, or town +level. Additionally, holder attestation mechanisms can be trusted by verifiers +to preserve privacy, by providing proofs that an issuer exists in a set of trusted +entities, without needing to disclose the exact issuer. +

    From a6032bd8eea360182d752a3c635cb9ec5d72f810 Mon Sep 17 00:00:00 2001 From: Gabe <7622243+decentralgabe@users.noreply.github.com> Date: Tue, 19 Sep 2023 11:08:05 +0200 Subject: [PATCH 07/58] Update index.html Co-authored-by: Ted Thibodeau Jr --- index.html | 31 +++++++++++++++++-------------- 1 file changed, 17 insertions(+), 14 deletions(-) diff --git a/index.html b/index.html index ad88dcb8c..7a7d8a8d3 100644 --- a/index.html +++ b/index.html @@ -5089,20 +5089,23 @@

    Issuer Cooperation Impacts on Privacy

    inability to do so.

    -In addition to aforementioned privacy protections an issuer may take, -issuers should be aware of data they leak associated with identifiers they -make use of, and claim types they use when issuing credentials. One -such example would be an issuer issuing drivers licenses, revealing which -location(s) they have jurisdiction in which in turn leaks ensitive location information -about where subjects resides. Verifiers may take advantage of this -information by requesting a credential when in fact they are interested in -which issuer your credential is associated with, and information that issuer -may have leaked. To mitigate such occurences, issuers might choose to leverage -common identifiers to mask specific location information or other sensitive metadata, -e.g. a shared issuer at a state or country level, instead of at a county, city, or town -level. Additionally, holder attestation mechanisms can be trusted by verifiers -to preserve privacy, by providing proofs that an issuer exists in a set of trusted -entities, without needing to disclose the exact issuer. +In addition to previously described privacy protections an issuer may take, +issuers should also be aware of data they leak associated with identifiers +and claim types they use when issuing credentials. One example of this would +be an issuer issuing drivers licenses which reveal both the location(s) in +which they have jurisdiction and the location of the subject's residence. +Verifiers may take advantage of this by requesting a credential +ostensibly to check that the subject is licensed to drive a limousine, when +in fact they are interested in metadata about the credential, such as which +issuer issued the credential, and tangential information that may have been +leaked by the issuer, such as the subject's home address. To mitigate such +leakage, issuers might choose to use common identifiers to mask specific +location information or other sensitive metadata, e.g., a shared issuer at a state +or nation level, instead of at the level of a county, city, town, or other smaller +municipality. Further, holder attestation mechanisms can be used by +verifiers to preserve privacy, by providing proofs that an issuer +exists in a set of trusted entities, without needing to disclose the exact +issuer.

    From ea5906e0d4061c40a956837205d476bc438e2669 Mon Sep 17 00:00:00 2001 From: Gabe <7622243+decentralgabe@users.noreply.github.com> Date: Mon, 25 Sep 2023 16:02:57 -0500 Subject: [PATCH 08/58] Update index.html Co-authored-by: Ted Thibodeau Jr --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 7a7d8a8d3..c449e729d 100644 --- a/index.html +++ b/index.html @@ -5089,7 +5089,7 @@

    Issuer Cooperation Impacts on Privacy

    inability to do so.

    -In addition to previously described privacy protections an issuer may take, +In addition to previously described privacy protections an issuer may use, issuers should also be aware of data they leak associated with identifiers and claim types they use when issuing credentials. One example of this would be an issuer issuing drivers licenses which reveal both the location(s) in From 79791d083bbdfdcac511a6015b48e6c1da481c6d Mon Sep 17 00:00:00 2001 From: Gabe <7622243+decentralgabe@users.noreply.github.com> Date: Tue, 26 Sep 2023 16:52:23 -0500 Subject: [PATCH 09/58] Apply suggestions from code review Co-authored-by: Manu Sporny --- index.html | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/index.html b/index.html index c449e729d..9d9508132 100644 --- a/index.html +++ b/index.html @@ -5089,19 +5089,19 @@

    Issuer Cooperation Impacts on Privacy

    inability to do so.

    -In addition to previously described privacy protections an issuer may use, -issuers should also be aware of data they leak associated with identifiers +In addition to previously described privacy protections an issuer might use, +issuers need to also be aware of data they leak associated with identifiers and claim types they use when issuing credentials. One example of this would be an issuer issuing drivers licenses which reveal both the location(s) in which they have jurisdiction and the location of the subject's residence. -Verifiers may take advantage of this by requesting a credential -ostensibly to check that the subject is licensed to drive a limousine, when +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 may have been +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 choose to use common identifiers to mask specific -location information or other sensitive metadata, e.g., a shared issuer at a state -or nation level, instead of at the level of a county, city, town, or other smaller +location information or other sensitive metadata. For example,, a shared issuer +identifier at a state or nation level, instead of at the level of a county, city, town, or other smaller municipality. Further, holder attestation mechanisms can be used by verifiers to preserve privacy, by providing proofs that an issuer exists in a set of trusted entities, without needing to disclose the exact From 0c87ee03dd4693a66b554b73ea56a9ddd80fcc52 Mon Sep 17 00:00:00 2001 From: Gabe <7622243+decentralgabe@users.noreply.github.com> Date: Fri, 29 Sep 2023 15:31:13 -0500 Subject: [PATCH 10/58] Update index.html Co-authored-by: Ted Thibodeau Jr --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 9d9508132..aaee55ea8 100644 --- a/index.html +++ b/index.html @@ -5100,7 +5100,7 @@

    Issuer Cooperation Impacts on Privacy

    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 choose to use common identifiers to mask specific -location information or other sensitive metadata. For example,, a shared issuer +location information or other sensitive metadata; for example, a shared issuer identifier at a state or nation level, instead of at the level of a county, city, town, or other smaller municipality. Further, holder attestation mechanisms can be used by verifiers to preserve privacy, by providing proofs that an issuer From d3568d71cd1872c0785c47ecc832a7784908068b Mon Sep 17 00:00:00 2001 From: "Michael B. Jones" Date: Fri, 13 Oct 2023 11:28:31 -0700 Subject: [PATCH 11/58] Remove "proof" clauses from initial examples (#1308) * Remove "proof" clauses from initial examples * Adjust title of examples --------- Co-authored-by: Orie Steele --- index.html | 54 ++++++++---------------------------------------------- 1 file changed, 8 insertions(+), 46 deletions(-) diff --git a/index.html b/index.html index aaee55ea8..ff798e5b8 100644 --- a/index.html +++ b/index.html @@ -924,7 +924,7 @@

    Concrete Lifecycle Example

    verifiable credential in a digital wallet.

    - 
    +        
     {
   // set the context, which establishes the special terms we will be using
   // such as 'issuer' and 'alumniOf'.
@@ -951,22 +951,6 @@ 
    Concrete Lifecycle Example
    
       // name of the university
       "name": "Example University"
     }
-  },
-  // digital proof that makes the credential tamper-evident
-  // see the NOTE at end of this section for more detail
-  "proof": {
-    // the type of embedded proof securing the verifiable credential
-    "type": "DataIntegrityProof",
-    // the name of the cryptographic signature suite
-    "cryptosuite": "eddsa-2022",
-    // the date the signature was created
-    "created": "2023-06-18T21:19:10Z",
-    // purpose of this proof
-    "proofPurpose": "assertionMethod",
-    // the identifier of the public key that can verify the signature
-    "verificationMethod": "https://university.example/issuers/565049#key-123",
-    // the digital signature value
-    "proofValue": "zQeVbY4oey5q2M3XKaxup3tmzN4DRFTLVqpLMweBrSxMY2xHX5XTYV8nQApmEcqaqA3Q1gVHMrXFkXJeV6doDwLWx"
   }
 }
         
    
@@ -983,7 +967,7 @@ 
    Concrete Lifecycle Example
    
 verifiable presentation. The verifiable presentation is sent to
 the verifier and verified.
         
    
-        
    +        
     {
   "@context": [
     "https://www.w3.org/ns/credentials/v2",
@@ -1006,39 +990,17 @@ 
    Concrete Lifecycle Example
    
         "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
         "name": "Example University"
       }
-    },
-    "proof": {
-      "type": "DataIntegrityProof",
-      "cryptosuite": "eddsa-2022",
-      "created": "2023-06-18T21:19:10Z",
-      "proofPurpose": "assertionMethod",
-      "verificationMethod": "https://university.example/issuers/565049#key-1",
-      "proofValue": "zQeVbY4oey5q2M3XKaxup3tmzN4DRFTLVqpLMweBrSxMY2xHX5XTYV8nQA
-        pmEcqaqA3Q1gVHMrXFkXJeV6doDwLWx"
     }
-  }],
-  // digital signature by Pat on the presentation
-  // protects against replay attacks
-  "proof": {
-    "type": "DataIntegrityProof",
-    "cryptosuite": "eddsa-2022",
-    "created": "2018-09-14T21:19:10Z",
-    "proofPurpose": "authentication",
-    "verificationMethod": "did:example:ebfeb1f712ebc6f1c276e12ec21#keys-1",
-    // 'challenge' and 'domain' protect against replay attacks
-    "challenge": "1f44d55f-f161-4938-a659-f8026467f126",
-    "domain": "4jt78h47fh47",
-    "proofValue": "zqpLMweBrSxMY2xHX5XTYV8nQAJeV6doDwLWxQeVbY4oey5q2pmEcqaqA3Q1
-      gVHMrXFkXM3XKaxup3tmzN4DRFTLV"
-  }
+  }]
 }
         
    
 
         
    
-Implementers that are interested in understanding more about the
-proof mechanism used above can learn more in Section  and by reading the following specifications:
-Data Integrity [[VC-DATA-INTEGRITY]] and the "Proofs" section of the Verifiable
+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 [[VC-SPECS]].
         
    
       

From 5536809b1f2a4e223ef3300a2b4ef65add6177ac Mon Sep 17 00:00:00 2001
From: Orie Steele 
Date: Fri, 13 Oct 2023 17:47:38 -0500
Subject: [PATCH 12/58] Remove CL Signature example (#1305)

---
 common.js  |  10 -----
 index.html | 111 ++---------------------------------------------------
 2 files changed, 4 insertions(+), 117 deletions(-)

diff --git a/common.js b/common.js
index b90283a0a..b51ca0e52 100644
--- a/common.js
+++ b/common.js
@@ -55,16 +55,6 @@ var vcwg = {
       status: "CG-DRAFT",
       publisher: "Credentials Community Group"
     },
-    "CL-SIGNATURES": {
-      title: "A Signature Scheme with Efficient Protocols",
-      href: "https://www.researchgate.net/publication/220922101_A_Signature_Scheme_with_Efficient_Protocols",
-      authors: [
-        "Jan Camenisch",
-        "Anna Lysyanskaya"
-      ],
-      status: "Peer Reviewed Paper",
-      publisher: "IBM Research"
-    },
     // aliases to known references
     "HTTP-SIGNATURES": {
       aliasOf: "http-signatures"
diff --git a/index.html b/index.html
index ff798e5b8..2208204c0 100644
--- a/index.html
+++ b/index.html
@@ -598,9 +598,6 @@ 
    Use Cases and Requirements
    
           
  • 
 Securing Verifiable Credentials using Data Integrity Proofs [[VC-DATA-INTEGRITY]].
           
    • 
-          
  • 
-Camenisch-Lysyanskaya Zero-Knowledge Proofs [[?CL-SIGNATURES]].
-          
    • 
         
 
         
    
@@ -3508,68 +3505,11 @@ 
    Zero-Knowledge Proofs
    
 The examples below highlight how the data model might be used to issue and
 present verifiable credentials in zero-knowledge.
         
    
-        
    
-The provided examples will either be significantly re-written to demonstrate how
-to secure a verifiable credential using a normatively defined method that
-enable zero knowledge proofs, or they will be removed.
-        
    
-        
    
-The following example shows one method of using verifiable credentials in
-zero-knowledge. It makes use of a Camenisch-Lysyanskaya Signature
-[[?CL-SIGNATURES]], which allows the presentation of the verifiable
-credential in a way that supports the privacy of the
-holder and subject through the use of selective disclosure of the
-verifiable credential values. Some other cryptographic systems which rely
-upon zero-knowledge proofs to selectively disclose attributes can be found in the
-Verifiable Credential Specifications Directory [[?VC-SPECS]] as well.
-        
    
-
-        
    -{
-  "@context": [
-    "https://www.w3.org/ns/credentials/v2",
-    "https://www.w3.org/ns/credentials/examples/v2"
-  ],
-  "type": ["VerifiableCredential", "ExampleDegreeCredential"],
-  "credentialSchema": {
-    "id": "did:example:cdf:35LB7w9ueWbagPL94T9bMLtyXDj9pX5o",
-    "type": "did:example:schema:22KpkXgecryx9k7N6XN1QoN3gXwBkSU8SfyyYQG"
-  },
-  "issuer": "did:example:Wz4eUg7SetGfaUVCn8U9d62oDYrUJLuUtcy619",
-  "credentialSubject": {
-    "givenName": "Jane",
-    "familyName": "Doe",
-    "degree": {
-      "type": "ExampleBachelorDegree",
-      "name": "Bachelor of Science and Arts",
-      "college": "College of Engineering"
-    }
-  },
-  "proof": {
-    "type": "CLSignature2019",
-    "issuerData": "5NQ4TgzNfSQxoLzf2d5AV3JNiCdMaTgm...BXiX5UggB381QU7ZCgqWivUmy4D",
-    "attributes": "pPYmqDvwwWBDPNykXVrBtKdsJDeZUGFA...tTERiLqsZ5oxCoCSodPQaggkDJy",
-    "signature": "8eGWSiTiWtEA8WnBwX4T259STpxpRKuk...kpFnikqqSP3GMW7mVxC4chxFhVs",
-    "signatureCorrectnessProof": "SNQbW3u1QV5q89qhxA1xyVqFa6jCrKwv...dsRypyuGGK3RhhBUvH1tPEL8orH"
-  }
-}
-        
    
-        
    
-The example above provides the verifiable credential definition by using
-the credentialSchema property and a specific proof that is
-usable in the Camenisch-Lysyanskaya Zero-Knowledge Proof system.
-        
    
-
-        
    
-The next example utilizes the verifiable credential above to generate a
-new derived verifiable credential with a privacy-preserving proof. The
-derived verifiable credential is then placed in a
-verifiable presentation, so that the verifiable credential
-discloses only the claims and additional credential metadata that the
-holder intended. To do this, all of the following requirements are
-expected to be met:
+        
    
+Examples of leveraging vc-di-bbs,
+will be added here in the future, or this section will be removed.
         
    
-
+        
         
 
-        
    -{
-  "@context": [
-    "https://www.w3.org/ns/credentials/v2",
-    "https://www.w3.org/ns/credentials/examples/v2"
-  ],
-  "type": "VerifiablePresentation",
-  "verifiableCredential": [
-    {
-      "@context": [
-        "https://www.w3.org/ns/credentials/v2",
-        "https://www.w3.org/ns/credentials/examples/v2"
-      ],
-      "type": ["VerifiableCredential", "ExampleDegreeCredential"],
-      "credentialSchema": {
-        "id": "did:example:cdf:35LB7w9ueWbagPL94T9bMLtyXDj9pX5o",
-        "type": "did:example:schema:22KpkXgecryx9k7N6XN1QoN3gXwBkSU8SfyyYQG"
-      },
-      "issuer": "did:example:Wz4eUg7SetGfaUVCn8U9d62oDYrUJLuUtcy619",
-      "credentialSubject": {
-        "degreeType": "ExampleBachelorDegree",
-        "degreeSchool": "College of Engineering"
-      },
-      "proof": {
-        "type": "AnonCredDerivedCredentialv1",
-        "primaryProof": "cg7wLNSi48K5qNyAVMwdYqVHSMv1Ur8i...Fg2ZvWF6zGvcSAsym2sgSk737",
-        "nonRevocationProof": "mu6fg24MfJPU1HvSXsf3ybzKARib4WxG...RSce53M6UwQCxYshCuS3d2h"
-      }
-  }],
-  "proof": {
-    "type": "AnonCredPresentationProofv1",
-    "proofValue": "DgYdYMUYHURJLD7xdnWRinqWCEY5u5fK...j915Lt3hMzLHoPiPQ9sSVfRrs1D"
-  }
-}
-        
    
         
    
           Verifiable
@@ -3662,14 +3567,6 @@ <h3>Zero-Knowledge Proofs</h3>
           </figcaption>
         </figure>
 
-        <p class=
-Important details regarding the format for the credential definition and
-of the proofs are omitted on purpose because they are outside of the scope of
-this document. The purpose of this section is to guide implementers who want to
-extend verifiable credentials and verifiable presentations to
-support zero-knowledge proof systems.
-        
    
-
       
 
       
    

From 5d8849b546bca192620b4220742e346fa4539935 Mon Sep 17 00:00:00 2001
From: Ivan Herman 
Date: Mon, 16 Oct 2023 15:18:59 +0200
Subject: [PATCH 13/58] Add `relatedResource` and `digestSRI` to the
 vocabulary.

* Added anchors to the `digestSRI` and `relatedResource` terms (to be used by the vocabulary)
* Added a section to define the `sristring` datatype
* Added the `digestSRI`, `relatedResource`, `mediaType` to the v2 context
* Added the `digestSRI` and `relatedResource` properties, as well as the `sriString` datatype to `vocabulary.yml`
* Added a section on datatypes in the `template.html` file for the vocabulary generation
* Added the `vocabulary.drawio` file to the repository and expanded the `README.md` file in the the corresponding directory
* Updated the diagram, finalized the vocabulary (there were syntax errors)
* `sristring` -> `sriString`

---------

Co-authored-by: Ted Thibodeau Jr 
Co-authored-by: David I. Lehn 
---
 .gitignore                             |   3 +-
 contexts/credentials/v2                |  12 +
 index.html                             |  52 ++-
 vocab/credentials/v2/README.md         |   6 +-
 vocab/credentials/v2/template.html     |  28 +-
 vocab/credentials/v2/vocabulary.drawio | 501 +++++++++++++++++++++++++
 vocab/credentials/v2/vocabulary.svg    | 460 +++++++++++++----------
 vocab/credentials/v2/vocabulary.yml    |  26 +-
 8 files changed, 876 insertions(+), 212 deletions(-)
 create mode 100644 vocab/credentials/v2/vocabulary.drawio

diff --git a/.gitignore b/.gitignore
index 17be60e94..c02751408 100644
--- a/.gitignore
+++ b/.gitignore
@@ -8,8 +8,9 @@
 .vscode
 .idea
 .gitignore
+*.bkp
 
 **/node_modules
 **/.DS_Store
 **/.vscode
-**/package-lock.json
\ No newline at end of file
+**/package-lock.json
diff --git a/contexts/credentials/v2 b/contexts/credentials/v2
index db71e8ca7..7564e7ab8 100644
--- a/contexts/credentials/v2
+++ b/contexts/credentials/v2
@@ -66,6 +66,14 @@
       "@id": "https://www.iana.org/assignments/jwt#..."
     },
 
+    "digestSRI": {
+      "@id": "https://www.w3.org/2018/credentials#digestSRI",
+      "@type": "https://www.w3.org/2018/credentials#sriString"
+    },
+    "mediaType": {
+      "@id": "https://schema.org/encodingFormat"
+    },
+
     "VerifiableCredential": {
       "@id": "https://www.w3.org/2018/credentials#VerifiableCredential",
       "@context": {
@@ -149,6 +157,10 @@
         "confidenceMethod": {
           "@id": "https://www.w3.org/2018/credentials#confidenceMethod",
           "@type": "@id"
+        },
+        "relatedResource": {
+          "@id": "https://www.w3.org/2018/credentials#relatedResource",
+          "@type": "@id"
         }
       }
     },
diff --git a/index.html b/index.html
index 2208204c0..25980785a 100644
--- a/index.html
+++ b/index.html
@@ -2931,7 +2931,7 @@ 
    Integrity of Related Resources
    
         
    
 To validate that a resource referenced by a verifiable credential is the
 same at verification time as it is at issuing time, an implementer MAY include a
-property named relatedResource that stores an array of objects that
+property named relatedResource that stores an array of objects that
 describe additional integrity metadata about each resource referenced by the
 verifiable credential. If relatedResource is present, there
 MUST be an object in the array for each remote resource for each context used in
@@ -2945,7 +2945,7 @@ 
    Integrity of Related Resources
    
         
    
 Each object in the relatedResource array MUST contain the
 following: the [[URL]] to the resource named id and the
-digestSRI information for the resource constructed using the method
+digestSRI information for the resource constructed using the method
 specified in Subresource
 Integrity.
         
    
@@ -6051,6 +6051,54 @@ 
    Vocabularies
    
         
 
       
    
+
+      
    
+        
    Datatypes
    
+        
    
+          This section defines datatypes that are used by this specification.
+        
    
+
+        
    
+            
    The sriString Datatype
    
+        
+            
    
+              The string provides the integrity information for a resource using the method specified in the [[SRI]] specification.
+            
    
+        
+            
    
+              The `sriString` datatype is defined as follows:
+            
    
+        
+            
    
+              
    The URL denoting this datatype
    
+              
    
+                `https://www.w3.org/2018/credentials#sriString`
+              
    
+              
    The lexical space
    
+              
    
+                See the ABNF grammar, defining the `integrity` 
+                attribute in the [[SRI]] specification, for the restrictions on the string format.
+              
    
+              
    The value space
    
+              
    
+                A (possibly empty) list of (alg,val) pairs, where alg identifies a hash function, and val is an integer as a standard mathematical concept.
+              
    
+              
    The lexical-to-value mapping
    
+              
    
+                Any element of the lexical space is mapped to the value space by   
+                following the parse metadata algorithm based
+                on the ABNF grammar in the [[SRI]] specification.
+              
    
+              
    The canonical mapping
    
+              
    
+                The canonical mapping consists of the lexical-to-value mapping.
+              
    
+            
    
+        
    
+
+
+      
    
+
       
    
         
    Differences between Contexts, Types, and CredentialSchemas
    
 
diff --git a/vocab/credentials/v2/README.md b/vocab/credentials/v2/README.md
index ba2867147..fd2edd84b 100644
--- a/vocab/credentials/v2/README.md
+++ b/vocab/credentials/v2/README.md
@@ -9,5 +9,9 @@ The generation of the final files is done via a github action (see `/.github/wor
 
 - `Readme.md`: this file.
 - `vocabulary.yml`: the core vocabulary specification. _Any change on the vocabulary must be made by modifying this file;_ see the separate [description](https://github.com/w3c/yml2vocab) of the underlying YAML format.
-- `template.json`: an HTML template file used by the script; it is the skeleton of the final HTML format based on [ReSpec](https://respec.org/docs/). If the file is modified, care should be taken not to change the core structure and the various, possibly empty, HTML elements with `@id` values. The script fills those elements with content when generating the `vocabulary.html` file.
+- `vocabulary.drawio`: the vocabulary diagram in the [draw.io](https://www.drawio.com/) format. _Any change on the vocabulary diagram must be made by modifying this file._ 
+  
+    The corresponding application can be downloaded and used directly, or added to Google Docs. Note that, due to some bug in the software the exported SVG file must be ran through a [post-processing script](https://github.com/iherman/drawio-svg/), to be downloaded and run separately.
+- `vocabulary.svg`: the SVG file for the vocabulary, generated from `vocabulary.drawio`.
+- `template.json`: an HTML template file used by the script; it is the skeleton of the final HTML format based on [ReSpec](https://respec.org/docs/). If the file is modified, care should be taken not to change the core structure and the various, possibly empty, HTML elements with `@id` values. The script fills those elements with content when generating the `vocabulary.html` file (and removes any sections that remain empty after processing).
 
diff --git a/vocab/credentials/v2/template.html b/vocab/credentials/v2/template.html
index 455c0700d..e2cdce94a 100644
--- a/vocab/credentials/v2/template.html
+++ b/vocab/credentials/v2/template.html
@@ -14,7 +14,7 @@
         const retval = content
           .replace('Class definitions
         
    Property definitions
    
       
    
 
+      
    
+        
    Datatype definitions
    
+      
    
+
       
    
         
    Definitions for individuals
    
       
    
@@ -220,6 +224,10 @@ 
    Reserved classes
    
         
    Reserved properties
    
       
 
+      
    
+        
    Reserved datatype definitions
    
+      
    
+
       
    
         
    Reserved individuals
    
       
    
@@ -240,6 +248,10 @@ 
    Deprecated classes
    
         
    Deprecated properties
    
       
 
+      
    
+        
    Deprecated properties
    
+      
    
+
       
    
         
    Deprecated individuals
    
       
    
@@ -270,13 +282,14 @@ 
    Diagram description
    
         
    
         
    
           The "VerifiableCredential" ellipse is connected to the "credentialSchema", "credentialStatus",
-          "credentialSubject", "issuer", "evidence", "refreshService", "renderMethod", and "confidenceMethod"
-          boxes, through connecting lines styled as Domain Of. 
+          "credentialSubject", "issuer", "relatedResource", "evidence", "refreshService", "renderMethod", 
+          and "confidenceMethod" boxes, through connecting lines styled as Domain Of. 
           It is also connected to the crossing point circle with a similar connecting line,
           styled as Domain Of.
           The "VerifiablePresentation" ellipse is connected to the crossing point circle, as well as the "holder" 
           and "verifiableCredential" boxes, with a similar connecting line, styled as Domain Of. 
-          The crossing point circle is connected to the "termsOfUse", "validFrom", and "validUntil" boxes with a connecting line styled as Domain Of.
+          The crossing point circle is connected to the "termsOfUse", "validFrom", and "validUntil" boxes with a 
+          connecting line styled as Domain Of.
           The "verifiableCredential" box is connected to the "VerifiableCredentialGraph" ellipse with a connecting
           line styled as Range. 
           The "JsonSchemaCredential" ellipse is connected to the "VerifiableCredential" ellipse with a 
@@ -292,13 +305,18 @@ 
    Diagram description
    
           connected to those Class ellipses, with connecting lines styled as Range. 
         
    
         
    
-          Finally, the "CredentialSchema" ellipse is connected to one more ellipse, on the far right
+          The "CredentialSchema" ellipse is connected to one more ellipse, on the far right
           side of the diagram, styled as Class and labeled as "JsonSchema", with a connecting line
           styled as Superclass. This "JsonSchema" ellipse is also connected to a Property box
           labeled as "jsonSchema", through a connector line styled as Domain Of. This "jsonSchema"
           box is connected to a Datatype shape labeled as "rdf:JSON", with a connecting line
           styled as Range. 
         
    
+        
    
+          Finally, on the lower far right side of the diagram, there is a separate Property box labeled as 
+          "digestSRI", connected to a Datatype shape labeled as "sristring", with a connecting line 
+          styled as Range.
+        
    
       
     
 
diff --git a/vocab/credentials/v2/vocabulary.drawio b/vocab/credentials/v2/vocabulary.drawio
new file mode 100644
index 000000000..3b7b22c27
--- /dev/null
+++ b/vocab/credentials/v2/vocabulary.drawio
@@ -0,0 +1,501 @@
+
+  
+    
+      
+        
+        
+        
+          
+            
+          
+        
+        
+          
+            
+          
+        
+        
+          
+            
+          
+        
+        
+          
+            
+          
+        
+        
+          
+            
+            
+            
+              
+            
+          
+        
+        
+          
+            
+            
+          
+        
+        
+          
+        
+        
+          
+            
+            
+            
+              
+            
+          
+        
+        
+          
+            
+          
+        
+        
+          
+            
+          
+        
+        
+          
+            
+          
+        
+        
+          
+            
+          
+        
+        
+          
+            
+          
+        
+        
+          
+            
+          
+        
+        
+          
+            
+          
+        
+        
+          
+            
+          
+        
+        
+          
+            
+          
+        
+        
+          
+            
+          
+        
+        
+          
+            
+          
+        
+        
+          
+            
+          
+        
+        
+          
+            
+          
+        
+        
+          
+            
+          
+        
+        
+          
+            
+            
+          
+        
+        
+          
+            
+            
+            
+              
+              
+            
+          
+        
+        
+          
+            
+            
+            
+              
+            
+          
+        
+        
+          
+            
+            
+            
+              
+            
+          
+        
+        
+          
+            
+            
+            
+              
+            
+          
+        
+        
+          
+            
+            
+            
+              
+            
+          
+        
+        
+          
+            
+            
+            
+              
+            
+          
+        
+        
+          
+            
+            
+            
+              
+            
+          
+        
+        
+          
+            
+            
+            
+              
+            
+          
+        
+        
+          
+        
+        
+          
+            
+            
+            
+              
+            
+          
+        
+        
+          
+            
+            
+            
+              
+            
+          
+        
+        
+          
+            
+            
+          
+        
+        
+          
+            
+            
+            
+              
+            
+          
+        
+        
+          
+            
+            
+            
+              
+            
+          
+        
+        
+          
+            
+          
+        
+        
+          
+            
+          
+        
+        
+          
+            
+          
+        
+        
+          
+            
+          
+        
+        
+          
+            
+          
+        
+        
+          
+            
+          
+        
+        
+          
+            
+          
+        
+        
+          
+            
+            
+          
+        
+        
+          
+            
+            
+          
+        
+        
+          
+            
+            
+          
+        
+        
+          
+            
+            
+          
+        
+        
+          
+            
+            
+          
+        
+        
+          
+            
+            
+          
+        
+        
+          
+            
+            
+          
+        
+        
+          
+            
+          
+        
+        
+          
+            
+            
+            
+              
+            
+          
+        
+        
+          
+        
+        
+          
+        
+        
+          
+        
+        
+          
+        
+        
+          
+            
+          
+        
+        
+          
+        
+        
+          
+        
+        
+          
+            
+            
+          
+        
+        
+          
+        
+        
+          
+        
+        
+          
+        
+        
+          
+        
+        
+          
+        
+        
+          
+            
+            
+          
+        
+        
+          
+        
+        
+          
+        
+        
+          
+            
+            
+            
+              
+              
+            
+          
+        
+        
+          
+        
+        
+          
+        
+        
+          
+            
+            
+          
+        
+        
+          
+        
+        
+          
+        
+        
+          
+        
+        
+          
+        
+        
+          
+        
+        
+          
+        
+        
+          
+            
+          
+        
+        
+          
+        
+        
+          
+        
+        
+          
+            
+          
+        
+        
+          
+            
+            
+          
+        
+        
+          
+            
+          
+        
+        
+          
+            
+            
+          
+        
+        
+          
+            
+          
+        
+        
+          
+            
+            
+            
+              
+            
+          
+        
+        
+          
+            
+          
+        
+        
+          
+            
+          
+        
+        
+          
+            
+            
+          
+        
+      
+    
+  
+
diff --git a/vocab/credentials/v2/vocabulary.svg b/vocab/credentials/v2/vocabulary.svg
index 23504055e..b39e02c22 100644
--- a/vocab/credentials/v2/vocabulary.svg
+++ b/vocab/credentials/v2/vocabulary.svg
@@ -1,13 +1,13 @@
 
-    
-        
+    
+        
         
             
                 
    
                     
    
                         
    
                             
-                                
+                                
                                     verifiableCredential
                                 
                             
@@ -18,15 +18,15 @@
             verifiableCredential
         
     
-    
-        
+    
+        
         
             
                 
    
                     
    
                         
    
                             
-                                
+                                
                                     VerifiableCredential
                                 
                             
@@ -37,15 +37,15 @@
             VerifiableCredential
         
     
-    
-        
+    
+        
         
             
                 
    
                     
    
                         
    
                             
-                                
+                                
                                     JsonSchemaCredential
                                 
                             
@@ -56,15 +56,15 @@
             JsonSchemaCredential
         
     
-    
-        
+    
+        
         
             
                 
    
                     
    
                         
    
                             
-                                
+                                
                                     VerifiablePresentation
                                 
                             
@@ -81,15 +81,15 @@
     
     
     
-    
-        
+    
+        
         
             
                 
    
                     
    
                         
    
                             
-                                
+                                
                                     VerifiableCredentialGraph
                                 
                             
@@ -102,15 +102,15 @@
     
     
     
-    
-        
+    
+        
         
             
                 
    
                     
    
                         
    
                             
-                                
+                                
                                     credentialSchema
                                 
                             
@@ -121,15 +121,15 @@
             credentialSchema
         
     
-    
-        
+    
+        
         
             
-                
    
+                
    
                     
    
                         
    
                             
-                                
+                                
                                     credentialStatus
                                 
                             
@@ -137,18 +137,18 @@
                     
    
                 
    
             
-            credentialStatus
+            credentialStatus
         
         
-    
-        
+    
+        
         
             
-                
    
+                
    
                     
    
                         
    
                             
-                                
+                                
                                     credentialSubject
                                 
                             
@@ -156,18 +156,18 @@
                     
    
                 
    
             
-            credentialSubject
+            credentialSubject
         
         
-    
-        
+    
+        
         
             
-                
    
+                
    
                     
    
                         
    
                             
-                                
+                                
                                     issuer
                                 
                             
@@ -175,18 +175,18 @@
                     
    
                 
    
             
-            issuer
+            issuer
         
         
-    
-        
+    
+        
         
             
-                
    
+                
    
                     
    
                         
    
                             
-                                
+                                
                                     evidence
                                 
                             
@@ -194,18 +194,18 @@
                     
    
                 
    
             
-            evidence
+            evidence
         
         
-    
-        
+    
+        
         
             
-                
    
+                
    
                     
    
                         
    
                             
-                                
+                                
                                     refreshService
                                 
                             
@@ -213,18 +213,18 @@
                     
    
                 
    
             
-            refreshService
+            refreshService
         
         
-    
-        
+    
+        
         
             
-                
    
+                
    
                     
    
                         
    
                             
-                                
+                                
                                     renderMethod
                                 
                             
@@ -232,18 +232,18 @@
                     
    
                 
    
             
-            renderMethod
+            renderMethod
         
         
-    
-        
+    
+        
         
             
-                
    
+                
    
                     
    
                         
    
                             
-                                
+                                
                                     confidenceMethod
                                 
                             
@@ -251,18 +251,18 @@
                     
    
                 
    
             
-            confidenceMethod
+            confidenceMethod
         
         
-    
-        
+    
+        
         
             
-                
    
+                
    
                     
    
                         
    
                             
-                                
+                                
                                     termsOfUse
                                 
                             
@@ -270,18 +270,18 @@
                     
    
                 
    
             
-            termsOfUse
+            termsOfUse
         
         
-    
-        
+    
+        
         
             
-                
    
+                
    
                     
    
                         
    
                             
-                                
+                                
                                     validFrom
                                 
                             
@@ -289,18 +289,18 @@
                     
    
                 
    
             
-            validFrom
+            validFrom
         
         
-    
-        
+    
+        
         
             
-                
    
+                
    
                     
    
                         
    
                             
-                                
+                                
                                     validUntil
                                 
                             
@@ -308,18 +308,18 @@
                     
    
                 
    
             
-            validUntil
+            validUntil
         
         
-    
-        
+    
+        
         
             
                 
    
                     
    
                         
    
                             
-                                
+                                
                                     holder
                                 
                             
@@ -334,40 +334,40 @@
     
     
     
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-        
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+        
         
             
-                
    
+                
    
                     
    
                         
    
                             
-                                
+                                
                                     RenderMethod
                                 
                             
@@ -375,18 +375,18 @@
                     
    
                 
    
             
-            RenderMethod
+            RenderMethod
         
         
-    
-        
+    
+        
         
             
-                
    
+                
    
                     
    
                         
    
                             
-                                
+                                
                                     CredentialEvidence
                                 
                             
@@ -394,18 +394,18 @@
                     
    
                 
    
             
-            CredentialEvidence
+            CredentialEvidence
         
         
-    
-        
+    
+        
         
             
-                
    
+                
    
                     
    
                         
    
                             
-                                
+                                
                                     RefreshService
                                 
                             
@@ -413,18 +413,18 @@
                     
    
                 
    
             
-            RefreshService
+            RefreshService
         
         
-    
-        
+    
+        
         
             
-                
    
+                
    
                     
    
                         
    
                             
-                                
+                                
                                     ConfidenceMethod
                                 
                             
@@ -432,18 +432,18 @@
                     
    
                 
    
             
-            ConfidenceMethod
+            ConfidenceMethod
         
         
-    
-        
+    
+        
         
             
-                
    
+                
    
                     
    
                         
    
                             
-                                
+                                
                                     TermsOfUse
                                 
                             
@@ -451,18 +451,18 @@
                     
    
                 
    
             
-            TermsOfUse
+            TermsOfUse
         
         
-    
-        
+    
+        
         
             
                 
    
                     
    
                         
    
                             
-                                
+                                
                                     CredentialSchema
                                 
                             
@@ -473,15 +473,15 @@
             CredentialSchema
         
     
-    
-        
+    
+        
         
             
                 
    
                     
    
                         
    
                             
-                                
+                                
                                     CredentialStatus
                                 
                             
@@ -494,27 +494,27 @@
     
     
     
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-    
-        
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+    
+        
         
             
                 
    
                     
    
                         
    
                             
-                                
+                                
                                     JsonSchema
                                 
                             
@@ -528,16 +528,16 @@
     
     
     
-    
+    
     
     
-    
-    
+    
+    
     
         
             
    
                 
    
-                    
    
+                    
    
                         
                             Datatype
                         
@@ -548,14 +548,14 @@
         Datatype
     
     
-    
-    
-    
+    
+    
+    
     
         
             
    
                 
    
-                    
    
+                    
    
                         
                             Graph containment
                         
@@ -565,29 +565,14 @@
         
         Graph con...
     
-    
-    
-    
-    
-        
-            
    
-                
    
-                    
    
-                        Class
-                    
    
-                
    
-            
    
-            
-        Class
-        
     
-    
-    
+    
+    
     
         
             
    
                 
    
-                    
    
+                    
    
                         Property
                     
    
                 
    
@@ -596,14 +581,14 @@
         Property
     
     
-    
-    
-    
+    
+    
+    
     
         
             
    
                 
    
-                    
    
+                    
    
                         Superclass
                     
    
                 
    
@@ -612,14 +597,14 @@
         Superclass
     
     
-    
-    
-    
+    
+    
+    
     
         
             
    
                 
    
-                    
    
+                    
    
                         Domain
                         
    
                         of
@@ -630,14 +615,14 @@
         Domain...
     
     
-    
-    
-    
+    
+    
+    
     
         
             
    
                 
    
-                    
    
+                    
    
                         Range
                     
    
                 
    
@@ -646,13 +631,13 @@
         Range
     
     
-    
-    
+    
+    
     
         
             
    
                 
    
-                    
    
+                    
    
                         Reserved
                         
    
                         class
@@ -663,12 +648,12 @@
         Reserved...
     
     
-    
+    
     
         
             
    
                 
    
-                    
    
+                    
    
                         Reserved
                         
    
                         property
@@ -678,18 +663,32 @@
         
         Reserved...
     
-    
-        
+    
+        
     
-    
-        
+    
+    
+    
+        
+            
    
+                
    
+                    
    
+                        Class
+                    
    
+                
    
+            
    
+            
+        Class
+        
+        
+        
         
             
                 
    
                     
    
-                        
    
+                        
    
                             
-                                
+                                
                                     jsonSchema
                                 
                             
@@ -700,25 +699,82 @@
             jsonSchema
         
     
-    
-    
-    
-        
+    
+    
+    
+    
+        
+            
    
+                
    
+                    
    
+                        
+                            rdf:JSON
+                        
+                    
    
+                
    
+            
    
+            
+        rdf:JSON
+        
+    
+    
+        
+        
+        
+            
+                
    
+                    
    
+                        
    
+                            
+                                
+                                    relatedResource
+                                
+                            
+                        
    
+                    
    
+                
    
+                
+            relatedResource
+            
+        
+    
+    
+    
+        
         
             
-                
    
+                
    
                     
    
-                        
    
-                            
-                                rdf:JSON
+                        
    
+                            
+                                
+                                    digestSRI
+                                
+                            
+                        
    
+                    
    
+                
    
+            
+            digestSRI
+        
+        
+        
+        
+        
+            
+                
    
+                    
    
+                        
    
+                            
+                                sriString
                             
                         
    
                     
    
                 
    
                 
-            rdf:JSON
+            sriString
             
         
-    
-    
+    
+    
 
diff --git a/vocab/credentials/v2/vocabulary.yml b/vocab/credentials/v2/vocabulary.yml
index 27cfcc280..d39a0c29a 100644
--- a/vocab/credentials/v2/vocabulary.yml
+++ b/vocab/credentials/v2/vocabulary.yml
@@ -1,6 +1,6 @@
 vocab:
   - id: cred
-    value: https://w3.org/2018/credentials#
+    value: https://www.w3.org/2018/credentials#
 
 # prefix:
 #   - id: odrl
@@ -99,6 +99,14 @@ property:
     range: IRI
     comment: An entity about which claims are made.
 
+  - id: digestSRI
+    label: Subresource integrity digest
+    defined_by: https://www.w3.org/TR/vc-data-model-2.0/#defn-digestSRI
+    range: cred:sriString
+    see_also: 
+      - label: Subresource Integrity Metadata
+        url:  https://www.w3.org/TR/SRI/#the-integrity-attribute
+    
   - id: evidence
     label: Evidence
     defined_by: https://www.w3.org/TR/vc-data-model-2.0/#defn-evidence
@@ -153,6 +161,12 @@ property:
     status: reserved
     range: cred:RenderMethod
 
+  - id: relatedResource
+    label: Related resource
+    domain: cred:VerifiableCredential
+    range: IRI
+    defined_by: https://www.w3.org/TR/vc-data-model-2.0/#defn-relatedResource
+
   - id: termsOfUse
     label: Terms of use
     defined_by: https://www.w3.org/TR/vc-data-model-2.0/#defn-termsOfUse
@@ -178,3 +192,13 @@ property:
     domain: cred:VerifiablePresentation
     range: cred:VerifiableCredentialGraph
     comment: The value of this property identifies a Verifiable credential graph. (Informally, it indirectly identifies a Verifiable credential contained in a separate graph.)
+
+datatype:
+  - id: sriString
+    label: Datatype for digest SRI values
+    upper_value: xsd:string
+    defined_by: https://www.w3.org/TR/vc-data-model-2.0/#the-sristring-datatype
+    see_also: 
+      - label: Subresource Integrity Metadata
+        url:  https://www.w3.org/TR/SRI/#the-integrity-attribute
+ 

From 87a4db3ac61e55c1bec93f5553fe79893b1d33c0 Mon Sep 17 00:00:00 2001
From: Manu Sporny 
Date: Wed, 18 Oct 2023 09:45:05 -0400
Subject: [PATCH 14/58] Remove extraneous trailing spaces.

---
 index.html | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/index.html b/index.html
index 25980785a..c61928413 100644
--- a/index.html
+++ b/index.html
@@ -3509,7 +3509,7 @@ 
    Zero-Knowledge Proofs
    
 Examples of leveraging vc-di-bbs,
 will be added here in the future, or this section will be removed.
         
    
-        
+
         
      
           
    • 
 Each derived verifiable credential within a verifiable
@@ -4958,8 +4958,8 @@ 
      Issuer Cooperation Impacts on Privacy
      
 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 choose to use common identifiers to mask specific 
-location information or other sensitive metadata; for example, a shared issuer 
+leakage, issuers might choose to use common identifiers to mask specific
+location information or other sensitive metadata; for example, a shared issuer
 identifier at a state or nation level, instead of at the level of a county, city, town, or other smaller
 municipality. Further, holder attestation mechanisms can be used by
 verifiers to preserve privacy, by providing proofs that an issuer
@@ -6060,15 +6060,15 @@ 
      Datatypes
      
 
         
      
             
      The sriString Datatype
      
-        
+
             
      
               The string provides the integrity information for a resource using the method specified in the [[SRI]] specification.
             
      
-        
+
             
      
               The `sriString` datatype is defined as follows:
             
      
-        
+
             
      
               
      The URL denoting this datatype
      
               
      
@@ -6076,7 +6076,7 @@ 
      The sriString Datatype
      
               
      
               
      The lexical space
      
               
      
-                See the ABNF grammar, defining the `integrity` 
+                See the ABNF grammar, defining the `integrity`
                 attribute in the [[SRI]] specification, for the restrictions on the string format.
               
      
               
      The value space
      
@@ -6085,7 +6085,7 @@ 
      The sriString Datatype
      
               
               
      The lexical-to-value mapping
      
               
      
-                Any element of the lexical space is mapped to the value space by   
+                Any element of the lexical space is mapped to the value space by
                 following the parse metadata algorithm based
                 on the ABNF grammar in the [[SRI]] specification.
               
      

From 9234fb4ebee500ee1a7fdf883b751a3a0e41095a Mon Sep 17 00:00:00 2001
From: Joe Andrieu 
Date: Wed, 18 Oct 2023 08:14:20 -0700
Subject: [PATCH 15/58] Adding issue marker for adding validation to image

---
 index.html | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/index.html b/index.html
index 889f180e0..8d32c28a8 100644
--- a/index.html
+++ b/index.html
@@ -2552,7 +2552,9 @@ 
      Lifecycle Details
      
          verifiable data registry">
           
      
             The roles and information flows for this specification.
-            NEEDS VALIDATE
+                    
      
+                       Validation needs to be added to image
+                    
      
           
      
         
 

From 64b3e57cee26a2b9cbf2f4455a4f4b731ce528d2 Mon Sep 17 00:00:00 2001
From: Joe Andrieu 
Date: Wed, 18 Oct 2023 08:16:29 -0700
Subject: [PATCH 16/58] Update index.html

---
 index.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/index.html b/index.html
index 8d32c28a8..90e0b7eb2 100644
--- a/index.html
+++ b/index.html
@@ -4653,7 +4653,7 @@ 
      Bearer Credentials
      
         
      
       
      
 
-      
      
+      
      
         
      Validation
      
 
         
      

From 4831cf87229371782727368e3e5a1862031f0dba Mon Sep 17 00:00:00 2001
From: Joe Andrieu 
Date: Wed, 18 Oct 2023 08:16:45 -0700
Subject: [PATCH 17/58] Update index.html

Co-authored-by: Gabe <7622243+decentralgabe@users.noreply.github.com>
---
 index.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/index.html b/index.html
index 90e0b7eb2..cf2433af2 100644
--- a/index.html
+++ b/index.html
@@ -2633,7 +2633,7 @@ 
      Lifecycle Details
      
         
      
 
         
      
-This specification also does not define an authorization framework nor 
+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, it is required that verifiers MUST 

From b9831104a775a05bdafae0cc665dc99e2d80f07f Mon Sep 17 00:00:00 2001
From: Joe Andrieu 
Date: Wed, 18 Oct 2023 08:19:20 -0700
Subject: [PATCH 18/58] Update index.html

Co-authored-by: Andres Uribe 
---
 index.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/index.html b/index.html
index cf2433af2..48e746b39 100644
--- a/index.html
+++ b/index.html
@@ -4661,7 +4661,7 @@ 
      Validation
      
 evaluate any relevant claims before relying upon them. This 
 evaluation may 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  as well as a variety of specific business process checks such as:
+Many verifiers will perform the checks listed in Appendix  as well as a variety of specific business process checks such as:
         
      
 
         
        

From d031bdbb09612c6b3d0e4fd867241e0d591e23e8 Mon Sep 17 00:00:00 2001
From: Joe Andrieu 
Date: Wed, 18 Oct 2023 08:21:12 -0700
Subject: [PATCH 19/58] Update index.html

Co-authored-by: Gabe <7622243+decentralgabe@users.noreply.github.com>
---
 index.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/index.html b/index.html
index 48e746b39..834138481 100644
--- a/index.html
+++ b/index.html
@@ -5687,7 +5687,7 @@ 
        Validity Periods
        
 The validFrom and validUntil properties are expected
 to be within an expected range for the verifier. 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 period, as expressed using the validFrom and validUntil properties, is always considered a component of validation, which is perforemed **after** verification.
+credential is not in the past. Because some credentials can be useful for secondary purposes even if their original validity period has expired, validity period, as expressed using the validFrom and validUntil properties, is always considered a component of validation, which is performed **after** verification.
         
        
       
      
 

From 856a5c0dacf10b2efc2134dc9d2b89df343abd72 Mon Sep 17 00:00:00 2001
From: Joe Andrieu 
Date: Wed, 18 Oct 2023 08:21:47 -0700
Subject: [PATCH 20/58] Update terms.html

Co-authored-by: Gabe <7622243+decentralgabe@users.noreply.github.com>
---
 terms.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/terms.html b/terms.html
index 68d3a59f0..f01c2c79b 100644
--- a/terms.html
+++ b/terms.html
@@ -132,7 +132,7 @@
 The assurance that a claim from a specific issuer satisfies
   the business requirements of a verifier 
   for a particular use. This specification defines how verifiers 
-  verifyverifiable credentials and verifiable presentations. 
+  verify verifiable credentials and verifiable presentations. 
   
      
   It also specifies that Verifiers MUST validate claims in VCs before 
   relying on them. However, the means for such validation vary widely and 

From 357e2188fc93b538c7300e159b3aff5c75de1c74 Mon Sep 17 00:00:00 2001
From: Joe Andrieu 
Date: Wed, 18 Oct 2023 08:22:25 -0700
Subject: [PATCH 21/58] Update terms.html

Co-authored-by: Gabe <7622243+decentralgabe@users.noreply.github.com>
---
 terms.html | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/terms.html b/terms.html
index f01c2c79b..09701addc 100644
--- a/terms.html
+++ b/terms.html
@@ -137,8 +137,8 @@
   It also specifies that Verifiers MUST validate claims in VCs before 
   relying on them. However, the means for such validation vary widely and 
   are outside the scope of this specification. It is expected that 
-  verifiers will trust certain issuers for certain claims and apply their 
-  own rules to determine which claims in which credentials are suitable
+  verifiers will trust certain issuers for certain claims and apply their 
+  own rules to determine which claims in which credentials are suitable
   for use by their systems.
   
   
      verifiable credential
      

From a49142dd35bbaca83cac696bbaad9fa8f128b522 Mon Sep 17 00:00:00 2001
From: Joe Andrieu 
Date: Wed, 18 Oct 2023 08:24:01 -0700
Subject: [PATCH 22/58] Update index.html

Co-authored-by: Gabe <7622243+decentralgabe@users.noreply.github.com>
---
 index.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/index.html b/index.html
index 834138481..5305ce293 100644
--- a/index.html
+++ b/index.html
@@ -989,7 +989,7 @@ 
      Concrete Lifecycle Example
      
    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 
+   verifiable credential, the verifier also confirms that 
    the id for the alumni claim matches the id of the creator of the 
    verifiable presentation.
 
      

From cc5cd920acbbc88481993323dacfdaa699686896 Mon Sep 17 00:00:00 2001
From: Orie Steele 
Date: Sat, 21 Oct 2023 14:54:11 -0500
Subject: [PATCH 23/58] Remove unused references and vendor-specific protocols.

---
 common.js  | 64 ++----------------------------------------------------
 index.html | 22 ++++++++-----------
 2 files changed, 11 insertions(+), 75 deletions(-)

diff --git a/common.js b/common.js
index b51ca0e52..481be3ef6 100644
--- a/common.js
+++ b/common.js
@@ -5,15 +5,6 @@ var vcwg = {
   // Add as the respecConfig localBiblio variable
   // Extend or override global respec references
   localBiblio: {
-    "REST": {
-      title: "Architectural Styles and the Design of Network-based Software Architectures",
-      date: "2000",
-      href: "http://www.ics.uci.edu/~fielding/pubs/dissertation/",
-      authors: [
-        "Fielding, Roy Thomas"
-      ],
-      publisher: "University of California, Irvine."
-    },
     "VC-SPECS": {
       title: "Verifiable Credential Specifications Directory",
       href: "https://w3c.github.io/vc-specs-dir/",
@@ -44,38 +35,6 @@ var vcwg = {
       status: "WD",
       publisher: "Verifiable Credentials Working Group"
     },
-    "LDP-REGISTRY": {
-      title: "Linked Data Cryptographic Suite Registry",
-      href: "https://w3c-ccg.github.io/ld-cryptosuite-registry/",
-      authors: [
-        "Manu Sporny",
-        "Drummond Reed",
-        "Orie Steele"
-      ],
-      status: "CG-DRAFT",
-      publisher: "Credentials Community Group"
-    },
-    // aliases to known references
-    "HTTP-SIGNATURES": {
-      aliasOf: "http-signatures"
-    },
-    "MACAROONS": {
-      title: 'Macaroons',
-      // TODO: create spec
-      href: 'http://macaroons.io/',
-      authors: ['Arnar Birgisson', 'Joe Gibbs Politz', 'Úlfar Erlingsson',
-        'Ankur Taly', 'Michael Vrable', 'Mark Lentczner'],
-      status: 'unofficial',
-      publisher: 'Credentials Community Group'
-    },
-    'OPEN-BADGES': {
-      title: 'Open Badges',
-      href: 'https://github.com/openbadges/openbadges-specification',
-      authors: ['Brian Brennan', 'Mike Larsson', 'Chris McAvoy',
-        'Nate Otto', 'Kerri Lemoie'],
-      status:   'BA-DRAFT',
-      publisher:  'Badge Alliance Standard Working Group'
-    },
     'RDF-NORMALIZATION': {
       title: 'RDF Dataset Normalization',
       href: 'http://json-ld.github.io/normalization/spec/',
@@ -96,20 +55,8 @@ var vcwg = {
       status: 'ED',
       publisher: 'Credentials Community Group'
     },
-    'HASHLINK': {
-      title: 'Cryptographic Hyperlinks',
-      href: 'https://datatracker.ietf.org/doc/draft-sporny-hashlink/',
-      authors: ['Manu Sporny'],
-      status: 'Internet-Draft',
-      publisher: 'Internet Engineering Task Force (IETF)'
-    },
-    'IPFS': {
-      title: 'InterPlanetary File System (IPFS)',
-      href: 'https://en.wikipedia.org/wiki/InterPlanetary_File_System',
-      publisher: 'Wikipedia'
-    },
-    'VC-JSON-SCHEMA-2023': {
-      title: 'Verifiable Credentials JSON Schema 2023',
+    'VC-JSON-SCHEMA': {
+      title: 'Verifiable Credentials JSON Schema Specification',
       href: 'https://www.w3.org/TR/vc-json-schema/',
       authors: ['Gabe Cohen', 'Orie Steele'],
       status: 'FPWD',
@@ -122,13 +69,6 @@ var vcwg = {
       status: 'WD',
       publisher: 'W3C JSON-LD 1.1 Working Group'
     },
-    'VC-JWT': {
-      title: 'Securing Verifiable Credentials using JSON Web Tokens',
-      href: 'https://w3c.github.io/vc-jwt/',
-      authors: ['Orie Steele', 'Michael Jones'],
-      status: 'ED',
-      publisher: 'W3C Verifiable Credentials Working Group'
-    },
     'VC-SPECS': {
       title: 'Verifiable Credentials Specifications Directory',
       href: 'https://w3c.github.io/vc-specs-dir/',
diff --git a/index.html b/index.html
index c61928413..e90ba2830 100644
--- a/index.html
+++ b/index.html
@@ -2421,7 +2421,7 @@ 
      Data Schemas
      
 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
-[[?VC-JSON-SCHEMA-2023]] validation.
+[[?VC-JSON-SCHEMA]] validation.
         
      
 
         
      Data Schemas
 
         
      
 In the example above, the issuer is specifying a
-credentialSchema, which points to a [[?VC-JSON-SCHEMA-2023]] file that
+credentialSchema, which points to a [[?VC-JSON-SCHEMA]] file that
 can be used by a verifier to determine if the
 verifiable credential is well formed.
         
      
 
         
      
-For information about linkages to JSON Schema [[?VC-JSON-SCHEMA-2023]] or other
+For information about linkages to JSON Schema [[?VC-JSON-SCHEMA]] or other
 optional verification mechanisms, see the Verifiable Credentials
 Implementation Guidelines [[VC-IMP-GUIDE]] document.
         
      
@@ -3301,7 +3301,7 @@ 
      Terms of Use
      
       
      
         
      Evidence
      
 
-        
      
+        
      
 This feature is at risk and will be removed from the specification if at least
 two independent, interoperable implementations are not demonstrated for a
 single extension type by the end of the Candidate Recommendation Phase. If
@@ -5047,11 +5047,7 @@ 
      Content Integrity Protection
      
         
      
 While this specification does not recommend any specific content integrity
 protection, document authors who want to ensure links to content are integrity
-protected are advised to use URL schemes that enforce content integrity. Two
-such schemes are the [[HASHLINK]] specification and the [[IPFS]]. The example
-below transforms the previous example and adds content integrity protection to
-the JSON-LD Contexts using the [[HASHLINK]] specification, and content integrity
-protection to the image by using an [[IPFS]] link.
+protected are advised to use URL schemes that enforce content integrity.
         
      
 
         
      @@ -5064,7 +5060,7 @@ 
      Content Integrity Protection
      
   "type": ["VerifiableCredential", "ExampleAlumniCredential"],
   "credentialSubject": {
     "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
-    "image": "ipfs:/ipfs/QmXfrS3pHerg44zzK6QKQj6JDk8H6cMtQS7pdXbohwNQfK/image",
+    "image": "https://example.com/image",
     "alumniOf": {
       "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
       "name": "Example University"
@@ -5719,7 +5715,7 @@ 
      Schema
      
 according to the credentialSchema type definition for the
 verifiable credential and the verifier's own schema evaluation
 criteria. For example, if the credentialSchema's type value is
-[[?VC-JSON-SCHEMA-2023]], then a verifier can ensure a credential's
+[[?VC-JSON-SCHEMA]], then a verifier can ensure a credential's
 data is valid against the given JSON Schema.
         
      
       
      
@@ -5762,7 +5758,7 @@ 
      Base Context
      
 JSON-LD Context to be either stabilized, or removed, before the publication of
 this specification as a Proposed Recommendation. While that means that this
 specification could be delayed if dependencies such as [[?VC-DATA-INTEGRITY]],
-[[?VC-JOSE-COSE]], SD-JWT, [[?VC-JSON-SCHEMA-2023]], or status list
+[[?VC-JOSE-COSE]], SD-JWT, [[?VC-JSON-SCHEMA]], or status list
 do not enter the Proposed Recommendation phase around the same time frame, the
 Working Group is prepared to remove the dependencies if an undue burden is
 placed on transitioning to the Recommendation phase. This is a calculated
@@ -6105,7 +6101,7 @@ 
      Differences between Contexts, Types, and CredentialSchemas
      
         
      
 The verifiable credential and verifiable presentation data models
 leverage a variety of underlying technologies including [[JSON-LD]] and
-[[?VC-JSON-SCHEMA-2023]]. This section will provide a comparison of the
+[[?VC-JSON-SCHEMA]]. This section will provide a comparison of the
 @context, type, and credentialSchema
 properties, and cover some of the more specific use cases where it is possible
 to use these features of the data model.

From e07bae4fe5a1346c170d0568fbadad304fa3a329 Mon Sep 17 00:00:00 2001
From: Joe Andrieu 
Date: Tue, 24 Oct 2023 13:17:17 -0700
Subject: [PATCH 24/58] Apply suggestions from code review

Applying Manu's suggestions.

Co-authored-by: Manu Sporny 
---
 index.html | 6 +++---
 terms.html | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/index.html b/index.html
index 5305ce293..9452e2e46 100644
--- a/index.html
+++ b/index.html
@@ -2636,7 +2636,7 @@ 
      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, it is required that verifiers MUST 
+  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
@@ -4657,7 +4657,7 @@ 
      Bearer Credentials
      
         
      Validation
      
 
         
      
-When processing verifiable credentials, verifiers MUST 
+When processing verifiable credentials, verifiers  
 evaluate any relevant claims before relying upon them. This 
 evaluation may be done in any manner desired, as long as it satisfies
 the requirements of the verifier doing the validation. 
@@ -5687,7 +5687,7 @@ 
      Validity Periods
      
 The validFrom and validUntil properties are expected
 to be within an expected range for the verifier. 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 period, as expressed using the validFrom and validUntil properties, is always considered a component of validation, which is performed **after** verification.
+credential is not in the past. Because some credentials can be useful for secondary purposes even if their original validity period has expired, validity period, as expressed using the validFrom and validUntil properties, is always considered a component of validation, which is performed after verification.
         
      
       
      
 
diff --git a/terms.html b/terms.html
index 09701addc..35a4666a0 100644
--- a/terms.html
+++ b/terms.html
@@ -53,7 +53,7 @@
   
      
 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, numbers, and strings. Any entity may perform roles
+abstract concepts, numbers, and strings. Any entity might perform roles
 in the ecosystem, if it is capable of doing so. Note that some
 entities fundamentally cannot take actions, e.g., the string "abc"
 cannot issue credentials. 
      
@@ -134,8 +134,8 @@
   for a particular use. This specification defines how verifiers 
   verify verifiable credentials and verifiable presentations. 
   
      
-  It also specifies that Verifiers MUST validate claims in VCs before 
-  relying on them. However, the means for such validation vary widely and 
+  It also specifies that verifiers validate claims in verifiable credentials 
+  before relying on them. However, the means for such validation vary widely and 
   are outside the scope of this specification. It is expected that 
   verifiers will trust certain issuers for certain claims and apply their 
   own rules to determine which claims in which credentials are suitable

From 114c452eff060415f98940095081d85ba93736dc Mon Sep 17 00:00:00 2001
From: Joe Andrieu 
Date: Tue, 24 Oct 2023 13:17:49 -0700
Subject: [PATCH 25/58] Update index.html

Co-authored-by: Manu Sporny 
---
 index.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/index.html b/index.html
index 9452e2e46..5fc82233b 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 currency of a Verifiable Credential or Verifiable Presentation are established, a verifier MUST validate included claims using their own business rules before relying on them. Such reliance SHOULD only occur after evaluating the issuer, the proof, the subject, and the claims, against verifier policy. 
+that 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 evaluating the issuer, the proof, the subject, and the claims, against one or more verifier policies. 
         
      
       
 

From 03c922da6a4e3a24de315b7f50d26328532027fb Mon Sep 17 00:00:00 2001
From: Manu Sporny 
Date: Sat, 21 Oct 2023 17:00:12 -0400
Subject: [PATCH 26/58] Add suggestion to use Oblivious HTTP when fetching
 resources.

---
 common.js  |  7 +++++++
 index.html | 14 +++++++++++++-
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/common.js b/common.js
index 481be3ef6..115df5d80 100644
--- a/common.js
+++ b/common.js
@@ -82,6 +82,13 @@ var vcwg = {
       authors: ['Daniel Buchner', 'Brent Zundel', 'Martin Riedel', 'Kim Hamilton Duffy'],
       status: 'DIF Ratified Specification',
       publisher: 'Decentralized Identity Foundation'
+    },
+    'OHTTP': {
+      title: 'Oblivious HTTP ',
+      href: 'https://ietf-wg-ohai.github.io/oblivious-http/draft-ietf-ohai-ohttp.html',
+      authors: ['Martin Thomson', 'Christopher A. Wood'],
+      status: 'Working Group Draft',
+      publisher: 'IETF Oblivious HTTP Application Intermediation'
     }
   }
 };
diff --git a/index.html b/index.html
index e90ba2830..b9d50b806 100644
--- a/index.html
+++ b/index.html
@@ -4385,7 +4385,7 @@ 
      Long-Lived Identifier-Based Correlation
      
       
 
       
      
-        
      Device Fingerprinting
      
+        
      Device Tracking and Fingerprinting
      
 
         
      
 There are mechanisms external to verifiable credentials that are used to
@@ -4406,6 +4406,18 @@ 
      Device Fingerprinting
      
 In some cases, tracking technologies might need to be disabled on devices that
 transmit verifiable credentials on behalf of a holder.
         
      
+
+        
      
+One mechanism that implementers might consider utilizing when fetching external
+resources that are associated with a verifiable credential or a
+verifiable presentation is the Oblivious HTTP protocol [[?OHTTP]].
+Oblivious HTTP allows a client to make multiple requests to an origin server
+without that server being able to link those requests to the client or to
+identify the requests as having come from the same client, while placing only
+limited trust in the nodes used to forward the messages. Using Oblivious HTTP
+is one privacy-preserving mechanism that can be used to reduce the possibility
+of device tracking and fingerprinting.
+        
      
       
      
 
       
      

From 737cdea1a7aed138eadf3db8b8cb737a7dc7339e Mon Sep 17 00:00:00 2001
From: Manu Sporny 
Date: Tue, 24 Oct 2023 14:51:13 -0400
Subject: [PATCH 27/58] Fix grammar in OHTTP section.

Co-authored-by: Ted Thibodeau Jr 
---
 index.html | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/index.html b/index.html
index b9d50b806..c37bfda10 100644
--- a/index.html
+++ b/index.html
@@ -4408,13 +4408,13 @@ 
      Device Tracking and Fingerprinting
      
         
      
 
         
      
-One mechanism that implementers might consider utilizing when fetching external
-resources that are associated with a verifiable credential or a
-verifiable presentation is the Oblivious HTTP protocol [[?OHTTP]].
+The Oblivious HTTP protocol [[?OHTTP]] is one mechanism that implementers might
+consider using when fetching external resources that are 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 the client or to
-identify the requests as having come from the same client, while placing only
-limited trust in the nodes used to forward the messages. Using Oblivious HTTP
+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. Hence, Oblivious HTTP
 is one privacy-preserving mechanism that can be used to reduce the possibility
 of device tracking and fingerprinting.
         
      

From 491b378929b600d6e9f21d75444e780145495d90 Mon Sep 17 00:00:00 2001
From: Manu Sporny 
Date: Tue, 24 Oct 2023 14:51:36 -0400
Subject: [PATCH 28/58] Update link to OHTTP draft at IETF.

---
 common.js | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common.js b/common.js
index 115df5d80..d1b009a65 100644
--- a/common.js
+++ b/common.js
@@ -85,7 +85,7 @@ var vcwg = {
     },
     'OHTTP': {
       title: 'Oblivious HTTP ',
-      href: 'https://ietf-wg-ohai.github.io/oblivious-http/draft-ietf-ohai-ohttp.html',
+      href: 'https://datatracker.ietf.org/doc/html/draft-ietf-ohai-ohttp',
       authors: ['Martin Thomson', 'Christopher A. Wood'],
       status: 'Working Group Draft',
       publisher: 'IETF Oblivious HTTP Application Intermediation'

From 966b2755791df7d2e0cc966c5505ade05eb26a9a Mon Sep 17 00:00:00 2001
From: Manu Sporny 
Date: Sun, 29 Oct 2023 19:34:46 -0400
Subject: [PATCH 29/58] Add concrete examples of when OHTTP is useful.

---
 index.html | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/index.html b/index.html
index c37bfda10..cac572850 100644
--- a/index.html
+++ b/index.html
@@ -4416,8 +4416,26 @@ 
      Device Tracking and Fingerprinting
      
 identify those requests as having come from a single client, while placing only
 limited trust in the nodes used to forward the messages. Hence, Oblivious HTTP
 is one privacy-preserving mechanism that can be used to reduce the possibility
-of device tracking and fingerprinting.
+of device tracking and fingerprinting. Concrete examples for how Oblivious HTTP
+can benefit ecosystem participants are included below.
         
      
+
+        
        
+          
      • 
+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
+check the validity of a verifiable credential by fetching an
+externally linked revocation list.
+          
        • 
+          
      • 
+A verifier can reduce signalling 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.
+          
        • 
+        
      
       
      
 
       
      

From d4a6ee20f9a6d51d84af446d4a09cb216897a92d Mon Sep 17 00:00:00 2001
From: Manu Sporny 
Date: Sun, 22 Oct 2023 19:43:57 -0400
Subject: [PATCH 30/58] Add section on trust boundaries in privacy
 considerations.

---
 index.html | 42 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)

diff --git a/index.html b/index.html
index cac572850..255297b31 100644
--- a/index.html
+++ b/index.html
@@ -4264,6 +4264,48 @@ 
      Spectrum of Privacy
      
         
      
       
      
 
+      
      
+        
      Software Trust Boundaries
      
+
+        
      
+There are a variety of trust boundaries that exist in the
+ecosystem described by this specification.
+Just like an individual using a web browser trusts the web browser not to betray
+their trust by uploading their personal information to a data broker, a similar
+trust exists between the roles in the ecosystem described by this specification
+and the software that operates on the behalf of each of those roles. For
+example,
+        
      
+
+        
+
+        
      
+The examples above are not exhaustive, and there can be a variety of other
+expectations that roles have of the software that they use to achieve their
+goals. The common thread between each of these expectations is that each
+role expects the software that it uses to not violate privacy expectations.
+That is, it is expected that the software will operate in the best interests
+of the role and a violation of those expectations is a violation of trust that
+will result in the software being replaced by something that does not violate
+that trust. Implementers are strongly advised to write software that does not
+violate the trust of the roles they are serving.
+        
      
+      
      
+
       
      
         
      Personally Identifiable Information
      
 

From c9c31208c476fbaaf821edc0ae6381214834a0e4 Mon Sep 17 00:00:00 2001
From: Manu Sporny 
Date: Sun, 22 Oct 2023 19:44:51 -0400
Subject: [PATCH 31/58] Clarify types of software used by roles.

---
 index.html | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/index.html b/index.html
index 255297b31..012189890 100644
--- a/index.html
+++ b/index.html
@@ -4279,17 +4279,17 @@ 
      Software Trust Boundaries
      
 
         
 

From efd3992db2b4e9f69768b6ca5a8a1475739e29ac Mon Sep 17 00:00:00 2001
From: Manu Sporny 
Date: Sun, 29 Oct 2023 20:09:38 -0400
Subject: [PATCH 32/58] Fix grammar/flow in trust boundaries section.

Co-authored-by: Ted Thibodeau Jr 
---
 index.html | 45 +++++++++++++++++++++++++--------------------
 1 file changed, 25 insertions(+), 20 deletions(-)

diff --git a/index.html b/index.html
index 012189890..06103f6af 100644
--- a/index.html
+++ b/index.html
@@ -4268,41 +4268,46 @@ 
      Spectrum of Privacy
      
         
      Software Trust Boundaries
      
 
         
      
-There are a variety of trust boundaries that exist in the
+A variety of trust relationships exist in the
 ecosystem described by this specification.
-Just like an individual using a web browser trusts the web browser not to betray
-their trust by uploading their personal information to a data broker, a similar
-trust exists between the roles in the ecosystem described by this specification
-and the software that operates on the behalf of each of those roles. For
-example,
+An individual using a web browser trusts the web browser 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:
         
      
 
         
 
         
      
-The examples above are not exhaustive, and there can be a variety of other
-expectations that roles have of the software that they use to achieve their
-goals. The common thread between each of these expectations is that each
-role expects the software that it uses to not violate privacy expectations.
-That is, it is expected that the software will operate in the best interests
-of the role and a violation of those expectations is a violation of trust that
-will result in the software being replaced by something that does not violate
-that trust. Implementers are strongly advised to write software that does not
-violate the trust of the roles they are serving.
+The examples above are not exhaustive, and the users in these roles can also
+expect a variety of other things from the software they use to achieve their
+goals; the common thread is that the software is expected to preserve user
+privacy. That is, the software is expected to operate in the best interests
+of the user, and a violation of that expectation is a violation of trust
+that will result in the software being replaced by something that does not
+violate that trust. Implementers are strongly advised to write software that
+does not violate the trust of the users it will serve.
         
      
       
      
 

From 56b52a6931dcd540e97d61ef8b88e68ef2c19204 Mon Sep 17 00:00:00 2001
From: Manu Sporny 
Date: Sun, 29 Oct 2023 20:26:28 -0400
Subject: [PATCH 33/58] Fix flow and examples in trust boundaries section.

---
 index.html | 39 +++++++++++++++++++++------------------
 1 file changed, 21 insertions(+), 18 deletions(-)

diff --git a/index.html b/index.html
index 06103f6af..153f19b24 100644
--- a/index.html
+++ b/index.html
@@ -4269,41 +4269,44 @@ 
      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 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:
+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:
         
      
 
         
 
         
      
 The examples above are not exhaustive, and the users in these roles can also
 expect a variety of other things from the software they use to achieve their
-goals; the common thread is that the software is expected to preserve user
-privacy. That is, the software is expected to operate in the best interests
+goals. That is, the software is expected to operate in the best interests
 of the user, and a violation of that expectation is a violation of trust
 that will result in the software being replaced by something that does not
 violate that trust. Implementers are strongly advised to write software that

From 6382c0af43fb14225f7c40467877f8e3359020a6 Mon Sep 17 00:00:00 2001
From: Manu Sporny 
Date: Sun, 29 Oct 2023 20:29:50 -0400
Subject: [PATCH 34/58] Add statement about software auditing in trust
 boundaries section.

---
 index.html | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/index.html b/index.html
index 153f19b24..01e981cf5 100644
--- a/index.html
+++ b/index.html
@@ -4310,7 +4310,10 @@ 
      Software Trust Boundaries
      
 of the user, and a violation of that expectation is a violation of trust
 that will result in the software being replaced by something that does not
 violate that trust. Implementers are strongly advised to write software that
-does not violate the trust of the users it will serve.
+does not violate the trust of the users it will serve. Implementers are
+also advised to provide auditing features in the software that they create
+such that the users, or trusted third parties, can audit that the software is
+behaving in their best interests.
         
      
       
 

From aace5b075008046168cf747e6d7ef20105aa38d8 Mon Sep 17 00:00:00 2001
From: Manu Sporny 
Date: Sun, 29 Oct 2023 20:47:33 -0400
Subject: [PATCH 35/58] Add text on not being able to act in best interest of
 role.

---
 index.html | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/index.html b/index.html
index 01e981cf5..1c00ee2de 100644
--- a/index.html
+++ b/index.html
@@ -4315,6 +4315,20 @@ 
      Software Trust Boundaries
      
 such that the users, or trusted third parties, can audit that the software is
 behaving in their best interests.
         
      
+
+        
      
+Readers are advised that some software, such as a website that provides services
+to a single verifier and multiple holders, might operate as a
+user agent to both
+roles, but might not always be able to simultaneously operate in the best
+interests of all parties. For example, if that website detects an attempt at
+fraudulent verifiable credential use among multiple holders, it
+might report such an anomaly to the verifier, which would not be in the
+best interest of the holder committing the violation, but would be in the
+best interest of the verifier. It is strongly advised that when software
+operates in this manner, that it is made clear whose best interest in which the
+software is operating though mechanisms such as a website usage policy.
+        
      
       
 
       
      

From 904235584761783fd60f11c9dcddacd558f39096 Mon Sep 17 00:00:00 2001
From: Manu Sporny 
Date: Tue, 31 Oct 2023 09:37:59 -0400
Subject: [PATCH 36/58] Fix grammar and flow in trust boundaries section.

Co-authored-by: Ted Thibodeau Jr 
Co-authored-by: Brent Zundel 
---
 index.html | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/index.html b/index.html
index 1c00ee2de..656bb3afc 100644
--- a/index.html
+++ b/index.html
@@ -4283,8 +4283,8 @@ 
      Software Trust Boundaries
      
 An issuer's
 user agent
 (issuer software), such as an online education platform, is expected to only
-issue verifiable credentials to individuals that have completed their
-education.
+issue verifiable credentials to individuals that the issuer asserts
+have completed their educational program.
           
      • 
           
    • 
 A verifier's
@@ -4299,21 +4299,21 @@ 
      Software Trust Boundaries
      
 user agent
 (holder software), such as a digital wallet, is expected to only divulge
 information to a verifier when the holder has consented to
-the release of information.
+the release of that information.
           
      • 
         
    
 
         
    
 The examples above are not exhaustive, and the users in these roles can also
 expect a variety of other things from the software they use to achieve their
-goals. That is, the software is expected to operate in the best interests
+goals. In short, the software is expected to operate in the best interests
 of the user, and a violation of that expectation is a violation of trust
 that will result in the software being replaced by something that does not
 violate that trust. Implementers are strongly advised to write software that
 does not violate the trust of the users it will serve. Implementers are
 also advised to provide auditing features in the software that they create
-such that the users, or trusted third parties, can audit that the software is
-behaving in their best interests.
+such that the users, or trusted third parties, can check whether the software
+is indeed behaving in their best interests.
         
    
 
         
    
@@ -4326,8 +4326,8 @@ 
    Software Trust Boundaries
    
 might report such an anomaly to the verifier, which would not be in the
 best interest of the holder committing the violation, but would be in the
 best interest of the verifier. It is strongly advised that when software
-operates in this manner, that it is made clear whose best interest in which the
-software is operating though mechanisms such as a website usage policy.
+operates in this manner, that it is made clear in whose best interest the
+software is operating through mechanisms such as a website usage policy.
         
    
       
 

From 5168ddc7922b430a2166d415bd33b5411031c445 Mon Sep 17 00:00:00 2001
From: Manu Sporny 
Date: Tue, 31 Oct 2023 09:38:29 -0400
Subject: [PATCH 37/58] Specify who is providing what to platform in trust
 boundaries.

Co-authored-by: Ted Thibodeau Jr 
---
 index.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/index.html b/index.html
index 656bb3afc..1a282a32d 100644
--- a/index.html
+++ b/index.html
@@ -4292,7 +4292,7 @@ 
    Software Trust Boundaries
    
 (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.
+the platform by such individuals.
           
           
  • 
 A holder's

From 699d594915ebe0fa489c91b0ad84f810aca09a18 Mon Sep 17 00:00:00 2001
From: Manu Sporny 
Date: Tue, 31 Oct 2023 09:41:38 -0400
Subject: [PATCH 38/58] Minor grammar fix in fraudulent VC usage.

---
 index.html | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/index.html b/index.html
index 1a282a32d..9a93c5d77 100644
--- a/index.html
+++ b/index.html
@@ -4323,11 +4323,13 @@ 
    Software Trust Boundaries
    
 roles, but might not always be able to simultaneously operate in the best
 interests of all parties. For example, if that website detects an attempt at
 fraudulent verifiable credential use among multiple holders, it
-might report such an anomaly to the verifier, which would not be in the
-best interest of the holder committing the violation, but would be in the
-best interest of the verifier. It is strongly advised that when software
-operates in this manner, that it is made clear in whose best interest the
-software is operating through mechanisms such as a website usage policy.
+might report such an anomaly to the verifier, which might be considered
+to not be in the best interest of the holder committing the violation,
+but would be in the best interest of the verifier as well as any
+holders not committing such a violation. It is strongly advised
+that when software operates in this manner, that it is made clear in whose best
+interest the software is operating through mechanisms such as a website usage
+policy.
         
    
       
 

From 19fb1e3c82adb9392cbb143cd37d92b2bd601ce4 Mon Sep 17 00:00:00 2001
From: Kristina <52878547+Sakurann@users.noreply.github.com>
Date: Wed, 25 Oct 2023 17:43:21 -0700
Subject: [PATCH 39/58] Kristina stepping down as a co-chair

---
 README.md | 1 -
 1 file changed, 1 deletion(-)

diff --git a/README.md b/README.md
index 9fadf7fba..f9da9e85a 100644
--- a/README.md
+++ b/README.md
@@ -19,7 +19,6 @@ mailing list.
 * Charter: [https://www.w3.org/2022/06/verifiable-credentials-wg-charter.html](https://www.w3.org/2022/06/verifiable-credentials-wg-charter.html)
 * Chairs
   * Brent Zundel - @brentzundel
-  * Kristina Yasuda - @Sakurann
 
 ### Verifiable Credentials github repos
 * [Use Cases](https://github.com/w3c/vc-use-cases)

From a12a5e141ed2081f44b8b81f7dfb732f5f62f349 Mon Sep 17 00:00:00 2001
From: Joe Andrieu 
Date: Tue, 31 Oct 2023 09:15:33 -0700
Subject: [PATCH 40/58] Update index.html

Co-authored-by: Manu Sporny 
---
 index.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/index.html b/index.html
index 5fc82233b..e35f0b423 100644
--- a/index.html
+++ b/index.html
@@ -4659,7 +4659,7 @@ 
    Validation
    
         
    
 When processing verifiable credentials, verifiers  
 evaluate any relevant claims before relying upon them. This 
-evaluation may be done in any manner desired, as long as it satisfies
+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  as well as a variety of specific business process checks such as:
         
    

From 4d77ad04529b8fa53a003134bfc2a3e64aeea3df Mon Sep 17 00:00:00 2001
From: Joe Andrieu 
Date: Tue, 31 Oct 2023 09:19:20 -0700
Subject: [PATCH 41/58] Update terms.html

---
 terms.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/terms.html b/terms.html
index 35a4666a0..19209fb0f 100644
--- a/terms.html
+++ b/terms.html
@@ -53,7 +53,7 @@
   
    
 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, numbers, and strings. Any entity might perform roles
+abstract concepts, fictional characters, and arbitrary text. Any entity might perform roles
 in the ecosystem, if it is capable of doing so. Note that some
 entities fundamentally cannot take actions, e.g., the string "abc"
 cannot issue credentials. 
    

From 64a136afae888ce9554a0d0fccda7d9a765ffdf9 Mon Sep 17 00:00:00 2001
From: Joe Andrieu 
Date: Wed, 6 Sep 2023 08:25:18 -0700
Subject: [PATCH 42/58] rebased to latest from W3C main

---
 terms.html | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/terms.html b/terms.html
index b6b6b4eb6..7c8677a34 100644
--- a/terms.html
+++ b/terms.html
@@ -51,12 +51,12 @@
   
   
    entity
    
   
    
-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, numbers, and strings. Any entity might perform
-roles in the ecosystem, if it is capable of doing so. Note that some entities
-fundamentally cannot take actions; for example, the string "abc" cannot issue
-credentials. 
    
+Any abstract or concrete noun that can be referenced in statements.
+Entities include people, organizations, physical things, documents,
+abstract concepts, numbers and strings. An entity may perform roles
+in the ecosystem, if it is capable of doing so. Note that some
+entities fundamentally cannot take actions, e.g., the string "abc"
+cannot issue credentials. 
   
    graph
    
   
    
 A network of information composed of subjects and their relationship
@@ -65,8 +65,7 @@
   
    holder
    
   
    
 A role an entity might perform by possessing one or more
-verifiable credentials and generating verifiable presentations from
-them.
+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.

From 6ac71506b8affb0f22fd4859eca580ffaa3f5cb9 Mon Sep 17 00:00:00 2001
From: Joe Andrieu 
Date: Thu, 14 Sep 2023 09:55:06 +0200
Subject: [PATCH 43/58] Apply suggestions from code review

Thanks, TallTEd

Co-authored-by: Ted Thibodeau Jr 
---
 terms.html | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/terms.html b/terms.html
index 7c8677a34..43349d547 100644
--- a/terms.html
+++ b/terms.html
@@ -51,9 +51,9 @@
   
    
   
    entity
    
   
    
-Any abstract or concrete noun that can be referenced in statements.
+Anything that can be referenced in statements as an abstract or concrete noun.
 Entities include people, organizations, physical things, documents,
-abstract concepts, numbers and strings. An entity may perform roles
+abstract concepts, numbers, and strings. Any entity may perform roles
 in the ecosystem, if it is capable of doing so. Note that some
 entities fundamentally cannot take actions, e.g., the string "abc"
 cannot issue credentials. 
    

From 6adb49787b322ff164e02915aa58397049644e23 Mon Sep 17 00:00:00 2001
From: Joe Andrieu 
Date: Thu, 14 Sep 2023 14:58:53 +0200
Subject: [PATCH 44/58] Update terms.html

Co-authored-by: Ted Thibodeau Jr 
---
 terms.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/terms.html b/terms.html
index 43349d547..693489426 100644
--- a/terms.html
+++ b/terms.html
@@ -52,7 +52,7 @@
   
    entity
    
   
    
 Anything that can be referenced in statements as an abstract or concrete noun.
-Entities include people, organizations, physical things, documents,
+Entities include but are not limited to people, organizations, physical things, documents,
 abstract concepts, numbers, and strings. Any entity may perform roles
 in the ecosystem, if it is capable of doing so. Note that some
 entities fundamentally cannot take actions, e.g., the string "abc"

From 6333d445be813dad2715c735b59822cdea6d352c Mon Sep 17 00:00:00 2001
From: Joe Andrieu 
Date: Sun, 1 Oct 2023 21:20:57 -0700
Subject: [PATCH 45/58] full text pass at updating validation/verification
 language

---
 index.html | 97 ++++++++++++++++++++++++++++++++++--------------------
 1 file changed, 62 insertions(+), 35 deletions(-)

diff --git a/index.html b/index.html
index 9a93c5d77..98949ffdb 100644
--- a/index.html
+++ b/index.html
@@ -305,10 +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 the truth of claims encoded therein can be evaluated; however,
-the issuer can include values in the evidence property to help the verifier
-apply their business logic to determine whether the claims have sufficient
-veracity for their needs.
+that truth of claims encoded therein. Rather, once the authenticity and currency of a Verifiable Credential or Verifiable Presentation are established, a verifier MUST validate included claims using their own business rules before relying on them. Such reliance SHOULD only occur after evaluating the issuer, the proof, the subject, and the claims, against verifier policy. 
         
    
       
 
@@ -912,6 +909,9 @@ 
    Concrete Lifecycle Example
    
 Verification of the verifiable presentation by the
 verifier.
           
    • 
+          
  • 
+            Validation by the verifier of relevant claims contained in the verifiable presentation.
+          
    • 
         
 
         
    
@@ -962,9 +962,20 @@ 
    Concrete Lifecycle Example
    
 verifiable credential. Pat selects the alumni
 verifiable credential, which is then composed into a
 verifiable presentation. The verifiable presentation is sent to
-the verifier and verified.
-        
    
-        
    +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 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.
    
+        
     {
   "@context": [
     "https://www.w3.org/ns/credentials/v2",
@@ -2370,7 +2381,7 @@ 
    Data Schemas
    
 
         
      
           
    • 
-Data verification schemas, which are used to verify that the structure
+Data verification schemas, which are used to establish that the structure
 and contents of a credential or verifiable credential conform to a
 published schema.
           
      • 
@@ -2460,12 +2471,12 @@ 
      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
-verifiable credential is well formed.
+verifiable credential is well-formed.
         
      
 
         
      
-For information about linkages to JSON Schema [[?VC-JSON-SCHEMA]] or other
-optional verification mechanisms, see the Verifiable Credentials
+For information about linkages to JSON Schema [[?VC-JSON-SCHEMA-2023]] or other
+optional schema validation mechanisms, see the Verifiable Credentials
 Implementation Guidelines [[VC-IMP-GUIDE]] document.
         
      
 
@@ -2505,7 +2516,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
-the proof provided with the verifiable credential is valid.
+the proof provided with the verifiable credential is well-formed.
         
      
 
 
@@ -2540,6 +2551,7 @@ 
      Lifecycle Details
      
          verifiable data registry">
           
      
             The roles and information flows for this specification.
+            NEEDS VALIDATE
           
      
         
 
@@ -2566,10 +2578,12 @@ 
      Lifecycle Details
      
           
           
    • 
 A verifier verifies the authenticity of the presented
-verifiable presentation and verifiable credentials. This should
-include checking the credential status for revocation
+verifiable presentation and verifiable credentials and 
+checks any credential status
 of the verifiable credentials.
           
      • 
+          
    • 
+After verification, a verifier validates the relevant claims in presented verifiable credentials, using their own business logic to evaluate which issuers are appropriate for which claims and which subjects are appropriate for the requested use.
      • 
          
    • 
 An issuer might revoke a
 verifiable credential.
@@ -2592,7 +2606,7 @@ 
      Lifecycle Details
      
 
         
        
           
      1. 
-An issuer issues to a holder.
+An issuer issues a verifiable credential to a holder.
           
        2. 
           
      2. 
 The holder presents to a verifier.
@@ -2600,6 +2614,12 @@ 
        Lifecycle Details
        
           
      3. 
 The verifier verifies.
           
        4. 
+          
      4. 
+The verifier validates claims.
+          
        5. 
+          
      5. 
+The verifier applies valid claims.
+          
        6. 
         
      
 
         
      
@@ -2610,13 +2630,15 @@ 
      Lifecycle Details
      
         
      
 
         
      
-This specification also does not define an authorization framework nor the
-decisions that a verifier might make after verifying a
-verifiable credential or verifiable presentation,
-taking into account the holder, the issuers of the
-verifiable credentials, the contents of the
-verifiable credentials, and its own policies.
-        
      
+This specification also does not define an authorization framework nor 
+does it restrict the business decisions that a verifier might make
+after verifying a verifiable credential or verifiable 
+  presentation. However, it is required that verifiers MUST 
+  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.
+ 
      
 
         
      
 In particular, Sections  and
@@ -4683,14 +4705,15 @@ 
      Bearer Credentials
      
         
      
       
 
-      
      
-        
      Validity Checks
      
+      
      
+        
      Validation
      
 
         
      
-When processing verifiable credentials, verifiers are expected to
-perform many of the checks listed in Appendix  as
-well as a variety of specific business process checks. Validity checks might
-include checking:
+When processing verifiable credentials, verifiers MUST 
+evaluate any relevant claims before relying upon them. This 
+evaluation may 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  as well as a variety of specific business process checks such as:
         
      
 
         
        
@@ -4715,8 +4738,9 @@ 
        Validity Checks
        
         
        
 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 a revocation list can notify the issuer that a
-specific business is likely interacting with the holder. This could
+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
 knowledge.
         
        
@@ -5372,10 +5396,12 @@ 
        Unauthorized Use
        
         
        
         
        Inappropriate Use
        
         
        
-While valid cryptographic signatures and successful validity checks
+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. Toward the pursuit of appropriate use,
-it is crucial to consider the source and authenticity of the information. For
+are interchangeable for all contexts. It is crucial for verifiers to
+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. 
+
        
+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 the propriety of credential use,
@@ -5769,7 +5795,8 @@ 
        Proofs (Signatures)
        
 The digital signature provides a number of protections, other than tamper
 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. The
+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
 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
@@ -5788,7 +5815,7 @@ 
        Validity Periods
        
 The validFrom and validUntil properties are expected
 to be within an expected range for the verifier. For example, a
 verifier can check that the end of the validity period of a verifiable
-credential is not in the past.
+credential is not in the past. Because some credentials can be useful for secondary purposes even if their original validity period has expired, validity period, as expressed using the validFrom and validUntil properties, is always considered a component of validation, which is perforemed **after** verification.
         
        
       
      
 

From 5b3bb428178cda7c18b67aace5b255512494aef2 Mon Sep 17 00:00:00 2001
From: Joe Andrieu 
Date: Sun, 1 Oct 2023 21:21:40 -0700
Subject: [PATCH 46/58] updated terms.html to use new validation langauge

---
 terms.html | 25 +++++++++++++++----------
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/terms.html b/terms.html
index 693489426..6b8838fcc 100644
--- a/terms.html
+++ b/terms.html
@@ -126,14 +126,19 @@
 A program, such as a browser or other Web client, that mediates the
 communication between holders, issuers, and verifiers.
   
-  
      validation
      
-  
      
-The assurance that a verifiable credential or a
-verifiable presentation meets the needs of a verifier and other
-dependent stakeholders. This specification is constrained to verifying
-verifiable credentials and verifiable presentations regardless of
-their usage. Validating verifiable credentials or
-verifiable presentations is outside the scope of this specification.
+  
      validation
      
+  
      
+The assurance that a claim from a specific issuer satisfies
+  the business requirements of a verifier 
+  for a particular use. This specification defines how verifiers 
+  verifyverifiable credentials and verifiable presentations. 
+  
      
+  It also specifies that Verifiers MUST validate claims in VCs before 
+  relying on them. However, the means for such validation vary widely and 
+  are outside the scope of this specification. It is expected that 
+  verifiers will trust certain issuers for certain claims and apply their 
+  own rules to determine which claims in which credentials are suitable
+  for use by their systems.
   
      
   
      verifiable credential
      
   
      
@@ -162,11 +167,11 @@
   
      verification
      
   
      
 The evaluation of whether a verifiable credential or verifiable presentation
-is an authentic and timely statement of the issuer or presenter, respectively.
+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 proof method 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..
+of claims encoded in the credential.
 
   
      
   
      verifier
      

From 6ff22b7f42336159532630b0b600fb6143a240c4 Mon Sep 17 00:00:00 2001
From: Joe Andrieu 
Date: Wed, 18 Oct 2023 08:14:20 -0700
Subject: [PATCH 47/58] Adding issue marker for adding validation to image

---
 index.html | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/index.html b/index.html
index 98949ffdb..8386f7a33 100644
--- a/index.html
+++ b/index.html
@@ -2551,7 +2551,9 @@ 
      Lifecycle Details
      
          verifiable data registry">
           
      
             The roles and information flows for this specification.
-            NEEDS VALIDATE
+                    
      
+                       Validation needs to be added to image
+                    
      
           
      
         
 

From 115d44ec905f3a9b06bdb844367e4fb6b8a2bb83 Mon Sep 17 00:00:00 2001
From: Joe Andrieu 
Date: Wed, 18 Oct 2023 08:16:29 -0700
Subject: [PATCH 48/58] Update index.html

---
 index.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/index.html b/index.html
index 8386f7a33..86a3e845c 100644
--- a/index.html
+++ b/index.html
@@ -4707,7 +4707,7 @@ 
      Bearer Credentials
      
         
      
       
      
 
-      
      
+      
      
         
      Validation
      
 
         
      

From c3a389805fb3d5047c2c4ec0723c6495d474b4e9 Mon Sep 17 00:00:00 2001
From: Joe Andrieu 
Date: Wed, 18 Oct 2023 08:16:45 -0700
Subject: [PATCH 49/58] Update index.html

Co-authored-by: Gabe <7622243+decentralgabe@users.noreply.github.com>
---
 index.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/index.html b/index.html
index 86a3e845c..6b249b9d4 100644
--- a/index.html
+++ b/index.html
@@ -2632,7 +2632,7 @@ 
      Lifecycle Details
      
         
      
 
         
      
-This specification also does not define an authorization framework nor 
+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, it is required that verifiers MUST 

From aa68ca2d831d74db49f8172b0f7d678b76429392 Mon Sep 17 00:00:00 2001
From: Joe Andrieu 
Date: Wed, 18 Oct 2023 08:19:20 -0700
Subject: [PATCH 50/58] Update index.html

Co-authored-by: Andres Uribe 
---
 index.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/index.html b/index.html
index 6b249b9d4..c02b03609 100644
--- a/index.html
+++ b/index.html
@@ -4715,7 +4715,7 @@ 
      Validation
      
 evaluate any relevant claims before relying upon them. This 
 evaluation may 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  as well as a variety of specific business process checks such as:
+Many verifiers will perform the checks listed in Appendix  as well as a variety of specific business process checks such as:
         
      
 
         
        

From ceb8685d75e382737ae45849dcf0fd58b505d433 Mon Sep 17 00:00:00 2001
From: Joe Andrieu 
Date: Wed, 18 Oct 2023 08:21:12 -0700
Subject: [PATCH 51/58] Update index.html

Co-authored-by: Gabe <7622243+decentralgabe@users.noreply.github.com>
---
 index.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/index.html b/index.html
index c02b03609..72407856d 100644
--- a/index.html
+++ b/index.html
@@ -5817,7 +5817,7 @@ 
        Validity Periods
        
 The validFrom and validUntil properties are expected
 to be within an expected range for the verifier. 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 period, as expressed using the validFrom and validUntil properties, is always considered a component of validation, which is perforemed **after** verification.
+credential is not in the past. Because some credentials can be useful for secondary purposes even if their original validity period has expired, validity period, as expressed using the validFrom and validUntil properties, is always considered a component of validation, which is performed **after** verification.
         
        
       
      
 

From 19671d9faf04b814ec4103b54140d3a42f750e42 Mon Sep 17 00:00:00 2001
From: Joe Andrieu 
Date: Wed, 18 Oct 2023 08:21:47 -0700
Subject: [PATCH 52/58] Update terms.html

Co-authored-by: Gabe <7622243+decentralgabe@users.noreply.github.com>
---
 terms.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/terms.html b/terms.html
index 6b8838fcc..18e3b7289 100644
--- a/terms.html
+++ b/terms.html
@@ -131,7 +131,7 @@
 The assurance that a claim from a specific issuer satisfies
   the business requirements of a verifier 
   for a particular use. This specification defines how verifiers 
-  verifyverifiable credentials and verifiable presentations. 
+  verify verifiable credentials and verifiable presentations. 
   
      
   It also specifies that Verifiers MUST validate claims in VCs before 
   relying on them. However, the means for such validation vary widely and 

From 31d3481584a91c481444a28851c3f147ef930765 Mon Sep 17 00:00:00 2001
From: Joe Andrieu 
Date: Wed, 18 Oct 2023 08:22:25 -0700
Subject: [PATCH 53/58] Update terms.html

Co-authored-by: Gabe <7622243+decentralgabe@users.noreply.github.com>
---
 terms.html | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/terms.html b/terms.html
index 18e3b7289..5104c7570 100644
--- a/terms.html
+++ b/terms.html
@@ -136,8 +136,8 @@
   It also specifies that Verifiers MUST validate claims in VCs before 
   relying on them. However, the means for such validation vary widely and 
   are outside the scope of this specification. It is expected that 
-  verifiers will trust certain issuers for certain claims and apply their 
-  own rules to determine which claims in which credentials are suitable
+  verifiers will trust certain issuers for certain claims and apply their 
+  own rules to determine which claims in which credentials are suitable
   for use by their systems.
   
   
      verifiable credential
      

From b9e31f453dbeb133bc7b6edeeeec0efc727970b9 Mon Sep 17 00:00:00 2001
From: Joe Andrieu 
Date: Wed, 18 Oct 2023 08:24:01 -0700
Subject: [PATCH 54/58] Update index.html

Co-authored-by: Gabe <7622243+decentralgabe@users.noreply.github.com>
---
 index.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/index.html b/index.html
index 72407856d..3361ef4cc 100644
--- a/index.html
+++ b/index.html
@@ -970,7 +970,7 @@ 
      Concrete Lifecycle Example
      
    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 
+   verifiable credential, the verifier also confirms that 
    the id for the alumni claim matches the id of the creator of the 
    verifiable presentation.
 
      

From 124e6b56f08d6eb570b8ca679f5a29a789078df4 Mon Sep 17 00:00:00 2001
From: Joe Andrieu 
Date: Tue, 24 Oct 2023 13:17:17 -0700
Subject: [PATCH 55/58] Apply suggestions from code review

Applying Manu's suggestions.

Co-authored-by: Manu Sporny 
---
 index.html | 6 +++---
 terms.html | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/index.html b/index.html
index 3361ef4cc..881b4677a 100644
--- a/index.html
+++ b/index.html
@@ -2635,7 +2635,7 @@ 
      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, it is required that verifiers MUST 
+  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
@@ -4711,7 +4711,7 @@ 
      Bearer Credentials
      
         
      Validation
      
 
         
      
-When processing verifiable credentials, verifiers MUST 
+When processing verifiable credentials, verifiers  
 evaluate any relevant claims before relying upon them. This 
 evaluation may be done in any manner desired, as long as it satisfies
 the requirements of the verifier doing the validation. 
@@ -5817,7 +5817,7 @@ 
      Validity Periods
      
 The validFrom and validUntil properties are expected
 to be within an expected range for the verifier. 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 period, as expressed using the validFrom and validUntil properties, is always considered a component of validation, which is performed **after** verification.
+credential is not in the past. Because some credentials can be useful for secondary purposes even if their original validity period has expired, validity period, as expressed using the validFrom and validUntil properties, is always considered a component of validation, which is performed after verification.
         
      
       
      
 
diff --git a/terms.html b/terms.html
index 5104c7570..d42809153 100644
--- a/terms.html
+++ b/terms.html
@@ -53,7 +53,7 @@
   
      
 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, numbers, and strings. Any entity may perform roles
+abstract concepts, numbers, and strings. Any entity might perform roles
 in the ecosystem, if it is capable of doing so. Note that some
 entities fundamentally cannot take actions, e.g., the string "abc"
 cannot issue credentials. 
      
@@ -133,8 +133,8 @@
   for a particular use. This specification defines how verifiers 
   verify verifiable credentials and verifiable presentations. 
   
      
-  It also specifies that Verifiers MUST validate claims in VCs before 
-  relying on them. However, the means for such validation vary widely and 
+  It also specifies that verifiers validate claims in verifiable credentials 
+  before relying on them. However, the means for such validation vary widely and 
   are outside the scope of this specification. It is expected that 
   verifiers will trust certain issuers for certain claims and apply their 
   own rules to determine which claims in which credentials are suitable

From 9664ed05d3a23df57ea5cf14b94783491e7b8cfc Mon Sep 17 00:00:00 2001
From: Joe Andrieu 
Date: Tue, 24 Oct 2023 13:17:49 -0700
Subject: [PATCH 56/58] Update index.html

Co-authored-by: Manu Sporny 
---
 index.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/index.html b/index.html
index 881b4677a..b309fbb74 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 currency of a Verifiable Credential or Verifiable Presentation are established, a verifier MUST validate included claims using their own business rules before relying on them. Such reliance SHOULD only occur after evaluating the issuer, the proof, the subject, and the claims, against verifier policy. 
+that 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 evaluating the issuer, the proof, the subject, and the claims, against one or more verifier policies. 
         
      
       
 

From 061c4ccda33f565eec10d1a3e8f14135802ecc24 Mon Sep 17 00:00:00 2001
From: Joe Andrieu 
Date: Tue, 31 Oct 2023 09:15:33 -0700
Subject: [PATCH 57/58] Update index.html

Co-authored-by: Manu Sporny 
---
 index.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/index.html b/index.html
index b309fbb74..fcc65d325 100644
--- a/index.html
+++ b/index.html
@@ -4713,7 +4713,7 @@ 
      Validation
      
         
      
 When processing verifiable credentials, verifiers  
 evaluate any relevant claims before relying upon them. This 
-evaluation may be done in any manner desired, as long as it satisfies
+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  as well as a variety of specific business process checks such as:
         
      

From 119263a56cefd776820222f2fd96732e090e787e Mon Sep 17 00:00:00 2001
From: Joe Andrieu 
Date: Tue, 31 Oct 2023 09:19:20 -0700
Subject: [PATCH 58/58] Update terms.html

---
 terms.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/terms.html b/terms.html
index d42809153..352b9e96f 100644
--- a/terms.html
+++ b/terms.html
@@ -53,7 +53,7 @@
   
      
 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, numbers, and strings. Any entity might perform roles
+abstract concepts, fictional characters, and arbitrary text. Any entity might perform roles
 in the ecosystem, if it is capable of doing so. Note that some
 entities fundamentally cannot take actions, e.g., the string "abc"
 cannot issue credentials.