Skip to content

Commit

Permalink
Reword Authorization section based on @David-Chadwick's feedback.
Browse files Browse the repository at this point in the history
  • Loading branch information
@msporny
msporny committed Nov 1, 2018
1 parent ec06fbc commit b4be879
Showing 1 changed file with 12 additions and 8 deletions.
20 changes: 12 additions & 8 deletions index.html
View file
Expand Up @@ -2047,14 +2047,18 @@ <h2>Disputes</h2>
<h2>Authorization</h2>

<p>
It is arguable that <a>verifiable credentials</a> or
<a>verifiable presentations</a> should be used as authorization mechanisms
that a <a>holder</a> could use to access various
systems. This specification does not contemplate such a usage of verifiable
credentials and MUST NOT be considered an authorization framework on its own.
The Working Group did consider authorization use cases
during the creation of this specification and is pursuing that work as an
architectural layer that is built on top of this specification.
<a>Verifiable credentials</a> are intended as a means of reliably identifying
subjects. Whilst it is recognized that Role Based Access Controls (RBAC) and
Attribute Based Access Controls (ABAC) rely on this identification as a means
of authorizing subjects to access resources, this specification
MUST NOT be used for authorization purposes without an accompanying
authorization framework.
</p>

<p>
The Working Group did consider authorization use cases during the creation of
this specification and is pursuing that work as an architectural layer that is
built on top of this specification.
</p>

</section>
Expand Down

14 comments on commit b4be879

@David-Chadwick
Copy link
Contributor

Choose a reason for hiding this comment

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

This text is fine for me. But we must ensure that the rest of the data model document falls in line with this statement. In particular we cannot have the subject delegating a VC to a holder by issuing another VC, as that is blatant authorisation. Restricting holders to subjects would solve this, but is extremely limiting. How do we address this Gordian knot of subject NE holder without authorisation?

@jandrieu
Copy link
Contributor

Choose a reason for hiding this comment

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

The only way a holder can issue another VC with a new subject and the same issuer would be if they control the issuer's keys. In which case all bets are off.

We have to assume the keys are safely maintained. In which case, the holder can't issue another VC in the way you suggest.

@David-Chadwick
Copy link
Contributor

Choose a reason for hiding this comment

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

@jandrieu . Sorry but you have misread what I wrote. The subject is issuing the other VC. Consequently the subject is the issuer. I never said or implied that the subject would try to masquerade as the original issuer. This is clearly not possible unless they stole the issuer's keys. In delegation chains, the subject of the first credential becomes the issuer of the next credential. And as delegation has been ruled out of scope we still have this Gordian knot to untie.

@jandrieu
Copy link
Contributor

Choose a reason for hiding this comment

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

Ok. But anyone can say anything about anyone. So I'm not understanding your concern. Of course a holder can issue a VC. But that's not delegation, that's just a new VC. No relation to the old VC. I also don't see how making subject=holder solves your concern (so I'm not understanding your use case). The holder could just issue a VC where subject = the new holder, and still have your "delegation". It seems like you are assuming some sort of naive delegation, accepted by the verifier regardless of issuer. But that isn't how VCs work.

That said I have more problems with the phrase "Verifiable credentials are intended as a means of reliably identifying
subjects." That simply isn't true. VCs are a way for verifiers to be able to reliably accept statements made by someone (the issuer) other than the presenter (aka the holder).

Identity assurance is significantly downstream from the verifiable credential. Which is why it's a bad idea to assume subject= holder. Other means must be used, preferably a superiority of information, to establish whether the subject is in fact the active individual behind the presentation.

@David-Chadwick
Copy link
Contributor

Choose a reason for hiding this comment

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

My concern is that the verifier needs to know when it can "reliably accept" a VC. The verifier needs to be able to determine the difference between the following presentations:

a) when the original holder is the subject, and the subject passes the VC to a third party, and the third party passes the VC to the verifier in a VP, and
b) when the original holder is the third party, and the third party passes it to the verifier in a VP, and
c) when an attacker picks up a copy of a VC and passes it to the verifier in a VP, and
d) when the original holder is the subject, and the subject passes the VC to a third party who passes it to a verifier in a VP, when the issuer intended that the VC was only ever to be presented by the subject.

In each case the verifier is receiving the VC and VP from a third party holder who is not the subject. In cases a) and b) the VC should be accepted, whilst in cases c) and d) it should be rejected.

My concern is that the data model should contain sufficient information to allow the verifier to determine when it can reliably accept the VP and embedded VC(s).

As to your second point about VCs being a means of identification, you said "VCs are a way for verifiers to be able to reliably accept statements made by someone (the issuer) other than the presenter (aka the holder)." I would say in the vast majority of uses, the VC holder will be the subject so you statement does not apply to the vast majority of uses. And in the cases where your statement does apply, the holder is not the subject, then my concern above addresses you point about "reliably accept". How does the verifier know that it can reliably accept the VC? You said "other means must be used", but I am not sure what you mean by this. I am saying that the data model should be used whenever possible, and that we should include information in our data model document to allow the verifier to determine "reliably accept"

@jandrieu
Copy link
Contributor

Choose a reason for hiding this comment

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

I think I've identified the disconnect. I believe your examples suffer from a lack of explicit assertion about whether or not the transmitter of the VC is claiming to be the subject.

In (a), since you accept that, I must presume the third party is not asserting they are the subject (they are just a middle man without interference).

In (b), it's not clear if the "third party" holder is the subject, but I'm guessing they are and that in their VP they are asserting they are (implicitly or otherwise), which is fine since you accept that.

In (c), I must presume the "attacker" is asserting they are the subject when they aren't, which is bad.

In (d), it's not clear if the third party is asserting they are the subject or not. If they are, that's bad. If they aren't, then IMO, that's an inappropriate restraint on the use of VCs by the issuer. It's one thing for the DMV to say that my license only applies to me. It's another thing altogether to say that anyone who transmits my drivers license without claiming to be me is violating the TOU. That only I can send that sequence of bits over the wire. That's an iteration of the eternal failure of DRM to prevent the flow of information. We can't restrict the distribution of the VC, we can only provide means for dealing with assertions that the transmitter is the subject.

It seems to me it's the implied assertion that the "passing of a VC" means the holder is the subject that is the problem.

As I discuss in my comment in #252 The use case of Sam, claiming his citizenship has a Verifiable Presentation that includes two VCs for which Sam is not claiming to be the subject. Although he is "passing the VC" to the verifier, there is no claim that he is the subject (in the VP) and the verifier should not assume that he is making such a claim. In fact, the Verifier should NEVER assume the holder is making the claim that they are the subject.

If I've identified the disconnect, we should definitely clarify this.

With a lot of effort, I believe I understand how your use cases are addressed.

Reading through to the RsaSignature2018 suite, i see that the "creator" field" of the proof section is presumably where, if you have the same value as the subject of the VC which is also the same value as the id of the VP, then you would know the VP was signed by subject of the original VC. That would "prove" that the VP is signed by the subject of the VC and therefore, the holder = subject.

I'm hoping @msporny or @dlongley can verify if I'm understanding that this is the mechanism in the current spec for addressing @David-Chadwick's use cases.

We have at least three situations where this implied assertion is a poor choice:

  1. the holder isn't the subject, and is NOT pretending to be the subject (as in Sam's case in the citizen use case),
  2. the signing of the VP is done with a key other than that associated with the subject of the VC, but for which the holder is claiming to be the subject. This is inevitable with long-lived credentials, and
  3. there are multiple subjects and/or multiple VCs in the presentation, precluding a simple 1:1 mapping from the proof creator to a VC id.

How one handles the above cases is, unfortunately, left as an exercise for the reader, but there isn't even language explaining that it's the creator field that gives the clue to solve David's question.

It reminds me of the old adage: the course was very thorough. If it wasn't in the homework, it was on the final exam. I do think David's concerns are addressed when the proof creator = the subject of an included vc, but it took a lot to tease that out. And we have no discussion of how the more complex variations above are addressed.

FWIW, I believe #2 and #3 currently are to be addressed by an additional self-asserted credential in which claims are made relating the subjects of other VCs to the holder of the presentation. But maybe I'm misunderstanding how poor Sam might establish his claim to citizenship.

Finally, you are correct. I mispoke.

I meant my point that VCs are not intended as a means of identifying subjects. They are not on their own a means of identity assurance. The verifiability of VCs has only proof-of-control for assurance, which is grossly insufficient. However, my statement of what VCs are was not quite correct. Here's a correction.

VCs are a way for verifiers to be able to reliably accept statements made by someone (the issuer) without needing to trust where it came from and without contacting the issuer for verification.

The point is you can't presume to trust how the VC arrived at the verifier. You can't trust the wallet software. You can't trust the SSL or eek http channel. You can't trust the presenter who may or may not be the holder who signed the presentation, much less may not be the subject.

All you can trust is the math. Not who gives it to you or how you get it. You certainly can't trust that subject=holder unless the math links those identifiers cryptographicaly.

@msporny
Copy link
Member Author

@msporny msporny commented on b4be879 Nov 9, 2018 •
edited

Choose a reason for hiding this comment

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

I'm hoping @msporny or @dlongley can verify if I'm understanding that this is the mechanism in the current spec for addressing @David-Chadwick's use cases.

More or less, but with a minor correction. To see if subject===holder, a verifier would:

  1. Look in the claim of a VC and extract the id... this is the subject identifier.
  2. Look at the proof of the VP that encapsulates the VC and extract the creator of the proof, which is (an I'm over simplifying here) going to be a public key identifier.
  3. Look up the public key identifier, which will give you a machine-readable document (e.g., a DID Document).
  4. Check to see who the (using your term, @jandrieu, which we're probably going to adopt) controller of the key is, which will be another URL of some sort (e.g., a DID).
  5. Look up the public key controller, which will give you a machine-readable document (e.g., a DID Document, most likely the same DID Document that you got in step 3).
  6. Check to see that the public key controller claims that the public key identifier is theirs and that it's used for authentication. This establishes a bidirectional relationship between the public key controller and the public key -- if you don't do both, there are cryptographic attacks that become possible under certain conditions that mix URL types.
  7. Finally, if the subject identifier in the VC and the public key controller in the DID Document are the same, then subject===holder.

A bit overly detailed, but that's exactly how it is implemented, IIRC.

@David-Chadwick
Copy link
Contributor

Choose a reason for hiding this comment

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

@jandrieu "I think I've identified the disconnect. I believe your examples suffer from a lack of explicit assertion about whether or not the transmitter of the VC is claiming to be the subject."

The holder is definitely NOT claiming to be the subject. No masquerade is involved. I said that In each of the 4 cases the verifier is receiving the VC and VP from a third party holder who is not the subject.

I have never had any issues or problems in the cases where the holder is the subject and is claiming to be the subject. Except in the case of key update this should be trivial to verify. (And X.509 has a solution for CA key update that works, so this is not particularly of concern to me either.)

@jandrieu if you look at my 4 cases again, in the light of the above explanation, I think you will see that the verifier has a problem that our current maths cannot solve.

@jandrieu
Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, but you never said whether or not "passing the VC" to a verifier means creating a VP in which the holder claims to be the subject. This is what I believe you are assuming. That making a VP and giving it to a verifier implies the assertion by the holder (who is not the subject) that they are the subject. It does not. The verifier shouldn't expect that it does.

Ok. Let's look at the 2 cases you have problems with.

c) when an attacker picks up a copy of a VC and passes it to the verifier in a VP, and

Unless the "attacker" makes the assertion that they are the subject (and they aren't), then there is no problem. The Verifier should NOT assume the presenter/attacker is the subject. In fact, the only way, today, for the "attacker" to assert they are the subject is by signing the VP with a creator ID equal to the subject ID (as detailed by @msporny above), which means one of two things.

Either the key is compromised and proof-of-control is not a reliable factor or the "attacker" is actually the subject which isn't a problem because it isn't actually an attack.

If you want some language explaining the limits of proof-of-control because it fails as an assurance factor when the key is stolen or compromised, that is probably a good idea. But my sense is that isn't what you were trying bring up, which means I probably still don't understand what this attacker is doing and why the verifier is confused about whether or not they are the subject.

d) when the original holder is the subject, and the subject passes the VC to a third party who passes it to a verifier in a VP, when the issuer intended that the VC was only ever to be presented by the subject.

This is either DRM and completely out of scope, or again, you're assuming the "presentation" implies the holder is claiming to be the subject, in which case the problem is the assumption, not the data model. Re-read my dissection of that above. There are plenty of presentations that in fact, rely on the flexibility that the holder may or may not be the subject of any one or more of the VCs included. If the VP has the subject-holder link between the proof and the VC, then the verifier can use proof-of-control to prove it. If the VP doesn't, then what you're trying to prevent is the transmittal of data contrary to a licensor's wishes, which is DRM and out of scope.

I believe the maths show exactly the distinctions you want. If the proof of the VP doesn't demonstrate that the creator of the VP is the subject, then there should be no conclusion by the verifier about the relationship of the holder to the VC.

@David-Chadwick
Copy link
Contributor

Choose a reason for hiding this comment

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

Let me try a different approach so see if we can address our disconnect. I am only addressing cases where

  1. the holder is not the subject
  2. the holder is not trying to masquerade as the subject (the holder is happy to be him/herself).
  3. the verifier does not know the subject or the holder (it only has a bunch of IDs)
  4. the subject's VC contains some implied benefit (direct or indirect) - I think this applies to all VCs, otherwise there is no point in possessing them.

The verifier needs to know under which circumstances it should accept the VC and VP from the holder and when it should refuse to accept them.

The following 2x2 matrix addresses all the possibilities as to when the verifier should accept or reject the VP and VC

                                              Holder is
                                    legitimate     thief/illegimate    
holder is             subject       1.Accept       2.Accept
claiming
benefit for           holder        3.Accept        4.Reject

Since the data model is generic then we cannot envisage all the use case that VCs will be developed for. Consequently we have to generate a specification that addresses all cases (as far as practicable).

Here are some examples of VCs for the 4 cases above

  1. A supermarket loyalty card that gives points to the subject.
  2. A supermarket loyalty card that gives points to the subject.
  3. A prescription, where the pharmacist gives the drugs to the holder (to take back to the subject)
  4. A prescription, where the pharmacist gives the drugs to the holder (to sell on the black market)

In my opinion we do a dis-service to the community if our data model does not allow the verifier to determine the difference between cases 3 and 4.

The solution is quite simple. The subject produces a VC and gives it to the holder, which indicates to the verifier that the holder is legimate. The holder presents both VCs to the verifier. In case 4. the holder will not have the second VC (the one issued by the subject) and therefore the verifier knows to reject the VP.

@jandrieu
Copy link
Contributor

Choose a reason for hiding this comment

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

Right. What you are trying to do is not what VCs are for.

The pattern you are describing is a delegatable authorization instead of an assertion about a subject. Which is out of scope.

In fact, the difference between 3 and 4 isn't just technically out of scope, it is fundamentally impossible without perfect knowledge of the future actions of the holder. Any holder who may be duly authorized to bring the drugs back to the subject could in fact change their mind and sell some or all of the drugs on the black market. This is a fundamentally unsolvable problem.

All that should be inferred from a verifiable credential are that the issuer stands by the claims asserted therein. In other words, that the claims about the subject are asserted as fact by the issuer.

You want to attach downstream authorization to that statement, and are raising the legitimate question about why this is problematic. It's problematic because it's not a problem that VCs solve. They are not designed to solve it. They shouldn't be interpreted to solve it. And, frankly, we probably need better language explaining why the use you favor is the "wrong way" to use VCs.

Although it may sound like I'm saying "you're wrong", I'm actually thrilled that you have brought up this drive to use VCs as authorization, because you are highlighting EXACTLY why they should NOT be used as authorization. When you treat VCs as authorization, you will absolutely create the problem you have above. It's inevitable. Because verifiability of VCs does nothing for the relationships you are trying to embody in them.

That's why authorization is out of scope. Because it's not what VCs are meant to do. We don't deal with the edge cases, we don't deal with the main cases. We intentionally carved a scope for VCs that allow anyone to verifiably say anything about anyone without needing to "phone home" to verify that statement is still valid. That's a huge step forward.

It is not authorization.

It doesn't handle delegation of authorization.

So... I'm fairly sure I understand what you're trying to do. I just think you're advocating for something that this group has consistently agreed is out of scope for VCs.

To your final point, you have just bootstrapped a proof-of-control delegation mechanism for a VC that authorizes a prescription. Great. But it still doesn't address your concern about the black market. And it also doesn't need any changes in VC spec. As you just described, it's a simple matter of business rules as to which one is recognized by the pharmacy. If you have a rule--by law, regulation, insurance policy, or otherwise--that the only way to redeem a prescription is to either be the subject or be acting on behalf of the subject, with a formal, cryptographic delegation, then that's perfectly a viable thing to do. There are many who would disagree that that's the best way to do it, but you can absolutely do it.

That is something you build on top of VCs, as has been said repeatedly (you are free to build authorization and delegation systems on top of VCs).

It is not part of VCs themselves.

@David-Chadwick
Copy link
Contributor

Choose a reason for hiding this comment

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

@jandrieu "What you are trying to do is not what VCs are for."

We fundamentally disagree about this. I think our specification also disagrees with you. Read the abstract of our specification again, repeated below

"Credentials are a part of our daily lives; driver's licenses are used to assert that we are capable of operating a motor vehicle, university degrees can be used to assert our level of education, and government-issued passports enable holders to travel between countries. This specification provides a mechanism to express these sorts of credentials on the Web in a way that is cryptographically secure, privacy respecting, and machine verifiable."

Now if that is not about authorisation, I don't know what is.

@jandrieu
Copy link
Contributor

Choose a reason for hiding this comment

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

Driver's license do not authorize you to drive any particular car, nor even authorize you to have access to a car on some sort of lottery / shared service. It just says that the state recognizes your ability to drive legally.

University degrees don't authorize anyone to do anything. They merely state that according to a given university, the subject has met certain requirements for a degree.

Passports don't authorize anyone to travel. They simply demonstrate that a given state has recognized the subject as a legitimate person under their jurisdiction. The traveller still needs permission from the destination country.

So... no. None of those are authorizations.

They are, however, statements by an issuer about a subject. Which is what VCs are.

@David-Chadwick
Copy link
Contributor

Choose a reason for hiding this comment

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

I beg to disagree with you. We are not talking about VCs in wallets, but VCs presented to verifiers. When a policeman stops you in your car, you show him your driving license to prove you are authorised to drive this car, and in fact, any car. (As an aside, this is the advantage of a VC to an object capability). If you do not have your license with you, you are in trouble. I am sure you are aware of this. The driving license is a necessary authorisation, though not sufficient. You also have to show your insurance VC as well. This also may allow you to drive any car not belonging to you (mine does) as well as the named car that you own.

When you apply for a job, showing your degree certificate may be a necessary (though not sufficient) authorisation token. Without it, you may be disqualified from applying. I am currently advertising for a researcher and a degree is a necessary qualification. We reject applications withouth degree certificates. So it is an authorisation.

In order to travel around Europe my passport is sufficient authorisation to enter any EC country. Without it, I will be refused entry. So it is an authorisation to enter the European country. (and again much better than an object capability as it is an authorisation for all countries in the world - again necessary but not always sufficient)

I believe that each of your use cases are examples of using VCs for authorisation.

Please sign in to comment.