Re: Macaroons: capabilities vs credentials
David Barbour <[email protected]>
| Newsgroups | gmane.comp.capabilities.general |
|---|---|
| Message-ID | <CAAOQMSs7dMxVVxrJVwO=3qCiSSYEe-HprSgaPjsOcO6kKhFjcQ@mail.gmail.com> |
On Wed, Dec 10, 2014 at 10:28 PM, Tony Arcieri <[email protected]> wrote: > > I know the term "capability" is a bit sacred, and the authors of the paper > call Macaroons a credential instead of a capability. However, do Macaroons > fulfill the general ideals of capabilities? > Based on your description, and skimming the paper, I think these bearer credentials are not capabilities. They are, in principle, only weakly coupled to the resource or action being performed. Are users/programmers precisely selecting which credentials they use for each action? I suspect not. But it might be interesting to model them with capabilities and value sealing (sealer/unsealer pairs). There are patterns that can model contexts and insist a computation occur within a context (contextual confinement). Modeling each system in the other, and vice versa, would help show the strengths and flaws of each. My intuition is that the sort of evidence that macaroons can ask for might be rather ad-hoc and difficult to gather, which could greatly complicate application of the idea beyond testing a few de-facto standard conditions. > > Does a capability cease to be a capability (and become a "credential") if > bound to an authentication mechanism like a TLS client certificate? > Well, there's also the "which objects you're carrying" (bearer of authority, holder of key) vs. "specific use of an object" (invocation of authority, selection of key). I wonder if, in context, this difference might be the more important one. Binding to a TLS client certificate can be modeled in capability systems, e.g. as a rights amplification pattern using sealer/unsealer pairs. It's also possible to model keychain objects and bundles of authority and so on, but I wouldn't describe whole capability-patterns as capabilities. > Are "contextual caveats" a good idea? > Is "rights amplification" a good idea? Maybe for some problems, but it would be a complicated and inefficient foundation for distributing authority. I imagine your question has a similar answer. _______________________________________________ cap-talk mailing list [email protected] http://www.eros-os.org/mailman/listinfo/cap-talk