[cap-talk] request for comments on capability design
tetron at interreality.org
Wed May 16 23:38:01 EDT 2007
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. 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.
> > 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.
> > 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).
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.
> > 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:
> ) 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
> Are you familiar with Tyler Close's web-calculus services model:
> ? 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.
> > 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.
> 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).
VOS which is a free software distributed object system designed to serve
as a platform for multiuser 3D virtual worlds. Virtual worlds have a
peculiar set of requirements that tends to cut across a lot of fields,
of which robust security is often overlooked.
> 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.
Yes, that is true in my design. I think the main fudge factor in what I
described is that it includes a public object id that may be guessable,
but that only gets you as far as the default security policy. My
interpretation of capability systems (E specifically) was that you have
a single unguessable identifier, and you can't even compare two
capabilities to see if they refered to the same logical underlying
object without going to the object server.
> 2. In so far as communication is enabled by #1, active elements can
> send and receive capabilities across their existing capability
Yes, that is also part of my design.
> Regarding how user, group, and role-based abstractions in capability
> systems - you happened to catch "us" (the capability community) at an
> interesting transition point.
What can I say, good timing.
> 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.
Hmm, interesting. Have any significant multiuser systems been built
using this security paradigm? What is the user experience like, in
> 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.
Interesting. I'll have to take a look at it.
> Good luck with your development!
Thanks for taking the time to reply!
[ 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
Size: 189 bytes
Desc: Digital signature
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20070516/0be306e8/attachment.bin
More information about the cap-talk