Re: Joins on capabilities that have passed through different membranes

On Jan 4, 2016, at 17:53, 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 obtain=
ed from Alice and Bob respectively. Semantically, the two capabilities poin=
t to the same object, in that the messages passed to either one are ultimat=
ely 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 pointi=
ng to the same object. So, what happens when you join them?

As has been mentioned already, the party performing the join is making itse=
lf potentially have a confused deputy problem because it now has a capabili=
ty with more authority than any given purpose-for-which-it-was-given.

However, that's its own problem, and in the case where =91it=92 is a person=
, which I assume is your case, we know people are fairly good at dealing wi=
th it.

> The naive answer seems to be "they can't be joined because they're not th=
e same". However, this answer seems highly problematic in practice.

This na=EFve answer is correct under the case where Alice and Bob separatel=
y constructed membranes/caretakers that don't know about each other, _and_ =
you don't want to construct a joined capability yourself. But there's no te=
chnical reason against the latter: you construct a capability whose behavio=
r is to forward to one or the other of the two.

The only global feature required to do this is to be able to ask =93are the=
se two caps the same modulo revocation?=94 -- THAT is what you need to thin=
k carefully about the existence and semantics of.

> It seems to me that it is necessary to separate the notion of the endpoin=
t object to which the capabilities point from the notion of restrictions/re=
quirements added on top of them (where cap A has the requirement "Alice's a=
ccess 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 endpoi=
nt is the same, then the requirements must be "merged".

-- and I think this is my previous paragraph in different words.

> "Merging" requirements could either mean taking the intersection (the joi=
ned capability is revoked if either original capability is revoked) or the =
union (the joined capability is revoked if *both* inputs are revoked). Intu=
itively, intersection seems more intuitive, but it means that any one party=
 to the join can subsequently cause an outage of the joined capability by r=
evoking their own input, which seems problematic in practical use cases.

As far as I can see, your intuition is being unhelpful. What reason to do a=
n intersection is there?

(Well, I can see it as a part of establishing some policy, for example, del=
iberately giving both Alice and Bob the authority to revoke. But I think it=
 would be better to express that policy in a fully explicit way which is no=
t a =93join=94.)

One way to think about a unionis as a matter of reliability: you have two =
=93communication paths=94 and you try whichever one works. (Or send an idem=
potent message on both.)

> Alternatively, it could be up to the entity performing the join to specif=
y intersection or union, but if one or the other is almost always correct I=
'd rather not expose this additional cognitive overhead to developers.

I hope you are not proposing to, at the programming level, _implicitly_ per=
form a join. This would be harmful DWIM. I see no reason not to _implement_=
 a union and not bother to implement other options -- unless you are buildi=
ng a non-extensible system which would then be unable to express an interse=
ction.

-- =

Kevin Reid                                  <http://switchb.org/kpreid/>