multiple identity servers

Brad Fitzpatrick brad at
Wed May 18 12:21:30 PDT 2005

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 as her main identity server, but also list
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,


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
> 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
> >
> >
> _______________________________________________
> yadis mailing list
> yadis at

More information about the yadis mailing list