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 <<marc.stern@approach.be>>

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 <<marc.stern@approach.be>>

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 <<marc.stern@approach.be>>

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 <<cantor.2@osu.edu>>

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 <<luismi.alvarez@gmail.com>>

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 <<cantor.2@osu.edu>>

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 <<Josh.Howlett@ja.net>>

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 <<Josh.Howlett@ja.net>>

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.

PublicComments20090326-20090525 (last edited 2009-08-28 17:04:25 by cantor.2)