OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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

On Mon, Nov 10, 2008 at 10:32 AM, Scott Cantor <cantor.2@osu.edu> wrote:
>> 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.

Perhaps you're right.

>> 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).

Okay, good.

>> 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.

That's fine.

> 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).

In the case of HoK Web Browser SSO, the problem is likely associated
with the X.509 certificate obtained from TLS client auth (so the
RequestUnsupported status code is relevant, I think).  To bind an
element other than <ds:X509Certificate> to the assertion, the IdP has
to ASN.1-decode the certificate and parse the ASN.1.  Since the
encoding of the certificate is not guaranteed, the IdP's ability (or
lack thereof) to decode various encodings comes into play.

There's not much we can do about this in the HoK Web Browser SSO
Profile except to perhaps RECOMMEND to the client to use a DER-encoded
certificate.  I doubt that recommendation is gonna make much
difference, however.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]