multiple identity servers

[ydnar]

If there are multiply-defined identity server links, then the behavior 
should be to try them in order, until one succeeds?

That is, unless one of the identity servers is on the client's blacklist, 
in which case it can skip it and go on to the next.

Or should a client be able to prefer one identity server over another? IE 
prefer LiveJournal or TypeKey over the user's own ID server?

y


On Wed, 18 May 2005, Brad Fitzpatrick wrote:

> Hmmm.... okay.
> 
> Downsides:  all consumer can do is pick at random --- user experience
> confusion.  Sometimes you'll get prompted for one, sometimes the other.
> But the user specified two, so she should be prepared for that.
> 
> What if the the consumer does pick which it trusts more... usually user
> will be asked to use the first, but some consumers will trust the second
> more?  User might forget the had listed the second one if only 1 in 20
> sites use it.
> 
> Then again:  once we do permission granting, a user might want to list
> typekey.com as her main identity server, but also list livejournal.com.
> Now said user goes to flickr to auth, and asks to post a picture to
> LiveJournal.  flicker, seeing you have livejournal as an identity server,
> uses that, as well as asking for "post" permission.  (the permission name
> is left up to the identity server, usually a service acting as an identity
> server)  Then LiveJournal identity server returns a permission token,
> like:
> 
>     "may::post::brad::<expires_time>::<base64_dsa_signature>"
> 
> Then flickr goes and does a normal LJ WebServices API call, and uses
> "brad" as the username, and instead of brad's password, uses the above
> permission token (which includes the signature).
> 
> So yeah, liking it again.
> 
> - Brad
> 
> 
> On Wed, 18 May 2005, ydnar wrote:
> 
> > I like the idea of having multiple servers. I like the idea of having both
> > TypePad and/or LiveJournal being able to assert http://shaderlab.com.
> >
> > Since the OpenID client stores the assertable URL (ideally), and not the
> > identity server URL.
> >
> > y
> >
> >
> > On Wed, 18 May 2005, Martin Atkins wrote:
> >
> > > Brad Fitzpatrick wrote:
> > > > WTF was I smoking?  If one fails because the server's down, we don't know
> > > > how to fall back to the next, since we never got notified that it was
> > > > down.  The user's browser did.
> > > >
> > > > Okay, one identity server!
> > > >
> > >
> > > Failing to multiple servers wasn't the point. The idea was that
> > > consumers might have an identity server whitelist or blacklist, so a
> > > user can assert multiple servers in the hope that one will be used. As I
> > > mentioned before, the common case is that the consumer will have no
> > > prejucide and will just pick any one. (probably the first)
> > >
> > > Some measure of fallback could be provided by having the helper pick one
> > > at random so that a different one is picked each time the user hits the
> > > login button, but that's so unlikely to happen it doesn't seem worth
> > > worrying about as a spec requirement.
> > >
> > > _______________________________________________
> > > yadis mailing list
> > > yadis at lists.danga.com
> > > http://lists.danga.com/mailman/listinfo/yadis
> > >
> >
> > _______________________________________________
> > yadis mailing list
> > yadis at lists.danga.com
> > http://lists.danga.com/mailman/listinfo/yadis
> >
> >
>