It's pretty BS... Software built around OpenID needs to be rewritten to detect when http://username@domain.tld/ is entered as a OpenID login and if it's @gmail.com address, contact Google's OpenID servers.

From the comments on the original story at Blogspot:

This is because http://username@domain.tld/ is a valid URL and can thus be used as an OpenID.

The problem is that while that may very well be a valid URI, it's not a standard URI and OpenID software hasn't been written to use this kind of mechanism.

To make matters even worse, there is no OpenID server set up at gmail.com - servers need to put a special case for when the @tld.com matches gmail and contact the appropriate OpenID servers in that case.. it's basically Google demanding that you authenticate their users on their terms.

Test results for OpenID: http://openidenabled.com/resources/openid-test/diagnose-serv... http://openidenabled.com/resources/openid-test/diagnose-serv...

EDIT

Here's the link to the Google OpenID documentation for developers, it's even more bloated than I thought:

http://code.google.com/apis/accounts/docs/OpenID.html

You need to ask Google to give you the URI to the OpenID endpoint for a given account. Each account has a different OpenID endpoint, and different incoming requests are routed to different endpoints....

And I quote:

3. 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.

4. Google returns an XRDS document, which contains endpoint address.

5. The web application sends a login authentication request to the Google endpoint address. This action redirects the user to a Google Federated Login page.

They're being pretty damn cavalier about using an OpenID that's not really OpenID in the first place.