SAML Wiki
Public Comments
The following documents underwent Public Review between 26 March 2009 and 25 May 2009:
See the OASIS official announcement for details about this Public Review.
The comments received during the Public Review period are itemized below.
SAML V2.0 Attribute Extensions
No comments
SAML V2.0 Metadata Extension for Entity Attributes
No comments
SAML V2.0 Holder-of-Key Web Browser SSO Profile
The following comments were received.
Comment 1
- Reference
http://lists.oasis-open.org/archives/saml-dev/200904/msg00035.html
- From
Marc Stern <<[email protected]>>
- Comment
- The profile claims it "virtually eliminates man-in-the-middle attacks" but a man-in-the-middle (MitM) attack is still possible with this profile.
- Suggested action
The profile should clarify what is required to prevent MitM attacks. In particular, make it clear that a formal X.509-based PKI is not a requirement to prevent a a MitM attack. On the other hand, such a PKI is sufficient. In general, the IdP MUST verify that the key does in fact belong to the subject. Note that a successful TLS exchange is not sufficient since it merely proves that the key belongs to the presenter, not the subject.
- Action taken
Normative requirements (from [SAML2HoKAP]) emphasized in section 2.6.4 of Draft-12
Comment 2
- Reference
http://lists.oasis-open.org/archives/saml-dev/200904/msg00039.html
- From
Marc Stern <<[email protected]>>
- Comment
- Relax the strict TLS requirement. Substitute normative language such as "a key/certificate MUST be sent to the IdP in a secure manner."
- Suggested action
- Use standard terminology: "a protocol that establishes proof of possession of a known key MUST be used."
- Action taken
- TBD
Comment 3
- Reference
- None, this comment was made during a back-channel exchange.
- From
Marc Stern <<[email protected]>>
- Comment
- Do not require the same certificate to be used at both the IdP and the SP.
- Suggested action
The profile should be clear about this (if it isn't already). This is not required in general. It depends on what the IdP binds to the assertion. For example, if the IdP binds a <ds:X509Certificate> element or a <ds:X509IssuerSerial> element, then yes, the presented certificate is necessarily the same at both the IdP and the SP. On the other hand, if the IdP binds a <ds:X509SubjectName> element or a <ds:X509SKI> element, then no, the presented certificate need not be the same.
- Action taken
- None, since this is already quite clear in [SAML2HoKAP]
Comment 4
- Reference
- None, this comment was made during a back-channel exchange.
- From
Scott Cantor <<[email protected]>>
- Comment
The profile should not elicit requirements merely to conform with current browser limitations.
- Action taken
- None, since there are no such requirements
SAML V2.0 Holder-of-Key Assertion Profile
The following comments were received.
Comment 1
- Reference
http://lists.oasis-open.org/archives/saml-dev/200903/msg00007.html
- From
luismi alvarez santana <<[email protected]>>
- Comment
- None, the poster was merely asking for clarification.
- Action taken
- None
Comment 2
- Reference
http://lists.oasis-open.org/archives/security-services-comment/200904/msg00004.html
- From
Scott Cantor <<[email protected]>>
- Comment
- Use the phrase "public key" rather than "certificate" in the following passage: "Suppose a SAML issuer wishes to issue a response containing one or more holder-of-key assertions. As a prerequisite, the SAML issuer MUST possess an X.509 certificate known to be associated with the attesting entity."
- Suggested action
- The previous passage is correct. It doesn't say the IdP has to possess a certificate "ahead of time." It says the IdP has to possess a certificate prior to issuing the response, which is true by virtue of the TLS exchange.
- Action taken
- None
Comment 3
- Reference
http://lists.oasis-open.org/archives/saml-dev/200905/msg00004.html
- From
Josh Howlett <<[email protected]>>
- Comment
Clarify the following passage in the profile: "The <saml:SubjectConfirmation> element MAY contain a <saml:NameID> element. If it does, the latter identifies an attesting entity different from the subject of the assertion. If the <saml:SubjectConfirmation> element does not contain a <saml:NameID> element, then the attesting entity and the subject are one and the same."
- Suggested action
Append the following sentences: "If the <saml:SubjectConfirmation> element contains a <saml:NameID> element, the attesting entity is presumably acting on behalf of the subject. To more strongly signal a delegation scenario, a <saml:Condition> element MAY be used (cf. [SAML2ConDel])." The latter is a non-normative cross-reference to the SAML V2.0 Condition for Delegation Restriction.
- Action taken
- Suggested text added to Draft-10
SAML V2.0 Metadata Interoperability Profile
No comments
SAML V2.0 Condition for Delegation Restriction
The following comments were received.
Comment 1
- Reference
http://lists.oasis-open.org/archives/security-services-comment/200903/msg00005.html
- From
- Jeff Krug
- Comment
- Concerned about lack of expository material explaining how the condition would be used and which use cases would apply.
- Action taken
- Added a new terminology/motivation subsection to Draft 02 describing common scenarios involving intermediaries, and distinguishing when this extension would come into play. The generality of the extension makes it difficult to be precise about use cases because the profile is independent of all of the surrounding flows involved. Additional questions raised by the comments seem more in the vein of SAML implementation questions, and were answered on-list.
Comment 2
- Reference
http://lists.oasis-open.org/archives/security-services-comment/200905/msg00005.html
- From
Josh Howlett <<[email protected]>>
- Comment
- Question was raised in regards to a different document about a mention of delegation.
- Action taken
- None here, but the impacted document was adjusted to clarify matters.