Bad journalism or bad communication?

Identity master Ben Laurie of Google pushes back on me for picking up Eric Norlin's recent piece on Google Authentication.  Ben writes:

I’ve been trying to resist the temptation to comment on posts such as Dick Hardt’s “Google Account Authentication: two steps forward, one step back” and Kim Cameron’s “GOOGLE’S AUTHENTICATION VERSUS MICROSOFT’S LIVE ID” (which is mostly Eric Norlin’s “Google’s authentication vs. Microsoft’s Live ID“), since I work for Google and such comments might be misconstrued. However, bad journalism is bad journalism, even if you’re a blogger and I’m a Google employee, so I’m going to comment anyway. Note that, like everything I blog here, this post does not reflect Google’s views, nor does it use any knowledge I may or may not have as a Google employee.

Firstly, as everyone who pays attention knows, Google doesn’t announce what it’s going to do, only what it’s already done. So, what does it mean to contrast thus (from Eric Norlin’s piece)? “Of extreme importance is the fact that Windows Live ID will [my italics] support WS-Trust, WS-Federation, CardSpace and ADFS (active directory federation server).” vs. “Contrast all of this with Google’s announcement: create Google account, store user information at Google, get authentication from Google — are we sensing a trend?” – well, yes, the trend I’m sensing is that Windows Live ID does much what Google does today. Tomorrow they both may do something different. As of right now, what are the options? Is there any mature, reliable, secure identity federation mechanism that’s widely used? I think not. Note, BTW, that Live ID is currently vapourware, you can’t even get SDKs for it yet, let alone actually use it.

I need to begin by responding that I didn't know “Google doesn't anounce what it's going to do, only what it's already done.”  This must sound incredibly naive on my part, but it's true.

I guess I don't have a good enough understanding of the cultural differences between various companies.  I'm used to being required to share a roadmap with enterprises and large organizations.  They need that to facilitate their planning.  But in retrospect I can see that Google may not need to function this way.  I'm probably not the only one who hasn't understood this, so I appreciate Ben's explanation of how we should interpret Google's announcements.

Secondly, I agree that neither MSN nor Google nor AOL nor anyone else has a federation mechanism that's widely used outside their own properties at internet scale. 

Above all else, I agree with Ben's statement that, “Tomorrow they both may do something different.”  So peace, bro’.

Speaking of peace, Ben on Liberty:

Some have argued that Liberty is the answer to this, in that it’s mature, reliable and secure. But it isn’t widely used, partly because of complexity, partly because in its early days it royally screwed over people who might have driven adoption, like the Apache Software Foundation, and partly because of complex IPR issues. At least, I’ve heard, the IPR might be getting fixed. I watch that space with interest.

Ben on Dick Hardt:

Dick Hardt: “Google has just released Google Account Authentication. My initial reaction: great technology for rich clients and web sites acting acting on behalf of the user, but deepens the Google identity silo.” What does this mean? How does allowing applications to access a user’s Google services deepen anything? Did Dick actually read what these services do?

“The Google Account Authentication for installed apps is a bold move to standardize an API for working with installed applications. Unfortunate that it is domain centric. The user has to provide their Google credentials. Clearly the easy, safe choice that creates more value for the user’s google credential. Also makes it harder for any identity management technology to manage the Google credential.”


  • Duh, of course you have to provide a Google credential, you’re going to access a Google service. What kind of credential did you expect to present? Your Yahoo login?
  • Why does providing an API to allow applications to use user’s credentials make it harder for software to manage those credentials? I’m obviously missing something, but I can’t see what.
  • “Google Account Authentication for Web-Based Applications looks like it is opening up the SSO mechanisms that Google has been using across their various properties so that other properties can get a token to act on behalf of the user.” Hmmm … that sounds just like something an identity management technology could manage. But that problem was from a whole paragraph before, hopefully the reader will have forgotten about it by now.

Ben on the pack of us:

Its sad to see blogs following the newspaper trend, where the only articles worth writing are critical, regardless of the facts. Readership is king! To hell with accuracy!

Yikes.  Do I slither forward in a river of yellow journalism? 

I hope not.  The story I told was, “this is how Eric Norlin sees what's happening.”  He influences a lot of people, and his views are themselves important.  If Eric has drawn the wrong conclusions, it's important to get that message out – including to Eric, as has happened here.  Both Eric's piece and Ben's response have helped that happen.  I for one understand things better than I would have had none of this discussion happened.

And in case it matters, my own conclusion was actually different from Eric's.  I wrote, and I don't think it was at all critical:

.. I personally hope that Google embraces federation, Information Cards and the identity metasystem. They have enough smart people who understand these issues that I expect they will.

I see lots of room for us to work together, lots of agreement on the big picture, and  lots of good people doing the execution. 

Published by

Kim Cameron

Work on identity.