Subject NE Holder #106

David-Chadwick · 2018-02-06T09:15:29Z

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.

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.

The text was updated successfully, but these errors were encountered:

David-Chadwick · 2018-02-25T17:17:08Z

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 · 2018-02-25T18:40:10Z

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 · 2018-02-25T19:21:57Z

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 · 2018-02-25T19:26:19Z

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 · 2018-02-26T18:11:12Z

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 · 2018-02-28T18:54:59Z

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 · 2018-07-13T16:42:22Z

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.

burnburn · 2018-08-29T16:15:52Z

PR #198 addressing this was merged. Please reopen if needed.

stonematt added this to the VCM2: Resolve Subject != Holder milestone Feb 13, 2018

burnburn mentioned this issue Feb 27, 2018

Profiles #107

Closed

burnburn added the ready for PR This issue is ready for a Pull Request to be created to resolve it label Feb 27, 2018

burnburn assigned David-Chadwick Feb 27, 2018

David-Chadwick mentioned this issue Mar 13, 2018

ADD a new section on Subject NE Holder. #122

Closed

burnburn mentioned this issue Jun 15, 2018

Added a new section on Subject NE Holder #169

Closed

burnburn added pr exists and removed ready for PR This issue is ready for a Pull Request to be created to resolve it labels Jun 25, 2018

burnburn closed this as completed Aug 29, 2018

RieksJ mentioned this issue Mar 19, 2019

Does 'subject' relate to credentials or to claims? #464

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Subject NE Holder #106

Subject NE Holder #106

David-Chadwick commented Feb 6, 2018 •

edited by msporny

David-Chadwick commented Feb 25, 2018 •

edited by msporny

msporny commented Feb 25, 2018

David-Chadwick commented Feb 25, 2018

David-Chadwick commented Feb 25, 2018

David-Chadwick commented Feb 26, 2018 •

edited

David-Chadwick commented Feb 28, 2018

Drabiv commented Jul 13, 2018 •

edited

burnburn commented Aug 29, 2018

Subject NE Holder #106

Subject NE Holder #106

Comments

David-Chadwick commented Feb 6, 2018 • edited by msporny

David-Chadwick commented Feb 25, 2018 • edited by msporny

msporny commented Feb 25, 2018

David-Chadwick commented Feb 25, 2018

David-Chadwick commented Feb 25, 2018

David-Chadwick commented Feb 26, 2018 • edited

David-Chadwick commented Feb 28, 2018

Drabiv commented Jul 13, 2018 • edited

burnburn commented Aug 29, 2018

David-Chadwick commented Feb 6, 2018 •

edited by msporny

David-Chadwick commented Feb 25, 2018 •

edited by msporny

David-Chadwick commented Feb 26, 2018 •

edited

Drabiv commented Jul 13, 2018 •

edited