Links

Ben Laurie blathering


Google Account Authentication

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.

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.

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

Well…

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

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!

11 Comments

  1. Whilst I agree that some of the press commentary has pitched this in terms of vendor sports, I do believe that Eric and Dick are raising legitimate concerns in the light of the significance of Google on the web, just as similar concerns were raised when Microsoft announced Hailstorm/Passport.

    It seems to me that the definition of good journalism involves verifying the available facts and commenting accordingly. That being the case Google’s policy not to “announce what it’s going to do” means that commentary has to be based on what Google has done. Microsoft with LiveID has announced its intentions with LiveID and so that can figure in the commentary. Of course, that situation may change at which point sound commentary should reflect that change.

    You’re absolutely right that there is not currently a “mature, reliable, secure identity federation mechanism that’s widely used?” as the recent long running debate regarding the definition of federated identity on the Identity Gang demonstrates. But that does not mean that Google can not make official statements, alongside the announcement of the authentication APIs, that it is actively participating (which you certainly are) in the ongoing discussions in the community to establish some open, interoperable mechanism. It is not a statement of what Google is going to do but it does show that Google intends to move in the right direction.

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

    It seems to me that the issue is less about opening up Google’s SSO to various properties to get a token to act on behalf of the user but rather whether a token provided by another property could be used, through federation agreements, to act on behalf of the user. I think this gets to Dick’s “deepen” comment regarding the ownership of the identity data.

    Comment by Neil Macehiter — 22 Jul 2006 @ 17:55

  2. […] 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. […]

    Pingback by Kim Cameron’s Identity Weblog » Bad journalism or bad communication? — 23 Jul 2006 @ 2:57

  3. […] Ben Laurie from Google responded to my post on Google Account Authentication: two steps forward, one step back. A few comments that I’d like to respond to: 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? […]

    Pingback by Identity 2.0 » Google’s Identity Silo — 23 Jul 2006 @ 4:37

  4. Hey Ben, suprised to see this post given conversations we had. I think Google did what was right for Google, but has an opportunity to do what is right for the user and the internet by helping to drive Identity 2.0. More detail over at: http://identity20.com/?p=72

    Comment by Dick Hardt — 23 Jul 2006 @ 4:39

  5. Could you explain why Google shouldn’t allow their accounts system to be accessed by Yahoo credentials?

    Comment by Fred — 23 Jul 2006 @ 5:10

  6. […] LinksBen Laurie blathering « Google Account Authentication […]

    Pingback by Links » Identity 2.0 - Apples and Oranges — 23 Jul 2006 @ 16:15

  7. […] Eric Norlin responds to the Ben Laurie post I addressed here:  Ben Laurie, an employee of Google who is quite clear about the fact that he does not represent Google itself, is responding to my earlier post contrasting Google and Microsoft. Ben’s pushing back on my contrasting of Google’s Account Authentication versus Microsoft’s Live ID, and my treatment therein. Specifically: […]

    Pingback by Kim Cameron’s Identity Weblog » Eric Norlin and Dick Hardt hold firm — 23 Jul 2006 @ 17:13

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

    I don’t know what happened between Liberty and Apache in the past, and I’m not sure exactly which kinds of complexity were of concern, but I can certainly comment on the IPR situation, since Liberty has adopted SAML V2.0 whole for its “Liberty Federation” solution. So let’s look at what’s going on with SAML IPR-wise (documented at http://www.oasis-open.org/committees/security/ipr.php).

    Between December 2004 and June 2006, four companies — AOL, RSA, Fidelity Investments, and Sun — have issued “non-assertion covenants” on SAML. Some of these companies had previously publicly identified specific patents or patent applications that they thought applied. I wrote about the news of Sun’s NAC here:

    http://www.xmlgrrl.com/blog/archives/2006/06/15/a-promise-to-you-dear-developers/

    A NAC is a very good thing indeed for developers, providing an unprecedented level of assurance. Prior to these statements, the only declared IPR on SAML itself was from RSA, and they offered royalty-free usage in return for registering with them, a step which I believe was of concern to Apache.

    I’m not sure what other news you’re watching this space for, but if there’s some answer I can provide (or research) in response to questions or concerns you may still have, I hope you’ll bring them to my attention.

    Comment by Eve M. — 24 Jul 2006 @ 14:42

  9. […] The end result of the blog deathmatch between me, Kim, Eric and Dick was a deathly silence on what I consider to be the core issue. […]

    Pingback by Links » Comparing Apples and Apples: Microsoft and Google Authentication — 1 Aug 2006 @ 15:17

  10. […] Ben Laurie of Google writes that something important was left unsaid in the recent discussion of federation and large Internet properties: The end result of the blog deathmatch between me, Kim, Eric and Dick was a deathly silence on what I consider to be the core issue. […]

    Pingback by Kim Cameron’s Identity Weblog » Yes or No? — 2 Aug 2006 @ 21:39

  11. […] I agree with that. Have a look at a discussion about identity, for example here there it seems to be impossible to allow multiple choice. Till the day that we just use terminals (again), the intermediate solution to the identity problem isto provide your customers multiple choices to store a little bit of information about the role they chose on the internet. We at THINSIA do this as well: On our HEARTBEAT-ID site, people can login with their i-name (identity broker), and later with our HEARTBEAT-ID (biometric access method).The use of OpenID is probably the easiest way, later on we will use e-directory from Novell.Our customers will then access their side and their programs, using the THINSIA technology. Having the choice of identity provider and access provider is the way to go. The internet is about giving lots of people lots of choices. […]

    Pingback by THINSIA BLOG » Lots of choices — 15 Feb 2007 @ 21:57

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress