[cap-talk] Another "core" principle - Brinkmann

[Marcus Brinkmann]

Hi,

I think I see now what you want to achieve.  I think you can achieve
all of this in a pure capability model, assuming revocable delegation
(without any identity tracking) and a MyCap? operation.  No extension
to the capability model seems to be necessary.  Here is a very rough
sketch of what needs to happen, I can expand on this if necessary,
although it seems rather standard to me.

I will pick up on your scenario that there is a system service S, an
administrator R, and users Alice, Bob and Carol.

Access to S by means of a capability P is delegated initially to R
(initial configuration), then to Alice as P_A.

1. Step: Revocable delegation with identity binding.

Alice creates a new capability P_B, derived from P_A, which is bound
to an identity "Bob".  The quotes indicate that this is a name for Bob
which is now shared between Alice and S.  A name can be a fingerprint,
a capability, whatever.  If this name should be good enough for R to
know who "Bob" is, Alice and S and R need to agree on a common name
service.  Weakening this requirement seems useful in the case where
arbitrary users want to introduce new identifiers for their own sake.

P_A->Bind_Identity ("Bob") => P_B

The binding is stored in the server S for later reference.

The capability P_B is then delegated to Bob by Alice.  Bob can repeat
this step for a delegation to Carol, yielding a capability P_C, bound
to "Carol", delegated to Carol.


2. Step: Emergency capabilities

Presumably, Carol wants to be able to use the capability even if Bob
revokes it, assuming that Alice or R will agree.  To establish this
possibility, she needs to retain a communication channel with S (or
some equivalent service) that has a lifetime beyond Bob's delegations.
You assumed such a channel when describing the example to me, where
Carol gets a message to some effect like: "Go ask Alice".

So Carol requests an "emergency capability" from S by means of her
capability P_C, for example:

P_C->GetEmergencyCap () -> E_P_C

This capability will be directly delegated from S to C.  It will be
associated with the same internal object as P_C, but as a weak
reference and providing a different interface (more details below).

Now bad things happen, and "Bob" is revoked (the identity, not the
person :)


3. Step: Revocation of identities

Somehow "Bob" is removed from the equation, and all capabilities
delegated by Bob are lost.  This affects Carol, and only Carol, at
this point.  P_C is now a dead capability.


4. Step: Appeal for Resurrection

Carol notices that P_C is dead, for example by invoking it.  Now she
can use the emergency capability E_P_C to query the object status, for
example the delegation chain as in your example interface output.

C can now appeal at R or Alice, or whatever.

E_P_C->WhatsGoingOn () => "Bob's identity was lost..."

E_P_C->Resurrect () => New P_C     ; (*) Returns later, see below.

Note that the last call may not return yet.  First, something else
needs to happen:


5. Step: Bypass and Reclamation

Say Alice complies with Carols request.  Then she makes a call to S,
granting Carol access.  While she is at it, she can also clean up the
resources occupied by the identity "Bob":

P_A->Bypass (P_B, "Carol") => void  ; SIDE-EFFECT: (*) above returns

P_B->Destroy ();


Many details are wrong with this, but probably none you care about
(resource management, etc).  Also, again we ignored matters of how to
establish identities across parties.  Apart from a ton of other
problems I see with this scenario I think it (or some variation of it)
achieves roughly what you asked for.

Thanks,
Marcus