[cap-talk] SAML assertions as capabilities vs. ocaps

[Jed Donnelley]

At 09:18 PM 4/24/2008, Karp, Alan H wrote:
>Jed wrote:
> >
> > Does your challenge amount to essentially trying to
> > make Horton more efficient (fewer messages?)?
> >
>That's not the goal, but yes.  The goal is to make attenutated 
>delegation and responsibility tracking work with no more messages 
>than in our SAML approach - one message to delegate, delegator to 
>delegatee, and one message to invoke, delegatee to object.  Horton 
>isn't it because it needs lots of messages to do the introduction.

It can't be done on an ocap base with so few messages.  Just
consider where the one delegation message goes to.  If it
goes to the delegate then no attenuation (let alone future
control over attenuation) can be done with any ocaps
sent in the message.  If it goes anywhere else other than
to the delegatee then you need another message to the
delegatee.

I think if one were to use cryptography for the identity
mechanism in a Horton analog (replace the sealer/unsealer
pairs with their crypto analogs) then you could get much closer
(fewer messages), but still not just the two messages.

Just thinking about this a bit without even considering your
SAML approach, I can't see how you can do what you claim/seek
without providing the attenuation facility in the object
service code.   That seems to break modularity in some
respects as the object service code must know about how to
do attenuation (unneeded in a mechanism like Horton).

If you're willing to build your attenuation mechanism into
the object service code and build the state change for
the object metadata into the delegation mechanism (e.g.
via cryptography), then I believe you can achieve what
you're looking for, but it isn't pure ocap and probably
ends up looking pretty much like what you have with the SAML
assertion mechanism.

Hmmm.  Might I have over constrained the problem?  Maybe
you allow additional object invocations as long as they
aren't forced to be "long distance"?  After all, if an
object invocation costs no more than a subroutine call
(e.g. language enforced, not considered a "message"), then
considering all invocations (e.g. ala Horton) as messages
over estimates the cost of an ocap implementation.

Maybe I need to better understand the constraints of
the challenge.

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