[cap-talk] cap-share - membranes - optional/mandatory, unwrapping? (was: Blue sky)

[Marcus Brinkmann]

At Thu, 14 Dec 2006 23:45:52 -0800,
Jed Donnelley <capability at webstart.com> wrote:
> If Alice wants to tell the server of the resource that the
> capability delegated from her to Bob and thence to Carol
> should now be accepted independently of Bob, why shouldn't
> the server honor such a request?  After all, Alice could
> do such a direct delegation in any case.  From the viewpoint
> of both Alice and Carol such an action just saves a lot
> of apparently unnecessary work.  Bob really has nothing to
> say about it.  Let's not consider implementation issues
> at this point, but just the functionality.  Why shouldn't
> such a seemingly useful facility be made available?

I don't think there is a reason not to make it available.  Note that
if Alice revokes the copy to Bob, Carol loses it as well, so Alice
already dominates Carol.  An alternative proposal which also
illustrates why it is not a problem:

Instead of putting the functionality into the server, put it in Carol:
Alice gives Carol a copy of the capability.  Carol uses EQUAL? to
figure out that this is a copy of a capability it got from Bob.  Then
Carol can use either capability co-equally, as long as both work.  If
either fails, it can start to use the other.  This requires that Carol
has a mechanism, similar to a name server, where "retry-"capabilities
can be fetched on error.  In this scenario, Carol doesn't even care if
Alice dominates Bob or the other way round.

Alice and Carol can conspire to give Carol access to the capability
even if Bob wants to deny it because Alice dominates Bob.  I don't see
an issue here.  There are tangential issues, different in the
different implementations, about who has information about what.  But
I am not sure that these fine points play any significant role in this
example.  They may if you are worried about exposing EQUAL?.

Thanks,
Marcus