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

[David Chizmadia (Home)]

Alan,

     We may have conflicting assumptions, but
one of mine is that the object system is all
local so an object invocation is no more
expensive than a crypto operation.

Karp, Alan H wrote:
> David Chizmadia wrote:
>>      The samlPolicy is the tuple
>> (Authority, authorizationsMap) wrapped in a
>> sealed box. For the samlPolicy originating
>> from the samlBox, the Authority is the samlBox.
>> To allow authority attenuation, an intermediate
>> holder can use the samlPolicy they received as
>> the Authority to construct a new samlPolicy
>> with a more restricted authorizationsMap. The
>> samlBox unwinds a chain of samlPolicy tuples
>> until it reaches the one it issued.
>>
> That's closer, but I'm not sure how it works.
> 
> How is the sealer/unsealer managed?  I assume
> that the samlBox holds the unsealer, and the
> sealer is available to everyone.  I think
> making that sealer available to everyone
> involves extra messages.  In our SAML approach,
> each delegation is signed with the delegator's
> private signing key, which doesn't require key
> communication.

     Well, actually, I would do it the other way
around, since the sealer would have to be private
(e.g., private key in SAML) to do the signature,
while the unsealer would have to be public to
permit verification of the seal. No additional
message is needed if we include the unsealer
object reference as part of the Authority object.
This would be equivalent to including the public
key of an intermediary in a derived SAML assertion.

> How does the delegatee invoke the delegated
> object?  In our SAML example, we used the
> authorization assertions as the method
> arguments.  Since the assertions are open
> documents, the invoked method could extract
> the service URL for subsequent invocation.
> Sealed boxes are opaque, so the delegatee
> can't get the object reference.

     Remember that my premise is that we are using
a powerBox-like pattern: so the delegatee will be
a supplicant to (ultimately) the samlBox for the
object reference that it will eventually call.
After I sent my last message, I realized that
I had made the delegatee's job harder than needed
by making that client call the samlBox directly
with a samlPolicy obtained from the samlAssertion.
It actually makes more sense for the samlAssertion
to be a forwarder to the samlBox.

     You do need to get out of the document mentality
since this design is simply local objects all the
way down. So your act of extracting the URL is
replaced by the act of requesting the capability
from the samlBox (via the samlAssertion).

> Maybe the answer is to send a list corresponding
> to our SOAP header as an extra argument, e.g.,
> objRef.foo([objRef,AuthMap,seal,samlPolicy],...),
> where samlPolicy is seal([objRef,Authority,AuthMap]).
> The method would check the invocation against the
> policy, e.g.,
> 
>         def sealer { ... }
>         to foo(policy, ...) // Other arguments
>         {
>            if (this == sealer.unseal(policy)[0] &&
>                  attenuationCheck(sealer.unseal(policy)[2]) ) // Plus other checks
>            {
>                  ...
>            }
>         }
> 
> I'm sure Dean can do this without EQ.

     Probably, but since all objects are local, it
seems like an unnecessary optimization.

-DMC