Re: [security-services] Correction to my diatribe about assertion Subjects on last call

[Nate Klingenstein <ndk@internet2.edu>]

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
>