RE: [security-services] "Final" PE text for SSO profile

["Brian Campbell" <bcampbell@pingidentity.com>]

In 3.4.1.4 there's text that says, "The resulting assertion(s) MUST
contain a <saml:AudienceRestriction> element referencing the requester
as an acceptable relying party. Other audiences MAY be included as
deemed appropriate by the identity provider."

I know you've been trying not to be redundant in profiles so it seems
like (because of the above) we could drop the text in your proposal
below that says, "Each bearer assertion MUST contain an
<AudienceRestriction> including the service provider's unique identifier
as an <Audience>."

> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2@osu.edu]
> Sent: Sunday, August 28, 2005 7:54 PM
> To: 'SAML'
> Subject: [security-services] "Final" PE text for SSO profile
> 
> Modified text with suggestions from Tom W....
> 
> -- Scott
> 
> Suggested clarifications to Profiles:
> 
> Section 4.1.4.2, <Response> Usage, replace the list at lines 541-572,
with
> the following list:
> 
> . If the response is unsigned, the <Issuer> element MAY be omitted,
but if
> present (or if the response is signed) 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.
> 
> . Assertions without a bearer <SubjectConfirmation> MAY also be
included;
> processing of additional assertions or <SubjectConfirmation> elements
is
> outside the scope of this profile.
> 
> . At lease one bearer <SubjectConfirmation> element MUST contain a
> <SubjectConfirmationData> element that itself MUST contain 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 also 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."
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in
OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php