[cap-talk] Confusing deputies with SAML assertions (was: Re: Confused Deputies in Capability Systems)

[John Carlson]

On Feb 10, 2009, at 1:16 AM, Jed Donnelley wrote:

> At 12:53 AM 2/10/2009, John Carlson wrote:
>
>>> Jed wrote:
>>> I use the term "capability" to refer to a representation of object
>>> access (access authority) that:
>>>
>>> 1.  can be validated when used as authorization for a service
>>> request, and
>>>
>>> 2.  can be communicated between any two processes that can
>>> communicate data.
>>>
>>> Do SAML assertions meet the above criteria (#1, #2) for
>>> "capabilities"?
>>
>> I believe that #1 can be met with asymmetric encryption of SAML.  The
>> capability is encrypted similar to your paper, Jed--here
>> http://www.webstart.com/jed/papers/Managing-Domains/#s13
>>     Whatever comes out of the  encryption may be communicated between
>> two processes, thus #2 can be met.  Recall that Alan's implementation
>> sends the authorization SAML to the active entity when the active
>> entity authenticates.
>
> If so then how is it that, "Bob can protect himself by making sure
> the submitter (Alice) of the request has the rights being
> delegated."  Why does Bob need to do such protecting, and what tools
> does he have available for doing so?
>
> As I suggested in my previous message, what I mean by "communicate a
> capability" includes the notion that the sender must have the rights
> being communicated. Is that different than those being "delegated."
>
> Maybe it's time for an interactive discussion.  I'm afraid I may be
> contributing more confusion that clarity.

I think that Bob can check his public key ring to see if Alice is on  
it.  If Bob doesn't have Alice's public key, then Alice's request  
won't be validated.  If Alice's public key is on Bob's public key  
ring, then Bob is not protected.  So Bob would probably have to ignore  
the PKI around him, which would contain Alice's public key.

John