Re: Macaroons: capabilities vs credentials

On Thu, Dec 11, 2014 at 8:31 PM, Tony Arcieri <[email protected]> wrote:
>
> The way I see it though, you can either use something like a Macaroon or a
> proof of authority, or you have a crypto-capability:
>
> 1) in the Macaroon model, the service you're authorizing yourself to uses
> logic to determine if you're authorized
> 2) in the crypto-capability model, your authority derives itself merely by
> possession of the appropriate cryptographic keys to have a particular power
> in the protocol
>

> This is ultimately what it comes down to, right?
>

I don't believe so. It isn't just about "what you have". It's also about
"how you use it." The dynamics are different between bearer credentials and
capabilities, and some of those differences are significant to a security
analysis. For example, the confused deputy problem applies to bearer
credentials because the bearer can't easily make precise choices about
which set of credentials are in use for a specific action.



So Macaroons aren't capabilities. But could they be used as a framework to
> build capabilities?
>

Maybe.

Depending on the language we use with a macaroon, their nature can change a
lot. For example, we could, offline, build up a script that invokes
multiple capabilities on a remote machine, that filters inputs and return
values, and so on, and that only permits holders of the script to add code
either at the beginning or at the end (basic composition). In this use
case, the language needn't allow developers to say anything at all about
the bearer.

The idea of hash chaining as a basis for authorization doesn't need to be
used for bearer credentials.  That idea can be wielded effectively (and
perhaps much more so) in a capability-oriented manner. (Again, "how you use
it" matters.)

But to the extent we stick with the concept of bearer credentials, I doubt
a capability system would emerge. It isn't the path of least resistance.
And it may require using a restricted subset of the expressiveness of the
macaroon's language, or use it in awkward ways. Asking developers to use a
restricted subset of features doesn't have a very good history of success.

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk