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

Reply via email to