eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Update: Several bloggers breathlessly yesterday rushed to note that Google is supporting OpenID without reading the fine print in the OpenID developer documentation.
It turns out that Google isn’t technically using OpenID, but has actually created its own flavor of the standard, according to The NeoSmart Files blog. The blog is published by Mahmoud H. Al-Qudsi for NeoSmart Technologies, anon-profit organization specializing in tech research and development.
OpenID allows Internet users to log on to many different Web sites via single sign-on, a convenience for people tired of entering user names and passwords for every Web site they had. Microsoft, Yahoo and AOL all support the standard and the tech world has been waiting on Google.
What Google proposed yesterday is an OpenID-like button, so that when a user accesses the home page of a Web site that uses the Google Data APIs (the code behind the button), he can click on that button to enter the site instead of having to fill out a login box or account creation form. The user gets bounced to a Google page, where he confirms he wants to access the OpenID-enabled site.
But according to The NeoSmart Files, Google isn’t actually using OpenID:
“With OpenID, the user memorizes a web URI, and provides it to the sites he or she would like to sign in to. The site then POSTs an OpenID request to that URI where the OpenID backend server proceeds to perform the requested authentication. In Google’s version of the OpenID “standard,” users would enter their @gmail.com e-mail addresses in the OpenID login box on OpenID-enabled sites, who would then detect that a Google e-mail was entered. The server then requests permission from Google to use the OpenID standard in the first place by POSTing an XML document to Google’s “OpenID” servers. If Google decides it’ll accept the request from the server, it’ll return an XML document back to the site in question that contains a link to the actual OpenID URI for the e-mail account in question.“
That’s geek speak for Google is playing a shell game with OpenID. Google admits as much in the technical documentation here, where it notes what it has done is “a departure from the process outlined in OpenID 1.0.”
David Recordon, an open standards guru and technical platform engineer at Six Apart, agreed. He noted:
“The piece that Google is currently doing differently is requiring pre-registration of each OpenID Relying Party before users can login to a given site. This does break the common deployment of OpenID on the web today, but Eric Sachs of Google has said on the OpenID mailing list that this is temporary as they work to stabilize their OpenID Provider.“
Sachs did write in this blog post yesterday that “we are providing limited access to an API for an OpenID identity provider that is based on the user experience research of the OpenID community.”
But let’s be realistic, most bloggers and journalists are looking to filter the information, not read between the technical lines. Moreover, they probably wouldn’t even grasp the exact meaning of the technical distinction in Sachs’ phrasing, particularly after reading the headline of Sachs’ post, “Google move toward single sign-on with OpenID.”
Given that Microsoft, Yahoo and AOL are all OpenID supporters, the conclusion most of us leapt to was that Google was joining the fray, not joining the fray with a caveat or *. But such is the case, even if, as Recordon wrote in reference to The NeoSmart Files post: “people seem to like controversy…”
NeoSmart does seem to like that indeed, noting that Google’s iteration of OpenID is so different that existing OpenID relying parties won’t be able to use it. The post concludes, with some vitriol:
“OpenID is an open, community-based standard. Stabbing them in the back by creating an incompatible standard “based on” the same technology and masquerading under the same name isn’t the way to go. Google may have the best interests of decentralized authentication in mind, and perhaps even the better protocol to boot; but this is no way to prove a point… Thanks, Google. Good to see you’re still doing the whole “Do no evil” thing, the community really appreciates this kind of approach to improving de facto standards and pushing decentralized authentication!“
I’m glad NeoSmart called our attention to this distinction. It reminds us as bloggers/journalists that we need to be on our toes. I’ll be the first to admit if I hadn’t been 4 stories deep yesterday and to burnt out to write with any clarity when I saw the Google post, I’d have fallen into the same wrong conclusion trap.
Kudos for the NeoSmart files for the catch. In the meantime, I’ll be Google Watching for when Google “stabilizes its OpenID provider.” Whatever that means.
*Google’s Sachs explains what he means and adds clarity to the issue in a follow-up blog post here.
The snag is a couple technology issues Google is working to fix, as Sachs wrote: “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 a relying party today.”
Google is working to remedy the issues. Frederic Lardinois has a cogent explanation at ReadWriteWeb here.