Skip to content
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

Jump to bottom

Subjectnotequal holder #198

Merged
merged 6 commits into from
Aug 14, 2018
Merged

Subjectnotequal holder #198

Changes from 2 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
363 changes: 363 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,369 @@ <h2>Evidence</h2>
</p>

</section>
<section>

<h1>Subject Not Equal To Holder</h1>
Copy link
Member

Choose a reason for hiding this comment

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

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

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


<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

"type": ["Credential", "ProofOfAgeCredential"],
"issuer": "https://dmv.example.gov/issuers/14",
"issued": "2010-01-01",
"claim": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"name": "Mr John Doe",
"address": "10 Some Street, Anytown, ThisLocal, Country X",
Copy link
Member

Choose a reason for hiding this comment

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

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

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

"dateOfBirth": "2001-01-01",
"gender": "male",
Copy link
Member

Choose a reason for hiding this comment

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

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

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

Done in next version

"placeOfBirth": "Anytown, ThisLocal, Country X",
Copy link
Member

Choose a reason for hiding this comment

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

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

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

"nationality": "X",
Copy link
Member

Choose a reason for hiding this comment

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

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

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

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


</section>

<section>
<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.
Copy link
Member

Choose a reason for hiding this comment

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

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

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)

Copy link
Member

Choose a reason for hiding this comment

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

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

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

</p>

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

</p>

<section>

<h3> Delegatable Property </h3>
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 stomping on what we expect OCAPs to be used for... don't know how I feel about this other than it makes me uneasy. Can you at least put a

beside it stating that the WG has not determined if this is the proper approach yet? I don't want this to keep this PR from getting into the spec.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We have had long discussions about OCAPs vs VCs and it is clear that there are separate use cases and roles for both of these.
Role delegation in organisations is very common - so common in fact that most organisations could not function without the ability to delegate roles. This is why the example is the delegation of a role.
RBAC is also very common in organisations, and role delegation is needed in this.

Copy link
Member

Choose a reason for hiding this comment

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

Role delegation in organisations is very common

I'd argue that role delegation in organizations, while common, is executed in very different ways... some of them, dangerously. I'd also argue that we need to be crystal clear about what "role delegation" means... because in may cases, it means "I'm granting permission for person X to do action Y for time period Z." ... but in reality, what usually happens is "I'm enabling person X to be me without restriction".

... and that's what it looks like you're modeling here, which is why I'm objecting to the data model enabling that scenario. It's the text book definition of ambient authority - https://en.wikipedia.org/wiki/Ambient_authority

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Delegation is essential for several reasons such as scalability and flexibility. I would argue that we cannot stop it from happening, so we should provide tools to support it.
Consider any large scale operation, such as credit cards, moving to VCs e.g. VISA. A verifier needs to trust VISA (at least) as the root of trust. VISA issues 'visa' VCs to issuing banks (there are literally thousands of these). An issuing bank issues 'visa' VCs to its customers. We don't want each verifier to have to configure all issuing banks into its trust store. This would be unmanagable. Instead the verifier checks the delegation chain from customer to issuing bank to VISA root of trust. But we have to stop customers issuing a 'visa' VC to someone else. The Delegatable Property does this quite neatly since by default no VC is delegatable. Only VISA has to put the Delegatable Property into the 'visa' VCs that it issues to issuing banks. And in so doing, we have made life much simpler for verifiers and issuers.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Substantial change has now been made in this section. Now delegation is forbidden unless the Delegatable property is added. (Previously delegation was the default that could optionally be forbidden).


<p>
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. A verifier that receives a verifiable
credential that is not delegatable MUST reject any verifiable credential that has
been delegated from it.

</p>

<pre class="example nohighlight" title="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": { ...
}
}
</pre>

</section>

<section>

<h3> Delegation through Recursion </h3>

<p>
With recursion, the subject issues a credential to the delegated holder in which:
Copy link
Member

Choose a reason for hiding this comment

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

This creates confused deputy attacks, doesn't it? I'm struggling to understand what the use case is here other than ones we know we don't want "Here, use my access badge"?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No I do not believe that delegation of an organisational role from one person to another person creates a confused deputy, as the delegate inherits the permissions of the delegator, which is what is intended.
Could you please explain why you think the delegate might be a confused deputy?

Copy link
Contributor

Choose a reason for hiding this comment

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

It does create a confused deputy problem because you're authorizing based on identity, and if you're authorizing based on identity you're holding onto a larger set of credentials about "who you are" rather than "what you're doing". It's not that the inheriting of permissions is unintended in the confused deputy... a confused deputy is usually behaving as designed, and that is part of the point of the confused deputy problem. I encourage reading the original confused deputy example. The problem is that the program holding that authority cannot distinguish the purpose for which it should be using its wide range of authority. This is why an identity-centric approach to authority will always lead to confused deputies... not because they are misprogrammed, but because the problem is inherent in that design.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@cwebber I beg to disagree with you. If I intend someone to take over my role, say because I am on holiday or ill for a period of time, then I do want them to inherit ALL my privileges. The purpose is clearly to inherit all my authority, otherwise they could not take on my role in its entirety. Most organisations today operated in this way. They cannot function without delegation.

Copy link
Member

Choose a reason for hiding this comment

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

@David-Chadwick, I think there are three statements you're making here that we need to separate:

  1. Organizations need to delegate authority.

I think everyone agrees on that.

  1. The way organizations delegate authority are Verifiable Credentials.

We do not have consensus on that and I really doubt we'll get there because this creates confused deputy and ambient authority issues. We have at least @cwebber, @dlongley, and myself in agreement on that (having put a tremendous amount of thought into this).

  1. You want to be able to grant ALL of your privileges to an entity.

This is the definition of confused deputy AND ambient authority and the academic and corporate literature on why this is a terrible security design paradigm goes back to the 1970s.

At this point, I suggest that we wipe the section you've authored on delegation, put an issue marker in there pointing to an issue on delegation when subject != holder, and sort the solution out in that issue.

I don't want to delay getting this PR merged due to this one issue, which doesn't seem like it's going to be resolved any time soon.

Copy link
Contributor

@dlongley dlongley Jul 19, 2018 •
edited
Loading

Choose a reason for hiding this comment

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

I want to clarify -- the ability to grant all privileges to another entity is not the confused deputy problem/ambient authority, rather, a system where there is only a binary choice of delegating all privileges (for all targets) or none at all leads straight to it.

People should be able to delegate authority. The system that enables it should allow for granularity from zero delegation to full (and everything in between). Furthermore, authority should be targeted.

The VC model is about identity not authority. It is also designed, primarily, to address use cases where a VC can be issued by one party and verified by many different parties. The issuer does not get to decide what privileges are granted by the verifier(s) (or for what targets); they merely make claims about attributes that subjects possess. That is not an appropriate design for decentralized authorization and delegation. But you can build something appropriate on top of it -- that uses identity as a starting place to instantiate rights/privileges. This is what OCAP-LD is for.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@dlongley. Thankyou for your clarification of confused deputy, which is very helpful to this discussion. I will go further than your clarification however, and say that confused deputy is not in essence to do with delegating authority, nor whether there is a binary choice in the delegation, but rather, it is when one party asks another party (the deputy) to perform an action that the deputy is authorised to perform but the requestor is not. In RBAC, the process of role delegation is separate from the process of requesting an action, so providing the process for requesting an action ensures that the requestor has full authority for the requested action, then the confused deputy problem cannot happen. Furthermore hierarchical RBAC allows for fine grained delegation of authority by delegating a subordinate role to the one possessed, so your issue of binary choice is not relevant here. Since the text on delegation is only concerned with delegation and not with requesting actions, then I do not see that the confused deputy problem is relevant to the proposed text.

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.
</p>
<p>
Note: the exact format of this credential has not yet been agreed by the working group
</p>
<pre class="example nohighlight" title="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": {
Copy link
Member

Choose a reason for hiding this comment

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

This property is now "verifiableCredential"

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

"id": "http://example.gov/credentials/3732",
"type": ["Credential", "Role"],
Copy link
Member

Choose a reason for hiding this comment

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

Should probably be RoleCredential... even though this is getting into OCAP territory... this feels like the wrong way to model this... we need a different use case here.

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

"issuer": "https://dmv.example.gov",
"issued": "2010-01-01",
"claim": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"role": "Project Manager"
Copy link
Member

Choose a reason for hiding this comment

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

Why role and not type? ... and wouldn't you want to also associate their role w/ an organization and department? Again, this is why we shouldn't be expressing this sort of access control stuff as a VC... it's too easy to mess up.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Because the property that is being delegated is the role.
Yes you could also associate organisation if needed. But typically the organisation will be the initial issuer who will issue roles to all its employees. And the organisation will be the root of trust for the verifier. So once an employee gets a role VC (issued by the organisation) and is allowed to delegate it to another employee, we do not really need the organisation name to be repeated in the delegated VC.

Copy link
Member

Choose a reason for hiding this comment

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

I understand and now am more strongly against the proposal. This will lead to ambient authority attacks and we must not suggest that as a standard operating practice in the core specification: https://en.wikipedia.org/wiki/Ambient_authority

Copy link
Member

Choose a reason for hiding this comment

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

I suggest that we do not support this use case in this version of the VC spec, noting that we may address it via OCAPs or in the next version of the specification and noting that delegation is very easy to get wrong and that extensions should be wary of any sort of delegation mechanism.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Two points

  1. By not mentioning delegation in the spec does not stop it from happening, but rather, allows unrestricted delegation to happen. This is what we learnt from v1 X.509, where anyone with an X.509 PKC could issue another PKC and thereby become a de-facto CA. We had to insert the basic constraints extension into v3 X.509 to stop this from happening. The Delegatable property that I am suggesting is equivalent to the X.509 basic constraints extension.
  2. Role delegation does not introduce vulnerabilities of either the confused deputy or ambient authority types because the delegation of all privileges assigned to the role is intended. To quote Wikipedia confused deputy is when "the associated permission changes unintentionally".

},
"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...W3JT24 = "
}
}
},
"proof": { ...
}
}

</pre>


</section>

<section>
<h3> Delegation through Verifiable Presentations </h3>

<p>

Through the use of verifiable presentations, the subject delegates a credential to a
holder, by issuing a new credential to the holder 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 verifiable presentation that contains these two credentials.
</p>



<pre class="example nohighlight" title="An example of delegation using a
verifiable presentation">
{
"id": "did:example:76e12ec21ebhyu1f712ebc6f1z2",
"type": ["VerifiablePresentation"],
"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": "https://some.dns.com/VC/123456789",
Copy link
Member

Choose a reason for hiding this comment

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

W3C specs are required to use example.com and example.org in examples. dns.com is a real website.

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

"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": "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 MAY indicate this by
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 good.

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

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

<p>
Copy link
Member

Choose a reason for hiding this comment

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

You need a class="issue" on the p tag.

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

Note: it is for further study which, if any, of the above 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