[cap-talk] Capabilities - the rub, identity

Jed at Webstart donnelley1 at webstart.com
Tue Nov 21 19:31:27 CST 2006

At 02:31 PM 11/18/2006, Sandro Magi wrote:
>John Carlson wrote:
> >>> From the description, it sounds like he's referring to what you would
> >>> call a directory. His "2-factor capability" is then simply the
> >>> directory capability + the index/name into the directory.
> >>
> >> Sandro
> >
> > I'm not so sure it's like a directory, unless the directory is like a
> > class with instances in it.
>Yes, exactly. I don't mean a passive filesystem-like directory, I mean a
>generalized object directory, which maps names/indices to any kind of

Let me see if I understand.  It sounds to me like you are simply suggesting
that there be some base capability set (e.g. stored in a directory) that is
associated with an identity.  Anybody (or any process) that can show
that it "is" the identity (e.g. by password, certificate, biometrics,
whatever) is given access to the directory (all it's contents - e.g.
a "home" directory).  This would typically be done by means of
communicating the directory to a process that is also listening
to and taking commands from an entity at the other end of a
communication channel assumed to be the "identity".

Is that what you are getting at?  If so, I believe that approach is
quite common in object/capability systems.  Every system I
know has worked in some sense like that.  Do others know of
a different model?

I think the base issue ("the rub") the identity/acl people have with
capabilities can be easily seen from the perspective of such a
home/identity directory.  Suppose I'm a user identified to a system
and accessing it through some sort of "shell" that's been given access
to my "home" directory as above.  Then I create a new object, let's
say a file, and store the most powerful capability that I receive for it
in my 'home' directory.  Now I run a program that I give this capability
to that file object and it communicates it to a program that deposits
it into YOUR 'home' directory.

At this point we ask ourselves, what auditing has happened?  How do
I know that you now have access to this file object?  If at a later time
I feel you should no longer have access to this file, how do I remove
your access?  Oh sure, with capability revocation, but what mechanism(s)
are in place to make that easy or the norm?

Just to carry this example a bit further, the "account" capability in
the NLTSS system was used more or less like a credit card to
pay for things.   When I created the file I needed to pass in
an instance of an account capability to do so.  If I later invalidated
the account capability that I used to create the file, the file would
be destroyed (including your capability to it).  I could even get
back a bill from my account showing me the things I am paying
for.  If there were any that I no longer considered useful I could
instruct the account to stop paying for them, causing them to
be destroyed.

I won't go further except to say I consider this a sensitive and
not well understood/explored area of object/capability systems.
There's more than one way to do "it" and no agreement that
I'm aware of regarding best ways.

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

More information about the cap-talk mailing list