Shibboleth Developers

[Eric Fazendin <>]

Thanks everyone for reviewing the draft and providing your comments.  They are very helpful.

I think Lukas has addressed a lot of the issues raised in this thread, and I agree with his comments.

PingPong IdP Discovery is not a solution for all use cases.  Although it sounds like Peter may have some ideas I haven't thought through, I like to dump IdP discovery protocols into a couple of buckets of 'prompting the user', 'common domain', and then PingPong (maybe that bucket would be called querying the browser).  I think where acceptable and viable, 'prompting the user' and 'common domain' are probably better IdP discovery mechanisms.  It's been my experience though that establishing a common domain across all possible IdPs and SPs for a given federation can be very difficult, and sometimes prompting the user causes an unacceptable amount of friction.

Just to run through some of the topics though:

PingPong IdP Discovery is not meant for scenarios where an SP would accept assertions from very large numbers of IdPs.  (thanks for the wording clarification there)

It is meant to attempt to improve the user experience as much as possible, and provide a fallback mechanism to a different IdP discovery mechanism where it fails.

If shared PCs are used and they cache profile data, PingPong would lead to inaccurate results.  I would think there would be a lot of other problems in this scenario as well though.

Prioritization is a recommendation to attempt to improve the speed of completing PingPong.  For example, maybe 90% of an SP's users come from 2 or 3 IdPs.  Maybe the user's IP address can be associated to an IdP.  Etc.

I'm not sure what definition is being used for 3rd party cookies, but cookies need to be read through an iframe.  They are never written through an iframe.  I'm curious though, what issues are seen with this?

There are definitely issues if a user has more than one IdP (that's trusted by the SP) and if one of the user's IdPs is more relevant to the particular SP/SSO transaction.  But it is possible (at least in my implementation of PingPong) that two or more IdPs on a given Page indicate they have authenticated the user in the past and for SSO links to be displayed for both.  It's not a perfect solution, but it attempts to address the problem.

On Fri, Dec 17, 2010 at 10:33 AM, Scott Cantor <> wrote:

> > Which would mean it's useless without third party cookies, right?
>
> No third party cookies are required. Only cookies at the IdP and at the
> SP for which a user has set cookies anyway.

I'm fairly sure that an IFRAME (or any FRAME in fact) reading or writing a
cookie *is* a third party cookie. I thought we had cleared this up when I
showed that last logout UI proposal doesn't work (wasn't that IFRAME-based?)

-- Scott