[cap-talk] Where to use responsibility delegation (was: mailkey: ...)

[Jed Donnelley]

At 08:36 AM 6/5/2007, David Hopwood wrote:
>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.

My concern was simply that with the above approach the
responsible delegation would be used much (!) more.  With
the approach I'd been considering, for example, when
applications were initialized, when capabilities were
stored into and fetched from directories, etc., etc.
(in short, most of the time) no responsibility tracking
delegation was used.  Responsibility tracking was
reserved for when capabilities were delegated
(with responsibility tracking) between high level
identities (nominally between people).

With the above approach ("Alice -> app1 -> Bob -> app2")
it seems that responsibility tracking delegation would
be used all the time.  That puts much more of a performance
focus on the mechanism.

> > 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.

Ha!  I see.  Since I haven't before focused on the language
level, you can understand how my view of what constitutes
the "vast majority" might differ ;-)

> > 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".

Good thoughts.  I guess such "details" can be left for a
first implementation.  I think if we can pull out a
minimal protocol (Horton based, Mailkey based or some
other approach, it doesn't matter to me) that meets the
requirements of "responsible delegation" (i.e. delegation
with identity tracking) then we will have provided a
valuable design option for capability systems.

As you may recall, my original goal was to show that
object/capability systems can provide such delegation
tracking for responsible "identities" for auditing/logging
and what MarkM refers to as "reactive" access control.
I hope as things settle out that requirement will be met.
Met in such a way that systems designed and implemented
with such a facility will not be considered overly
complex and will have good performance.

Of course the user interface issues for POLA and more
generally POLA communication of capabilities still have
to meet general complexity and performance requirements
(e.g. to answer Lampson's lament), but it seems to me
that good progress has been made in those areas.

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