-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Subject NE Holder #106
Comments
I propose to change 6.3 to the following 6.3. Holder Acts on Behalf of Subject 6.3.1 Relationship Property Example 6.4: An example of the relationship property, where a parent asserts their child is under 16
6.4 Issuer Authorises Holder 6.4.1 Holder ID Property Example 6.5. A credential issued to a holder
6.5 Holder Acts on Behalf of Verifier 6.6 Holder has no relationship to Subject, Issuer or Verifier |
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:
This says that the subject is a parent, but not to whom they're a parent. I suggest something like:
-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: |
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. |
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 |
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. 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.
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.
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'.
|
I believe that this issue can now be closed as the PR has been issued and the discussion will continue on the PR page. |
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. |
PR #198 addressing this was merged. Please reopen if needed. |
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.
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
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
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
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: