Soothing music all around

Google's Ben Laurie continues with a post I'd call “Cogent with cloudy periods”:

Not surprispingly, my post “Google Account Authentication” attracted some pretty instant responses, as well as comments on the post itself.

On further reflection, comparing Live ID with Google’s authentication is comparing apples and oranges. Live ID may allow people to choose who they accept authentication from, but where does it say that anyone is planning to accept anyone’s word other than their own? In particular, where do Microsoft say they’re going to grant access to Microsoft properties using identity tokens issued by anyone other than Microsoft?

Interesting. Let me explain how I see it. The Windows Live ID whitepaper is about the technical architecture of Windows Live ID, and new capabilities allowing it to be part of a standardized, multi-centered, federated identity fabric. This includes support for Information Cards. Reading the paper, it's easy to see how enterprises or groups of users could gain access to Windows Live services using their native systems federating with Windows Live ID, rather than requiring separate accounts. The business model for this would be totally straightforward.

Now, in terms of how the protocols work, a similar federation relationship could be established between a Windows Live and a Yahoo or a Google. But the business models there are way harder to figure out. You need multiple players to buy in – it needs to be a win/win/win. I don't think anyone has figured this stuff out. Basically, it's a lot easier to change technologies than to change business models.

Still, to me, it makes sense to put a safer, more flexible technical infrastructure in place that offers advantages within current business models while simultaneously laying the groundwork for new approaches as they arise. But let's try to see the two as relatively autonomous.

Ben continues:

Eric Norlin says: “Lots of people inside of Microsoft now understand *why* they must open the silo, and that learning is precisely because of their experience with Passport.” But is this actually true? What Microsoft appears to have learnt is that it can’t get everyone to accept its credentials. So, what’s the next best thing? Get everyone to use MS technology for accepting credentials. Perhaps that’ll even lead to Passport Mark II where the default is to trust Microsoft. Where does Microsoft’s work on Infocard or Live ID or whatever-the-passport-nom-de-jour is show that Microsoft has any intention whatsoever of opening their silo? What it shows is that they think everyone else should open their silo.

This mish-mashes so many orthogonal ideas together that it gets a wee bit looney. If the following sounds disconnected, it's because the way Ben connected things doesn't make any sense to me:

  • It's true that a lot of us at Microsoft want to “open the silo”. That doesn't make it easy, or make it obvious what to do.
  • WS-Trust is not Microsoft Technology, unless IBM is now part of Microsoft – not to mention the hundred or so other companies who have worked on the WS specifications.
  • Information Cards are not Microsoft proprietary for two reasons: first, the protocols are in OASIS standardization and available royalty-free; and, second, because there is a consortium building real open-source implementations today (OSIS).
  • I don't understand why Ben wants to confuse a service offering like Windows Live ID with a cross platform technology initiative like the Identity Metasystem.
  • I'm even more mystified at the implication that our Cardspace implementation of Information Cards is a plot. It doesn't offer special advantages to Windows Live ID. Services like those offered by Google get equal billing with services that might come from Microsoft. What is the sin here?
  • Given the difference between services and open cross platform technology, why call Cardspace “the-passport-nom-de-jour” – except to be naughty?

Anyway, I'm just going to assume Ben had a bad hair day, which everyone has a right to.

Parhaps the flurry of postings made it look like people were ganging up on Google – not at all my intention – I still think that on identity our interests converge and we're all in similar places.

At any rate, Ben concludes thus:

Fred asks: “could you explain why Google shouldn’t allow their accounts system to be accessed by Yahoo credentials?”

All I can say is what I already said: there isn’t a widely used, mature, reliable, secure identity federation mechanism available today. Whether Google wants to do this or not, in practice, they can’t. Such decisions have to wait for standardised mechanisms to emerge, in my view.

Dick is “suprised to see this post given conversations we had”. Well, Dick, if the fact that I don’t always agree with you is surprising, then you’d better stock up on soothing music or something.

I think the situation calls for soothing music all around. How about Iggy Pop?

Published by

Kim Cameron

Work on identity.

8 thoughts on “Soothing music all around”

  1. Ok, I have installed .NET 3.0 July CTP and since I already had IE7 Beta 3, it took only a few minutes, no reboot required. This stuff seems to be of good quality already!

    To the comment …

    I have to admit Ben Laurie has some good arguments.

    Today we have identity silos without the possibility of interoperability. With Infocards we might end up with the same identity silos but with the distant promise of interoperability. However, the technological opportunities will be stopped by the business who wants to protect some important aspects like identity information and branding.

    The cardspace implementation will create a much more pleasant and more importantly secure and consistent environment for the user. Small sites will benefit from the interoperability with the big silos.

    Larger sites however will keep a tight guard on their identity information and will continue to do so in the future, even with Identity 2.0 or Infocards.

    Consider this: would Microsoft ever give up being an identity provider? Why not?

Comments are closed.