[cap-talk] capability copy and capability map

[Marcus Brinkmann]

At Wed, 25 Oct 2006 12:55:55 -0700,
"Mark Miller" <erights at gmail.com> wrote:
> 
> On 10/25/06, Marcus Brinkmann <marcus.brinkmann at ruhr-uni-bochum.de> wrote:
> > The challenge by the L4 people is to find a use case of capability
> > copy that can not be avoided by a different overall system design.
> 
> 
> With capability copy, in the scenario shown at
> <http://www.erights.org/elib/equality/grant-matcher/>, if Alice and
> Dana both give the Grant Matcher copies of their capabilities to KEQD,
> the Grant Matcher can compare them, see whether they are the same, and
> if so, then send $20 to KEQD on either cap, since these caps are now
> known to be equivalent. On KeyKOS, the relevant primitive is the
> Discrim key.
> 
> In a system supporting only capability map, how would you solve the
> grant matcher puzzle?

Well, first you would need to convince the L4 group to include the
discrim or eq? ability.  I think that their rejection of that ability
is crumbling, but so far it is not part of their published designs.
In private discussions with various members of the L4 group in
Dresden, eq? was acknowledged to be a useful operation to have.
(However, in past discussions there has been considerable difference
in specific implementations with regards to which capabilities can be
compared and how efficient such comparisons are).

> EQ and rights amplification are closely related. For suitable
> definitions of EQ and rights amplification, either can be trivially
> built from the other. But it is at least difficult to build these
> starting from a cap system with neither (such as Joule or pure
> Actors).
> 
> I don't yet understand map and its consequences, but it seems to me
> like a map-only cap system at least resembles a cap system with no
> primitive EQ. In a map-only cap system, how do you do rights
> amplification?

Should the eq? operation yield true when comparing a wrapper and the
wrapped object?

If wrapping is understood to be used for revocable delegation, I think
that "yes" would be a reasonable answer to that question.  However,
one can also make a reasonable argument against is.  But then the
delegation is not transparent anymore.

Personally, for the use cases I think about most, I think that
revocable delegation should be transparent to eq?.  In this case,
I believe that "eq? or not" and "map vs copy" are unrelated
discussions.  "eq?" should then compare the root nodes of the mapped
capabilities, rather than the individual nodes.

Thanks,
Marcus