From 0a824e8d43fca88c4fbfcf1b59d74637ebacf668 Mon Sep 17 00:00:00 2001 From: Manu Sporny Date: Sat, 19 Oct 2024 13:42:47 -0400 Subject: [PATCH] Update CR2 to latest on main branch. --- transitions/2024/CR2/index.html | 112 ++++++++++++++++++++------------ 1 file changed, 72 insertions(+), 40 deletions(-) diff --git a/transitions/2024/CR2/index.html b/transitions/2024/CR2/index.html index 959dd1b..ef6b54c 100644 --- a/transitions/2024/CR2/index.html +++ b/transitions/2024/CR2/index.html @@ -1381,6 +1381,28 @@

Verifiable Credential Data Integrity 1.0

+
+
+ Example 5: A data document with an attached proof that uses the 'expires' property + 
{
+  "@context": [
+    {"myWebsite": "https://vocabulary.example/myWebsite"},
+    "https://w3id.org/security/data-integrity/v2"
+  ],
+  "myWebsite": "https://hello.world.example/",
+  "proof": {
+    "type": "DataIntegrityProof",
+    "cryptosuite": "ecdsa-rdfc-2019",
+    "created": "2020-06-11T19:14:04Z",
+    // the proof expires a month after it was created
+    "expires": "2020-07-11T19:14:04Z",
+    "verificationMethod": "https://ldi.example/issuer#zDnaepBuvsQ8cpsWrVKw8fbpGpvPeNSjVPTWoq6cRqaYzBKVP",
+    "proofPurpose": "assertionMethod",
+    "proofValue": "z98X7RLrkjnXEADJNUhiTEdwyE5GXX8cyJZRLQZ7vZyUXb23ZkdakfRJ7adYY8hn35EetqBkNw813SGsJHWrcpo4"
+  }
+}
+
+

The Data Integrity specification supports the concept of multiple proofs in a single document. There are two types of multi-proof @@ -1398,7 +1420,7 @@

Verifiable Credential Data Integrity 1.0

- Example 5: A proof set in a data document + Example 6: A proof set in a data document 
{
   "@context": [
     {"myWebsite": "https://vocabulary.example/myWebsite"},
@@ -1439,7 +1461,7 @@ 
Verifiable Credential Data Integrity 1.0
 

         

         

-    Example 6: A proof chain in a data document
+    Example 7: A proof chain in a data document
   
 
{
   "@context": [
     {"myWebsite": "https://vocabulary.example/myWebsite"},
@@ -1600,7 +1622,7 @@ 
Verifiable Credential Data Integrity 1.0
 

         

-    Example 7: An integrity-protected image that is associated with an object
+    Example 8: An integrity-protected image that is associated with an object
   
 
{
   ...
   "image": {
@@ -1710,7 +1732,7 @@ 
Verifiable Credential Data Integrity 1.0
 

 The vocabulary in JSON-LD format [JSON-LD11].


 
-SHA2-256 Digest: b3b13c6db415597cd65af7816351829832e8d74002b76d3676443802a4ac4409
+SHA2-256 Digest: 10a012489a3abe38f9871b986f27fbfa49a54d8d9edbe857a60bb2ce7baed416
               
             
             
@@ -1720,7 +1742,7 @@ 
Verifiable Credential Data Integrity 1.0
 

 The vocabulary in Turtle format [TURTLE].


 
-SHA2-256 Digest: ee513554388a5a76f71878a257d3bad30eba76a6d21cfef890eba894652c12d8
+SHA2-256 Digest: 2f7e055d789cbde920ac0279bfd147f56e07140811abcf273a8d8164a4afdfcb
               
             
             
@@ -1731,7 +1753,7 @@ 
Verifiable Credential Data Integrity 1.0
 
HTML-RDFA].


 
 
-SHA2-256 Digest: 237304135da080e730d93079f6a34a616e8d10c77be0012051b1fa6cbedb4605
+SHA2-256 Digest: eeea4710c7cb7640bb70f9d016e86eab7dc06ab804dc70057cc7c05cce1f8489
               
             
           
@@ -3249,12 +3271,15 @@ 
Verifiable Credential Data Integrity 1.0
 
5.8 Verification Method Binding

         
 
-        
Issue 3

-Implementers must ensure that a verification method is bound to a particular
-controller by going from the verification method to the controller document,
-and then ensuring that the controller document also contains the verification
-method.
-        

+        

+Implementers ensure that a verification method is bound to a particular
+controller by going from the definition of the verification method to the
+controller document, and then ensuring that the controller document also
+contains a reference to the verification method. This process is described
+in the algorithm for
+
+retrieving a verification method.
+        

       
 
       
5.9 Verification Relationship Validation

@@ -3262,8 +3287,8 @@ 
Verifiable Credential Data Integrity 1.0
 

 When an implementation is verifying a proof, it is
-imperative that it verify not only that the verification method used to
-generate the proof is listed in the controller document, but also that it
+imperative that it verify not only that the verification method used to
+generate the proof is listed in the controller document, but also that it
 was intended to be used to generate the proof that is being verified. This process
 is known as "verification relationship validation".
         

@@ -3392,7 +3417,7 @@ 
Verifiable Credential Data Integrity 1.0
 
conforming secured document.
 Readers might note, however, that JSON-LD contexts
-and verification methods can contain URLs that might be retrieved
+and verification methods can contain URLs that might be retrieved
 over a network connection. This concern exists for any URL that might be
 loaded from the network during or after verification.
         

@@ -3401,12 +3426,12 @@ 
Verifiable Credential Data Integrity 1.0
 
JSON-LD contexts are described in Section
-2.4 Contexts and Vocabularies, and some verification methods, such as
+2.4 Contexts and Vocabularies, and some verification methods, such as
 did:key [DID-KEY], do not need to be fetched from the network at all.
         

         

 When it is not possible to use cached information, such as when a specific HTTP
-URL-based instance of a verification method is encountered for the first
+URL-based instance of a verification method is encountered for the first
 time, implementers are cautioned to use defensive measures to mitigate 
 denial-of-service attacks during any process that might fetch a resource
 from the network.
@@ -3534,7 +3559,7 @@ 
Verifiable Credential Data Integrity 1.0
 

         

-At minimum, the verification method for the previous proof, such as a
+At minimum, the verification method for the previous proof, such as a
 public key, is seen by the creator of the next proof in a proof chain. This
 can be a privacy concern if the creator of the previous proof did not intend
 to be included in a proof chain, but is an inevitable outcome when
@@ -3558,14 +3583,14 @@ 
Verifiable Credential Data Integrity 1.0
 
conforming secured document. Readers might
 note, however, that JSON-LD contexts and
-verification methods can contain resource URLs that might be retrieved
+verification methods can contain resource URLs that might be retrieved
 over a network connection leading to fingerprinting concerns.
         

 
         

 For example, creators of conforming secured documents might craft unique
 per-document URLs for JSON-LD contexts and
-verification methods. When verifying such a document, a verifier fetching
+verification methods. When verifying such a document, a verifier fetching
 that information from the network would reveal their interest in the
 conforming secured document to the creator of the document, which might lead
 to a mismatch in privacy expectations for any entity that is not the creator of
@@ -3683,8 +3708,8 @@ 
Verifiable Credential Data Integrity 1.0
 
2.1.1 Proof Sets and 2.1.2 Proof Chains describe how multiple proofs
 can be expressed in a secured data document; that is, instead of a single
 proof included in the secured data document, one can express multiple
-proofs in an list as shown in Example 5 and
-Example 6. The elements of this list are
+proofs in an list as shown in Example 6 and
+Example 7. The elements of this list are
 members of a proof set and, optionally, a proof chain. The purpose of
 this section is to explain the intended use of each of these features and, in
 particular, their differing security properties. These differing security
@@ -3709,7 +3734,7 @@ 
Verifiable Credential Data Integrity 1.0
 

       

         

-    Example 8: Symbolic expression of how a proof is created
+    Example 9: Symbolic expression of how a proof is created
   
 
{
   "type": "DataIntegrityProof",
   "cryptosuite": "eddsa-jcs-2022",
@@ -3731,7 +3756,7 @@ 
Verifiable Credential Data Integrity 1.0
 

       

         

-    Example 9: Symbolic expression of a proof set
+    Example 10: Symbolic expression of a proof set
   
 
{
   // Remainder of secured data document not shown (above)
   "proof": [{
@@ -3758,7 +3783,7 @@ 
Verifiable Credential Data Integrity 1.0
 

       

         

-    Example 10: Removal of a signature in a proof set
+    Example 11: Removal of a signature in a proof set
   
 
{
   // Remainder of secured data document not shown (above)
   "proof": [{
@@ -3790,7 +3815,7 @@ 
Verifiable Credential Data Integrity 1.0
 

       

         

-    Example 11: Proof chain containing first proof with `id` property set
+    Example 12: Proof chain containing first proof with `id` property set
   
 
{
   // Remainder of secured data document not shown (above)
   "proof": {
@@ -3812,7 +3837,7 @@ 
Verifiable Credential Data Integrity 1.0
 

       

         

-    Example 12: Proof chain containing two proofs
+    Example 13: Proof chain containing two proofs
   
 
{
   // Remainder of secured data document not shown (above)
   "proof": [{
@@ -3845,7 +3870,7 @@ 
Verifiable Credential Data Integrity 1.0
 

       

         

-    Example 13: Proof chain containing three proofs
+    Example 14: Proof chain containing three proofs
   
 
{
   // Remainder of secured data document not shown (above)
   "proof": [{
@@ -4013,9 +4038,12 @@ 
Verifiable Credential Data Integrity 1.0
 

 Portions of the work on this specification have been funded by the United States
 Department of Homeland Security's Science and Technology Directorate under
-contracts 70RSAT20T00000029, 70RSAT21T00000016, and 70RSAT23T00000005. The
-content of this specification does not necessarily reflect the position or the
-policy of the U.S. Government and no official endorsement should be inferred.
+contracts 70RSAT20T00000029, 70RSAT21T00000016, 70RSAT23T00000005,
+70RSAT20T00000010/P00001, 70RSAT20T00000029, 70RSAT21T00000016/P00001,
+70RSAT23T00000005, 70RSAT23C00000030, 70RSAT23R00000006, and the National
+Science Foundation through NSF 22-572. The content of this specification does
+not necessarily reflect the position or the policy of the U.S. Government and no
+official endorsement should be inferred.
       

 
       

@@ -4103,7 +4131,7 @@ 
Verifiable Credential Data Integrity 1.0
 
[ASCII]

       ISO/IEC 646:1991, Information technology -- ISO 7-bit coded character set for information interchange.  Ecma International. URL: https://www.ecma-international.org/publications-and-standards/standards/ecma-6/
     
[CONTROLLER-DOCUMENT]

-      Controller Documents 1.0. Manu Sporny; Michael Jones.  W3C. 8 September 2024. W3C Working Draft. URL: https://www.w3.org/TR/controller-document/
+      Controller Documents 1.0. Manu Sporny; Michael Jones.  W3C. 15 October 2024. W3C Working Draft. URL: https://www.w3.org/TR/controller-document/
     
[INFRA]

       Infra Standard. Anne van Kesteren; Domenic Denicola.  WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/
     
[JSON-LD11]

@@ -4127,7 +4155,7 @@ 
Verifiable Credential Data Integrity 1.0
 
[URL]

       URL Standard. Anne van Kesteren.  WHATWG. Living Standard. URL: https://url.spec.whatwg.org/
     
[VC-DATA-MODEL-2.0]

-      Verifiable Credentials Data Model v2.0. Manu Sporny; Ted Thibodeau Jr; Ivan Herman; Michael Jones; Gabe Cohen.  W3C. 28 August 2024. W3C Candidate Recommendation. URL: https://www.w3.org/TR/vc-data-model-2.0/
+      Verifiable Credentials Data Model v2.0. Manu Sporny; Ted Thibodeau Jr; Ivan Herman; Michael Jones; Gabe Cohen.  W3C. 19 October 2024. W3C Candidate Recommendation. URL: https://www.w3.org/TR/vc-data-model-2.0/
     
[XMLSCHEMA11-2]

       W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes. David Peterson; Sandy Gao; Ashok Malhotra; Michael Sperberg-McQueen; Henry Thompson; Paul V. Biron et al.  W3C. 5 April 2012. W3C Recommendation. URL: https://www.w3.org/TR/xmlschema11-2/
     

@@ -4168,9 +4196,9 @@ 
Verifiable Credential Data Integrity 1.0
 
[TURTLE]

       RDF 1.1 Turtle. Eric Prud'hommeaux; Gavin Carothers.  W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/turtle/
     
[VC-DI-ECDSA]

-      Data Integrity ECDSA Cryptosuites v1.0. Manu Sporny; Martin Reed; Greg Bernstein; Sebastian Crane.  W3C. 28 August 2024. W3C Candidate Recommendation. URL: https://www.w3.org/TR/vc-di-ecdsa/
+      Data Integrity ECDSA Cryptosuites v1.0. Manu Sporny; Martin Reed; Greg Bernstein; Sebastian Crane.  W3C. 15 October 2024. W3C Candidate Recommendation. URL: https://www.w3.org/TR/vc-di-ecdsa/
     
[VC-DI-EDDSA]

-      Data Integrity EdDSA Cryptosuites v1.0. Manu Sporny; Dmitri Zagidulin; Greg Bernstein; Sebastian Crane.  W3C. 28 August 2024. W3C Candidate Recommendation. URL: https://www.w3.org/TR/vc-di-eddsa/
+      Data Integrity EdDSA Cryptosuites v1.0. Manu Sporny; Dmitri Zagidulin; Greg Bernstein; Sebastian Crane.  W3C. 15 October 2024. W3C Candidate Recommendation. URL: https://www.w3.org/TR/vc-di-eddsa/
     
[VC-EXTENSIONS]

       Verifiable Credential Extensions. Manu Sporny.  W3C Verifiable Credentials Working Group. W3C Editor's Draft. URL: https://w3c.github.io/vc-extensions/
     
[WEBCRYPTOAPI]

@@ -4311,7 +4339,9 @@ 
Verifiable Credential Data Integrity 1.0
 

       § 2.1 Proofs 
     
  • 
-      § 5.9 Verification Relationship Validation 
+      § 5.8 Verification Method Binding (2) 
+    
  • 
+      § 5.9 Verification Relationship Validation 
     
    •