[cap-talk] What Horton cannot do? (Was: mailkey: transfer of accountability...)

[Jed Donnelley]

At 02:40 PM 5/31/2007, James A. Donald wrote:

>...Seems to me that some of the things that Horton is
>attempting to do probably cannot be done, or even very clearly defined,
>with the result that it grows without limit in complexity, and declines
>without limit in comprehensibility.

I'm puzzled by your statement that:

"some of the things that Horton is attempting to do probably
cannot be done, or even very clearly defined" (and the rest,
but let me focus on this)

Horton in only attempting to do one thing:

To communicate a permission from an active object, A,
with one identity (able to sign as one identity, Alice)
to another active object, B, with a different identity
(able to sign as a second identity, Bob) so that the
capability representing the permission is labeled
differently, in particular as having been delegated
from Alice to Bob, when it arrives at B.

The little bit that is non-intuitive (to me anyway)
is that A should never have access to the form that
Bob is responsible for (signed by Bob), and B should
never have access to the form that Alice is
responsible for (signed by Alice).

As you see in the protocol in the paper:

http://www.erights.org/download/horton/document.pdf

the basic idea is:

1.  Start for the induction with A assumed to have
a capability that is labeled as Alice's responsibility.
How this is represented in C is a matter for C to
decide (e.g. keep an Alice who in a table associated
with the 'object' designation).

2.  A acts for Alice to send a message to C (who services
requests on the capabilities - provides the permission)
saying, "please make me a version of this capability that
is labeled as having been delegated from Alice to Bob".

Since the starting capability was Alice's responsibility,
the Alice part is no problem.  However, C only knows
Bob by the 'Bob who' that A passes to C with the request.
C then makes up a capability labeled as having been
delegated from Alice to Bob and then [Important] seals
it with the 'Bob who' (I think of this as encrypting
it with Bob's public key) to send back to A.

3.  Once A has the sealed capability back, it's a simple
matter to send it to B who can unseal it (with Bob's
unsealer which B is assumed to have but A does not) to
recover the capability that is labeled as delegated from
Alice to Bob.  B now has it and A never did.

In the above I've factored out the stubs and the management
of Carol's service responsibility, but I believe it captures
the essence of the delegation.  MarkM or AlanK or others can
correct me if I've missed something essential.

As you should notice, nothing is said about the meaning
of the identities.  If you just think of them as
public key (the who's) and private key (the me's) pairs
I think you'll get the idea.  It is outside the scope
of the Horton protocol to deal with binding the identities
to any meaning (e.g. like to a person).  One can easily
imagine how binding to a person would happen in an
organization, but you still have the usual cross
organization issues (e.g. as with public/private key
pairs) if you branch outside such an identity binding
framework.  I'm a web of trust kind of guy (e.g. pgp/gpg),
so I don't have any particular issue with tying meaning
to such "identities" across organizational boundaries,
but in that your mileage may vary.

Still, it seems clear to me that Horton is able to
do the simple delegation work that is claimed.

What exactly do you believe to be either impossible
or unclearly defined?

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