Using OpenID as a login for my website - redundant providers

Question

How do I support redundancy on my OpenID login website?

For instance, I have users that demand 100% uptime (yeah, right, but let's get as close as we can).

Some of them use less available providers (ie, myphpid on their own website, or an ID on a startup which has frequent downtime). Now I can shuttle them to a more reliable provider, but I also want to have some redundancy.

One solution I hope I can deploy, but don't understand enough about OpenID to try is:

Set up several phpmyids on different hosting services with the same credentials (hash/key/etc) but different domains (ideally I'd have a round robin DNS and the same name, but I also want to account for the case where they have different domains).

Will this work? In other words, I have the exact same phpmyid files, including the credentials, on different servers. Can I use example.com/id and example2.com/id and expect it to look the same on my end so I don't have to link multiple OpenId accounts to each user in my system?

While I use the example of phpmyid, the question is more general - are the credentials what's important, or is the domain/ip/??? also linked in such a way as to prevent this?

Is there, or can there be, a standard that would allow one to move one's OpenID from one provider to another without having to delink and relink on each website they used that openid on?

-Adam

Answer 1

I recently posted an answer to the question "How do I use more than one OpenID?" which may address your concerns.

A professional provider should have a redundant service commonly archieved by having a load balancer in front of two separate servers, but users should host an XRDS document on a custom domain (or by using an i-name) with references to different providers (for fallback purposes)

You could also host identical data on different servers but round robin wont help you. This is because round robin just acts as a simple load balancer (it doesn't check whether a host is accessible).

Answer 2

An OpenID is a URL. example.com/id and example2.com/id are two different OpenIDs, regardless of which provider hosts them or what credentials the users share with those providers. The reliability of an OpenID really comes down to the reliability of hosting that URL. Yes, you can define fallback providers in your XRDS document, but you still have to be able to discover that document from the OpenID URL in the first place.

So the reliability techniques for OpenID are, for the most part, the same as for any other web resource with a fixed URL. And, as a relying party, there isn't a lot you can do about that. As you said, it's up to your users to choose an OpenID provider that suits their own requirements. You might suggest to your users that they ask their OpenID provider if a service level agreement is available.

The one thing you can do is allow your users to associate their account in your application with multiple OpenIDs.