[cap-talk] What's not to like? (was: Join "Another core principle")

[Jed Donnelley]

At 09:34 PM 12/19/2006, Sandro Magi wrote:
>Jonathan S. Shapiro wrote:
> >> As I recall your definition, the only difference is that delegation
> >> involves responsibility tracking.  Except for performance, is there any
> >> reason not to do the tracking on everything that passes through the
> >> membrane?
> >
> > I do not know what responsibility tracking means. Delegation through a
> > membrane means that when the sender's capability is revoked, the
> > receiver's capability is revoked. Since that is *precisely* what we are
> > trying to avoid in this scenario, delegation is not the appropriate
> > action here.
>
>Isn't introduction (Carol->Alice via Bob) the only way to obtain a
>capability that will survive a revocation of a third-party introducer
>(Bob)?

The introduction needn't be done through Bob.  It can be done
external to Bob.  All that matters is that Carol is introduced
to Alice in such a way that Alice decides it's appropriate to
delegate directly to Carol the capability that was formerly
delegated through Bob to Carol.

We have a facility with capabilities (the ability to delegate
with revocation and responsibility tracking) that we don't have
at all with ACLs.  However, with some uses of this additional
facility we end up with awkward (at least) dangling references
when delegated capabilities are revoked - in this case when
Bob's access is revoked.  We can do better.  Shouldn't we?

>And isn't that how it should be, since the resource itself
>(Alice) will want to provide a distinct, revocable capability for the
>new party (Carol).

It could be distinct, but why do you believe it "should" be?
I believe Jonathan and I have been arguing that requiring it
to be distinct creates a mess for Carol and I argue an
impossible situation for David.

I don't understand why it seems so difficult to imagine
the appropriate book keeping being done at the server to
facilitate the needed authorization of Carol's existing
capabilities in her presumed to be complex and historically
developed capability directory structure, and also to
enable David's existing capabilities delegated from Carol.

This is a situation where we're trying to get the best
of both worlds.  We want the ability to delegate as
with capabilities (enabling modular POLA extensions)
while at the same time availing ourselves of an ACL-like
ability to re enable existing references.

Since it's apparent that this is possible (though we may
still have to pick a "best" implementation and interface),
isn't it clear that it provides a useful value and is
still faithful to the basic object-capability paradigm?

What's not to like?

--Jed  http://www.webstart.com/jed-signature.html