Re: Joins on capabilities that have passed through different membranes

On Mon, Jan 04, 2016 at 08:37:18PM -0800, Alan Karp wrote:
> I don't think unification makes sense.

IMHO unification would only make some sort of sense if the union
of the two capabilities should give the possibility to perform
an act than cannot be performed by either of the capabilities in
isolation: I can do this because BOTH Alice and Bob agree. That
would be some kind of escrow protocol, and would probably need
some kind of escrow object. If you don't have the need for both
Alice and Bob to agree, then you can do with only one, and if
you can, then you should, just because it's simpler. I could
imagine some kind of added weight given by Bob's agreement, but
either you need it, or you don't . . . or it's a post-action
audit trail.

Happy New Year!

> 
> On Mon, Jan 4, 2016 at 5:53 PM, Kenton Varda <[email protected]> wrote:
> 
> > Hi Mark and cap-talk,
> >
> > I'm interested to know if you've thought about the following problem:
> >
> > You want to perform a join on two capabilities A and B, which were
> > obtained from Alice and Bob respectively. Semantically, the two
> > capabilities point to the same object, in that the messages passed to
> > either one are ultimately routed to the same place. However, the two
> > capabilities have different conditions under which they become revoked,
> > because the original creator of the capability wanted to maintain the
> > ability to revoke Alice's and Bob's access independently. Therefore,
> > capabilities A and B are not really pointing to the same object. So, what
> > happens when you join them?
> >
> > The naive answer seems to be "they can't be joined because they're not the
> > same". However, this answer seems highly problematic in practice.
> >
> > It seems to me that it is necessary to separate the notion of the endpoint
> > object to which the capabilities point from the notion of
> > restrictions/requirements added on top of them (where cap A has the
> > requirement "Alice's access has not been revoked" and cap B has the
> > requirement "Bob's access has not been revoked"). When joining two
> > capabilities -- as long as the endpoint is the same, then the requirements
> > must be "merged".
> >
> > "Merging" requirements could either mean taking the intersection (the
> > joined capability is revoked if either original capability is revoked) or
> > the union (the joined capability is revoked if *both* inputs are revoked).
> > Intuitively, intersection seems more intuitive, but it means that any one
> > party to the join can subsequently cause an outage of the joined capability
> > by revoking their own input, which seems problematic in practical use
> > cases. E.g. in the escrow case, if Alice owes Bob money upon completion of
> > a contract, Alice could disrupt the contract capability just before it
> > becomes complete so that the escrow agent never pays out. I haven't thought
> > of any serious problems with taking the union of the requirements instead.
> > Alternatively, it could be up to the entity performing the join to specify
> > intersection or union, but if one or the other is almost always correct I'd
> > rather not expose this additional cognitive overhead to developers.
> >
> > -Kenton
> >
> > _______________________________________________
> > cap-talk mailing list
> > [email protected]
> > http://www.eros-os.org/mailman/listinfo/cap-talk
> >
> >

> _______________________________________________
> cap-talk mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/cap-talk