4.1 Web Browser SSO Profile
4.1.4.2 <Response> Usage
=20
=20
=20
4.1.4.3 <Response> Message Processing Rules
=20
=20
What if the assertion has multiple <SubjectConfirmation> elements and
they all have a Method attribute of bearer - one of that fulfils the
requirement above but a different one has a <SubjectConfirmationData>
without a Recipient attribute or with one that doesn't match the ACS
URL? According to the wording in section 2.4.1 of Core (see bottom of
mail), it sounds like only one <SubjectConfirmation> needs to be
verified. But the wording above makes it sound like all
<SubjectConfirmation> elements need to be verified, with a Method
attribute of bearer. =20
=20
=20
Basically the same as the previous question but with respect to
NotOnOrAfter.
=20
Also, what if there are multiple assertions, one of which fulfils the
criteria from 4.1.4.2 but another one, perhaps an assertion containing
only attribute statements, that does not have any <SubjectConfirmation>
elements? What if it had a <SubjectConfirmation> with a Method
attribute other than bearer? What if it had a <SubjectConfirmation>
that couldn't be verified?
=20
=20
=20
Here the wording is "the bearer <SubjectConfirmationData>" where in the
previous two sections it is "any bearer <SubjectConfirmationData>." Is
there a mistake here or is there a reason for this subtle change in
wording?
=20
=20
=20
Does the "SHOULD" wording here mean that my previous questions are
really moot and I can do whatever I feel like or personally think is
most appropriate (except for the MUSTs)?
=20
4.1.4.5 POST-Specific Processing Rules
=20
=20
I understand that the intent of this is to prevent replay of assertions
used to SSO when the POST binding is used. But what exactly is a
'bearer assertion'? It is sort of implied in 4.1.4.2 and 4.1.4.3 but it
is not really clear - this seems like pretty informal loose wording for
a normative document. Is a bearer assertion any assertion that has an
<AuthnStatement> and a <Subject> element with at least one
<SubjectConfirmation> element containing a Method of
"urn:oasis:names:tc:SAML:2.0:cm:bearer" that contains a
<SubjectConfirmationData> element that contains a Recipient attribute
containing the service provider's assertion consumer service URL and a
valid NotOnOrAfter attribute but that does not contain a NotBefore
attribute and also has an InResponseTo attribute corresponding to the ID
of the <AuthnReqest>, if there was a request, but no InResponseTo
attribute if the <Response> was unsolicited? Is a bearer assertion any
assertion that conforms to these restrictions or must it also have been
specifically relied upon to create a security context for the principal?
Or is a bearer assertion any assertion that has a <SubjectConfirmation>
element containing a Method of "urn:oasis:names:tc:SAML:2.0:cm:bearer"?
I'm sure there are many other permutations that might be considered
reasonable interpretations here but one way or the other it's not clear
to me.
=20
=20
