Shibboleth Developers

["Scott Cantor" <>]

> If the IdP Discovery profile is not implemented, then there is no
> common domain.

You'll have to define "not implemented", you're just stating a
tautology...if it's not implemented, then it can't be implemented....

A common domain is configured into the implementation, but it doesn't exist
or not exist based on whether somebody writes code to support it in the
products they release.

> If there is no common domain, the IdP can not take
> advantage of a cookie writing service.  Likewise an SP (or WAYF) can
> not rely on a cookie reading service.  In other words, what exactly is
> there to "support" if no common domain exists?

Support in the code is the issue. You're still confusing this with a set of
deployment decisions, or I'm totally not getting your point.

> Are you assuming that the IdP and SP manage the cookie writing service
> and cookie reading service, respectively?  If so, where in the profile
> is this implied?

I'm assuming they have code and configuration machinery to interface with
the common domain if it exists for a deployment. Nothing more or less. If
they want to actually provide some of the machinery for the common domain,
they could, but it's not clearly their role to do this.

Let me note that SAMLv2 specifies a conformant IdP MUST implement support
for the profile, as did ID-FF. This isn't me inventing the idea.

The WAYF is the only new entity here, and since it compliments the profile
by design, it's simply common sense to me that it would also help support
it, mostly by either implementing the common domain service or at least by
using it to establish the "remember my choice" cookie.

-- Scott