[cap-talk] request for comments on capability design

[Peter Amstutz]

I finally got a chance to read the Horton paper and get back on track 
with thinking about capabilities.  I was interested note that it is 
essentially an elaboration of an idea I had described in my original 
message to this thread, with the added (and in retrospect very 
important) subtlety that the identity that is delegating authority is 
not given the opportunity to impersonate the identity it is delegating 
to.  I'm still mulling over how best to incorporate it into my design, 
but I appreciate the basic point.

More below:

On Thu, May 31, 2007 at 10:38:56AM -0700, Jed Donnelley wrote:

> >Well, both.  But yes, I am communicating references, and those
> >references can be passed around among clients.  The reason I use the
> >term "replication" is that the client may keep a cached copy of the data
> >so that local process requests are serviced immediately.
> 
> What data?  It sounds like you must have some specific semantics for
> these objects in mind.

Okay.  The object semantics are somewhat heavyweight which is why I 
avoided getting into it initially, but here it is:

A "virtual object" (vobject) as part of the Virtual Object System is an 
actor with the following semantics:

 * Each vobject is a separate logical thread of control.  Since creating 
100,000 OS threads for every object doesn't scale, this will be 
implemented using a mix of OS threads and continuation passing style.

 * Vobjects have no shared state and communicate via message passing.

 * Messages communicate primitive values (numbers, strings) plus object 
references/capabilities, and arrays/structs that can be decomposed into 
primitives (no recursive definitions).

 * A vobject has a list of "types" that it implements.  A type is an 
interface definition describing the messages (methods) accepted by the 
vobject, and the properties of the vobject.  Vobjects can be extended 
with new types at runtime, achiving a sort of dynamic multiple 
inheritance.  This sort of composition is very useful in practice, as it 
allows a number of orthogonal aspects to be grouped into a single 
logical object.

 * The vobject has a "child list" of outgoing references to other 
vobjects.  This is an ordered, associative list of (name, reference) 
pairs.  Vobject properties are also part of this list.

 * Vobjects are grouped into "sites".  A site is identified by a public 
key which is used to sign outgoing messages.  A site usually represents 
a single process (client or server).

I've omitted a few details but this should be sufficient to get the gist 
of the design.

> >I am also
> >working on a design that provides for replication of computation so that
> >the client optimistically computes results locally (in addition to
> >sending a message) in cases where responsiveness is important and/or
> >global consistancy doesn't matter.
> 
> How does a client know enough to compute what the server (with
> presumably more global information) would compute?

Since the client knows the type of object, it knows something about the 
expected behavior of methods -- or, if some kind of virtual machine is 
available, it can download a piece of code implementing the method.  If 
a method call can act using local information only (for example, 
changing the color of an object from green to blue) it can be applied 
locally, optimistically, for better interactive response.  Obviously 
this doesn't work in all cases, but it is a necessary feature for 
responsive user interfaces.

> >A replication would be a (reference, contents) pair.  So you have a copy
> >of some data that is owned remotely, but you're trying to avoid
> >downloading it again if it hasn't changed.
> 
> This sounds like some sort of file caching/locking mechanism, a rather
> specific sort of object.

As described above, I glossed over the details because I didn't think it 
was essential to my question -- in my system a "file" is really a set of 
properties associated with a vobject, and all vobjects are also 
"directories" that can hold references to other vobjects.

> >I should probably mention that one goal is that this protocol be useful
> >when in a broadcast environment, or doing multihop store-and-forward
> >routing.  Data integrity and who has authority to change that data is
> >important, but securing the actual contents is optional.
> 
> I'll be interested to hear how that impacts the design.  I don't know
> of any capability systems that have been impacted by such considerations.

I'm still figuring it out myself, actually.  One challenge I anticipate 
is having to distinguish between secure channels and cleartext channels, 
to ensure that sensitive capabilities don't get sent in cleartext.

> To handle revocation state must change in the server.  Not that I'm
> suggesting this as an implementation, but the signed data could
> be something as simple as an index into a sparse table.  Remove
> the entry at that index and the capability is revoked.

This sounds like more or less what I was planning to do.

Does the index itself need to be signed?  I'm not sure what the benefit 
of that would be, aside from defeating the "guess lots of numbers in the 
hopes of a 1/(2^64) chance of discovering a capability" type of attack, 
which is obviously the stupidest, most brute force attack you can mount 
on any capability system.

> I think the basic mechanisms apply across any communication means.
> Tyler's approach does leverage Web URLs, but I don't think that
> is essential.  Certainly the mechanisms that I describe in the
> managing domains paper applies across any general communication
> means.

Having looked at Waterken a bit, I can say that the primary difference 
is that I have a somewhat different object model (although one could 
probably establish a lossless mapping from one model to the other) and a 
different set of middleware requirements than your average web app, of 
which security is only one part.

-- 
[   Peter Amstutz  ][ tetron at interreality.org ][ peter.amstutz at gdit.com ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey:  pgpkeys.mit.edu  18C21DF7 ]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20070605/29b454c7/attachment.bin