Shibboleth Developers

["Scott Cantor" <>]

> Section 3.4.2:
> 
> - May the IdP put a response to the browser/artifact profile in the
> return parameter?

Technically, yes, but that would be a very bad idea and strongly worth
discouraging.

> Section 3.4.3:
> 
> - Evidently the SP may not put an authn request in the return
> parameter, thus there appears to be no way to optimize the message
> flow.

The WAYF has no way to know what the SP wants here, so adding in more
apparatus would be a mistake. If you want to tell the WAYF "here's a
request", we already have a way to do that.

> Both sections:
> 
> - Are other parameters (besides those listed) allowed?

Yes, but only in the sense that using URLs demands a certain liberalness to
what one accepts.

> - What does the WAYF do in case of errors, for example, if a required
> parameter is not included?  Will an error location for this endpoint
> be specified?

Without a return value, of course, no return is possible, thus an error page
can only be presented locally. Otherwise, nothing else is needed. The whole
thing is "best effort". If you can't set the cookie, so be it. If you can't
get the cookie value, that's the same as "no IdP was found". Let's keep it
lightweight.

> Yes, but that's not the only use of the cookie retrieval endpoint.  An
> SP may want to hand an authn request to the WAYF and say "here, deal
> with it, and I don't want to hear back from you."  Seems two types of
> retrieval endpoints are needed: one interactive (if necessary) and one
> not.

We already have that, that's what the WAYF does now. That's *not* this.

> Why not make the return parameter optional?  If it's included, no
> interaction is allowed.  If it's not included, it's up to the WAYF to
> determine the user's preferred IdP in whatever manner is appropriate.

See above. No need to make it optional, these are fundamentally different
requests with different purposes.

> Along these lines, I've hobbled together an IdP discovery profile with
> the following characteristics:
> 
> - Each user has an associated IdP history list (which is what the
> common domain cookie really is), which may be used to initialize form
> controls and silently redirect the client (if desired).

Check.

> - For a given user, for every SP there is a preferred IdP, that is,
> there is a list of (SP, IdP) ordered pairs associated with each user.

Implementation detail, not part of any profile.

> - Every SP has access to its corresponding preferred IdP.

Don't know what you mean by "has access to". And I also don't really see the
point...what's the use case for these pairs? In Shib, most SPs are usable
with any number of IdPs.

> - A GUI can be constructed to allow the user to modify the IdP history
> list.  Likewise, the user may also modify the (SP, IdP) ordered pairs.
>  The GUI is hosted by the WAYF.

Again, implementation detail, not a profile.

> - No DNS trickery is required.  All profile functionality is localized
> on a central WAYF.  The SP and IdP need not implement anything beyond
> simple redirects.

True of my proposal I think, though I still insist we implement the SAML
profile as well.

-- Scott