[cap-talk] mailkey: transfer of accountability

[Jed Donnelley]

At 08:54 AM 6/4/2007, 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.
>
>In mailkey, Bob knows from the email address and domain name that the
>introducer key is Carol's and not Alice's.  In Horton, Bob's request for
>the stub at Carol must go through Alice, which makes Horton more
>complicated.

This fact that the transformation of A's 'c' as Alice's responsibility
to B's 'c' that is Bob's responsibility having to go through C (acting
on Carol's behalf but without Carol's identity) is indeed one of the
things that concerns me about Horton - e.g. as I stated in:

http://www.eros-os.org/pipermail/cap-talk/2007-June/007785.html

If an approach like Mailkey could solve this problem, that would
be delightful.  As I mentioned in the above message, if we were
to design a version of 'Horton' that dealt with capabilities
as data (that is not bundling the permission to communicate,
not including dealing with confinement), then I can see my way
to a 'Horton' implementation that doesn't involve the third
(server) party C to be involved in the communication of the
transformed 'c' capability from A (where it is labeled as
Alice's responsibility) to B (where it is labeled as Bob's
responsibility).

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