PE text for SSO profile ambiguities

["Scott Cantor" <cantor.2@osu.edu>]

I took an AI on the last call to suggest some additional text to clarify
some ambiguities around the use of multiple assertions and statements in the
SSO profile. Allowing for these clarifications, I'm of the opinion that
while it would be possible to produce a new SSO profile that is simpler, the
overall confusion arising from doing this outweighs any practical benefits.

I consider these suggestions to be errata, as they don't preclude any use
cases that I can think of that people would have expected to accomplish with
this profile, and I suspect they line up pretty well with what most people
would be implementing.

About the only thing I really wish we'd changed is the multiple
authentication statement feature, which I still don't understand the use
case for, or the meaning of. But I added something that points out the fact
that if you have more than one, the semantics are undefined. But I clarified
handling of SessionNotOnOrAfter if you have multiple.

-- Scott

Suggested clarifications to Profiles:

Section 4.1.4.2, <Response> Usage, replace the list at lines 541-572, with
the following list:

. The <Issuer> element MAY be omitted, but if present it MUST contain the
unique identifier of the issuing identity provider; the Format attribute
MUST be omitted or have a value of
urn:oasis:names:tc:SAML:2.0:nameid-format:entity.

. It MUST contain at least one <Assertion>. Each assertion's <Issuer>
element MUST contain the unique identifier of the issuing identity provider;
the Format attribute MUST be omitted or have a value of
urn:oasis:names:tc:SAML:2.0:nameid-format:entity.

. If multiple assertions are included, then each assertion's <Subject>
element MUST refer to the same principal. It is allowable for the content of
the <Subject> elements to differ (e.g. using different <NameID> or
alternative <SubjectConfirmation> elements).

. Any assertion issued for consumption using this profile MUST contain a
<Subject> element with at least one <SubjectConfirmation> element containing
a Method of urn:oasis:names:tc:SAML:2.0:cm:bearer. Such an assertion is
termed a bearer assertion. Bearer assertions MAY contain additional
<SubjectConfirmation> elements and assertions without a bearer
<SubjectConfirmation> MAY be included; processing of additional assertions
of <SubjectConfirmation> elements is outside the scope of this profile.

. A bearer <SubjectConfirmation> element intended for consumption using this
profile MUST contain a <SubjectConfirmationData> element that contains a
Recipient attribute containing the service provider's assertion consumer
service URL and a NotOnOrAfter attribute that limits the window during which
the assertion can be delivered. It MAY contain an Address attribute limiting
the  client address from which the assertion can be delivered. It MUST NOT
contain a NotBefore attribute. If the containing message is in response to
an <AuthnRequest>, then the InResponseTo attribute MUST match the request's
ID.

. The set of one or more bearer assertions MUST contain at least one
<AuthnStatement> that reflects the authentication of the principal to the
identity provider. Multiple <AuthnStatement> elements MAY be included, but
the semantics of multiple statements is not defined by this profile.

. If the identity provider supports the Single Logout profile, defined in
Section 4.4, any authentication statements MUST include a SessionIndex
attribute to enable per-session logout requests by the service provider.

. Other statements MAY be included in the bearer assertion(s) at the
discretion of the identity provider. In particular, <AttributeStatement>
elements MAY be included. The <AuthnRequest> MAY contain an
AttributeConsumingServiceIndex XML attribute referencing information about
desired or required attributes in [SAMLMeta]. The identity provider MAY
ignore this, or send other attributes at its discretion.

. Each bearer assertion MUST contain an <AudienceRestriction> including the
service provider's unique identifier as an <Audience>.

. Other conditions (and other <Audience> elements) MAY be included as
requested by the service provider or at the discretion of the identity
provider. (Of course, all such conditions MUST be understood by and accepted
by the service provider in order for the assertion to be considered valid.)
The identity provider is NOT obligated to honor the requested set of
<Conditions> in the
<AuthnRequest>, if any.


In Section 4.1.4.3, <Response> Message Processing Rules:

Line 576, change "any bearer" to "the bearer"

Line 578, change "any bearer" to "the bearer"

Line 583, change to:
"Verify that any assertions relied upon are valid in other respects. Note
that while multiple bearer <SubjectConfirmation> elements may be present,
the successful evaluation of a single such element in accordance with this
profile is sufficient to confirm an assertion. However, each assertion, if
more than one is present, MUST be evaluated independently."

Line 584, change "any bearer" to "the bearer"

Append to paragraph ending on line 591:
"Note that if multiple <AuthnStatement> elements are present, the
SessionNotOnOrAfter value closest to the present time SHOULD be honored."