[cap-talk] request for comments on capability design

[Jed Donnelley]

At 08:38 PM 5/16/2007, Peter Amstutz wrote:
>On Wed, May 16, 2007 at 06:41:20PM -0700, Jed Donnelley wrote:
>
> > 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.
>
>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.

>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?

> > > 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.
>
>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.

> > > 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).
>
>If we have Alice, Bob and Carol, where Alice is the server, Bob is the
>client and Carol is a third party then:
>
>The first authority is:
>A (object is signed) --> publishes change --> B (accepts change)
>C (object is not signed) --> publishes change --> B (rejects change)
>
>The second authority is:
>
>B (has capability key) --> requests change --> A (applies change)
>C (doesn't have cap key) --> requests change --> A (ignores change)
>
>The difference is in the first case, generally only one entity (the
>owning site) can issue updates.  In the second case, multiple entities
>should be able to request changes (which would then cause a signed
>update to be issued going back to the first case).

Sorry, I'm still not understanding.  If one assumed that having
a capability was equivalent to having a signed object, then the
two cases above become the same.  That being the case I guess having
a capability differs in some way.  Perhaps you can explain your
motivation.

>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.

> > > 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.
>
>Ah!  Just the sort of idea I was hoping to get by posting to this list
>:-)  Yes, signing a sort of certificate of authority is certainly
>another possible approach I had not considered.  That neatly solves a
>couple problems (it avoids unbounded growth of per-object capability
>tables I envisioned and also permits capability reflection without
>requiring you go to the server) but how do you handle revocation with
>that model?

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.

> > 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?
>
>This looks very interesting.  I'll have to study web-calculus to be able
>to answer that question properly -- I certainly could be treading over
>similar ground.  But the easy answer is that I'm not designing a web
>system, and web-calculus seems to be at least web-oriented, so at most I
>would borrow their ideas to use in the context of my own 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.

> > > 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.
>
>Agreed.  It was just a strawman argument.

Glad we agree there.

> > 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.
>
>Okay, to briefly explain what I am working on, I am designing the next
>iteration of the Virtual Object System (VOS, http://interreality.org)...

I'll have to pick up on this later.  Thanks for explaining.

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