The following changes are for the
Bindings and Profiles Document. Line references are relative to the
draft-02 Word document.
Line 499 uses the term
"authentication assertion". This is an error and should actually be "SSO
assertion".
In response to my action item, the
text at lines 523-526 is currently:
523 At least one of the SAML assertions returned
to the destination site MUST be an SSO
assertion.
524 Authentication statements MAY be distributed
across more than one returned assertion.
525 The <saml:ConfirmationMethod> element of each assertion MUST be set
to
526 urn:oasis:names:tc:SAML:1.0:cm:artifact-01.
Note that this text is not very
precise since a confirmation is not really associated with an entire
assertion. It is part of the SAML subject that appears in every
statement within an assertion. I am assuming that the CM should be in every
statement in the SSO assertion.
Also, I understand that we allow
requests that include multiple artifacts, so I can understand how multiple SSO
assertions would need to be returned. However, I do not understand a use
case that would result in any assertions **other than SSO assertions** to be
returned in the samlp:Response to a samlp:Request for AssertionArtifact. Such
a response seems to be permitted by line 523, but I don't quite "get
it".
However, since other folks might
get it, I am not recommending a change to the first 2 lines above.
I do recommend an editorial
clarification for the last 2 lines (525-526) and some additional text to
satisfy the action item I took as follow:
The <saml:Subject> element for each statement in the SSO
assertion(s) being returned MUST contain a <saml:SubjectConfirmation> element as defined
below:
- The <saml:ConfirmationMethod> element MUST be set to
urn:oasis:names:tc:SAML:1.0:cm:artifact-01
- The <SubjectConfirmationData> element
SHOULD NOT be specified.
Note that I expressly limited the
inclusion of the SubjectConfirmation to the SSO assertions since I didn't
understand a use case for other assertions being included.
I think this is okay for V1.1, but
we should clarify it a bit more in V2.0.
Anyone disagree with these
changes?
Rob
Philpott
RSA
Security Inc.
The Most
Trusted Name in e-Security
Tel:
781-515-7115
Mobile:
617-510-0893
Fax:
781-515-7020
mailto:rphilpott@rsasecurity.com