OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [security-services-comment] Bindings/Profiles comments


Hi Frederick,


>>
>>I have some comments/questions on the 
>>Bindings and Profiles for the OASIS Security Assertion Markup 
>>Language (SAML)
>>Committee Specification 01, 31, May 2002
>>http://www.oasis-open.org/committees/security/docs/cs-sstc-bin
>>dings-01.pdf
>>

>>Editorial:
>>I believe the section #s for the SOAP over HTTP need to be 
>>updated, namely
>>3.1.3.2 on line [258] for authentication
>>3.1.3.3 on line [[263] for integrity
>>3.1.3.4 on  line [267] for confidentiality
>>

You are right, I will add these to the errata list.


>>Since SSL/TLS is recommended for inter-site transfer and 
>>artifact transmission, perhaps https should be
>>shown in the examples at line [443], [483].
>>

Fair enough, https would have been the better choice. However,
the example is correct as it stands.

>>There is also a typo on [831], extra backslash.

Agreed (where did that one creep in from?).

>>
>>It might be helpful to clarify the expectations of 
>>SubjectConfirmationData and ds:KeyInfo usage for the
>>different ConfirmationMethods in this profile. Is it true 
>>that only holder-of-key would be expected to have a
>>ds:KeyInfo SubjectConfirmation element (For the assertion 
>>subject), and none would have SubjectConfirmationData?
>>

The Holder-of-Key case is not involved in any of the web browser profiles.
The Browser/Artifact
profile does not require the use of SubjectConfirmationData or
ds:KeyInfo. 


>>Presumably the Bearer method would have a ds:KeyInfo element 
>>as part of the SAML response signature, but this
>>is separate from ConfirmationMethod.

I think you are now addressing the Browser/POST profile. While
there is a requirement that the SAML response message must be
signed (694-695) there is no implication that the included assertions
contain ds:KeyInfo element.
 

>>
>>regards, Frederick
>>
>>---------------------------------------
>>Frederick Hirsch
>>Technology Architect
>>Nokia Mobile Phones
>>5 Wayside Rd., Burlington, MA 01803 USA
>>frederick.hirsch@nokia.com
>>
>>----------------------------------------------------------------
>>To subscribe or unsubscribe from this elist use the subscription
>>manager: <http://lists.oasis-open.org/ob/adm.pl>
>>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC