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: "Scott Cantor" <>
  • To: "'Tom Scavo'" <>, <>
  • Subject: RE: Future of the WAYF discussion
  • Date: Wed, 28 Sep 2005 13:09:04 -0400
  • Organization: The Ohio State University

> 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.

It doesn't. I said "something like", not the profile itself.

The profile, which is not underspecified or vague, simply doesn't do what
you want. It requires that the SP host a machine in the domain and the
communication between the SP and that host is not specified. It is out of
scope. The profile includes primitive examples of how one might go about it,
but it's not normative. The normative part is the cookie, the rest is just
illustrative. There is no protocol there, so it is not usable between
independent components, it's like an internal application redirect.

The purpose of the profile is not to create a WAYF, it's to create a single
domain in which the cookie can live so that a user's choices at one SP can
be read by another. It has no other goal, the actual "WAYF" still lives at
the SP, as I keep advocating. Since our scale makes a shared domain a
problem, this pretty much shoots it down. It was designed for smaller sets
of sites.

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

A mistake carried over from Liberty that should have been corrected but
nobody caught it, so it's too late. The format of the cookie is annoying but
hardly important.

> Here are some notes re IdP Discovery I wrote awhile back:
>
> - Design goals:
> + The process should minimally interact with the user

Minimally could mean none. Two people already disagree, which means you also
have to build user interaction control into the protocol.

> + The user's preferred IdP depends on the SP

Then each SP should manage its own cookie and we can end the conversation,
which is why I keep arguing it's an SP and client issue.

> + All functionality is localized on a central WAYF

And who runs it?

-- Scott




Archive powered by MHonArc 2.6.16.

Top of Page