[cap-talk] request for comments on capability design

[Karp, Alan H]

Peter Amstutz wrote:
> 
>  * The capability key determines access.  When making a request, the 
> client furnishes the capability key as part of the message.  
> The server 
> receives the message, looks up the capability key in a table 
> stored on 
> that object, and fetches a security context.  

This sounds like a classical c-list implementation if the capability key
is the only way to designate the object.

>                                               The security context 
> describes what permissions are granted to the capability as well as 
> accounting information (such as who the capability originally 
> given to).  
> The security context determines if the message method is permitted on 
> the object.
> 
We did something similar with Client Utility (the precursor to e-speak).
However, we kept a separate list for each authenticated channel.  Also,
we did not want the security context to need to understand the
application semantics.  Instead, we had the security context forward the
permissions to the endpoint and let it make the decision.  An
alternative (probably better) approach is to have a different capability
key for each permission.  That's what we did in our first prototype.  I
can rationalize why we made the change, but I can't justify it.
> 
> My question is, is this a real capability system?  It is 
> modeled largely 
> on my understanding of E from http://erights.org and from discussions 
> with Kevin Reid on IRC.  

It is a capability system if you combine designation with authorization.

> I'm also curious how user, group and role-based 
> abstractions are best built using capabilities; in particular in the 
> situation where the user is on a public terminal, makes a transient 
> connection to a remote service and must authenticate himself 
> in order to 
> gain access to his files.
> 
Why would you want to build user, group, roles with capabilities?  Those
are hacks introduced in a vain attempt to make ACLs manageable.
Entering the system, whether from a public terminal or not, always
requires special handling.  All you need is a way for someone to attach
to a powerbox (sometimes called a user agent).  We refer to these people
as users, but in reality the system only cares what rights are available
for requests made over some channel.  A person could choose to attach to
a personal powerbox, one shared by members of a group, or one associated
with some role.  To the system it's just a powerbox.  The distinction is
entirely how people manage access to it.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp