But it looks like someone may have been a bit to hasty to pull that switch (perhaps itching to get some of the limelight Microsoft has been receiving for adding OpenID to all Live ID accounts just the day before yesterday)… because whatever it is that Google has released support for, it sure as hell isn’t OpenID, as they even so kindly point out in their OpenID developer documentation (that media outlets certainly won’t be reading):
- The web application asks the end user to log in by offering a set of log-in options, including Google.
- The user selects the "Sign in with Google" option.
- The web application sends a "discovery" request to Google to get information on the Google authentication endpoint. This is a departure from the process outlined in OpenID 1.0. [Emphasis added]
- Google returns an XRDS document, which contains endpoint address.
- The web application sends a login authentication request to the Google endpoint address.
- This action redirects the user to a Google Federated Login page.
As Google points out, this isn’t OpenID. This is something that Google cooked up that resembles OpenID masquerading as OpenID since that’s what people want to see – and that’s what Microsoft announced just the day before.
It’s not just a “departure” from OpenID, it’s a whole new standard.
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 email addresses in the OpenID login box on OpenID-enabled sites, who would then detect that a Google email 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 email account in question.
This is shown quite clearly in the following image (courtesy of Google, ironically):
As you can see, steps 3 & 4 are not part of OpenID and leave Google’s implementation of OpenID, such as it is, incompatible with everyone else.
Google actually mentions this in passing:
Starting today, 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. Websites can now allow Google Account users to login to their website by using the OpenID protocol. We hope the continued evolution of both the technical features of OpenID, as well as the improvements in user experience. will lead to a solution that can be widely deployed for federated login. One of the companies using this new service is www.zoho.com.
Eric Sachs, author of the blog post in question, doesn’t actually come out and say, but he does come very close.
Basically, Google has rewritten OpenID. Not only is it not exactly the same as the current OpenID protocol, it’s so different that existing OpenID relying parties won’t be able to use it. Only a handful of “partner sites” have been updated to understand Google’s perverted version of the OpenID standard, and anyone else hoping to authenticate via “OpenID” to Google’s servers will need to do the same.
But 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.
OpenID is on tenterhooks as it is, and cannot withstand any more efforts to splinter its adoption. Never mind the fact that almost all the big names adopting OpenID are joining only as providers and not as relying parties (rendering the whole basis of OpenID useless) – now even the provider side of things is chaos.
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!