[cap-talk] mailkey: Is this broken ?? Identity key access?

[David Hopwood]

Jed Donnelley wrote:
> At 01:51 PM 6/4/2007, David Hopwood wrote:
>>Jed Donnelley wrote:
>>>At 09:58 PM 6/3/2007, James A. Donald wrote:
>>>
>>>>He uses the key Alice gave him, to do stuff.  His
>>>>identity key is also required.
>>>
>>>Ah!  Now maybe we're getting somewhere.  You say
>>>Bob's identity key is also required?  So Bob must
>>>sign all his requests?  Doesn't that seem to suggest
>>>that every process acting on Bob's behalf (e.g.
>>>the Solitaire program) must have Bob's identity key?
>>>This seems to suggest that access to Bob's identity
>>>key is going to be rather widespread.  Am I missing
>>>something here?
>>
>>This problem is easily solved: just consider instances of
>>applications to be principals, as well as users. Then a typical
>>delegation chain (e.g. appearing in a log) will look like
>>"Alice -> app1 -> Bob -> app2", where Alice used her "app1"
>>to delegate to Bob, and Bob used his "app2" to access the
>>delegated object.
> 
> Except for the potential performance implications, I like
> that approach.

The overall performance cost is likely to be more dependent on
the membrane implementation than on the introduction protocol.
I have some ideas for optimizing membrane implementations that
should make the cost negligable, at least for membranes that
do not stretch across machines.

> That approach would seem to suggest that
> every communication of a capability includes a transfer
> of responsibility between identities (what you refer to as
> "principals").

Only communication of capabilities between applications or users.
The vast majority of capability communications will still be
intra-application procedure calls/message passing.

> It seems to me that the delegation chain
> could get deep pretty fast with that approach, but if done
> efficiently enough perhaps that would be OK.

I would expect the chain to be no more than 3 times longer
than it would have been otherwise.

Suppose the Alice has delegated an object abstraction C to
App1, and then App1 wants to delegate it further to App2.
If the delegation is done without Alice's intervention, then
the chain becomes "Alice -> App1 -> App2". But if App1 puts
up a trusted dialog allowing Alice to specify that C should
be accessible to App2, then the chain only needs to be
"Alice -> App2".

-- 
David Hopwood <david.hopwood at industrial-designers.co.uk>