← Prev in month
← Prev in thread
suggested text for AI-32 re: non-use of confirmation data in BAP and a couple of editorial changes
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:
← Prev in month
← Prev in thread