[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] comments re sstc-saml-holder-of-key-browser-sso-draft-07
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]