[cap-talk] Identity tokens (e.g. Kerberos) for responsibility labeling of capability invocations

[Jed Donnelley]

Karp, Alan H wrote:
> ...
> The main difference from Horton seems to be that responsibility is
> transferred by default.  Bob wants to start a program that can't
> authenticate as him.  He creates a new identity Bobbie and registers it
> with Carol.  Bob starts a program and gives it some of his capabilities
> and the ability to authenticate as Bobbie.  Carol assigns responsibility
> for the program's actions to Bobbie but needs to remember that Bob is
> responsible for the Bobbie account.  As James Donald noted, at the end
> of the day it becomes at least as complicated as Horton.
>   

Ah, with the above I think I finally can see where the disconnect may 
have been.

In this 'kerberos' thread there has been an implicit assumption that an 
additional identity
is created for each application, the Bobbie in the above, along the 
lines of what David
Hopwood was suggesting even for Horton as I recall.  That's fine in so 
far as it goes, but:

I still believe there is a problem with this approach.  It shows up in the
above where you note that "Carol assigns responsibility for the program's
actions to Bobbie but needs to remember that Bob is responsible for the
Bobbie account."

Unfortunately, I believe a program may well need to act on behalf
of more than one identity.  This is why I tried to introduce Dave into
the discussion.  However, I don't think you even need to go that far.
Consider the case where Alice delegated one capability to Bobbie
(leaving aside for the moment how Carol associates Bobbie with
Bob's responsibility - I can see how that might be handled in the
creation of the "Bobbie" token)  through the kerberos-like mechanism,
but Alice also communicates a capability to Bobbie that is supposed
to be acted on directly with Alice's responsibility (doesn't go through
any delegation mechanism to transfer responsibility, Horton or kerberos).

I think if those of you familiar with Norm Hardy's confused deputy
example will consider this situation in that context, it might be clearer.
The capability communicated with Alice's responsibility might be
the file to be compiled and the capability that is acted upon with
Bob's (Bobbies) authority is the log file capability (though this
capability to the log file will not be communicated from Alice).

I don't see how any situation of this sort where a single program
must act on behalf of multiple responsibility identities can be
handled by this kerberos sort of mechanism.

With the Horton sort of mechanism (whether the original
Horton or the Mailkey form or some other implementation),
the result is a capability labeled as the responsibility of the
appropriate identity.  Two or more such capabilities with
different responsible identities can be available to a single
active object (running code, domain, process).

I wonder if this discussion might lead us into deeper territory.
Namely, one could ask whether it "should" be possible for a
single running program (active object) to be able to act with
the responsibility of more than one identity.

I believe this should clearly be possible.  To me the argument
that might go something like "Well, the program was set
up and run by some responsible identity <party>, so shouldn't
all it's actions be considered the responsibility of that identity?"
is misguided ambient authority think.  I believe it's important to
be able to distinguish between the responsible programmer,
the responsible executer, and the identities responsible for
individual capabilities (permissions).  To me the kerberos
token approach seems to demand that every action of
an executing program must be the responsibility of a single
identity - presumably an identity that initiated the program
execution.  I view this approach as inadequate.

If I'm still missing something, perhaps Alan can explain to
me how "at the end of the day it (the identity token approach)
becomes at least as complicated as Horton." by explaining
how (or whether) an active object can act (safely) with the
responsibility of more than one identity with the kerberos approach.

--Jed  http://www.webstart.com/jed/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20070611/37bcfe58/attachment.html