Shibboleth Developers

["Scott Cantor" <>]

> It would be useful if Common Domain Cookie reading and writing
> services were implemented as servlet filters that could be deployed
> separately.

You've said this several times without ever explaining it, and I'll be quite
honest, I still have no idea what you mean by it. CDC reading and writing is
essentially an application function. I can't see why filters would enter
into it. Of course, a filter is just a servlet anyway, but it's a fairly
specialized one. I don't see why it's appropriate.

I think you're after reusable code, or something like that, but the reusable
code is just library code for the cookie, and that's already around. The
rest seems impossible to separate from the other functionality.

The main problem with this line of logic, filters aside, is that a CDC
implementation requires that discovery is entirely hosted at the SP. In
other words, to do anything with it, you need an entire UI for that built
into the SP.

Unless/until that is done, it makes no sense to me to even bother with it
because if you're building your own functionality for this (in your app),
then the SP doesn't need to do anything here, and you can build the CDC
reader or writer yourself as part of that function.

Another way to look at it is that as a discovery application with a UI, etc,
the WAYF code we have is the right place to put options for colocating the
thing in a common domain and doing a read when you go to it. That might make
sense, but that still isn't a filter.

Supposedly, the IdP is the one writing to it, although I find it more
sensible for the SP to do it, personally. Either way, again, that's part of
the SP/IdP "application" behavior, not any kind of filter.

Lastly, so far, I've heard the US govt express interest in the CDC concept,
and that's it. Nobody else seems to view it as practical. So is it worth our
time at this point?

-- Scott