headers
Andrew Arnott | 15 Jul 07:05

[OpenID] Multiple endpoints in a single XRDS document

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
Permalink | Reply |
headers
SitG Admin | 15 Jul 08:55

Re: [OpenID] Multiple endpoints in a single XRDS document

Some idle thoughts on how #3 might be implemented:
"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."

A delayed redirect, with a message for the user saying "Click here 
before 3 seconds elapse to cancel the automatic redirect to this URI 
where we *think* your OP is located."?

How about a delayed reload? A list of OP's, with each one opening 
into a new window (the URL might itself be the RP's site, a 
dynamically generated page automatically dispatching the user towards 
their OP), and when the page reloads itself it displays information 
on which OP's have been authenticated with, which have returned 
failures, which the user has been sent to but not returned, and - 
optionally ;) - what the overall Strength of their Identity is. At 
any time, the user can select "Okay, now I'm done with my OP's, this 
(perhaps single) assertion of authentication is all I want."

-Shade
Permalink | Reply |
headers
James Tindall | 15 Jul 10:52

Re: [OpenID] Multiple endpoints in a single XRDS document

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

-----------------------------------------
Permalink | Reply |
headers
Andrew Arnott | 15 Jul 17:24

Re: [OpenID] Multiple endpoints in a single XRDS document

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

_______________________________________________
general mailing list
general <at> openid.net
http://openid.net/mailman/listinfo/general
Permalink | Reply |
headers
SitG Admin | 15 Jul 18:41

Re: [OpenID] Multiple endpoints in a single XRDS document

>Anyone have any idea how to solve this dead OP problem?

There's also the possibility (however slim) that routing between the 
RP and OP might be fine, but between the *user* and OP have broken. 
No amount of "pings" from the RP will detect or solve this.

I was thinking about the "check OP in new windows" idea some more, 
and realized that it not only leaves a useless window in place after 
you've authenticated, but your *old* window is still there, 
refreshing away. The first part could be solved by auto-closing the 
window, but why close *that* window when it's the same site and can 
recognize that the dynamically generated *first* window can say 
"Okay, the user got back successfully, time to close."?

And it wouldn't even need to be "AUTHENTICATED successfully", the 
user could return with failure or a cancelled login, so long as we 
know that they're able to continue their login process at the RP.

Or the user could just close the newly opened window and click on 
another link in the original, same as they'd do if they couldn't 
establish a connection to their OP.

-Shade
Permalink | Reply |

Gmane