Subject NE Holder

[David-Chadwick]

The current document (30 Jan 2018 version) states in Section 2 Terminology “A holder is typically also the primary subject of the verifiable credentials that they are holding.”
This is fine, but it means we need a new section entitled "When Subject≠Holder".
The proposed new text is attached.

6. When Subject≠Holder
   The following diagram shows edge cases of when subject≠holder.
   <Include here the diagram at
   https://lists.w3.org/Archives/Public/public-vc-wg/2018Jan/att-0006/SubjectHolder.jpg >

Only some of the above edge cases are catered for in the data model as follows:

6.1 Credential Uniquely Identifies Subject
In this case, the claim may contain multiple properties that each provide an aspect of the identity of the subject

Example 6.1: An example of a credential that uniquely identifies subject

{   
   "id": "http://example.gov/credentials/3732",
   "type": ["Credential", "ProofOfAgeCredential"],
   "issuer": "https://dmv.example.gov",
   "issued": "2010-01-01",
   "claim": {
     "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
     "name": "Mr John Doe",
     "address": "10 Some Street, Anytown, ThisLocal, Country X",
     "dateOfBirth": "2001-01-01",
     "gender": "male",
     "placeOfBirth" : "Anytown, ThisLocal, Country X",
     "nationality" : "X",
  },   
  "proof": { ... } }

6.2 Subject Delegates to Holder
This is supported in the data model through the process of recursion, in which the subject issues a credential to the delegated holder. In the delegated credential, the issuer is the subject, the claim contains the id of the delegated holder, and the claim property is the credential that was originally issued to the subject. An example is provided in 6.2

Example 6.2: An example of a credential delegated from a subject to a holder that is valid for 2 days

{  
   "id": "1234",
   "type": ["DelegatedCredential", "AccessCredential"],
   "issuer": "did:example:ebfeb1f712ebc6f1c276e12ec21",
   "issued": "2010-01-06T00:00:00Z ",
   "expires": "2010-01-08T00:00:00Z ",
   "claim": {
     "id": "did:example:ebfeb1f712ebc6f1c2123456789",
     "credential”: {
	   "id": "http://example.gov/credentials/3732",
	   "type": ["Credential", "AccessCredential"],
          "issuer": "https://dmv.example.gov",
          "issued": "2010-01-01",
          "claim": {
          "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
          "access": "secretEncodedInformation”
           },
          "revocation": {
          "id": "http://example.gov/revocations/738",
          "type": "SimpleRevocationList2017"   },
       "proof": {
         "type": "LinkedDataSignature2015",
         "created": "2016-06-18T21:19:10Z",
         "creator": "https://example.com/jdoe/keys/1",
         "domain": "json-ld.org",
         "nonce": "598c63d6",
         "signatureValue": "BavEll0/I1zpYw8XNi1bgVg/sCneO4Jugez8RwDg/+     MCRVpjOboDoe4SxxKjkCOvKiCHGDvc4krqi6Z1n0UfqzxGfmatCuFibcC1wps     PRdW+gGsutPTLzvueMWmFhwYmfIFpbBu95t501+rSLHIEuujM/+PXr9Cky6Ed     +W3JT24="
               }
        }
   },   
  "proof": { ... } }

This process of recursion could continue without restriction. Therefore a new property “delegatable”, is added to the data model.

6.2.1 Delegatable Property
The delegatable property, a Boolean, states whether a credential is delegatable or not. If is present with the value true, or not present, then the credential is delegatable to a third party.

Example 6.3: An example of the delegatable property

{  
   "id": "http://example.gov/credentials/3732",
   "type": ["Credential", "ProofOfAgeCredential"],
   "issuer": "https://dmv.example.gov",
   "issued": "2010-01-01",
   "delegatable": false,
   "claim": {
     "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
     "ageOver": 21
  },   
  "proof": { ... } }

6.3 Holder Acts On Behalf Of the Subject, Issuer or Verifier
In the case where a third party holds a credential that refers to a subject who is not the holder, and there is no obvious link in the credential that binds the subject to the holder, then it is outside the scope of the data model how the verifier determines that the holder is entitled to hold the subject’s credential. The credential itself does not contain any information that indicates who the rightful holder is.

[David-Chadwick]

I propose to change 6.3 to the following

6.3. Holder Acts on Behalf of Subject
In this case, the Holder creates a Profile, in which the ID is the ID of the holder, and the Relationship property states the relationship between the Holder and the Subject.
Note. The verifier still has to validate that this relationship is true.
Note. It it for further study how a holder might insert the credentials of two or more different subjects into a profile and assert his or her relationship to all the subjects.

6.3.1 Relationship Property
The Relationship property states the Profile Holder's relationship to the Subject of the embedded credentials. It is defined as a string.
Note that values of this string will be defined in other standards, but It is likely that typical values might be "parent" (when the subject is a child) and "owner" (when the subject is a pet) etc.

Example 6.4: An example of the relationship property, where a parent asserts their child is under 16

{
  "id": "did:example:ebfeb1c276e12ec211f712ebc6f",
  "relationship": "parent", 
  "credential": [{
    "id": "http://dmv.example.gov/credentials/3732",
    "type": ["Credential", "ProofOfAgeCredential"],
    "issuer": "https://dmv.example.gov/issuers/14",
    "issued": "2010-01-01T19:73:24Z",
    "claim": {
      "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
      "ageUnder": 16
    },
    "proof": {
      "type": "RsaSignature2018",
      "created": "2017-06-17T10:03:48Z",
      "creator": "https://dmv.example.gov/issuers/14/keys/234",
      "nonce": "d61c4599-0cc2-4479-9efc-c63add3a43b2",
      "signatureValue": "pYw8XNi1bgVg/sCneO4BavEll0/I1zJugez8RwDg/+
      ibcC1wpsMCRVpjOboDoe4SxxKjkCOvKiCHGDvc4krqi6Z1n0UfqzxGfmatCuF
      zvueMWmFPRdW+gGsutPTLhwYmfIFpbBu95t501+rSLHIEuujM/+PXr+W3JT24
      9Cky6Ed="
    }
  }],
  "proof": [{
    "type": "RsaSignature2018",
    "created": "2017-06-18T21:19:10Z",
    "creator": "did:example:ebfeb1c276e12ec211f712ebc6f/keys/2",
    "nonce": "c0ae1c8e-c7e7-469f-b252-86e6a0e7387e",
    "signatureValue": "BavEll0/I1zpYw8XNi1bgVg/sCneO4Jugez8RwDg/+
    MCRVpjOboDoe4SxxKjkCOvKiCHGDvc4krqi6Z1n0UfqzxGfmatCuFibcC1wps
    PRdW+gGsutPTLzvueMWmFhwYmfIFpbBu95t501+rSLHIEuujM/+PXr9Cky6Ed
    +W3JT24="
  }]
}

6.4 Issuer Authorises Holder
In this case the issuer inserts into the credential the ID of the holder who is authorised to hold the credential.

6.4.1 Holder ID Property
The holderID property is inserted into a credential by the issuer, when the issuer authorises the holder to possess the credential.

Example 6.5. A credential issued to a holder

{ 
  "id": "http://example.gov/credentials/3732",
  "type": ["Credential", "ProofOfAgeCredential"],
  "issuer": "https://dmv.example.gov",
  "issued": "2010-01-01",
  "holderid": "did:example:ebfeb1276e12ec21f712ebc6f1c",
  "claim": {
  "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
  "name": "Mr John Doe",
  "address": "10 Some Street, Anytown, ThisLocal, Country X",
  },
  "proof": { ... } }

6.5 Holder Acts on Behalf of Verifier
The data model does not support this scenario.

6.6 Holder has no relationship to Subject, Issuer or Verifier
The data model does not support this scenario

[msporny]

Hi @David-Chadwick, I'm just focusing on syntax, not whether I agree with the way you've modeled it (agree with most of it, disagree with some). Some corrections below:

"relationship": "parent",

This says that the subject is a parent, but not to whom they're a parent. I suggest something like:

"parent": "did:example:ebfeb1f712ebc6f1c276e12ec21"

"access": "secretEncodedInformation”
"delegatable": false,

-1 to Access Control Lists -- they have bad security characteristics. I'd rather the group try to figure out how to use Object Capabilities as the security mechanism. We have been doing some reassuring R&D in the space for a couple of years and have deployed the first experiment that's going really well. More here:

https://w3c-ccg.github.io/ld-ocap/

[David-Chadwick]

The relationship property is in the profile and is set by the holder, so it states the holder's relationship to the subject (its not the other way around as you assert, since the subject cannot state anything). Therefore the holder is stating that he/she is the parent of the credential subject. If we take your idea of having a property pointing to an ID, then we would need to define separate properties for each relationship type, which means we cannot do it in the data model document. By doing it the way I suggest, we can define (and standardise the relationship property) and leave it to others to standardise the values. In this way the Data Model is fixed, but the relationship values are extensible.
So I disagree with the way you propose to model it.
However there is a third way, which would be to standardise the relationship property, and make its value a set of ID and value. I like this better, as it now allows the holder to state that he is the parent of subject1 and the wife of subject 2, and the profile could hold credentials of both the wife and the child.
So we take your idea and mine, combine them together and make a synergetic 3 :-)

[David-Chadwick]

Having an access control list property is simply an example of a claim that can be delegable. I am happy to change this example into another property that can be delegated.

Clearly an AgeOver property cannot be delegatable, so this is why the delegatable property is used with the AgeOver example to show that it cannot be deleged

[David-Chadwick]

Here is some revised text for delegation which uses the principles of RBAC delegation (which in many ways are similar to object capabilities).

6.2 Subject Delegates to Holder

This is supported in the data model in two different ways: through the use of either recursion or profiles. Both methods involve the subject issuing a new credential to the delegated holder.

This process of recursion could continue without restriction. Therefore a new property “delegatable”, is added to the data model.
6.2.1 Delegatable Property

The delegatable property, a Boolean, states whether a credential is delegatable or not. If it is present with the value true, or not present, then the credential is delegatable to a third party. If it is present with the value false then it is not delegatable.
Example 10: An example of a credential that is not delegatable

{
  "id": "http://dmv.example.gov/credentials/3732",
  "type": ["Credential", "ProofOfAgeCredential"],
  "issuer": "https://dmv.example.gov/issuers/14",
  "issued": "2010-01-01",
  "delegatable": false,
  "claim": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "ageOver": 21,
  },
  "proof": { ... }
}

6.2.2 Delegation through Recursion

With recursion, the subject issues a credential to the delegated holder in which: the issuer is the subject, the claim contains the id of the delegated holder, and the claim property is the credential that was originally issued to the subject. An example is provided below.
Example 11: An example of a credential delegated from a subject to a holder that is valid for 2 days

{ 
  "id": "1234",
  "type": ["Credential", "EmbeddedDelegatedCredential"],
  "issuer": "did:example:ebfeb1f712ebc6f1c276e12ec21",
  "issued": "2010-01-06T00:00:00Z ",
  "expires": "2010-01-08T00:00:00Z ",
  "claim": {
    "id": "did:example:ebfeb1f712ebc6f1c2123456789",
    "credential”: {
       "id": "http://example.gov/credentials/3732",
       "type": ["Credential", "Role"],
       "issuer": "https://dmv.example.gov",
       "issued": "2010-01-01",
       "claim": {
         "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
         "role": "Project Manager”
         },
       "revocation": {
       "id": "http://example.gov/revocations/738",
       "type": "SimpleRevocationList2017" },
       "proof": {
       "type": "LinkedDataSignature2015",
       "created": "2016-06-18T21:19:10Z",
       "creator": "https://example.com/jdoe/keys/1",
       "domain": "json-ld.org",
       "nonce": "598c63d6",
       "signatureValue": "BavEll0/I1zpYw8XNi1bgVg/sCneO4Jugez8RwDg/
+MCRVpjOboDoe4SxxKjkCOvKiCHGDvc4krqi6Z1n0UfqzxGfmatCuFibcC1wps 
PRdW+gGsutPTLzvueMWmFhwYmfIFpbBu95t501+rSLHIEuujM/+PXr9Cky6Ed +W3JT24="
    }
  }
},
"proof": { ... } }

6.2.3 Delegation through Profiles

Through the use of profiles, the subject delegates a credential to a holder, by issuing a new credential in which: the issuer is the subject, the subject is the delegated holder, and the claim contains the property to be delegated. In addition, the delegated holder creates a profile that contains these two credentials, and a relationships property in which one relationship refers to the original subject and has the value 'delegate' and the other relationship refers to the delegated credential and has the value 'self'.
Example 12: An example of delegation using a profile

{
  "id": "did:example:ebfeb1c276e12ec211f712ebc6f",
  "type": ["VerifiableProfile"],
  "holderid": "did:example:76e12ec21ebhyu1f712ebc6f1z2"
  "relationships": [
      {
      "subjectid": "did:example:ebfeb1f712ebc6f1c276e12ec21",
      "relationship": "delegate"
       },
       {
      "subjectid": "did:example:76e12ec21ebhyu1f712ebc6f1z2",
      "relationship": "self"
       }
    ]
  "credential": [
       "id": "http://example.gov/credentials/3732",
       "type": ["Credential", "Role"],
       "issuer": "https://dmv.example.gov",
       "issued": "2010-01-01",
       "claim": {
         "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
         "role": "Project Manager”
         },
       "revocation": {
       "id": "http://example.gov/revocations/738",
       "type": "SimpleRevocationList2017" },
       "proof": {
.....
     },
    {
    "id": "some other ID",
    "type": ["Credential", "DelagatedCredential"],
    "issuer": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "issued": "2010-01-03",
    "claim": {
      "id": "did:example:76e12ec21ebhyu1f712ebc6f1z2",
      "role": "Project Manager”
    },
    "proof": {
    "type": "RsaSignature2018",
    "created": "2017-06-17T10:03:48Z",
    "creator": "did:example:ebfeb1f712ebc6f1c276e12ec21/keys/234",
    "nonce": "d61c4599-0cc2-4479-9efc-c63add3a43b2",
    "signatureValue": "pYw8XNi1bgVg/sCneO4BavEll0/I1zJugez8RwDg/+
ibcC1wpsMCRVpjOboDoe4SxxKjkCOvKiCHGDvc4krqi6Z1n0UfqzxGfmatCuF
zvueMWmFPRdW+gGsutPTLhwYmfIFpbBu95t501+rSLHIEuujM/+PXr+W3JT24
9Cky6Ed="
    }
  }],
  "proof": [{
  "type": "RsaSignature2018",
  "created": "2017-06-18T21:19:10Z",
  "creator": "did:example:76e12ec21ebhyu1f712ebc6f1z2/keys/2",
  "nonce": "c0ae1c8e-c7e7-469f-b252-86e6a0e7387e",
  "signatureValue": "BavEll0/I1zpYw8XNi1bgVg/sCneO4Jugez8RwDg/+
MCRVpjOboDoe4SxxKjkCOvKiCHGDvc4krqi6Z1n0UfqzxGfmatCuFibcC1wps
PRdW+gGsutPTLzvueMWmFhwYmfIFpbBu95t501+rSLHIEuujM/+PXr9Cky6Ed
+W3JT24="
  }]
}

[David-Chadwick]

I believe that this issue can now be closed as the PR has been issued and the discussion will continue on the PR page.

[Drabiv]

A comment to the central premise of this issue and this diagram https://lists.w3.org/Archives/Public/public-vc-wg/2018Jan/att-0006/SubjectHolder.jpg

The statement that "Subject=Holder" is the most common case is not correct.

It is a common practice to provide identification documents to counterparties in dealings when relatively high stakes involved (buying/selling/renting something expensive). It is also very common and often legally required to make copies of identification documents (passport, driving license) and to attach them to contracts, agreements or to store them separately.

With digital credentials, copy = original. Thus whenever deal is struck digital credential is going to be provided to counterparty and stored by it.

Hence, situation when Subject≠Holder will be much more prevalent than Subject=Holder.