Discuss delegation in a non-normative way.

Author: David-Chadwick

index.html

@@ -2017,16 +2017,58 @@ <h4>Subject is the Holder</h4>
 <a>holder</a> and all contained <a>verifiable credentials</a> are about a
 <a>subject</a> that can be identified to be the same as the <a>holder</a>.
       </p>
+     <p>
+If only the credentialSubject is allowed to insert a verifiable credential
+into a verifiable presentation the issuer MAY insert the "subjectOnly" property 
+into the verifiable credential, as defined below. 
+
+<span class="issue">
+This feature is at risk and is likely to be removed due to lack of consensus.
+</span>
+      </p>
+
+   <section>
+
+   <h5> 'Subject Only' Property </h5>
+
+  <p>
+The Subject Only property states that a verifiable credential MUST only be
+encapsulated into a verifiable presentation whose proof was issued by the 
+credentialSubject. A verifiable presentation that contains a verifiable credential 
+containing the subjectOnly property whose proof creator is not 
+the credentialSubject is invalid.
+     </p>
+
+        <pre class="example nohighlight" title="Subject Only Property">
+{
+  "id": "http://dmv.example.gov/credentials/3732",
+  "type": ["VerifiableCredential", "ProofOfAgeCredential"],
+  "issuer": "https://dmv.example.gov/issuers/14",
+  "issued": "2010-01-01T19:73:24Z",
+  "claim": {
+    "credentialSubject": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+    "ageOver": 21
+    },
+  "SubjectOnly": "True",
+  "proof": { ..
+  "creator": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+  ... }
+}
+        </pre>
+
+       </section>
+
 
     </section>
 
     <section>
+
       <h4>Credential Uniquely Identifies a Subject</h4>
 
       <p>
 In this case, the <code>credentialSubject</code> property might contain
 multiple properties that each provide an aspect of the identity of the
-<a>subject</a>, and which together, unambiguously identifies the subject. Some
+<a>subject</a>, and which together, unambiguously identify the subject. Some
 use cases might not require the <a>holder</a> to be identified at all, such as
 checking to see if a doctor (the <a>subject</a>) is board certified. Other use
 cases might require the <a>verifier</a> to use out-of-band knowledge to
@@ -2061,162 +2103,30 @@ <h4>Credential Uniquely Identifies a Subject</h4>
 address, and birth date of the individual.
       </p>
 
+ 
    </section>
 
     <section>
-      <h4>Subject Passes the Verifiable Credential to a Holder</h4>
-
+         <h4>Subject Passes the Verifiable Credential to a Holder</h4>
       <p>
-<a>Verifiable credentials</a> are usually presented to <a>verifiers</a> by the
-<a>subject</a>. In some cases, the <a>subject</a> might need to pass the whole
-or part of a <a>verifiable credential</a> to another <a>holder</a>. The data
-model allows for both cases, as outlined below.
-      </p>
-
-      <p>
-If only the <a>subject</a> is allowed to present the
-<a>verifiable credential</a> to a <a>verifier</a>, the <a>issuer</a> MUST
-insert the <code>SubjectOnly</code> <code>termsOfUse</code> property into the
-<a>verifiable credential</a>, as defined below. <span class="issue">
-This feature is at risk and is likely to be removed due to lack of consensus.
-</span>
-      </p>
-
-      <p>
-If the <a>issuer</a> permits the <a>subject</a> to pass the whole or part of a
-<a>verifiable credential</a> to a <a>holder</a> (for example, a patient might
-pass a prescription <a>verifiable credential</a> to a relative for
-presentation to a pharmacist for dispensing), the <a>subject</a> MUST issue a
-<a>verifiable credential</a> to the <a>holder</a> containing the
-<code>credentialSubject</code> properties being passed on, as described below.
-<span class="issue">This feature is at risk and is likely to be removed and
-replaced with another solution, possibly created by another Working Group
-focusing on delegation of authority instead of delegation of attributes.
-</span>
-      </p>
-
-   <section>
-
-   <h5> SubjectOnly Terms of Use </h5>
-
-      <p class="issue" data-number=204>
-The group is currently debating the best security model for delegation. Readers
-should treat this entire section as at-risk and currently under debate.
-      </p>
-
-      <p>
-The <code>SubjectOnly</code> <code>termsOfUse</code> property states that a
-<a>verifiable credential</a> MUST be presented to a <a>verifier</a> by the
-<a>subject</a> only. If a <a>verifier</a> is presented with a
-<a>verifiable credential</a> containing the <code>SubjectOnly</code>
-<code>termsOfUse</code> property by anyone other than the <a>subject</a>, the
-<a>verifier</a> MUST refuse to accept it.
-     </p>
-
-        <pre class="example nohighlight" title="Subject Only termsOfUse property by an Issuer">
-{
-  "id": "http://example.edu/credentials/3732",
-  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
-  "issuer": "https://example.edu/issuers/14",
-  "issued": "2010-01-01T19:73:24Z",
-  "credentialSubject": {
-    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
-    "degree": {
-      "type": "BachelorDegree",
-      "name": "Bachelor of Science in Mechanical Engineering"
-    }
-  },
-  <span class="highlight">"termsOfUse": [{
-    "type": "SubjectOnly",
-    }]
-  }</span>,
-  "proof": { ... }
-}
-        </pre>
-
-       </section>
-
-  <section>
-   <h5> Passing on a Verifiable Credential </h5>
-
-      <p class="issue" data-number=204>
-The group is currently debating the best security model for delegation. Readers
-should treat this entire section as at-risk and currently under debate.
-      <p>
-
-      <p>
-When a <a>subject</a> passes a <a>verifiable credential</a> to a
-<a>holder</a>, the <a>subject</a> SHOULD issue a new
-<a>verifiable credential</a> to the <a>holder</a> in which the:
-
-        <ul>
-			<li>
-<a>Issuer</a> is the <a>subject</a>.
-			</li>
-			<li>
-<a>Subject</a> is the <a>holder</a> to whom the <a>verifiable credential</a>
-is being passed.
-			</li>
-			<li>
-<code>credentialSubject</code> property contains the data being passed on.
-	 		</li>
-		</ul>
+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. For example, a patient
+(the subject) may be too ill to take a prescription (the verifiable credential)
+to the pharmacist (the verifier), and so may ask a friend to take the
+prescription for him/her in order to pick up the medication.
+</p>
 
-As well, the <a>holder</a> creates a <a>verifiable presentation</a> containing
-these two <a>verifiable credentials</a>.
+<p>
+The data model allows for this, by the subject issuing a new verifiable
+credential and giving it to the new holder, so that the holder can present
+both verifiable credentials to the verifier. However, the content of this
+second verifiable credential is likely to be application specific, and therefore
+this specification does not standardise the contents of this second verifiable
+credential. Nevertheless a non-normative example is given in Appendix A.2
       </p>
-
-        <pre class="example nohighlight" title="An example of a holder presenting verifiable
-credential properties that have been passed to it by the subject">
-{
-  "id": "did:example:76e12ec21ebhyu1f712ebc6f1z2",
-  "type": ["VerifiablePresentation"],
-  "verifiableCredential": [{
-      "id": "http://example.gov/credentials/3732",
-      "type": ["VerifiableCredential", "PrescriptionCredential"],
-      "issuer": "https://example.edu",
-      "issued": "2010-01-01",
-      "credentialSubject": {
-        "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",
-      "credentialSubject": {
-        "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 = "
-  }]
-}
-        </pre>
-
-
+ 
    </section>
-  </section>
 
    <section>
       <h4>Holder Acts on Behalf of the Subject</h4>
@@ -3961,7 +3871,75 @@ <h3>Device Theft and Impersonation</h3>
         </ul>
 
     </section>
+<section>
+<h2> Appendix A.2 Subject passes a verifiable credential to someone else</h2>
+
+      <em>This section is non-normative.</em>
+
+<p>
+When the subject passes a verifiable credential to another
+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. 
+The holder may now create a verifiable presentation that contains these two
+verifiable credentials, so that the verifier can verify that the subject gave
+the original verifiable credential to the holder.
+
+      <pre class="example nohighlight" title="An example of a holder presenting 
+a verifiable credential that has been passed to it by the subject">
+{
+  "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 = "
+  }]
+}
+        </pre>
 
+<p>
+In the above example, a patient (the original subject) has passed a prescription 
+(the original verifiable credential) to a friend, and has issued a new verifiable
+credential to the friend, in which the friend is the subject, the original subject is
+the issuer, and the credential is a copy of the original prescription.
+</p>
   </body>
 </html>