Apparently I still care about OpenID. So it's going to sound bitter. Sorry for that.

What happened is some time ago Google has redesigned its profile pages and along with the redesign changed their URLs from http://www.google.com/profiles/username to http://profiles.google.com/username. As good network citizens they also set up a permanent HTTP redirect (301) from old addresses to new ones. Unfortunately this wasn't enough to deal with legacy.

Google profile pages are also OpenID identifiers. And they are actually make pretty good OpenID identifiers because they aggregate other profile pages and serve as a personal information hub from which one could explore a lot about a person. So many people used them as their OpenIDs. "Using" an OpenID identifier means that users become known to other sites by their exact Google profile URLs. And while on some sites there are additional ways to log in into an account on some there aren't. Also not all people bother to set up additional log in credentials (after all, OpenID was supposed to save people from this chore.)

Now, OpenID specification defines a protocol for normalization of user-supplied identifiers that instructs a consumer (a site to which the user tries to log in with the OpenID) to follow all redirects and consider the last address in the chain to be true user's identifier. This is a useful behavior: it lets people be sloppy and forget their trailing slashes and such…

By changing profile URL scheme Google has effectively disabled access for their users to their profiles on sites where they are registered with their Google OpenID.

Actually this is not the first time when Google does this. A while ago several users of my forum complained about exactly the same problem: Google OpenIDs have changed. Though at that time it was about their "other" OpenID URLs of the form https://www.google.com/accounts/o8/id?id={hash} and the hash was what has changed. And though these addresses have never been intended to serve as profile pages still their change has broken access to people's accounts…

Now I understand that if a simple redirect can trash accounts of a lot of people it means that the spec is not perfect. Perhaps it could address the need of a provider to freely change URL scheme and say something along the lines:

if a user-supplied identifier results in a permanent redirect consumer should keep track of a source address during the whole authentication process, use that as a claimed identifier and if there is a profile corresponding to it change it to the new address

But it doesn't say this. And many consumer sites on the Web are made by the spec and their Google users are suffering right now (a bit of drama won't do any harm). And as an owner of one such consumer site I wonder what I should do: make an exception for The G Almighty and go run a query updating Google OpenIDs in my database (and merging accounts of those who already has registered with the new ones) or just let users loose their accounts because their provider couldn't care less…

All this just breaks confidence in OpenID as a viable technology. Unfortunately at the time we don't have any better alternative (vendor-specific solutions notwithstanding).

Dear Google engineers! Is it possible to fix this?

I'm not a native English speaker and I'm trying to improve my language skills. Please feel free to use comments to correct any grammatical and spelling errors!

Comments: 3 (feed)

  1. people say specifying https://www.google.com/accounts/o8/id as openid url may be a workaround for that issue

    anyway, that's quite bad situation

  2. What about using delegation with Google profiles. That way you have complete control over your digital identity. However, this does require owning a domain name and running or having access to a web server at your URL.

  3. And this "however" makes all the difference, as it appears.

Add comment

Text delimited with a blank line becomes paragraphs, quoting is done with > on the left, list consists of items with a minus on the left, italic is marked with * from both sides, bold -- with **, code blocks are indented with 4 spaces