CTOForADay.com

The problem, for which both Passport and Project Liberty offer a solution, is to how to build a set of applications out of little pieces, where the little pieces are run all over the internet. You sign up, for example for an address book at X (let's say Yahoo! Mail), but you can access that address book in all the sites you use for webmail, and it shows up in Friendster. That's a simplistic example, but it's an example of the problem: Big applications on the internet are built from a lot of small pieces, and some companies want to be able to outsource those small pieces to companies that specialise in that service.

Web Services are simple, in premise - the idea that you can take any application, and provide a programming interface that runs on the web, rather than on the machines which run the rest of your application. Instead of building a monolithic application, where all of the code is in one big thing, you split everything out into smaller chunks, and distribute it across a set of servers; to scale an application locally, you do so on a local network - you then step from services on your local network into services on the internet.

There's a problem with all of this, and it's not immediately visible. The problem isn't getting all of those pieces to act like a single application - developers have been doing that since long before there was an Internet as it exists today - the problem is with you, the user.

That address book, sitting there, is your data; it represents you to that service. But all of the other little pieces also need to know something about you; even if it's purely to pass along the permission to view that data. This is where the Microsoft solution starts to look a lot different than the Liberty solution.

In a Passport world, you use Passport as your identity card - anyone who needs to get access to that information requests it from Microsoft via the passport protocols, and that makes the little window pop up, sent not by the provider but by Microsoft, to get that permission from you. I, the service provider, never see the password you gave to Microsoft, the identity provider.

But there's a problem with this: Either Microsoft needs to give me everything I need to know about you, or I need to ask it from you directly. But your identity, the one that matters, is the Microsoft one. It's that identity, managed by Microsoft, which all of the little components of the application use to identify you and your data as being you, the thing that allows all of those elements to maintain the illusion of a single service to you, the customer, instead of a lot of little bits that all require you to create a user account.

Worse yet, Microsoft doesn't support Passport for those of us who don't write our internet-enabled applications on Windows. If you write web apps on Solaris, Linux, Macs, or any of the other software out there, you're out of luck. That's not even just a limitation of the service you provide, either - your developers need to deploy their code to test plaforms that run Windows; they'll also need to be running Windows themselves, realistically. It's an intricate and beautiful stranglehold on what could have become, but didn't, a ubiquitous identity mechanism; sitting at my mac, deploying my applications on Linux with Windows running the database only, you can bet this wasn't a future I was looking forward to.

Liberty works on a principle of "federation". A group of companies basically decide to allow users to link accounts together. It can behave like the Microsoft system, allowing a range of service providers to get access to the contents of a single provider's identity. In many ways more importantly, however, it allows the system or the user to link a bunch of completely separate identities with the knowledge that they're all actually you. Nobody becomes that central point. Who you are depends on where you started using services; everyone else makes your identity on that service provider the one that matters.

Geared more towards the realist's modern business environment, where users have identity information at a broad range of service providers and already have far too many sources of identification, the system assumes, and does so correctly, that there's no way you're going to throw away all of those existing accounts and replace them with something which is, fundamentally, less flexible. What's needed is a way for identity information in any one arbitrary company to, at the request of the user, be linked to and shared with any other company's information, allowing that user to use either identification information to log into the other's service. Passport without a Microsoft; ubiquitous identity without a single, monolithic provider.

One might sarcastically say that, when seen that way, it's unsurprising that an open forum chose an open system with no centralised identity provider, where Microsoft saw a monolithic service owned and operated by themselves.

Liberty is just starting to take a foothold; over at WhatsOnWhen, we're still in the early phases of implementation - using Liberty internally to unify all of our different sites' user databases (legacy systems and new systems) into a single identification service for internal use. Then, we can link in our partners - allowing those who we buy some services from to get enough information to provide a seamless, single sign-on experience. Then we'll move into full-blown identity sharing.

Like FedEx, which is using Liberty to merge its own (ten?) different user databases, each with information about a user different from the others, into a single virtual authentication system, we're doing that across all of our applications, giving our users the ability to use their identity with any of the providers we provide personalised content for. And we get the benefit of being free to phase out those legacy identity systems, transparently, at our leisure, transferring users to a new, squeaky clean and more broadly useful system.

It means we will do less custom work to integrate custom services; it means we will spend less time reinventing yet another wheel each time one of those custom services needs to be done. And it means that, for our partners who buy our content, we now have a way of maintaining that single identity across their whole application, including our part of their system, without implementing a different authentication system for each partner, or forcing a partner to do something non-standard with their existing platform.

Verson 1.0 focused on the ability for provider A to federate, or link, to an account on provider B. The next version up will offer information sharing; a version to follow will, amongst other new features and improved capabilities, bring Microsoft's own Passport users into compatibility, and Redmond's database of Passport users will be able to use their identities to log into services just as easily as AOL's customers or FedEx's employees.

It's even leaking into consumer products:

Under the deal with Fountain Valley, California-based D-Link, D-Link's Wireless Media Player will stream AOL multimedia content to non-PC devices like TVs. IDWSF outlines permission-based attribute sharing, identity discovery service, interaction service, security profiles and support for devices that don't run HTTP-servers, like TV sets.

Plug in the wireless media device, and get multimedia internet stuff on your TV. Use your AOL account, and you get AOL content. But the platform isn't implementing an AOL identity protocol - anyone can implement the Liberty protocol, reach a commercial agreement on access, and you can log in using whatever information you've got with whichever provider you're with, and the box will work.

So there's hope for a future that's less demanding of users; one that will, ideally, mean that registering is easier, deregistering is simpler, and you'll have less reason to fill your Mac's keychain or your browser's security keyring with a million different usernames and passwords, all with the benefit of knowing that things you want to keep private to one service stay private to that service.