Subjectnotequal holder #198

David-Chadwick · 2018-07-09T21:10:02Z

I have re-based PR #169 to the latest changes in github, and removed the relationship object. I do believe that it has now addressed all the issues that have been raised.

Preview | Diff

Rebasing (I hope!)

msporny

The expression of relationships is good. The section on delegation is problematic and should probably be removed... I'm afraid it wouldn't pass security review in its current state due to confused deputy attacks and ambient authority issues.

msporny · 2018-07-09T21:20:18Z

index.html

+	"claim": {
+		"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
+		"name": "Mr John Doe",
+		"address": "10 Some Street, Anytown, ThisLocal, Country X",


I suggest using schema.org's address property: https://schema.org/address

Done in next version

msporny · 2018-07-09T21:21:07Z

index.html

+that uniquely identifies a subject">
+
+{
+	"id": "http://dmv.example.gov/credentials/3732",


Missing context, I suggest:

"@context": ["https://w3id.org/credentials/v1", "https://schema.org/"]

Done in next version

msporny · 2018-07-09T21:23:04Z

index.html

+		"name": "Mr John Doe",
+		"address": "10 Some Street, Anytown, ThisLocal, Country X",
+		"dateOfBirth": "2001-01-01",
+		"gender": "male",


Suggest https://schema.org/GenderType is used... specifically "Male".

My reading of schema.org is that is should be
"gender": "http://schema.org/Male"
or
"gender": "Male"

Done in next version

msporny · 2018-07-09T21:23:30Z

index.html

+		"address": "10 Some Street, Anytown, ThisLocal, Country X",
+		"dateOfBirth": "2001-01-01",
+		"gender": "male",
+		"placeOfBirth": "Anytown, ThisLocal, Country X",


Try to use real data and https://schema.org/address

Done in next version

msporny · 2018-07-09T21:24:33Z

index.html

+		"dateOfBirth": "2001-01-01",
+		"gender": "male",
+		"placeOfBirth": "Anytown, ThisLocal, Country X",
+		"nationality": "X",


Use real data here... GB, FR, etc.

Done in next version

msporny · 2018-07-09T21:37:00Z

index.html

+	"issued": "2010-01-01T19:73:24Z",
+	"claim": {
+		"id": "did:example:ebfeb1c276e12ec211f712ebc6f",
+		"child": {


+1, this is good.

msporny · 2018-07-09T21:38:07Z

index.html

+
+</pre>
+
+<p> It can easily be seen from the above example how an authoritative issuer could indicate that a person is the owner of a pet dog </p>


While it may be self-explanatory, I feel like this may be the central use case: guardianship (of people, pets, and things).

The delegation bit seems like the wrong way to do things...

msporny · 2018-07-09T21:39:26Z

index.html

+      <h2>Issuer Authorises Holder</h2>
+
+      <p>
+When the issuer wishes to authorise a holder to possess a credential that 


I don't understand the use case here. Why does the law enforcement officer have this credential in the first place? It's not explained in the text.

OOPS. I have omitted the figure that goes at the start of the section. I will need to add it.
(But if you look at the figure in the previous PR, which shows all the cases where Subject NE Holder, you will see that Law Enforcement is one of the examples where a holder may be given a VC by an issuer without the subject being aware of this, or not requesting it.)

Why do we need to embed any of the information about the holder? Why doesn't the issuer just give the credential to the holder? Is this a VC use case?

When a police officer looks up information on a potential suspect, the system that looks the information up only cares that the police officer has authenticated themselves. I know of no law enforcement system that tags the data w/ the entity receiving the data. I can sort of see how this might be useful information, but wonder if we could generalize this even further.

Look at this from the perspective of the verifier. The verifier is given a VC (for subject A) by holder B. The verifier needs to know (at least):
a) why has B got hold of this VC?
b) how is B related to A?
c) does B have A's permission to handle A's VC?
d) who to trust?
The answer to d) is the issuer. This is part of our trust model. Now if the issuer inserts into the VC that B is the holder of the VC and is related to A in the following way, then the verifier has all the above questions answered for him. This is why it is beneficial for some of the use cases for the issuer to insert information about the holder into the VC.

Alternatively, if B is not related to A, then the verifier needs to know (at least)
a) why has B got hold of this VC?
b) how is B related to the issuer?
c) does B have the issuer's permission to handle A's VC?
d) who to trust.
Again, the verifier trusts the isssuer, and the issuer is saying that it gave the VC to the holder for it to present to verifiers, and that the holder is of the following type (which indicates the relationship between the issuer and the holder). So all the verifier's questions are answered.

@msporny. If the VC does not indicate who the holder is, and the verifier has to rely on the presentation (signed by the holder) to verify this, then I assert that this is not possible....
unless either:
a) the verifier modifies its trust policy (e.g. I trust X to hold this set of VCs) or
b) the holder presents some other credential proving that they have the right to hold the VCs of strangers.
I think what you are proposing unnecessarily complicates the work of either or both the verifier and the holder (and possibly the issuer as well).

d) who to trust?
The answer to d) is the issuer. This is part of our trust model.

Is it? I don't understand this statement. Anyone can say anything about anyone... VCs just give us a way to prove who's saying it. Just because Bob issues a claim of foo about Carol in this VC doesn't mean that I trust that Bob's claim is true... I just know that Bob said it. Deciding who I trust is a different step, internal to the program using the VC tooling, not part of the VC workflow itself, right?

Please read Section 4, point 1
"The verifier trusts the issuer to issue the credential that it receives. "
If the verifier does not trust the issuer it will most likely discard the VC.

msporny · 2018-07-09T21:41:02Z

index.html

@@ -1238,6 +1238,369 @@ <h2>Evidence</h2>
        </p>

      </section>
+<section>
+
+      <h1>Subject Not Equal To Holder</h1>


We need a less computer-science-y way to describe these scenarios.

Done in next version

msporny · 2018-07-09T21:43:52Z

index.html

+       <h2>Subject Delegates to Holder</h2>
+
+     <p>
+This is supported in the data model in two different ways: through the use of either recursion or verifiable presentations. Both methods involve the subject issuing a new verifiable credential to the delegated holder.


Why doesn't the subject just issue an ocap to the holder for a very specific grant of authority. Delegating a credential is dangerous because you're not also delegating what that delegation can be used for. For example, if I delegate a driver's license to you... does that mean you can use it to open a bank account online? or open a line of credit? Or get into a bar? How are the limitations for that grant put into place? This is why we have OCAPs.

People do not delegate driving licenses, or age credentials. These will clearly be marked as not delegatable (in fact this should be the default. The issuer should clearly mark a VC as delegatable if it wants it to be)

I'd argue that people don't delegate roles either. They grant permission to operate on their behalf, given their authority as a particular role in an organization. I don't say "here, have my key card so you can do anything I can" (ambient authority)... I say "here, have my key card so you can do X, and only X". That's an OCAP.

I guess we just have to disagree over this point. Role delegation is very common in RBAC systems, and VCs are a new way of handing out roles to employees. (Our existing software, PERMIS (www.openpermis.org) uses X.509 ACs to hold roles. It would be nice to move to VCs).

David-Chadwick · 2018-07-19T11:22:33Z

Concerning #203

The Subject NE Holder text on "Holder Acts on Behalf of Subject" goes some way to preventing the issue of an unreliable verifier forwarding the VC when it should not, because it addresses the case when the holder is authorised by the issuer to be the holder. Clearly the verifier is not the original holder, nor is it the subject, so VC forwarding is made more difficult in this case.

David-Chadwick · 2018-08-06T17:19:29Z

The latest version brings the text (and diagram) in line with the VC WG minutes of 31 July 2018

msporny

While I don't agree with some of the data modeling aspects of this PR, I think we can pull this PR in as long as I'm able to make an editorial pass and make some substantive changes to the data model in the sections that have been added. I continue to feel like there is a disconnect when it comes to delegation of X (credentials, properties, etc.), and the rework to the section while better, still attempts to do this.

I don't want to keep this PR out there any longer, I think it's frustrating everyone involved... so let's pull it in, knowing that it's not final, and I can make an editorial/substantive pass on it to see if @David-Chadwick would be okay with the result.

msporny · 2018-08-07T14:24:28Z

index.html

+		"address": {
+                   "streetAddress": "10 Rue de Chose",
+                   "postalCode": "98052",
+                   "addressLocality": "Paris, France"


This isn't quite correct, but we can fix it after we pull the PR in as it's editorial.

msporny · 2018-08-07T14:27:39Z

index.html

+    "ageOver": 21
+  },
+  <span class="highlight">"termsOfUse": [{
+    "type": "SubjectOnly",


I'm fine w/ pulling this PR in, even though I disagree with this way of modelling "Subject Only". I think we need to clean up the data model for "presenter must be subject" terms of use... or "presenter may differ from subject" terms of use. There are security attack vectors that we need to think through wrt. what the default should be wrt. allowing the presenter to not be the subject.

msporny · 2018-08-07T14:29:20Z

index.html

+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


"the claim contains the properties that are being passed on" creates an enormous amount of complexity when processing credentials that are handed off... We should probably make it an all or nothing thing for v1.0.

Again, fine with pulling this in as long as we can change this later.

msporny · 2018-08-07T14:31:10Z

index.html

+			"issued": "2010-01-03",
+			"claim": {
+				"id": "did:example:76e12ec21ebhyu1f712ebc6f1z2",
+				"prescription": {....}


This is the wrong way to model this... again, happy to pull the PR in as long as we can clean this up after we pull the PR in.

msporny · 2018-08-07T14:32:53Z

index.html

+       </section>
+
+  <section>
+   <h3> Passing on a Verifiable Credential </h3>


Upon further review, we need to remove this section or not support it... stating "I'm letting person X use attributes Y and Z of my credential" is the wrong way to solve the "delegation" problem.

msporny · 2018-08-14T14:19:33Z

Pulling this PR in and making the changes based on the conversation in the WG last week.

David-Chadwick added 2 commits June 18, 2018 18:00

Merge pull request #1 from w3c/gh-pages

0143d24

Rebasing (I hope!)

Removed Relationship object

1f16971

msporny requested changes Jul 9, 2018

View reviewed changes

David-Chadwick added 2 commits July 9, 2018 23:19

Added figure

6d143d3

Added figure

3845507

Updates to Address Comments

7f64e6b

cwebber mentioned this pull request Jul 19, 2018

Delegated authorization & VC distribution #204

Closed

agropper mentioned this pull request Jul 19, 2018

How to prevent a Verifier from acting as an unauthorised Holder #203

Closed

Removed Delegation

e7c8d81

msporny approved these changes Aug 7, 2018

View reviewed changes

msporny merged commit d806b05 into w3c:gh-pages Aug 14, 2018

burnburn mentioned this pull request Aug 29, 2018

Subject NE Holder #106

Closed

decentralgabe mentioned this pull request Sep 16, 2022

Representing Delegated Credentials in the VCDM #930

Closed


		</pre>

		<p> It can easily be seen from the above example how an authoritative issuer could indicate that a person is the owner of a pet dog </p>

Subjectnotequal holder #198

Subjectnotequal holder #198

Conversation

David-Chadwick commented Jul 9, 2018 • edited by pr-preview bot Loading

msporny left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

David-Chadwick commented Jul 19, 2018

David-Chadwick commented Aug 6, 2018

msporny left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

msporny commented Aug 14, 2018

David-Chadwick commented Jul 9, 2018 •

edited by pr-preview bot

Loading