OpenID for Google Apps is Here, But Not Everybody's Happy

Written by Steven Walling / July 28, 2009 2:35 PM / 9 Comments

Google announced today that everyone using Google Apps enterprise or education editions can now use their organization's domain as a federated single sign-on. That means that millions of schools, businesses and other organizations can now use their Apps accounts as an OpenID.

For a movement that has seen adoption held back because of confusion or just plain unfamiliarity among consumers, this should be a huge boost. However, a few prominent developers and advocates feel that Google's approach is not entirely acceptable. They are critical of the use of vendor-specific extensions and APIs instead of the open standards that are so important to OpenID.

The Sound & Fury

The concern that some OpenID developers have expressed publicly is in regard to the way that OpenID discovery occurs. The crux of their concern is not whether Google's solution will work; it's about whether Apps OpenID will function as a provider that gives people full control of their online identity.

Independently of the OpenID Foundation, Google has rushed to use their own methods. Unlike OAuth, the discovery is currently a part of the OpenID core, even if it isn't related to how the actual authentication functions.

In order to be redirected from their domains to Google's OpenID service, relying parties will have to use an extension developed by Janrain, despite work that is well underway by the Foundation on a standard independent of any one vendor.

Google, Your New Identity Hub

Now that the Apps OpenID has been released, another issue has arisen. It's related to how Google will become an identity hub for SaaS partners which want to let their users login with their Apps accounts. Early partners in this program that were announced in the blog post by Google today include Ping Identity and Manymoon.

Some have taken issue with Google's API even being the fallback system should a normal request fail. But for these partners, it looks as if the API is not the fallback system: it's the default. By cutting corners and not using a more neutral method, Google is unlikely to get the support from the OpenID Foundation they want.

In a phone call today, Google's Eric Sachs said that though the company has no control over how partners choose to implement the system, it was necessary to use the API if they choose to present it to users as a way to log in directly with Apps.

Thin Ice

It would seem that despite best intentions for an exciting project, there are some issues that could curtail support for the initiative. The announcement of the plan was accidentally leaked to the public earlier this month, and it revealed fears at Google that the project could be viewed by the community as an attempt to co-opt OpenID.

To Google's credit, they've been talking with the OpenID Foundation to try and address any concerns. "We definitely do want to work with the community on this." said Sachs.

Still, any opposition from the OpenID Foundation or the community at large about how Google is implementing OpenID could damage its "don't be evil" credibility, at the very least.

Comments

Subscribe to comments for this post OR Subscribe to comments for all ReadWriteEnterprise posts

Let's be clear, there is no requirement for any developer to use Google's OpenID API extensions UNLESS they want Google Apps users to be able to log in to their sites using a corporate custom domain -- that's the trade off. Keep things as is and you still continue to be able to offer OpenID sign in to everyone with a real OpenID identity.

I think this exercise makes OpenID more usable and will bring it to more people's attention as a way to easily navigate around a password protected web. If OpenID starts getting used it benefits everyone. I appreciate the Google tweaks won't please the "purists" but prior to this OpenID had made few inroads into the shared sign in space: fewer than 2% of visitors to our site use it to sign in, whereas 50% of those using a third party identity sign in with Twitter OAuth for example. With the Google Apps announcement I believe we'll see things change and it's hard to argue it's not for the better as far as OpenID's future is concerned.

Ian Hendry
CEO, WeCanDo.BIZ
http://www.wecando.biz

Posted by: Ian Hendry | July 28, 2009 3:26 PM

I don't think this is a big boost. As you point out, this breaks compatibility and tries to muscle Google into the center of the discovery universe.

OpenID already has severe compatibility issues, with so many divergent implementations with divergent interpretations of a SHOULD-y spec. We don't need them to get even worse with proprietary extensions and different interpretations of the right way to deploy OpenID.

I hope enough people can see past the veneer to understand what today's so-called OpenID has really become. If Google wants to build a competitor to Facebook Connect, I would prefer they just do so, without mangling a previously open identity specification.

I don't blame Google for this, to be honest; nor do I blame co-conspirators Yahoo, Myspace, and AOL. Identity is a lucrative market, and branded buttons are fundamentally preferred by users to an egalitarian text box.

Google: please either roll your own, or work within the frameworks of the foundation and community. Either would be fine with me. Just don't leave a contorted chimera behind by domineering a community effort and using it as a friendly flag.

Posted by: magwitch | July 28, 2009 3:35 PM

A bit over my head this article, but I have an OpenID from an OpenID provider, does this mean that I now can use that OpenID to log on to Google? That would be great!

Posted by: Atle | July 28, 2009 7:30 PM

@ Atle

Sadly not. For this Google would need to offer OpenID sign in alongside the current sign in, which they don't.

@ magwitch

Google kind of had their own Facebook Connect equivalent in Google Friend Connect, but it's impossible to tie into existing user management systems. It also lacks, on a like for like basis, the ability to post activity feeds back to a central site that FBC has although this isn't a capability of OpenID either of course.

Ian Hendry
CEO, WeCanDo.BIZ
http://www.wecando.biz

Posted by: Ian Hendry | July 28, 2009 11:33 PM

Some people might be unhappy about Google's implementation but why should the OpenID Foundation (OIDF) be concerned about it? The OIDF was founded to promote OpenID. It's not about technology. From the OIDF site: "The OIDF does not dictate the technical direction of OpenID; instead it will help enable and protect whatever is created by the community." Google is part of the community.

OpenID is a technology, a protocol. People can do whatever they want with it.

Posted by: Carsten Pötter | July 28, 2009 11:41 PM

@Ian and Carsten, I'm dismayed at the apologism for this kind of behavior. It's Microsoft's old Embrace, Extend, Extinguish tactics with a much better PR campaign. This would be more of the "Extend" part.

Kerberos is just a protocol too. Kerberos gained extraordinarily widespread adoption after Microsoft picked it up, but then compatibility was deliberately broken with predictable results. MIT has finally spearheaded the creation of a Kerberos consortium(http://www.kerberos.org/about/FAQ.html) in an effort to bring back some interoperability to their world.

Reasonable people may disagree about whether wide deployment without a functional community or standards body, and at the expense of interoperability is ultimately good for a protocol. I happen to think it's not, because I think the entire point of standards-based protocols is interoperability.

But even if you think this is good, there needs to be honesty about what's being done and why, and a little less rah-rah cheerleading for any new deployment, no matter the long run impact of decisions made.

Posted by: magwitch | July 29, 2009 6:51 AM

To be fair, discovery is one of the hardest part of what's going on in the world of the open, social web. We've been at it easily over a year now and still don't have a final spec to go forward with.

Google has been collaborating with the community all along and I don't fault them for going as far as they could before the pace of the community started to impact their business objectives.

Would it have been a good thing to have the discovery protocol nailed down through a public, transparent process before Google launched this? Well, sure, maybe. But, just as HTML5 and CSS3 is being developed *simultaneously* with implementation in the browsers (namely WebKit), I think having implementation lead the protocol is also a productive path the pursue.

Let me put it this way: it only benefits Google to have their mechanism of discovery become widely deployed. To that end, they're more likely to work with others to make sure that their approach is mutually beneficial — or at least doesn't necessarily benefit them any more than anyone else. Give it six months and we'll have moved on from this — and hopefully will have a good format and protocol for addressing this obvious and as-yet-unsolved use case.

Posted by: factoryjoe.com | July 29, 2009 7:34 PM