Skip to Content.
Sympa Menu

shibboleth-dev - Re: Future of the WAYF discussion

Subject: Shibboleth Developers

List archive

Re: Future of the WAYF discussion


Chronological Thread 
  • From: Tom Scavo <>
  • To:
  • Subject: Re: Future of the WAYF discussion
  • Date: Wed, 28 Sep 2005 11:17:22 -0400
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DpBC/D2xvyGBlglpNPQ1n2V06m8O0BwYkrNWAeJERuX/Eq/ZPxxokp+OJn1oDHL28iIvNUwK0cvRQLUyV/qhteS6ti06tQlK4fEBPKL/XF7MtwPPZtBq5fGajH9jcTJDyKv5qug42ZCugRUv2A9rxxeNHyaOqM+b1I57/lFVXNs=

On 9/28/05, Chad La Joie
<>
wrote:
>
> > At this stage if one postulates a SAML_IDP cookie aware SP and possibly
> > a mechanism to manage the SAML_IDP cookie (maybe a browser plugin?) then
> > we should get to a situation when the user only sees the WAYF when they
> > genuinely have to set about discovering a new Identity Service.
>
> I keep wondering why a plugin is a good idea for managing the contents
> of a cookie.

A browser plugin is an interesting theoretical solution to IdP
Discovery, but if there's anything we've learned in the last ten years
(since the introduction of Java applets) it's that any solution that
depends on the client is doomed to failure (or at least problematic).

> Why not just have a webapp that does it?

I think I asked that awhile back and the answer was that the WAYF is
stateless and should remain that way. I agree with you though, Chad.
If there's a solution to IdP Discovery, it probably involves a webapp
on the server.

Tom



Archive powered by MHonArc 2.6.16.

Top of Page