Not exactly the post I want to write after a long week, but there have been severalposts following the developer launch of the Google OpenID IDP. Unfortunately, those posts are inaccurate, and it is worth clarifying what is going on so no one else makes the same mistake and repeats the (incorrect) claim that Google somehow "forked" OpenID.
The first criticism has something to do with the erroneous notion that, simply because the Google IDP supports the indirect lookup of a user's identity, this is somehow an invalid use of the OpenID protocol. On the contrary, it is using a standard technique known as Directed Identity, which can be found in the OpenID 2.0 specification here. Directed Identity allows users to enter a generic domain name (e.g.., "example.com"), rather than a fully qualified identity (e.g., "example.com/users/bob"), so that they can use their identity provider to make an informed decision about how much personal information to expose to the RP. This is a good thing. You want this. You want to be able to make that disclosure choice yourself.
Another (again mistaken) claim is that because, during the test launch, Google whitelisted the initial set of allowed Relying Parties, that the specification was somehow violated. On the contrary, there is nothing in the spec that requires an IDP to provide access to user data to all RPs (nor should it!), and in the case of the Google launch, the whitelisting was just planned for the initial launch anyway. The initial launch went well, and all RPs are now whitelisted. (This wasn't a reversal of policy, this was the plan all along.)
The third inaccuracy stems from the second. During the whitelist-only test launch, Google could not publish an XRDS document at the root of the gmail.com domain for all users because it would fail for users using it on non-whitelisted RPs. I can see how this would be confusing if one didn't know how OpenID 2.0 works with XRDS, but it was the right decision. And now that everyone is whitelisted, Google can publish the XRDS document on the root of gmail.com. (I don't think that part has launched yet -- in the meantime, you can use the explicit path of "https://www.google.com/accounts/o8/id" to fetch the XRDS document.)
And last, there seems to be a huge misunderstanding about email addresses vs. URLs as identifiers. URLs make fantastic identifiers -- for the 0.1% of the web population that understands that they "are" a URL. Fortunately, the other 99.9% of the world (our parents, for example) already understand that they have an email address. As has become increasingly clear to everybody doing usability research on OpenID (see here and here), we absolutely need to provide mechanisms for mapping human-friendly identifiers like email addresses to identities. That's not to say that URLs-as-identifiers should go away. On the contrary, I myself use "dewitt.unto.net" as my identifier, and fortunately, the spec is smart to allow for multiple ways of surfacing that identity. (Or more exotically, I expect we'll see great things to come with mobile phones or phone numbers as identifiers as well.)
While I don't fully understand the motivation behind the attacks made in those articles, I do find it rather unfortunate that they've been picked up and repeated by people who are similarly unfamiliar with the technology itself. I guess a lesson might be to pause for a second before repeating a rumor you don't personally understand.
The truth is that OpenID is still in its teenage years and still has a lot of growing up to do, but in the last few months we've several of the biggest sites on the web launch as identity providers (nearly everyone on the web has an OpenID now), and continued improvements and additions to the core specifications, and groundbreaking usability research. Bumps along the way notwithstanding, this is forward progress.
Update:
Kevin Marks has a great response about whether or not, as Ben Metcalfe says below, OpenID forked itself by turning into more than a mechanism for claiming resolvable URLs.
I'm personally of mixed opinions about this myself, as I don't want those more advanced use cases for OpenID overshadow the original role of OpenID as a standard for claiming URLs. In fact, I was among those not entirely in favor of putting these (admittedly valuable) new concepts into the core OpenID 2.0 spec, and would have preferred independent extensions instead. As people try and do more and more with OpenID -- such as SSO, profile exchange, and non-URL-based identity mappings -- this can indeed lead to what Dare calls the "square peg in a round hole" effect. But to be crystal clear, no one is forking the spec just by implementing the spec in a way it allows for.
And I stand duly chided by Kevin for the rhetorical exaggeration about whether or not the mainstream user can learn to type in a URL to identify themselves. The truth is that no one knows for sure if they can, though the research is showing that that those of us (myself included) who argued for URLs exclusively were probably hoping for too much. But as long as we can always map the user-driven identifiers back to URLs, then I do believe we get the best of both worlds.
As Kevin says, see you all at IIW!
Disclosure: I work for Google, and I represent Google on the OpenID Foundation board. That said, I'm really writing this as a member of the community, just trying to figure out how this story got so mixed up to begin with.