[no subject]

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