It seems like that is the only thing. Essentially, these are two completely different philosophies:
1- Authorization: each of us has a unique key to authenticate, and authorization is controlled server-side. For Adam to give Eve access to something, John must do so on the server, and all he tells Eve is "go ahead, you can do it now." 2- Capabilities: a unique key gives privilege rights for an action, and identifies the right to do that action, rather than the actor. You can share capabilities server-less. The problems I have with scenario 2 are: a- auditing (this is security, right?) is impossible. If Adam shares a key with Emily, we no longer know if it is Adam or Emily. b- behaviour is looser. Adam and Eve now share keys regularly, and may even share them outside I get the "no need to change anything on the server part," but IMHO the security issues outweigh. Now, if you combined them, that might be interesting from a security perspective, but that begins to sound a lot like Kerberos. On Fri, Feb 24, 2012 at 1:13 AM, Dan Yoder <[email protected]> wrote: > Perhaps the most significant thing about capabilities is that they > divorce identity from authorization. Adam can share a key with Eve and > now Eve has the associated privileges. > > I tried to outline the main advantages in the blog post: simplicity, > flexibility, and the intrinsic enforcement of the principle of least > privilege. If Adam wants Eve to be able to edit a particular blog > post, he can simply share an editing capability, without giving her > the ability to, say, delete the post entirely. And there is no server- > side logic involved in this action. It can be managed entirely by the > clients in a peer-to-peer fashion. > > You do need to protect and manage the keys, as you say, but I think > this is analogous to what happens in an identity-based system when you > manage roles and permissions. > > On Feb 22, 2:43 am, deitch <[email protected]> wrote: > > In a proper authorization system (as distinct from authentication), I > > have one credential - the one that identifies me as AD - and the > > system on the backend says, "I see that AD has authorization > > privileges to do actions A, B and D, but not C or E," and so allows me > > to do A. > > > > Here, rather than authenticating as AD, I authenticate as a capability > > to do A, i.e. a unique key that allows me to do action A (and a > > distinct one for B and one for D). Perhaps the capability > > authenticator identifies both me (authentication) and my capability to > > do A (authorization), so my capability key for action A (AD|A) would > > be unique from yours as DY (DY|A)? I still need to protect and manage > > the keys, in this case more than I would have if I just had the key > > identifying me as AD and relying on the backend system to check > > internally what authorization rights I have for A,B,D. > > > > What do I gain from having a separate key for each capability, as > > opposed to a single key authenticating me and relying on the system on > > which I am performing actions to manage authorization (or some > > delegated authorization manager)? What am I missing? > > > > On Feb 22, 5:28 am, Dan Yoder <[email protected]> wrote: > > > > > > > > > > > > > > > > > Our Web API uses a form of capability security. It's still evolving, > > > but I've written about what we've done thus far here: > > > > >http://www.spire.io/posts/web-capabilities.html > > > > > We'd love to hear from the Node community as to what they think of > > > this approach. > > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
