Shibboleth Developers

["Scott Cantor" <>]

> Is this a design for a per-SP discovery service?  This seems to be the
> case since the protocol doesn't require the unique identifier of an SP.

Ian already noted this in the topic, didn't he?

>  Also, since the return URL is arbitrary, how do you prevent a
> rogue SP from spoofing the user to divulge their preferred IdP?

Can you suggest a way to prevent this that's worth the effort? I see none,
short of adding more proprietary extensions and more information to register
just to make a WAYF, something that can never actually work well, slightly
more protective of a non-secret piece of data.

There's no common domain here, so there's no regulator of access to the
cookie built in. Without that, I don't see what we can do.

> I'm not sure what a "SAML IdP cookie" is, but does this service
> support the SAML2 Common Domain Cookie (CDC)? Will the CDC Reading
> and Writing Services be implemented?  (It sure would be nice to have
> servlet filters that implemented the CDC Reading/Writing Services.)

Nobody buys the idea of a common domain, but I really don't care, it's
orthogonal to this deliverable. The cookie maintained by the WAYF is not
shared, so it doesn't matter whether it's named _saml_idp or not, but for
consistency, yes, that's what "SAML IdP cookie" means.

I don't think any of us plan to build a CDC implementation by coupling the
IdP or SP implementations to this thing. But it should be possible to plug
one into the WAYF code and write whatever else is needed.

> To integrate with the SessionInitiator at the SP, would it be better
> to call the output parameter 'providerId' instead of 'entityID'?

You already filed a bug saying we should turn providerId into entityID. Now
you're saying we shouldn't?

> Then the return URL could point to a (lazy) SessionInitiator endpoint (or
> maybe I'm misunderstanding the purpose of this new service).

The assumption was that the 2.0 lazy binding will support entityID, or most
likely both for compatibility. There are other glitches like omitting a
target that make it impossible to do this with a 1.3 SP, so there will need
to be a patch to support this kind of discovery anyway. May as well just
patch it to support a new set of parameters supported by both versions.

-- Scott