search

w3c-ccg / zcap-spec

WORK ITEM: Authorization Capabilities (ZCAP) specification
https://w3c-ccg.github.io/zcap-spec/
Other
30 stars 10 forks source link

Clearer explaination of what ocaps are #5

Open cwebber opened 6 years ago

cwebber commented 6 years ago

Object Capabilities is limited authority by possession; you are allowed to do something in a system because you hold something that allows you to do it. A valet key is a good example of an object capability. It lets someone start and move your car without being able to also open the trunk of the car.

Manu and I came up with this sentence together; it would be nice to include it in the document.

David-Chadwick commented 6 years ago

A bearer verifiable credential is exactly the same thing.

msporny commented 6 years ago

A bearer verifiable credential is exactly the same thing.

Yes, in fact a verifiable credential can be anything (because any entity can say anything about any other entity). The problem that was identified, though, is that abstracting that far out may be very dangerous wrt. security. Developers may not understand the nuances and as a result will build insecure systems.

Some in the group would like a bright line between VCs and OCAPs. We believe that this will result in more secure systems.

To put it another way... most computers process a stream of 1s and 0s, but it doesn't help to describe everything in that way. We have formats and abstractions to help ourselves and others reason about what particular formats and abstractions are used for.

In the same way, some of us believe that drawing a distinct line between VCs and OCAPs would result in more secure systems by aiding developers to think in clear terms about what each of them are used for.

David-Chadwick commented 6 years ago

I do not believe you are abstracting "that far out". A verifiable credential is an authorisation token (if it does not give you some privilege there is little point in having it). An OCAP is a bearer privilege. So a bearer VC and bearer OCAP are in fact identical in content and purpose. To separate them out into two different formats is an unnecessary complication requiring two separate pieces of code to process them instead of one, leading to double the chances of bugs and security vulnerabilities. So you are doing a dis-service to the security community by having two different ways of doing the same thing.

dlongley commented 6 years ago

@David-Chadwick,

The fact that a VC gives you a privilege does not mean that the VC needs to "be that privilege".

VCs make assertions about the attributes one possesses, which a system may use to determine capabilities. That does not mean that VCs also need to make assertions about the capabilities one possesses (note capabilities designate the resource(s) upon which one may act). Being granted a certain capability may be the result of providing a VC in a certain context.

I will say that perhaps the abstraction we're looking for can happen within the VC data model. I'm not yet convinced that's a non-viable path forward. What I mean by that is that we could define some OcapCredential type and make it clear that only this type of credential should be used as a capability.

But, I'm suspect that this will fit in easily with some of the assertions made by people in this group regarding a desire to "lock down the top level of the data model". For example, specifying caveats/attenuations would not be possible with this "lock down" unless the group made it so. That means taking on more work that may be out of scope.

cwebber commented 6 years ago

@David-Chadwick The original sentence I had before Manu made edits about it discussed the differences between the ocap perspective and identity-based perspectives:

"ocap is authority by posession, as opposed to authority by identity"

We can probably model ocap on top of verifiable claims, but it may lead to dangerous errors. VC are about identity, about ideas about a person, and so if we end up trying to implement these on top of VC we will probably result in people paying attention to the identity rather than running the invocation chain algorithm, which would transform this from an ocap model into an ACL model.

The question isn't whether or not we can specify this on top of VC, but whether we should.

cwebber commented 6 years ago

A bearer verifiable credential is exactly the same thing.

I will note that bearer instruments are useful, and oauth 2.0 bearer tokens are very similar to object capabilities. However, "seeing" a bearer instrument means having its power, and for example in Veres One, we need to pass around object capabilities without just "seeing" them meaning you have power over them. (Some capabilities do work in such a bearer token way that "seeing" them gives you their power too, notably Google's Macaroons do work that way too.) So it may be possible to build bearer token based capaiblities on top of VC, but that does not remove the use cases of ld-ocap.

David-Chadwick commented 6 years ago

@cwebber Sorry but I am not sure what you are calling an ACL model, and what you are calling something else.

Assume we have an authz token (it could be a VC or OCAP, the format is not important for now) that allows someone to drive a car. This authz token could say either

  1. "Fred is authorised to drive car X" or
  2. "the holder is authorised to drive car X" or
  3. "Fred is an authorised driver" or
  4. "the holder is an authorised driver". Which of these do you call an ACL model, and what do you call the model for the other non-ACL models?

Assume all tokens are signed by an issuer who is trusted by car X and car Y. When presented to car X, all tokens will allow the holder to drive it, provided in the first and third cases the holder can prove that he is Fred. When presented to car Y, only the latter two will allow the holder to drive it, provided the holder can prove he is Fred for the third token. Therefore using a level of indirection, to a role instead of a action-resource tuple, is a more powerful model in my opinion. Furthermore it also allows the token to be restricted to car X through a policy constraint.

Both cars need to understand what "drive car" means. In addition for tokens 3 and 4 to work, both cars also need to know that role 'driver' is allowed to "drive car". For tokens 1 and 3 to work, both cars need to know how to authenticated Fred.

VC are capable of encoding all 4 token types. What about OCAP?

cwebber commented 6 years ago

This issue is about clear explanation about what we mean by ocap. Let's move conversation about ocap vs ACLs to #6 (as well as whether ld-ocap on top of VCs would accidentally be an ACL or not).