[OpenID] Multiple endpoints in a single XRDS document

[James Tindall]

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

-----------------------------------------