[cap-talk] Capabilities - the rub, an account

Jed at Webstart donnelley1 at webstart.com
Fri Nov 17 18:39:13 CST 2006

At 10:53 AM 11/16/2006, Marc Stiegler wrote:
>For the CapWiki, part of the design is, every time a user creates a cap
>for delegation, we put an entry for the revoker and audit trail on that
>user's home page, and include as much info as we can extract from the
>context and the user's explicit entries about who/why/how long this cap
>is for. This will give the user as much (well, actually, more)
>understanding of what authorities he has passed out, and who he passed
>them to, and what those people he gave the authority to should be held
>accountable for, than he gets with any traditional popular acl system.

Regardless of any implementation status I'd like to explore this space a bit
as I think it's coming close to "the rub".  Let's suppose we have something
like the above and compare it with a popular acl system - say Unix.

To be specific, how about using my favorite Web object example:


(I'd love to have some comparable capwiki examples to work with)

and suppose I have the facilities that you note above - namely that
I can at any time create new instances with revokers and some sort
of audit trail (I'm not quite sure what this feature consists of, but I
soldier on) available.  I could, for example, create a Marc Stiegler
instance of any capability that I might have, e.g. a read-only
capability that provides shared access to other capabilities (like
a directory) as above.

I could create such a capability and send it to you in an encrypted
message.  Presumably you could store such a capability in your
set of network capabilities.  At that point it seems we have a pretty
clear picture - I have the capability (owner rights, RW, etc. with a
revoker for the capability I sent to you) and you have a RO instance.

I could also do the same with a few other people, e.g. Alan and

At some point you might decide that you wished to delegate access
to this capability.  I presume that at that point you would create a
new instance with a new revoker that you could send to somebody
else - perhaps somebody working with you on a project.  We all
agree that this is possible in any case (cooperating conspirators
and all), so why not make it directly possible and with controls?

Alan and Tyler could do some similar delegations.

This process could go on, with revocable instances of the permissions
granted by this capability spread around.

Now at some point I (who am the only writer) post some information
to this object and some time soon I see this sensitive information
in some trade rag - shades of the HP board scandal.

I want to close the leak.  How do I go about doing so?  The first
thing I would like to be able to do is to find out who has read
this information.  How do I do that?  If I was to go to the
server and look at logs (assuming I have access to such
audit log information - seemingly a good idea for "my" object)
I could presumably see what reads have been done to that
object since I posed the information that was leaked.  This
log data might look something like:

Read times              Capability              IP

10/15/2006 17:23:10     Alan -> Sarah -> John
10/20/2006 13:15:07     Tyler -> Bob            ...
10/22/2006 23:17:45     Alan -> Sarah -> Sue
10/24/2006 09:24:16     Alan -> Sarah -> John

Is this the sort of thing you had in mind when you suggest that
with such a scheme one would have more information than one
has in a traditional acl system (e.g. Unix)?

If I'm going to plug my leak, how should I go about it?  It might
seem from the above that John, Bob, and Sue should be my
primary suspects.  However, it seems clear from the way
capabilities work that unless there is some identity binding
taking place during delegation then I also have to consider
Sarah, Alan, and Tyler as suspects.  Really the only person
I've exonerated from this log is Marc (or others that I've sent
the first level capability to besides Alan and Tyler).

How does this compare with an acl system?  Presumably in
an acl system with equivalent logging I would know which
identities did the reading, whether John, Bob, and Sue or
Tyler, John, and Sue, or whoever.  In the acl system (never
mind the question of whether such a system could be
implemented across the Web/Internet) it seems to me
we have more detailed and effective information.

Have I got it right/wrong with regard to what's possible with
DVH style capabilities?  Could we improve an object/capability
system so that delegated capabilities could only be accessed
by the receiver of the delegated capability and not the sender?
I'm sure that could be done with some effort.  I don't know of any
instance where it has been done.  Any effort to do so it seems to
me would start to get bound up in notions of identity, but perhaps
to a rather limited degree that could still remain faithful to the
base object/capability concept.

In the above I was dealing with delegation to people.  It seems to
me that similar issues would arise when dealing with delegation
to processes.  In a descriptor style object/capability system I
believe an over arching TCB could effect the appropriate labeling
of capabilities as they were communicated.  In a network system
(e.g. wideword, capwiki) I believe a more sophisticated exchange
mechanism would be needed.  I can imagine one if both sides
have public/private key pairs along the lines of the scheme in:


Perhaps I should get a reaction to the above discussion before
proceeding further.

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

More information about the cap-talk mailing list