Shibboleth Developers

[Tom Scavo <>]

Scott, thanks for putting this new stuff in the spec and offering it
up for discussion.

On Sun, 14 Nov 2004 22:54:41 -0500, Scott Cantor 
<>
 wrote:
> 
> Extended discovery profile after list exchange to include both the SAML 
> notion of an IdP/SP-controlled endpoint in common domain,
> and our concept of an independent WAYF, which seems to require additional 
> URL specification for get/set operations. None of this is
> implemented, so it needs review and probably prototyping.

Section 3.4.2:

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

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.

Both sections:

- Are other parameters (besides those listed) allowed?

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

> I think it matches an earlier discussion we had with EBSCO and some other 
> vendors about providing a silent redirect through the WAYF
> to detect the existence of SAML credentials. I think the "get" interface I 
> specified would satisfy that criteria, since I included
> language prohibiting user agent interaction.

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.

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.

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

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

- Every SP has access to its corresponding preferred IdP.

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

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

- No client-side functionality beyond basic cookie handling is assumed.

I'm writing up the details now...

Tom