From 5cb841137a3ee7ea11ab0839a68b4cddf2eb228e Mon Sep 17 00:00:00 2001 From: David-Chadwick Date: Thu, 15 Nov 2018 15:38:43 +0000 Subject: [PATCH] Removed Delegation --- index.html | 364 +++++++++++++++++++++++------------------------------ 1 file changed, 157 insertions(+), 207 deletions(-) diff --git a/index.html b/index.html index 333a3489c..1219bc580 100644 --- a/index.html +++ b/index.html @@ -220,16 +220,6 @@

What is a Verifiable Credential?

presentations can be rapidly transmitted, making them more convenient than their physical counterparts when establishing trust at a distance.

-

- The persistence of digital information, and the ease with which - disparate sources of digital data may be collected and correlated, - comprise a privacy concern that the use of verifiable and easily - machine-readable credentials threatens to exacerbate. A Privacy Considerations - section addresses these issues. Items of particular concern in - this specification may also be noted in the text. Examples of - how to use this data model using privacy-enhancing technologies - such as zero-knowledge proofs are also provided. -

Ecosystem Overview

@@ -1724,6 +1714,7 @@

Subject-Holder Relationships

+

Subject is the Holder

@@ -1734,96 +1725,24 @@

Subject is the Holder

that can be identified to be the same as the holder.

-
- -
-

Credential Uniquely Identifies Subject

- -

. -In this case, the claim may contain multiple properties that each -provide an aspect of the identity of the subject, and which together -unambiguously identify the subject. Some use cases may not require the -holder to be identified at all, such as checking to see if a doctor (the -subject) is board certified. Other use cases may require the verifier to -use out-of-band knowledge to determine the relationship between the -subject and the holder. -

- - 
-{
-  "@context": ["https://w3.org/2018/credentials/v1", "https://schema.org/"]
-  "id": "http://dmv.example.gov/credentials/332",
-  "type": ["VerifiableCredential", "IdentityCredential"],
-  "issuer": "https://dmv.example.gov/issuers/4",
-  "issued": "2017-02-24",
-  "claim": {
-    "name": "J. Doe",
-    "address": {
-      "streetAddress": "10 Rue de Chose",
-      "postalCode": "98052",
-      "addressLocality": "Paris",
-      "addressCountry": "FR"
-    },
-    "birthDate": "1989-03-15"
-    ...
-  },
-  "proof": { ... }
-}
-
- -

-The example above uniquely identifies the subject through the use of the -name, address, and birth date of the individual. -

- -
- -
-

Subject Passes the Verifiable Credential to a Holder

- -

-The group is currently debating the best security model for delegation. Readers -should treat this entire section as at-risk and currently under debate. -

- -

-Normally verifiable credentials will be presented to verifiers by the -subject. However in some cases, the subject may need to pass the whole or -part of a verifiable credential to another holder. The data model allows for -both cases as follows. -

-

If only the subject is allowed to present the verifiable credential to a verifier, the issuer MUST insert the "subject only" Terms of Use into the -verifiable credential, as defined below. +verifiable credential, as defined below. +

+ +

+ + This feature is at risk and is likely to be removed due to lack of consensus.

-

-If the subject is not forbidden by the issuer to pass the whole or part of a -verifiable credential to a holder, for example, a patient may pass a -prescription verifiable credential to a relative for the relative to present -it to a pharmacist for dispensing, then the subject MUST issue a verifiable -credential to the holder containing the claim properties that are being -passed on, as described below. -This feature is at risk and is likely to be removed and replaced with -another solution, possibly created by another Working Group, that focuses on -delegation of authority instead of delegation of attributes. - -

'Subject Only' Terms of Use

-

-The group is currently debating the best security model for delegation. Readers -should treat this entire section as at-risk and currently under debate. -

-

The Subject Only Terms of Use states that a verifiable credential MUST only be presented to a verifier by the subject. If a verifier is presented with a @@ -1851,76 +1770,72 @@

'Subject Only' Terms of Use

-
-

Passing on a Verifiable Credential

-

-The group is currently debating the best security model for delegation. Readers -should treat this entire section as at-risk and currently under debate. -

+

-

+

+

Credential Uniquely Identifies Subject

-When the subject passes a verifiable credential to a -holder, the subject SHOULD issue a new verifiable credential to the holder in which: -the issuer is the subject, -the subject is the holder to whom the verifiable credential is being passed, -and the claim contains the properties that are being passed on. In addition, the -holder creates a verifiable presentation that contains these two -verifiable credentials. +

+In this case, the claim may contain multiple properties that each +provide an aspect of the identity of the subject, and which together +unambiguously identify the subject.

- 
+Some use cases may not require the
+holder to be identified at all, such as checking to see if a doctor (the
+subject) is certified by a medical board. 
+      

+
+      
 {
-  "id": "did:example:76e12ec21ebhyu1f712ebc6f1z2",
-  "type": ["VerifiablePresentation"],
-  "credential": [{
-      "id": "http://example.gov/credentials/3732",
-      "type": ["VerifiableCredential", "PrescriptionCredential"],
-      "issuer": "https://dmv.example.gov",
-      "issued": "2010-01-01",
-      "claim": {
-        "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
-        "prescription": {....}
-      },
-      "revocation": {
-        "id": "http://example.gov/revocations/738",
-        "type": "SimpleRevocationList2017"
-      },
-      "proof": {....}
+  "@context": ["https://w3.org/2018/credentials/v1", "https://schema.org/"]
+  "id": "http://dmv.example.gov/credentials/332",
+  "type": ["VerifiableCredential", "IdentityCredential"],
+  "issuer": "https://dmv.example.gov/issuers/4",
+  "issued": "2017-02-24",
+  "claim": {
+    "name": "J. Doe",
+    "address": {
+      "streetAddress": "10 Rue de Chose",
+      "postalCode": "98052",
+      "addressLocality": "Paris",
+      "addressCountry": "FR"
     },
-    {
-      "id": "https://example.com/VC/123456789",
-      "type": ["VerifiableCredential", "PrescriptionCredential"],
-      "issuer": "did:example:ebfeb1f712ebc6f1c276e12ec21",
-      "issued": "2010-01-03",
-      "claim": {
-        "id": "did:example:76e12ec21ebhyu1f712ebc6f1z2",
-        "prescription": {....}
-      },
-      "proof": {
-        "type": "RsaSignature2018",
-        "created": "2017-06-17T10:03:48Z",
-        "creator": "did:example:ebfeb1f712ebc6f1c276e12ec21/keys/234",
-        "nonce": "d61c4599-0cc2-4479-9efc-c63add3a43b2",
-        "signatureValue": "pYw8XNi1..Cky6Ed = "
-      }
-    }
-  ],
-  "proof": [{
-    "type": "RsaSignature2018",
-    "created": "2017-06-18T21:19:10Z",
-    "creator": "did:example:76e12ec21ebhyu1f712ebc6f1z2/keys/2",
-    "nonce": "c0ae1c8e-c7e7-469f-b252-86e6a0e7387e",
-    "signatureValue": "BavEll0/I1..W3JT24 = "
-  }]
+    "birthDate": "1989-03-15"
+    ...
+  },
+  "proof": { ... }
 }
-        

+
+

+The example above uniquely identifies the subject through the use of the +name, address, and birth date of the individual. +

-
+ +
+

Subject Passes the Verifiable Credential to a Holder

+ + +

+Normally verifiable credentials will be presented to verifiers by the +subject. However in some cases, the subject may need to pass the verifiable credential +to another holder, for example, in the case where a patient (the subject) is too ill to +visit the pharmacist and asks someone else (the new holder) to visit the pharmacist and +present the verifiable credential prescription for him or her. +This can be enabled by the subject issuing a second verifiable credential and giving it +to the new holder, so that the holder can present both verifiable credentials to the verifier. + +Since the contents of this second verifiable credential are likely to be application +specific, this specification does not standardise the contents of it. However, Appendix A.2 +provides a non-normative example of such a use case. + +

+

Holder Acts on Behalf of the Subject

@@ -1965,7 +1880,7 @@

Holder Acts on Behalf of the Subject

{
   "id": "http://dmv.example.gov/credentials/3732",
-  "type": ["VerifiableCredential", "ProofOfAgeCredential"],
+  "type": ["VerifiableCredential", "ChildProofOfAgeCredential"],
   "issuer": "https://dmv.example.gov/issuers/14",
   "issued": "2010-01-01T19:73:24Z",
   "claim": {
@@ -2102,55 +2017,26 @@ 
Disputes

 
         

 The time may come when an entity wants to dispute a credential
-issued by the issuer. There are at least two different cases to consider:
-a subject disputes a claim made by the issuer, e.g. the address property is out
-of date, or an entity disputes a (false) claim made by the issuer about a
-different subject, e.g. an imposter is claiming the entity's social security
-number. Only the subject of a verifiable credential is entitled to issue a
-"DisputeCredential". A "DisputeCredential" issued by anyone other than the
-subject SHOULD be disregarded by the verifier, unless the verifier has some out
-of band means of ascertaining the truth of the dispute. This is to prevent
-denial of service attacks whereby an attacker falsely disputes a true claim.
-
-The mechanism for issuing a "DisputeCredential"
-is the same as issuing a regular credential except that the subject
-identifier for the claim in the "DisputeCredential" is the identifier of
-the disputed credential.  For example, if a credential with an identifier of
-https://example.org/credentials/245
-is disputed, an entity may issue one of the following credentials. In the
-former case, the subject might present this to the verifier along with the
-disputed credential. In the latter case, the entity might publish the
-"DisputeCredential" in a public venue to make it known that the credential
-is disputed.
-        

-
-        
+issued by another entity. The mechanism for doing this is the same as issuing
+a regular credential except that the subject identifier for the
+claims are those of the disputed credential. For example, if a disputed
+credential with an identifier of
+http://con-artist.example.com/credentials/3732
+contains disputed statements, an entity would issue the following credential
+in a public venue to make it known that the credential is disputed:
+        

+
+        
 {
   "@context": [
     "https://w3.org/2018/credentials/v1",
     "https://example.com/examples/v1"
   ],
-  "id": "http://example.com/credentials/123",
-  "type": ["VerifiableCredential", "DisputeCredential"],
-  "claim": {
-    "id": "http://example.com/credentials/245",
-    "currentStatus": "Disputed",
-    "statusReason": "Address is out of date"
-  },
-  "issuer": "https://example.com/people#me",
-  "issuanceDate": "2017-12-05T14:27:42Z",
-  "proof": { ... }
-}
-        

-
-
-        
-{
-  "@context": "https://w3id.org/credentials/v1",
-  "id": "http://example.com/credentials/321",
+  "id": "http://example.com/credentials/245",
   "type": ["VerifiableCredential", "DisputeCredential"],
   "claim": {
-    "id": "http://example.com/credentials/245",
+    "id": "http://con-artist.example.com/credentials/3732",
     "currentStatus": "Disputed",
     "statusReason": "Credential contains disputed statements",
     "disputedClaim": {
@@ -2430,7 +2316,7 @@ 
Issuer

         
Subject

         
    
           
  • The value associated with the id property for each
-          claim MUST identify a subject to the
+          credential MUST identify a subject to the
           verifier. For example, if a subject is identified and the
           verifier has public key metadata related to the subject that is
           used for authentication purposes, then the verifier MAY be able to
@@ -2559,18 +2445,6 @@ 
    Accessibility Considerations
    
 
       This section is non-normative.
 
-      
    
-There are a number of accessibility considerations of which implementors
-should be aware when processing data described in this specification.
-As with any implementation of web standards or protocols, ignoring
-accessibility issues will make this information unusable to a large
-subset of the population. It is important to follow accessiblity
-guidelines and standards such as [[WCAG21]] to ensure that all people,
-regardless of ability, can make use of this data. This is especially
-important when establishing systems that utilize cryptography and encryption,
-which, historically, have created problems for assistive technologies.
-      
    
-
       
    
 This section details the general accessibility considerations that should be
 taken into account when utilizing this data model.
@@ -2583,9 +2457,8 @@ 
    Data First Approaches
    
 cards, have poor accessibility characteristics. Some of these poor
 characteristics include, but are not limited to, small print,
 reliance on small, high resolution images, and no affordances for people with
-vision impairments.
+vision disabilities.
         
    
-
         
    
 When utilizing this data model to create verifiable credentials, it is
 suggested that data model designers use a "data first" approach. For example,
@@ -2595,7 +2468,7 @@ 
    Data First Approaches
    
 machine readable way rather than solely relying on the image to convey this
 information. This approach is preferred because a "data first" approach
 provides the foundational elements of building different interfaces for
-people with varying abilities.
+people with disabilities.
@@ -3397,7 +3270,84 @@

Device Theft and Impersonation

+
+

Accessibility Impact

+

There are a number of accessibility considerations of which implementors should be aware when processing data described in this specification. As with any implementation of web standards or protocols, ignoring accessibility issues will make this information unusable to a large subset of the population. It is important to follow accessiblity guidelines and standards such as [WCAG21] to ensure that all people, regardless of ability can make use of this data. This is especially important when establishing cryptography and encryption which historically have created problems for assistive technologies. +

+ +
+ +

Appendix A.2

+ +
+ +

Passing on a Verifiable Credential

+ + +This section is non-normative + +

+ +When the subject passes a verifiable credential to a +holder, the subject MAY issue a new verifiable credential to the holder in which: +the issuer is the subject, +the subject is the holder to whom the verifiable credential is being passed, +and the claim contains the properties that are being passed on. In addition, the +holder creates a verifiable presentation that contains these two +verifiable credentials. +

+ + 
+{
+  "id": "did:example:76e12ec21ebhyu1f712ebc6f1z2",
+  "type": ["VerifiablePresentation"],
+  "credential": [{
+      "id": "http://example.gov/credentials/3732",
+      "type": ["VerifiableCredential", "PrescriptionCredential"],
+      "issuer": "https://dmv.example.gov",
+      "issued": "2010-01-01",
+      "claim": {
+        "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+        "prescription": {....}
+      },
+      "revocation": {
+        "id": "http://example.gov/revocations/738",
+        "type": "SimpleRevocationList2017"
+      },
+      "proof": {....}
+    },
+    {
+      "id": "https://example.com/VC/123456789",
+      "type": ["VerifiableCredential", "PrescriptionCredential"],
+      "issuer": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+      "issued": "2010-01-03",
+      "claim": {
+        "id": "did:example:76e12ec21ebhyu1f712ebc6f1z2",
+        "prescription": {....}
+      },
+      "proof": {
+        "type": "RsaSignature2018",
+        "created": "2017-06-17T10:03:48Z",
+        "creator": "did:example:ebfeb1f712ebc6f1c276e12ec21/keys/234",
+        "nonce": "d61c4599-0cc2-4479-9efc-c63add3a43b2",
+        "signatureValue": "pYw8XNi1..Cky6Ed = "
+      }
+    }
+  ],
+  "proof": [{
+    "type": "RsaSignature2018",
+    "created": "2017-06-18T21:19:10Z",
+    "creator": "did:example:76e12ec21ebhyu1f712ebc6f1z2/keys/2",
+    "nonce": "c0ae1c8e-c7e7-469f-b252-86e6a0e7387e",
+    "signatureValue": "BavEll0/I1..W3JT24 = "
+  }]
+}
+
+ + +
+
-