[cap-talk] request for comments on capability design

[Jed Donnelley]

Peter Amstutz wrote:
> ...
>
> Objects are replicated from the "server" to "client" (I use these terms 
> for simplicity, it is actually more of a peer to peer system).  When the 
> client interacts with the replicated object, messages are sent back to 
> the server.  The server needs a way of deciding whether the client is 
> allowed to perform an action on an object.
Just working a bit on terminology - in the above when you say an object 
is "replicated"
from the server to a client, do you mean that a reference (pointer, 
capability, ...)
is communicated to the client?  Can clients communicate such references 
(capabilities)
among themselves?  If so then you are describing a capability system.  
If not then
I think I need more clarification.
> Also, for caching purposes 
> it should be possible to store and retrieve object replications to 
> persistant storage, so objects have a version, timestamp, and digital 
> signature that it can use to verify what version it has, and if the data 
> is authentic.
>   
Objects or references to objects?  I'm still a little bit puzzled by 
your terminology.
> So, there are two types of authority in this system.  There is the 
> authority to issue updates to a replicated object, and the authority to 
> ask an object on another site to be changed.
>   
How do these differ?  (still trying to reach understanding).
> The first type of authority seems pretty straightforward and a classic 
> use of public key cryptography which I've already described.
Perhaps, but:
> Knowing 
> the private key used to sign the communications is a very literal 
> implementation of the notion of capability.
>   
makes no sense to me.  I typically think of the private key as being 
owned by the object
server (e.g. see:

http://www.webstart.com/jed/papers/Managing-Domains/#s13

) for one system I worked on in this area.  E.g. this:

If c is the identification information for the resource, then any 
process able to obtain the data ServerSign(c) is assumed to have the 
right to access the resource. That is, if a process can produce a 
capability description "signed" by the server, then the capability is 
assumed to be valid.

Are you familiar with Tyler Close's web-calculus services model:

http://www.waterken.com/

?  Perhaps you could explain how what you are working on differs?
> The second type of authority is more complex, and where I'd like some 
> advice.  Just to get it out of the way, for reasons of efficiency and 
> concurrency, I believe this requires a distict approach from the first 
> type of authority, as distributing private keys on a per-object basis 
> (granting authority to publish a change to the object) creates as many 
> problems as it solves.
>   
Distributing private keys to communicate permissions seems a very bad 
idea to me in any case.
> I presently envision a capability system that looks like this:
>
>  * A fully qualified object identifier has three parts...
>
> 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.  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.
>
> Comments greatly appreciated,
> Peter
>   
Well ...  Generally it sounds to me like there is some substantial 
reinventing of the wheel going
on here.  You can see from my questions above that I'm not really sure 
what you are trying to
do or how.

Capability systems (now generally 'object/capability' systems for 
clarity) are quite simple.

1.  Active elements (processes, active objects) can only access objects 
if they have a
"capability" reference to the object.

2.  In so far as communication is enabled by #1, active elements can 
send and
receive capabilities across their existing capability references.

There are some interesting "details" that one can get into in terms of 
implementations, but
in terms of whether a system is a capability system, I believe the above 
decides it.

Regarding how user, group, and role-based abstractions in capability 
systems -
you happened to catch "us" (the capability community) at an interesting 
transition
point.

I would say that in the past the notion of a "user" in capability 
systems has
generally been a bootstrapping mechanism to access a bunch of capabilities -
e.g. in a directory dedicated to the "user".  That is, a "user" logs in
(e.g. username/password or whatever), the system finds that user's
bag of capabilities and gives it to some program (e.g. a shell) acting
on the user's behalf.  Generally I believe that's been it.  After that point
the user can send his/her capabilities anywhere that's permitted by
their existing capabilities, building up and sharing from there.
When a capability is invoked there is no notion of what "user"
invoked it.  "Groups" when they've existed in my experience have
been directories shared between some set of users.  Send a capability
to the directory to a process acting on the behalf of another user, and
that new user has been added to the "group."  Regarding "role-based"
abstractions - I really don't know.

One of the things that just happened (and so in the 40 year history
of capability systems must be considered just a recent blip) is that
some of us have described a mechanism for supporting the notion
of an "identity" (who did what?) in pure and simple object/capability
systems - a draft:

         Delegating Responsibility in Digital Systems:
                   Horton's "Who Done It?"

found at <http://www.erights.org/download/horton/document.pdf>

Of course you're welcome to consider that mechanism, but I would have to say
that it's still quite "raw" at this point.

Good luck with your development!

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