Shibboleth Developers

[Tom Scavo <>]

On Sat, 30 Oct 2004 15:24:31 -0400, Scott Cantor 
<>
 wrote:
> 
> > - IMHO, section 3.6 should be omitted.  As written, it adds nothing to
> > the existing SAML2 "profile", which itself is vague at best.
> 
> I think we, umm, disagree about the vagueness, or at least the necessity for
> it to be any less vague. "Doesn't solve an unsolvable problem" I would agree
> with.

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

> > Moreover, there seems to be a lot of overlap between the IdP Discovery
> > Profile and the WAYF.  Perhaps the two should be combined?
> 
> I do, section 2.3 already allows for the use of that profile. The WAYF is a
> non-normative component, it wouldn't be appropriate to require one to
> utilize the SAML profile. It dovetails with it fine, since it's essentially
> usable as a shared domain. It effectively just offloads the SP's role of
> participating in the profile to it.

Seems like the two complement one another.  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)?

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?

Cheers,
Tom