Verifiable Cred V1.1 Normative - Revision history

Tom: /* 5.6 Terms of Use */

2023-11-21T05:08:26Z

‎5.6 Terms of Use

Tom: /* Context */

2022-08-03T14:43:37Z

‎Context

Tom: /* Problems */

2022-08-03T14:40:59Z

‎Problems

Tom: /* Problems */

2022-08-03T14:38:59Z

‎Problems

Tom: /* Problems */

2022-08-03T05:57:16Z

‎Problems

Tom: /* Problems */

2022-08-03T05:55:12Z

‎Problems

Tom: /* Problems */

2022-08-03T05:54:32Z

‎Problems

Tom: /* Problems */

2022-08-03T05:53:19Z

‎Problems

Tom: /* Problems */

2022-08-03T05:53:02Z

‎Problems

Tom: /* Context */

2022-08-01T13:37:15Z

‎Context

@@ Line 151: / Line 151: @@
   termsOfUse
-  The value of the termsOfUse property MUST specify one or more terms of use policies under which the creator issued the credential or presentation. If the recipient (a holder or verifier) is not willing to adhere to the specified terms of use, then they do so on their own responsibility and might incur legal liability if they violate the stated terms of use. Each termsOfUse value MUST specify its type, for example, IssuerPolicy, and MAY specify its instance id. The precise contents of each term of use is determined by the specific termsOfUse type definition.
+  The value of the terms-Of-Use property MUST specify one or more terms of use policies under which the creator issued the credential or presentation. If the recipient (a holder or verifier) is not willing to adhere to the specified terms of use, then they do so on their own responsibility and might incur legal [[Liability]] if they violate the stated terms of use. Each terms-Of-Use value MUST specify its type, for example, IssuerPolicy, and MAY specify its instance id. The precise contents of each term of use is determined by the specific terms-Of-Use type definition.
 ===5.7 Evidence===

@@ Line 3: / Line 3: @@
 ==Context==
-The [https://www.w3.org/TR/vc-data-model/ Variable Cred Data Model Spec] is hard to read. This is a collection of only the mandatory bits separated from the optional bits with assistance from David Chadwick, one of the Authors of the spec. It is designed to be helpful for people who are familiar with identity standards.
+The [https://www.w3.org/TR/vc-data-model/ Variable Cred Data Model Spec] is hard to read. This is a collection of only the mandatory bits separated from the optional bits with assistance from David Chadwick, one of the Authors of the spec. It is designed to be helpful for people who are familiar with identity standards come up-to-speed quickly.
 ==Problems==

@@ Line 6: / Line 6: @@
 ==Problems==
-These are not necessarily defects in the VC data model as much as they are limitations in the model itself, which may be intentional.
+These are not necessarily defects in the VC data model as much as they are limitations in the model itself, which may have been intentional.
 # The VC data model is a definition of the structure (and use) of the credential and so term like ''Expiration Date'' applies not to the license or grant, but to the bucket of bits that is defined in the model.
 # In general, the use of term license in the real world conflates the concept of a grant with the documentation of that grant. So, a ''Driver's License'' sometimes refers to the grant of a privilege to use the public road with the documentation of that grant in an ISO 18013 paper or digital document.
 # All of today's [[Mobile Credential]]s have a problem distinguishing between the [[Subject]] and the [[Holder]]. The easiest way to think about the problem is a parent traveling with an under-age child that does not yet have a [[Smartphone]]. More work is needed in the UX of any proposed solution. Think about the challenge of being in front of a boarder agent with a long line of applicants trying to get the right credential to display on the agent's demand while still controlling the child.
-# The standard includes a long on long URLs that make it hard for a VC to be encoded in a single [[QR Code]], which is supposed to be the back-up for when the networks are down. The [[Smart Health Card]] took the approach of putting the context (i.e. shc://) outside the certificate, which allowed the SHC to be encoded in a single QR code image.
+# The standard includes several long URLs that make it hard for a VC to be encoded in a single [[QR Code]], which is suggested as a back-up for when the networks are down. The [[Smart Health Card]] took the approach of putting the context (i.e. shc://) outside the certificate, which allowed the SHC to be encoded in a single QR code image.
 # For many use cases, the most important element for verifiers would be [[Proof of Presence]] of the holder, for example, when an attribute like age of the holder is required by law. This is not defined in the standard, although there is an "Evidence" section where it could be included if defined elsewhere.

@@ Line 12: / Line 12: @@
 # All of today's [[Mobile Credential]]s have a problem distinguishing between the [[Subject]] and the [[Holder]]. The easiest way to think about the problem is a parent traveling with an under-age child that does not yet have a [[Smartphone]]. More work is needed in the UX of any proposed solution. Think about the challenge of being in front of a boarder agent with a long line of applicants trying to get the right credential to display on the agent's demand while still controlling the child.
 # The standard includes a long on long URLs that make it hard for a VC to be encoded in a single [[QR Code]], which is supposed to be the back-up for when the networks are down. The [[Smart Health Card]] took the approach of putting the context (i.e. shc://) outside the certificate, which allowed the SHC to be encoded in a single QR code image.
 ==Mandatory Elements==

@@ Line 11: / Line 11: @@
 # In general, the use of term license in the real world conflates the concept of a grant with the documentation of that grant. So, a ''Driver's License'' sometimes refers to the grant of a privilege to use the public road with the documentation of that grant in an ISO 18013 paper or digital document.
 # All of today's [[Mobile Credential]]s have a problem distinguishing between the [[Subject]] and the [[Holder]]. The easiest way to think about the problem is a parent traveling with an under-age child that does not yet have a [[Smartphone]]. More work is needed in the UX of any proposed solution. Think about the challenge of being in front of a boarder agent with a long line of applicants trying to get the right credential to display on the agent's demand while still controlling the child.
-# The standard includes a long on long URLs that make it hard for a VC to be encoded in a single QR code, which is supposed to be the back-up for when the networks are down. The [[Smart Health Card]] took the approach of putting the context (i.e. shc://) outside the certificate, which allowed the SHC to be encoded in a single QR code image.
+# The standard includes a long on long URLs that make it hard for a VC to be encoded in a single [[QR Code]], which is supposed to be the back-up for when the networks are down. The [[Smart Health Card]] took the approach of putting the context (i.e. shc://) outside the certificate, which allowed the SHC to be encoded in a single QR code image.
 ==Mandatory Elements==