[OpenID] Multiple endpoints in a single XRDS document

Tue Jul 15 18:50:34 UTC 2008

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
>>>>
>>>>
>>>>
>>> --
>>>
>>> -----------------------------------------
>>>
>>> James Tindall
>>>
>>> http://www.atomless.com/
>>>
>>> T : +44(0)1305 250 377
>>> M : +44(0)7971 012 032
>>> F : +44(0)1305 250 377
>>>
>>> -----------------------------------------
>>>
>>> _______________________________________________
>>> general mailing list
>>> general at openid.net
>>> http://openid.net/mailman/listinfo/general
>>>
>>>
>>>
>>
>>
>>
>
> --
>
> -----------------------------------------
>
> James Tindall
>
> http://www.atomless.com/
>
> T : +44(0)1305 250 377
> M : +44(0)7971 012 032
> F : +44(0)1305 250 377
>
> -----------------------------------------
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080715/81fd1ba6/attachment-0002.htm>