Skip to content

Subjectnotequal holder #198

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.

Sign up for GitHub

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

Merged
merged 6 commits into from
Aug 14, 2018
Merged

Subjectnotequal holder #198

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
0143d24
Merge pull request #1 from w3c/gh-pages
David-Chadwick Jun 18, 2018
1f16971
Removed Relationship object
David-Chadwick Jul 9, 2018
6d143d3
Added figure
David-Chadwick Jul 9, 2018
3845507
Added figure
David-Chadwick Jul 9, 2018
7f64e6b
Updates to Address Comments
David-Chadwick Jul 19, 2018
e7c8d81
Removed Delegation
David-Chadwick Aug 6, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions diagrams/subject-ne-holder.svg
View file
Open in desktop
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
312 changes: 312 additions & 0 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1238,6 +1238,318 @@ <h2>Evidence</h2>
</p>

</section>
<section>

<h1>The Subject Is Not The Holder</h1>

<p>
This section describes how the data model supports use cases in which the holder
of the credential is not the subject of the credential.
</p>

<p>
The following diagram depicts those instances when the subject is not equal to
the holder.
</p>

<figure>
<img style="margin: auto; display: block;" width="75%" src="diagrams/subject-ne-holder.svg">
<figcaption style="text-align: center;">
Subject Holder Relationships in Verifiable Credentials.
</figcaption>
</figure>

<p>
The following sections describe how each of these instances are handled in
the data model
</p>


<section>
<h2>Credential Uniquely Identifies Subject</h2>

<p>
In this case, the claim may contain multiple properties that each provide
an aspect of the identity of the subject, and which together unambiguously identify
the subject. In this case, it does not matter who the holder is, since the verifier
can unambiguously identify the subject of the verifiable credential.
</p>

<pre class="example nohighlight" title="An example of a credential
that uniquely identifies a subject">

{
"id": "http://dmv.example.gov/credentials/3732",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing context, I suggest:

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in next version

"@context": ["https://w3id.org/credentials/v1", "https://schema.org/"]
"type": ["Credential", "IdentityCredential"],
"issuer": "https://dmv.example.gov/issuers/14",
"issued": "2010-01-01",
"claim": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"name": "Mr John Doe",
"address": {
"streetAddress": "10 Rue de Chose",
"postalCode": "98052",
"addressLocality": "Paris, France"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

},
"birthDate": "2001-01-01",
"gender": "http://schema.org/Male",
"birthPlace": {
"streetAddress": "36 Rue de Different",
"postalCode": "102435",
"addressLocality": "Paris"
"addressCountry": "FR"
},

"nationality": "FR",
},
"proof": { ...
}
}
</pre>


</section>

<section>
<h2>Subject Passes the Verifiable Credential to a Holder</h2>

<p>
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 a holder. The data model allows for both cases as follows. </p>

<p>
If only the subject is allowed to present the verifiable credential to a verifier, the issuer MUST insert the "subject only" Terms of Use into the verifiable credential, as defined below. </p>

<p>
If the subject is not forbidden by the issuer to pass the whole or part of a verifiable credential to a holder, for example, a patient may pass a prescription verifiable credential to a relative for the relative to present it to a pharmacist for dispensing, then the subject MUST issue a verifiable credential to the holder containing the claim properties that are being passed on, as described below. </p>

<section>

<h3> 'Subject Only' Terms of Use </h3>

<p>
The Subject Only Terms of Use states that a verifiable credential MUST only be presented to a verifier by the subject. If a verifier is presented with a verifiable credential containing the Subject Only Terms of Use, by anyone other than the subject, it MUST refuse to accept it.</p>

<pre class="example nohighlight" title="Subject Only termsOfUse property by an Issuer">
{
"id": "http://dmv.example.gov/credentials/3732",
"type": ["VerifiableCredential", "ProofOfAgeCredential"],
"issuer": "https://dmv.example.gov/issuers/14",
"issued": "2010-01-01T19:73:24Z",
"claim": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"ageOver": 21
},
<span class="highlight">"termsOfUse": [{
"type": "SubjectOnly",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

}]
}</span>,
"proof": { ... }
}
</pre>

</section>

<section>
<h3> Passing on a Verifiable Credential </h3>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


<p>

When the subject passes a verifiable credential to a
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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"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.

verifiable credentials.
</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"],
"credential": [{
"id": "http://example.gov/credentials/3732",
"type": ["Credential", "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": ["Credential", "PrescriptionCredential"],
"issuer": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"issued": "2010-01-03",
"claim": {
"id": "did:example:76e12ec21ebhyu1f712ebc6f1z2",
"prescription": {....}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

},
"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>
<h2>Holder Acts on Behalf of Subject</h2>

<p>
When the holder wants to act on behalf of the subject, the issuer SHOULD indicate this by
either including the relationship of the holder in the subject's <a>claim</a>,
or by issuing a separate relationship credential to the holder.
Either way, the relationship describes the relationship between the holder and the subject of the claim, and helps the verifier to decide whether to accept the verifiable credential or not. </p>

<p class="issue"> It is outside
the scope of this standard how the issuer verifies the subject, the holder and the
relationship between them.

<p>
Note: it is for further study which, if any, of these mechanisms is to be
standardised by the working group.

</p>


<pre class="example nohighlight" title="An example of the relationship
property in a child's credential, so that a parent can hold it">

{
"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,
"parent": {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this is the correct way to express a relationship between two entities.

"type": "Mother",
"id": "did:example:ebfeb1c276e12ec211f712ebc6f"
}
},
"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": "pY9...Cky6Ed = "
}
}
</pre>

<pre class="example nohighlight" title="An example of a relationship credential issued to
a parent so that the parent can hold their child's verifiable credentials">

{
"id": "http://dmv.example.gov/credentials/3732",
"type": ["Credential", "RelationshipCredential"],
"issuer": "https://dmv.example.gov/issuers/14",
"issued": "2010-01-01T19:73:24Z",
"claim": {
"id": "did:example:ebfeb1c276e12ec211f712ebc6f",
"child": {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, this is good.

"type": ["Person", "Child"],
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21"
}
},
"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": "pY9...Cky6Ed = "
}
}

</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>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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...


</section>

<section>
<h2>Issuer Authorises Holder</h2>

<p>
When the issuer wishes to authorise a holder to possess a credential that
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

describes a subject who is not the holder, and the holder has no known relationship
with the subject, then the issuer inserts the
relationship of the holder to itself into the subject's credential.
</p>


<pre class="example nohighlight" title="An example of a credential
issued to a holder who is not the subject of the credential, who has no relationship
with the subject of the credential, but who has a relationship with the issuer">

{
"id": "http://dmv.example.gov/credentials/3732",
"type": ["Credential", "NameAndAddress"],
"issuer": "https://dmv.example.gov/issuers/14",
"holder": {
"type": "LawEnforcement",
"id": "did:example:ebfeb1276e12ec21f712ebc6f1c"
},
"issued": "2010-01-01",
"claim": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"name": "Mr John Doe",
"address": "10 Some Street, Anytown, ThisLocal, Country X"
},
"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": "pY9...Cky6Ed = "
}
} </pre>




</section>

<section>
<h2>Holder Acts on Behalf of Verifier or has no Relationship with the
Subject, Issuer or Verifier</h1>

<p>

The data model currently does not support either of these scenarios. It is
for further study how they might be supported.
</p>
</section>

</section>

<section>
<h2>Disputes</h2>
Expand Down