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


On Mon, Jan 5, 2009 at 1:20 PM, Scott Cantor <cantor.2@osu.edu> wrote:
>
>> Let's suppose, however, that the request is signed.  Does that abrogate
> the
>> IdP from its responsibility to verify the endpoint locations in
>> metadata?  In other words, is the IdP permitted to accept
>> authenticated requests from SPs that it otherwise knows nothing about?
>
> That's really up to the IdP, that's the problem. There's nothing you can
> write that gets around the fact that trust is out of scope, and ACS checking
> is all about trust because what you're doing is authenticating the
> destination.

How about this (intentionally verbose) text:

"The <samlp:AuthnRequest> element MAY be signed.  If the
<samlp:AuthnRequest> element is signed, and the IdP can successfully
verify the signature, the identity provider MAY (subject to policy)
choose to trust the content of the request message.  In particular,
the identity provider MAY accept the values of the
AssertionConsumerServiceURL or AssertionConsumerServiceIndex
attributes on the <samlp:AuthnRequest> element (if any) without
further processing."

"If the <samlp:AuthnRequest> element is not signed, the identity
provider MUST verify the content of the request message.  In
particular, the identity provider MUST verify the values of the
AssertionConsumerServiceURL or AssertionConsumerServiceIndex
attributes on the <samlp:AuthnRequest> element (if any).  In the
absence of such values, the identity provider MUST be certain that the
endpoint location of the assertion consumer service that it chooses to
use does in fact belong to the target service provider."

"Even if the <samlp:AuthnRequest> element is signed, the identity
provider MAY choose (subject to policy) to verify the request content
by some unspecified out-of-band means.  In all cases, the method by
which the identity provider verifies the request content is
unspecified.  For example, SAML metadata MAY be used for this
purpose."

> Or arguably you can satisfy the intent by saying "I trust anybody",
> presumably by also including a user consent piece that makes it the user's
> choice.

Well, I wouldn't go so far in the HoK Web Browser SSO Profile since
that seems to go against the intent or at least the spirit of the
profile.

> If there are two, it's entirely undefined which one you use, but that's very
> easy to implement. You may find it ambiguous, but that's not the same
> argument. I'm only saying it's easy to implement.
>
>> Can you briefly describe how a relying party parses the authentication
>> data from multiple AuthnStatements?
>
> Pick one. I can only say that's how I did it, and I believe that's supported
> by the text.

If the choice is arbitrary, then I see no point of allowing multiple
elements to begin with.  Unless there is a possible use case, no
matter how far fetched, I suggest we restrict ourselves to one and
only one AuthnStatement.

Tom


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