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:
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.
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.
Did you miss the part where they say "Google supports the OpenID 2.0 Directed Identity protocol, and provides authentication support as an OpenID provider"?
They're supporting 2.0 which supports discovery requests...
End users do not equate a URI as being anything that identifies them. To them, that is a website.
Why is openID hell bent on trying to spin the tables on everything that people know and are used to? They know email address = my identification/username.
The ONLY possible upside I can see, is that it slightly reduces the risk that they give the crown jewels (say, their Google User name and password) to some malicious site mistaking it for an open ID log in.
In other words, the fact that the identity is the web site is a feature. It may not be the right feature, but I think there is some design thought behind it being a url. So users get used to not immediately providing a password, but instead this URL, and THEN after some redirect shenanigans, they do their password etc...
It seems like the OpenID guys should have included the ability to use an email address as an OpenID in the first place. But this does increase the chances of uninformed users falling prey to phishing.
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.