[cap-talk] mailkey: transfer of accountability

[Jed Donnelley]

Karp, Alan H wrote:
> David Hopwood wrote:
>   
>> I think the simplest way to resolve this is for you to restate your
>> argument using the usual convention -- otherwise we're going 
>> to get into
>> horrible difficulties comparing with the Horton paper.
>>
>>     
> Alice has a reference to Bob and one to Carol.  Alice would like Bob to
> have a reference to Carol so that Carol will be able to distinguish
> requests from Bob from those from Alice.  Alice asks Carol to set up an
> introducer mailbox key for Bob to use, and Alice forwards it to Bob.
> Bob sets up a mailbox key for Carol to use and sends an email to the
> introducer key asking Carol for a new mailbox key that is not known to
> Alice.
>   
I'm sorry if I'm being dense on this, but:

In the above your refer to Alice and Bob and Carol as if they were the 
active objects.
I understand these somewhat metaphoric references.  However, we know 
that (at
least in the Horton description) it is A acting with capabilities b 
(labeled as
the responsibility of Alice) and c (also labeled as the responsibility 
of Alice) that
A actually has.  A does not have the beAlice (the equivalent of the 
private key
for Alice) and hence can't act as "Alice".  That is, A cannot sign 
anything (e.g.
unseal) as Alice to identify that it is acting on Alice's behalf.  A can 
only invoke
the capabilities 'b' and 'c' - which happen to be labeled as Alice's 
responsibility.
A might also have access to capabilities considered the responsibility 
of others
besides Alice.

In the Horton approach the identity capabilities are "hidden" inside the
responsibility transforming stubs and are used for the simple relabeling
process.

Here is my interpretation of this quote from James Donald:

"He <I think He=Bob in Jame's mind, but more precisely "he" is B acting
with some permission that is Bob's responsibility> uses the key Alice gave
him, to do stuff.  <fine>  His identity key is also required.

It's this second sentence that gives me some heartburn.  At that point
I seem to lose all sense of how Mailkey is supposed to work to solve
the problem of delegating permissions (capabilities) with responsibility
transformations.  If "who" is invoking a capability is determined by
an identity being invoked with every request (e.g. signing the request),
then it seems that all processes acting with any of an identities
responsibility must be able to act with all their responsibility (e.g.
must be able to sign any request in their name, even label any
capability as their responsibility).  This would require that every
request that is considered the responsibility of any identity
would have to come from an entity (active object, process) that
had access to the beIdentity (the public key for the identity).  If this
is the case then it seems to me that the communication of such
beIdentity capabilities must (by the Mailkey protocol) be so
widespread as to effectively make meaningless the value of the
responsibility logs.

I hope I can clear up my picture of how Mailkey is working in
this area.

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