Re: Macaroons: capabilities vs credentials
Tony Arcieri <[email protected]>
| Newsgroups | gmane.comp.capabilities.general |
|---|---|
| Message-ID | <CAHOTMV+wozKM=C5Y2K2K9dQsa8ftUN4aTO3cAbCxyyn1QYkRRQ@mail.gmail.com> |
On Wed, Dec 10, 2014 at 9:53 PM, David Barbour <[email protected]> wrote: > 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. > Macaroons make minting a unique credential which precisely authorizes a particular request easy, and I think this is one of their most interesting properties. For every request a client might create a new Macaroon which expires immediately and only authorizes a precise action. In the paper they describe these sorts of credentials as living for only a few seconds. Other systems have used HMAC-based constructions in this capacity (e.g. Amazon S3) but Macaroons enable any bearer of a token to add caveats and pass it along capability-style (unless "contextual caveats" have been added to bind a token to a single bearer), and any holder of the attenuated token can further use that to mint unique-token-per-request credentials. In contrast to a system like Amazon S3, where the client holds an HMAC key which is shared with the server, in a Macaroons-based system the key is held only by a particular target service, and a client can "sign" a request by encoding the parameters of the request as caveats in a request-specific Macaroon and authenticating them via a chained HMAC scheme. -- Tony Arcieri _______________________________________________ cap-talk mailing list [email protected] http://www.eros-os.org/mailman/listinfo/cap-talk