[cap-talk] Capabilities - the rub, identity

Jed at Webstart donnelley1 at webstart.com
Tue Nov 21 19:31:05 CST 2006

At 11:58 AM 11/18/2006, John Carlson wrote:

>Maybe we should try to clairify the difference between capabilities
>and public key encryption, since Jed has married them in my brain.

The base concept of a capability is simply a communicable permission
token.  Such tokens can be implemented as protected descriptors (e.g.
as in the Dennis and Van Horn model and more recently in systems like
KeyKOS, EROS, and even Plash and Polaris) or they can be implemented
as capabilities as data - e.g. as YURLs, Amoebe capabilities, capabilities
in NLTSS (e.g. acl based or PKI based), etc.

>My understanding is that the capability is what is encrypted or signed.
>encrypting or signing something doesn't alone give you any authority.
>Thus the 2-factor capability is the marriage between your public key
>identity and the normal capability.  They must go together to allow
>the system to work.
>The capability must be signed by the system for it to be used as a
>The system will only honor capabilities that are signed by an account
>holder, and that account must be in the system's public key ring- AN
>I'm getting tired of treating capabilities separately from ACLS when
>they can be clearly used together.  Read Jed's paper!
>Argh!  No wonder everyone's frustrated with capability people!

Gulp.  Of course I consider myself a "capability person".  In fact my
colleagues used to refer to me as "Mr. Capability".  Perhaps there are
others on this list in that boat.

I do believe that the relevant abstraction for a "capability" is a
communicable permission token.  However such communication
of a permission is implemented, IMHO it deserves the term "capability",
whether implemented as a protected descriptor (DVH, RATS, KeyKOS,
EROS, etc., etc.), using a PKI infrastructure (as in:


) or other cryptographic "password" capabilities (e.g. YURLs) or
even if implemented using an access control list, e.g. as in:

and in DCCS: http://www.webstart.com/jed/papers/DCCS/

The relevant factor for me is that the permission can be communicated
wherever communication is possible.  We know that any permission
can be communicated by proxy in any case (communicating conspirators),
so why not make the means available and convenient to communicate
such access directly?  Doing so allows more auditing at least and
potentially some better management (e.g. revocation) if not any additional
real control (since proxying can be done in any case).

I believe the principle that capabilities can always be delegated (in
opposition to the notion of a "can delegate" permission) should be
inviolate - since as we know proxying can always be done.

The place where access control by capabilities and access control
by identity based ACLs come into conflict I believe is when:

1.  Implementations only allow "owner"s to change the acls
(not any domain with a permission), and

2.  Identities (and owners and domains) end up being
anthropomorphized to the extent that they can only
effectively represent people (or at least broad person-like
virtual identities).  In particular there is no viable means to
restrict access on a per process basis.

This is the area I believe we need to focus on if we are ever to
reverse the fortunes of the object/capability model in commercial

--Jed http://www.webstart.com/jed/ 

More information about the cap-talk mailing list