14 messages in org.oasis-open.lists.security-servicesRe: [security-services] comments re s...| From | Sent On | Attachments |
|---|---|---|
| Tom Scavo | Oct 17, 2008 4:59 pm | |
| Nate Klingenstein | Nov 2, 2008 8:14 pm | |
| Tom Scavo | Nov 4, 2008 7:47 am | |
| Scott Cantor | Nov 4, 2008 8:09 am | |
| Scott Cantor | Nov 4, 2008 8:38 am | |
| Tom Scavo | Nov 4, 2008 8:39 am | |
| Tom Scavo | Nov 9, 2008 11:27 am | |
| Nate Klingenstein | Nov 9, 2008 9:13 pm | |
| Tom Scavo | Nov 10, 2008 5:38 am | |
| Mary McRae | Nov 10, 2008 5:53 am | |
| Scott Cantor | Nov 10, 2008 7:32 am | |
| Tom Scavo | Nov 10, 2008 10:53 am | |
| Scott Cantor | Nov 10, 2008 11:48 am | |
| Tom Scavo | Nov 10, 2008 12:02 pm |
| Subject: | Re: [security-services] comments re sstc-saml-holder-of-key-browser-sso-draft-07 | |
|---|---|---|
| From: | Tom Scavo (trsc...@gmail.com) | |
| Date: | Nov 9, 2008 11:27:40 am | |
| List: | org.oasis-open.lists.security-services | |
On Tue, Nov 4, 2008 at 11:09 AM, Scott Cantor <cant...@osu.edu> wrote:
Suppose, for example, an IdP issues an authn assertion and an attribute assertion (which is not unlikely). What is your advice regarding the subject confirmation of both assertions?
I assume it's the same as SSO now. You only accept assertions (for the purposes of the profile) if you can confirm them in the manner you expect/require.
If you're requiring HoK, you only accept the HoK assertions. Any others would be ignored or treated as excess baggage to be tracked in case some other profile plans to leverage them after SSO.
I don't think we're all on the same page with respect to the subject confirmation of the assertions in the response, so let me attempt to make this explicit:
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].
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].
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
Other status codes MAY be returned at the discretion of the identity provider.
Tom