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 <d...@xxxxxxxx> 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 nodejs@xxxxxxxxxxxxxxxx
To unsubscribe from this group, send email to
nodejs+unsubscribe@xxxxxxxxxxxxxxxx
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en