Shibboleth Developers

["Scott Cantor" <>]

> 1. If you're adding expository text for the next draft anyway, it might
> make sense to draw more of a picture in 2.2.3 about what happens if the
> discovery service can not determine an identity provider.

I assume by picture you mean "explain what that would mean to the SP", in
which case I agree.

> 2. In 2.3, "In the case that the return parameter includes a query
> string, the discovery service MAY ignore it for the purposes of this
> comparison".  Is there a reason why this is permissive?  I'd have
> thought that would cause interoperability problems if the SP and the DS
> didn't agree on the handling of the query string.

The handling isn't being disputed (the DS always returns to the complete
return location, including query string). The issue is validation of the
location against metadata, as in SSO when you check the ACS endpoint.

The reason for having a query string sent by the SP is some kind of
dynamism, so by definition it isn't likely to be predefined in metadata. The
point is to say that as long as the URL up to the query string is in the
metadata, it should be ok. In fact the MAY might need to be a MUST for this
reason.

An example:

Metadata says the SP named https://foo.edu/shibboleth has a DS return
location of https://foo.edu/Shibboleth.sso/Login

The SP sends the DS
return="https://foo.edu/Shibboleth.sso/Login?coolstuff=here"; (URL encoded of
course).

Now is that legal? The spec wants to say yes.

-- Scott