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
