[OpenID] Multiple endpoints in a single XRDS document

Andrew Arnott andrewarnott at gmail.com
Wed Jul 16 14:07:05 UTC 2008 

Agreed.  Pinging in advance in any fashion probably isn't the answer.  But
it's a shame that, aside from frames which suffer from fear of phishing as I
described, there's no way for an RP to recover after an OP fails.  The user
just needs to learn to click Back if that happens.  But even then, what is
the user to do?  Logging in again will surely fail again..... so he leaves
the RP site.  To an RP that really doesn't want to lose users to this, they
may want to seriously consider the extra checkbox saying "choose your
provider."

But then, 99.9% of OpenID users today don't have an XRDS listing more than
one OP anyway.  Most of them have yahoo.com or some other extremely reliable
OP though, so it's mostly a non-issue I guess.

Just ramblings as you can tell.

On Wed, Jul 16, 2008 at 1:02 AM, James Tindall <james at atomless.com> wrote:

> Yes, a redirect does not solve the problem of an offline OP. I think
> you're right 'pinging' the OP prior to authenticating to ensure that
> it's online may be the only solution.
> It just seems unfortunate to have to add yet another RP to OP
> communication step just to cater for any, probably extremely infrequent,
> OP downtime?
>
> =james.tindall
>
> Andrew Arnott wrote:
> > As I understand it, checkid_immediate is an optional step the RP can
> take,
> > that was added for AJAX scenarios.  In my mind, this is a useless feature
> as
> > checkid_setup also tends to be 'immediate' if checkid_immediate would
> have
> > worked, and if checkid_immediate fails, then the very next thing the RP
> > inevitably does is follow up with a checkid_setup request.
> >
> > As far as testing for OP-deadness, checkid_immediate is no good because
> it's
> > a redirect of the browser just as checkid_setup is.  If the OP is dead,
> the
> > user gets a dead-end error page regardless of what the openid.mode is set
> > to.
> >
> > Now, assuming all OPs are alive, the idea of running through all
> endpoints
> > with checkid_immediate first to see if any happen to authenticate, and
> only
> > if that fails doing a checkid_setup on the first good OP in the list is
> an
> > interesting idea.  It would serve the user as he/she would have a higher
> > likelihood of not being prompted for credentials, which is cool.  On the
> > negative side, it means that if the user has 3+ OPs listed, he gets
> > redirected *4 times* before finally seeing his first OP's authentication
> > page if none of them are willing to checkid_immediate.
> >
> > On Tue, Jul 15, 2008 at 9:16 AM, James Tindall <james at atomless.com>
> wrote:
> >
> >
> >> I've not double checked what the spec has to say about this Andrew but
> it
> >> seems to me that if an association with the chosen OP exists and is
> alive
> >> then the RP should simply attempt authorization using
> 'checkid_immediate'
> >> and if that then fails the RP should try authentication using the next
> >> endpoint in the list?
> >>
> >>
> >>
> >>
> >> Andrew Arnott wrote:
> >>
> >>
> >>> Another thought: since a responsible RP only creates a single
> association
> >>> with an OP and stores it until it expires, and these associations often
> >>> last
> >>> days, if the user has an endpoint in the XRDS doc that points to an OP
> >>> that
> >>> is currently down, but with whom the RP has an existing, unexpired
> >>> association with, the RP shouldn't try to create an association with
> that
> >>> OP.  Instead, it might say to itself "yes, I successfully have an
> >>> association with this OP, so I'll redirect the user to it", but the OP
> >>> happens to be down for 5 hours that day, effectively disabling the
> user's
> >>> ability to log in, in spite of the multiple OPs listed in the XRDS doc.
> >>>
> >>> So... perhaps OpenID can have a "ping, are you alive?" message in its
> >>> protocol.  But then we're no better than "dumb" RPs having to make
> >>> multiple
> >>> hits to the OP instead of just one.
> >>>
> >>> Another idea that keeps occuring to me is that the RP can use a
> frameset
> >>> to
> >>> keep an RP frame around and have the OP authentication happen in
> another
> >>> frame (iframe or frameset would work).  That way, the RP frame could
> have
> >>> something like "Is your Provider not responding?  Click here to try
> your
> >>> next best choice..." or something to that effect.  The problem with
> this
> >>> idea is that the URL on the browser will always be the RP, so the user
> >>> will
> >>> have one less way to confirm that this is indeed his genuine Provider
> and
> >>> not one of those notorious OpenID RP phishing attacks.
> >>>
> >>> Anyone have any idea how to solve this dead OP problem?
> >>>
> >>> On Tue, Jul 15, 2008 at 1:52 AM, James Tindall <james at atomless.com>
> >>> wrote:
> >>>
> >>>
> >>>
> >>>
> >>>> I've recently been writing an openid relying party library for the
> >>>> Kohana php framework and I think you're right, the way I've tried to
> >>>> handle multiple enpoints returned from the discovery phase is to first
> >>>> sort them by their priority values and then also filter out any that
> do
> >>>> not meet the (extension / security / openid-version) requirements set
> in
> >>>> the current relying party configuration and then finally attempt to
> >>>> establish an association with each endpoint in turn until a
> successfull
> >>>> association response is returned.
> >>>>
> >>>> I feel that all this is best done invisibly rather than requesting the
> >>>> user to jump through extra hoops. The user has after all -at some
> point-
> >>>> set the priority of the endpoints listed in the xrds and I suspect
> that
> >>>> most would not wish for further input during the process of
> >>>> authentication. My assumption being that the point of multiple
> endpoints
> >>>> is to hopefully cater for the requirements of as many different
> relying
> >>>> parties as possible and to have alternative/backup endpoints incase of
> >>>> errors or failures with any of the other endpoints in the list during
> >>>> authentication?
> >>>>
> >>>> =james.tindall
> >>>>
> >>>> Andrew Arnott wrote:
> >>>>
> >>>>
> >>>>
> >>>>> I'm curious how other libraries do (or plan to) handle multiple
> >>>>> endpoints
> >>>>>
> >>>>>
> >>>>>
> >>>> in
> >>>>
> >>>>
> >>>>
> >>>>> a single XRDS document.  I see a few considerations, in order:
> >>>>>
> >>>>>   1. Enumerate the services in the XRDS-defined priority order
> >>>>>   2. Skip the services that do not expose OpenID endpoints.
> >>>>>   3. Skip the OpenID endpoints with Providers that do not quality
> >>>>>   (whitelist/blacklist or advertised extension support
> >>>>>   4. Take the first endpoint that is left after these filters.
> >>>>>
> >>>>> But what about the rest of the endpoints listed?  Here are some
> >>>>> possibilities:
> >>>>>
> >>>>>   1. Just use the first endpoint and trust it works.
> >>>>>   2. Try each one successively.  That is, the RP should attempt to
> >>>>>   establish an association with each one until it succeeds with one,
> and
> >>>>>
> >>>>>
> >>>>>
> >>>> then
> >>>>
> >>>>
> >>>>
> >>>>>   redirect the user to that one for authentication.  Redirecting the
> >>>>>
> >>>>>
> >>>>>
> >>>> user to
> >>>>
> >>>>
> >>>>
> >>>>>   an unavailable Provider will result in a dead end failure page and
> the
> >>>>>
> >>>>>
> >>>>>
> >>>> RP
> >>>>
> >>>>
> >>>>
> >>>>>   will lose the opportunity at this point to try the next endpoint.
> >>>>>   3. A variant on the last, except that in addition to skipping OPs
> that
> >>>>>
> >>>>>
> >>>>>
> >>>> do
> >>>>
> >>>>
> >>>>
> >>>>>   not respond to association requests, allow the user to "fail" or
> >>>>>
> >>>>>
> >>>>>
> >>>> cancel the
> >>>>
> >>>>
> >>>>
> >>>>>   authentication on the first provider and proceed to the second
> >>>>>
> >>>>>
> >>>>>
> >>>> provider
> >>>>
> >>>>
> >>>>
> >>>>>   listed for another authentication attempt.
> >>>>>   4. Offer the user a list of his/her providers to choose from for
> >>>>>   authentication.
> >>>>>
> >>>>> Have thoughts been written already on which of these are best and/or
> >>>>>
> >>>>>
> >>>>>
> >>>> common
> >>>>
> >>>>
> >>>>
> >>>>> in existing libraries?
> >>>>>
> >>>>>
> >>>>>
> ------------------------------------------------------------------------
> >>>>>
> >>>>> _______________________________________________
> >>>>> general mailing list
> >>>>> general at openid.net
> >>>>> http://openid.net/mailman/listinfo/general
> >>>>>
> >>>>>
> >>>>>
> >>>>>
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080716/fd825adb/attachment-0001.htm>

More information about the general mailing list