[cap-talk] mailkey: Third party involvement?
capability at webstart.com
Tue Jun 5 11:31:34 EDT 2007
At 08:09 AM 6/5/2007, David Hopwood wrote:
>Jed Donnelley wrote:
> > At 04:51 PM 6/4/2007, Karp, Alan H wrote:
> >>But Carol has to know about each such account before the application can
> >>use her objects.
> > I think the above is exactly my no third party involvement
> > issue ( -> C as I briefly put it). I hope we're able to come
> > up with a way to get around that. My main concern is
> > that it will involve some sort of "split capability" (e.g.
> > the swiss number designator from the communication part).
>A specific distributed capability protocol (at the same level as CapTP)
>might do that, but probably as an implementation detail not visible to
>applications. The <principal+key at domain> addresses used by mailkeys can
>certainly be expressed that way (I'll say more about this separately).
I hope we can find a protocol that avoids third party involvement.
>It is inadvisable to use "split capabilities" to refer to such an
>implementation, since "split capabilities" meant something else in the
>context of Client Utility.
Certainly. If we can do it we can come up with a name - or not.
>We can avoid C (the object being delegated) having to be aware of
>the protocol. However, that does not *necessarily* mean that we will
>avoid C's machine or TCB being involved, which I think was your
>concern regarding latency and availability.
Exactly. It's the third party involvement that's the issue.
>However, I think the latency issue can be solved by using promise
> > I agree that there is no logical requirement for the objects being
> > delegated to be involved in the protocol, but that's the way
> > the current implementations (Horton and Mailkeys) are set up
> > as I read them. The Mailkeys implementation:
> > http://erights.org/elib/capability/horton/mailkeys.html
> > seems to be MarkM's interpretation of Rob Meijer's description
> > based on some rather minimal information (the PDF charts).
> > I would not be surprised to see some change there, and in
> > general in this sort of "who" business.
>Yes. I'll post my own object-capability interpretation of a simplified
>form of the mailkeys protocol.
I look forward to it. Glad to have the extra energy focused
on this problem. Since we're pushing on it now, it will be good
to see how far we can go.
More information about the cap-talk