[cap-talk] Identity tokens (e.g. Kerberos) for responsibility labeling of capability invocations
Jed Donnelley
capability at webstart.com
Mon Jun 11 22:14:02 EDT 2007
At 02:06 PM 6/11/2007, Karp, Alan H wrote:
>Jed wrote:
> >
> > If I'm still missing something, perhaps Alan can explain to
> > me how "at the end of the day it (the identity token approach)
> > becomes at least as complicated as Horton." by explaining
> > how (or whether) an active object can act (safely) with the
> > responsibility of more than one identity with the kerberos approach.
> >
>Here's where the complexity starts. If Carol has a means to distinguish
>the capability-as-data that she gave to David from the one she gave to
>Alice, then Carol can know that David is responsible for Bob's access.
>That's unlike Horton where David can choose to keep Bob out of the
>responsibility chain. Alice could give to Bob a different right to
>Carol. Bob could use the right he got from Alice and the one he got
>from David in a single request. There is no difference from what
>happens with Horton, except that Carol knows Bob issued the request. I
>don't see where any deputies get confused.
OK. Let me start with something that I don't understand how the above
approach can achieve. In the initial conditions the object A, acting on
Alice's behalf, has two capabilities serviced by C acting on Carol's behalf.
Let's call them c and d. Alice wishes to communicate these capabilities
to B/Bob. In a scenario that I don't see how the above approach can
satisfy, Alice's wishes to communicate one of the capabilities (let's
say c) with delegation to Bob (as with the Horton example), and Alice
wishes to communicate the other capability, d, directly to B/Bob (e.g.
still as Alice's responsibility).
If you can explain to me how this distinction (e.g. consider the
case where c == d) is enforced by A/Alice and is not left ambiently
to the prerogative of B/Bob then I expect I can more effectively
compare these approaches.
--Jed http://www.webstart.com/jed-signature.html
More information about the cap-talk
mailing list