OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



--- Scott Cantor <cantor.2@osu.edu> wrote:

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]