[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]