Shibboleth Developers

["Scott Cantor" <>]

> Agreed.  So why mention a non-solution to an essentially 
> unsolvable problem?

It's not a non-solution, it's a partial solution. Waiting for perfect is not
useful, particularly since we don't control the software that has to change.

> Seems like the two complement one another.

Exactly, that's my point. They don't replace one another, and some
deployments don't need something like a WAYF.

> The WAYF, being an
> interactive component, allows the user to choose a preferred IdP the
> first time around.  Thereafter, IdP discovery is automatic via the
> common domain cookie.  The only remaining issue is how does the user
> change their preferred IdP (short of deleting the cookie on the
> client, which removes all previous authn history)?

We need a way to edit the cookie in a structured interactive way. Mozilla
extension seems like a good start.

> I've read some of the previous discussion re a WAYF service using
> cookies to streamline and automate the IdP discovery process.  On the
> flip side, what should the common domain server do if the common
> domain cookie does not exist (presumably because it's the user's first
> time around)?  Either it interacts with the user (WAYF-like) or defers
> interaction to some other component (such as the SP, which receives no
> cookie value from the common domain).  I guess what I'm asking is: are
> WAYF and IdP Discovery converging on a single solution?

I don't think there will ever be a single solution until the client
addresses it. Just different pieces that work together to address aspects of
the problem in imperfect ways.

-- Scott