multiple identity servers

Brad Fitzpatrick brad at danga.com
Wed May 18 12:43:44 PDT 2005


That's up to the consumer.

Perhaps if any is blacklisted, they're all blacklisted!  That might be one
behavior.

Let's leave that up to the anti-spam folk.

For now my interest is in permission passing, which is why I care.  And to
leave things flexible for the future.


On Wed, 18 May 2005, ydnar wrote:

> 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
> > >
> > >
> >
>
> _______________________________________________
> yadis mailing list
> yadis at lists.danga.com
> http://lists.danga.com/mailman/listinfo/yadis
>
>


More information about the yadis mailing list