Google revises its OpenID implementation to accept all Relying Parties

The foundation for security and enterprise management

Google got to its position in the pantheon of technology companies by not being always right. It has made mistakes as often as, and as big as, anyone else in the industry. But what got Google its leadership position (in addition, of course, to a great search engine) is its ability to admit when it has made a mistake and then to correct it. Last week I mentioned that Google's implementation of OpenID had caused quite a stir in the OpenID community. There was happiness that Google - the Midas of technology companies - had touched their pet project but also despair that it wasn't a pristine implementation. One major sticking point was that your Google OpenID would not be usable at just any site that accepted OpenIDs (called "Relying Parties" or RPs).

Google would maintain a white list of vetted and approved sites and only those would be allowed to participate. Well sometime between when I wrote about that and when that newsletter was published, Google had a change of heart. According to a Google blog entry this was because of an overwhelming number of requests to become white-listed RPs.

I didn’t say Google wouldn’t fib about its reasoning, did I?

To continue reading, register here and become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

Google got to its position in the pantheon of technology companies by not being always right. It has made mistakes as often as, and as big as, anyone else in the industry. But what got Google its leadership position (in addition, of course, to a great search engine) is its ability to admit when it has made a mistake and then to correct it. Last week I mentioned that Google's implementation of OpenID had caused quite a stir in the OpenID community. There was happiness that Google - the Midas of technology companies - had touched their pet project but also despair that it wasn't a pristine implementation. One major sticking point was that your Google OpenID would not be usable at just any site that accepted OpenIDs (called "Relying Parties" or RPs).

Google would maintain a white list of vetted and approved sites and only those would be allowed to participate. Well sometime between when I wrote about that and when that newsletter was published, Google had a change of heart. According to a Google blog entry this was because of an overwhelming number of requests to become white-listed RPs.

I didn’t say Google wouldn’t fib about its reasoning, did I?

When someone does the right thing we need not examine either their motives or explanations too closely. It’s enough, I think, that the right thing gets done.

That said, I wish Google would own up to the real reason why it hasn’t become a RP. Not that it trails behind other technology leaders in this regard as there are few, if any, significant RPs. There are a couple that use white lists to specify OpenID providers whose credentials they will trust – but that’s not the vision of OpenID, is it?

In that same blog entry cited above, Eric Sachs, from the Google Security Team, says that the “…problem is that rich-client apps (desktop apps and mobile apps) are hard-coded to ask a user for their username and password. As an example, all Google rich-client apps would break if we supported federated login for our consumer users, and in fact they do break for the large number of our enterprise e-mail outsourcing customers who run their own identity provider, and for which Google is an RP today.”

If those apps aren’t calling a common service for authentication, then Google needs a new programmer-in-chief. And if they are, how hard is it to modify that service to accept multiple authentication methods?

No, the real reason most major Web sites are not jumping onto the OpenID bandwagon is a legal one. The lawyers want to know who will be liable when a security breach occurs. Not “if,” but “when.” Security breaches will occur. Some with minor consequences – but some with major consequences. Without ironclad contracts covering every conceivable possibility, the legal beagles won’t sign off on the plan. We need standardized, XML-enabled, auto-sensing legal contracts. OASIS, are you listening?

Read more about security in Network World's Security section.

Dave Kearns is a consultant and editor of IdM, the Journal of Identity Management.