RE: [saml-dev] SAML 1.1 Technical Overview (11 May 2004)

["Scott Cantor" <cantor.2@osu.edu>]

> By the way, this has nothing to do with the "introduction problem",
> which surfaces very early in the profile (step 2 below), that is, at
> the precise time the client firsts requests a secured resource at a
> service provider.  Since no security context yet exists, the service
> provider must turn the client away and redirect to an identity
> provider...but which identity provider?

Well, no, it doesn't *have* to turn the user away. It could collect all
sorts of input first, which I think it what Alistair is talking about. If I
enter a userid of some sort that can be reasonably used to map to my IdP,
then that's a solution, at some additional cost.

> The Identity Provider Discovery Profile in SAML 2.0 addresses this
> issue.  However, it is vague as written (perhaps intentionally) and
> moreover it does not seem to solve the problem.

I'm not sure why you think it's vague, but now is when we need feedback.
It's the same as the Liberty CDC profile, and it's about as specific as it
needs to be, I think. It's not a perfect solution, but it's a relatively
useful piece of the solution.

> Given that users may
> enroll with multiple identity providers, it is impossible to
> anticipate user wishes even with information about past behavior. 
> Seems the only reasonable solution is to let the user select the
> desired identity provider every time.

I think it's unreasonable to do that. Once maybe. But then you should offer
the option to remember the choice, and that's basically what the common
domain cookie does.

Also, depending on the deployment, multiple IdPs per user might be a very
uncommon case, making it a poor choice to optimize.

-- Scott