Shibboleth Developers

[Tom Scavo <>]

On 9/28/05, Scott Cantor 
<>
 wrote:
>
> At that point, what we'd need to do is change the model from "SP sends
> request to WAYF, who forwards it" to something like the SAML 2.0 discovery
> model where the SP sends messages to the WAYF and gets back an answer so it
> can kick off the request afterward.

Perhaps, but the SAML 2.0 IdP Discovery Profile is rather vague and
underspecified.  For instance, I'm still not sure what a "common
domain" is.  After digging into this a little deeper, it seems the
intent is for each entity to manage a host in the common domain.  I'm
not quite sure how this would work in practice.

Also, the syntax of the common domain cookie (a history list of
visited IdPs) is weird.  Why are each of the URIs base64-encoded?

Here are some notes re IdP Discovery I wrote awhile back:

- Design goals:
  + The process should minimally interact with the user
  + The process should minimally impact the SSO profile
  + The user's preferred IdP depends on the SP
  + User preferences are subject to change
- For each user:
  + there is an IdP history list
  + there is an SP history list
  + for every SP, there is a preferred IdP
+ A GUI that allows the user to manipulate the (SP, IdP) pairs
+ All 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

Tom