> The <samlp:AuthnRequest> element MAY include a <saml:Subject> element.
> This <saml:Subject> element MAY include a <saml:NameID> element or an
> <saml:SubjectConfirmation> element (or both). In all cases, any
> <saml:Subject> elements in the response MUST strongly match the
> <saml:Subject> element in the <samlp:AuthnRequest> as discussed in
> [SAML2Core].
I guess I don't understand the need to repeat that when it's part of core.
There's nothing different about this profile from the original when it comes
to putting a SAML subject in the request. As a practical matter, nobody does
it, and I guarantee that very few if any implementations would either handle
it, or handle it correctly. But if we wanted to delve into this topic, I
would suggest that this isn't the place to do it. It's a topic for SAML
implementation guidelines, which of course nobody is volunteering to write.
> If the <samlp:AuthnRequest> element does not include a <saml:Subject>
> element, or the <saml:Subject> element in the request does not contain
> a <saml:SubjectConfirmation> element, every assertion in the response
> MUST contain a <saml:SubjectConfirmation> element containing a
> <ds:X509Certificate> element. In other words, this profile defaults
> to subject confirmation via the <ds:X509Certificate> element, which
> corresponds to the conformance requirements of the HoK Assertion
> Profile [SAML2HoKAP].
That would be ok, I guess (and is essentially analagous to the bearer text
in the original profile, describing what you're supposed to do by default).
> If the <samlp:AuthnRequest> element contains an explicit
> <saml:SubjectConfirmation> element, and the identity provider is
> unable to produce a strongly matching <saml:SubjectConfirmation>
> element for any reason, the identity provider MUST return an error.
> In this case, the identity provider MAY return the following
> second-level status code:
>
> urn:oasis:names:tc:SAML:2.0:status:RequestUnsupported
Couple things...
This seems like a good errata for core, more than a specific addition to
this profile. I agree that the current text doesn't read all that well. It
implies that the IdP has to return an error, but it doesn't come out and say
it, so I think we should clean that up.
Secondly, there was a reason the original spec didn't mandate the error
code. I didn't think we wanted to presume what the underlying error was that
would result in the IdP refusing to honor the request. For example, the most
common case I could imagine was an authentication failure (in the sense that
the form of authentication didn't rise to the level required by the IdP).
-- Scott
