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

[David Chizmadia (Home)]

Alan, et al:

     I'm just thinking out loud here, but I'd like
to sketch out an approach and then have people
explain what I missed ... ;-)

     I start with an object that I'll call the
samlBox, which is essentially a powerBox that,
instead of consulting a user, consults a
samlPolicy. A samlAssertion is an object
containing the samlBox and samlPolicy and can
be passed around the object graph. A supplicant
calls the samlBox, supplying the samlPolicy as
a parameter, and receives back the capability
for which they are authorized.

     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.

     Does this get any closer to what you're
seeking?

-DMC

Karp, Alan H wrote:
> Looks OK, but it too closely models the SAML 
 > approach for me to learn anything new.  Horton
> does responsibility tracking with just object 
 > references, i.e., sealers and unsealers, but
 > no brands or guards.  Maybe something like
 > that would help me.