Joins on capabilities that have passed through different membranes

--===============2217619301482371627==
Content-Type: multipart/alternative; boundary=001a1145504c60c0b105288c83bc

--001a1145504c60c0b105288c83bc
Content-Type: text/plain; charset=UTF-8

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

--001a1145504c60c0b105288c83bc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Mark and cap-talk,<div><br></div><div>I&#39;m intereste=
d to know if you&#39;ve thought about the following problem:</div><div><br>=
</div><div>You want to perform a join on two capabilities A and B, which we=
re obtained from Alice and Bob respectively. Semantically, the two capabili=
ties point to the same object, in that the messages passed to either one ar=
e ultimately routed to the same place. However, the two capabilities have d=
ifferent conditions under which they become revoked, because the original c=
reator of the capability wanted to maintain the ability to revoke Alice&#39=
;s and Bob&#39;s access independently. Therefore, capabilities A and B are =
not really pointing to the same object. So, what happens when you join them=
?</div><div><br></div><div>The naive answer seems to be &quot;they can&#39;=
t be joined because they&#39;re not the same&quot;. However, this answer se=
ems highly problematic in practice.</div><div><br></div><div>It seems to me=
 that it is necessary to separate the notion of the endpoint object to whic=
h the capabilities point from the notion of restrictions/requirements added=
 on top of them (where cap A has the requirement &quot;Alice&#39;s access h=
as not been revoked&quot; and cap B has the requirement &quot;Bob&#39;s acc=
ess has not been revoked&quot;). When joining two capabilities -- as long a=
s the endpoint is the same, then the requirements must be &quot;merged&quot=
;.</div><div><br></div><div>&quot;Merging&quot; requirements could either m=
ean taking the intersection (the joined capability is revoked if either ori=
ginal capability is revoked) or the union (the joined capability is revoked=
 if *both* inputs are revoked). Intuitively, intersection seems more intuit=
ive, 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 pr=
oblematic in practical use cases. E.g. in the escrow case, if Alice owes Bo=
b money upon completion of a contract, Alice could disrupt the contract cap=
ability just before it becomes complete so that the escrow agent never pays=
 out. I haven&#39;t thought of any serious problems with taking the union o=
f the requirements instead. Alternatively, it could be up to the entity per=
forming the join to specify intersection or union, but if one or the other =
is almost always correct I&#39;d rather not expose this additional cognitiv=
e overhead to developers.</div><div><br></div><div>-Kenton</div></div>

--001a1145504c60c0b105288c83bc--

--===============2217619301482371627==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============2217619301482371627==--