OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Correction to my diatribe about assertion Subjects on last call

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
- 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]