[wss] Re: comments on WSS-SAML-02

[ronald monzillo <ronald.monzillo@sun.com>]

Mishra, Prateek wrote:

>First, a comment on WSS-SAML-02: 
>
>Do we need to state someplace that the recipient SHOULD authenticate
>the assertion issuer and ensure that the assertion has not been modified? 
>I guess this might fit into Section 3.1 (Processing Model).  
>  
>
Good catch. The only places where the SAML binding comes close to doing 
so are
in sections 3.5 and 3.6.5, but I think neither is sufficient. I agree 
that something should be
added to this affect to section 3.1 (and I will do so)

I also looked for the corresponding concept being called out more 
generally by the Core specification, and I think that although 
sections2.3 Missing or Inappropriate Claims, 8.3 Signature Validation,  
and Section 12 Error Handling, approximately cover what you are looking 
for, it certainly doesn't jump out at you. Maybe the validation of 
security tokens is called out somewhere else in the core, but I couldn't 
find it.

>Issuer authenticity and assertion integrity 
>may be provided in many different ways (e.g., via transport), but also by
>having the issuer sign the assertion. 
>
>Should use of digital signature for this purpose be described as
>mandatory-to-implement for recipients?
>
>  
>
I think so, although a specific reciepeinet should be free to skip (at 
its own risk)
the validataion of the assertion.

>Response to Ron's comments:
>http://lists.oasis-open.org/archives/wss/200210/msg00008.html
>
>
>  
>
>>>Comments on the SAML Binding/Profile:
>>>
>>>5. section 3.3 neglected to include the use of the URI
>>>attribute (on SecurityTokenReference) from the SS TC submission.
>>>This attribute is necessary to identify the responder at which
>>>to dereference the assertionID/reference.
>>>      
>>>
>
>[Prateek]
>
><SecurityTokenReference>s do not have URI attributes (do they?). I believe
>there is a <Reference> element that carries a URI attribute (Section 7.2).
>  
>
You are correct. they do not. More generally, I think the binding doc 
needs to
be improved to differentiate between  ID and direct references (a the 
core does).
As I understand things, the URI of the responder would be used for a 
"direct"
reference not an identifier reference.

>
>  
>
>>>7. A use case where an encrypted shared secret session key,
>>>is conveyed in a subject confirmation element within a SAML 
>>>authentication assertion should be added to the SAML binding.
>>>The subject would demonstrate knowledge of the key by signing 
>>>something with it. This form of SAML assertion would be used 
>>>in a manner analogous to a kerberos service ticket.
>>>
>>>      
>>>
>
>[Prateek]
>
>I see this as a sub-case of HolderOfKey which hasn't been explicitly
>worked out in the current draft. In other words, I think it is an additional
>use-scenario rather than a new use-case. Nothing in the current draft
>precludes it. Of course, that doesn't mean we know how to implement it
>with inter-operability.
>

Sounds right to me.

Ron

>  
>