So, here's the text I'd propose for draft -10:
● The <saml:Subject> element of every assertion returned MUST refer
to the principal. It is allowable for the content of the
<saml:Subject> elements to differ, e.g. using a different
<saml:NameID> or <saml:SubjectConfirmation> elements.
● The set of one or more assertions MUST contain at least one
<saml:AuthnStatement> that reflects the authentication of the
principal to the identity provider.
● Any assertion issued for consumption using this profile MUST be a
holder-of-key assertion as defined in [SAML2HoKAP] and adhere to
section 1.4 therein. If the <samlp:AuthnRequest> does not contain a
<saml:Subject> with a <saml:SubjectConfirmation>, and the service
provider does not indicate otherwise, such as through metadata, every
assertion in the response MUST contain a <ds:X509Certificate> element
in its <ds:X509Data>. This certificate SHOULD be DER-encoded. Other
certificate information MAY be included in additional child elements
of <ds:X509Data>.
On 20 Nov 2008, at 18:08, Scott Cantor wrote:
> Haven't seen the minutes for this week, but I wanted to get a
> correction to
> the list because my spiel about what the old SSO profile requires was
> totally wrong. I couldn't see the text in the red line version
> because it's
> so messy and forgot we fixed this problem.
>
> So, the old profile DOES requires that every assertion returned
> refers to
> the same principal. Obviously the HoK profile should do the same,
> and I
> would suggest that it explicitly copy that text if it didn't already.
>
> For the record, the current errata-changed text for bearer SSO is as
> follows:
> -----------------------
> - 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.
>
> - 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.
> -----------------------
>
> I would suggest that the HoK profile use essentially the same
> language, just
> s/bearer/holder-of-key/g, and I'll leave it to Nate/Tom to work out
> the
> right way to tie that notion of HoK to the HoK profile.
>
> While it might be nice to try to simplify the AuthnStatement rules,
> I think
> frankly it's more work than it's worth to come up with the right
> language,
> so my suggestion is just to drop it and copy the original (errata)
> text.
>
> -- Scott
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
