A modern quest in IT Security is evolving from the authentication system based on password.
Passwords are insecure when used alone, prone to so called identity thefts, and are complex to manage in a world where you interact with tens of authenticated services from different vendors every day.
Microsoft approached the problem serveral years ago, trying to enforce existing authentication systems and to simplify it calling for Single Sign-On (SSO) with a technology called Passport.
Passport has been everything but a success, and Microsoft today admits it failed in the project, assuming users and service providers would trust a system which relies on proprietary database system (Passport accounts and login associations are stored in Microsoft servers).
Passport is today widespread but just because it's mandatory for MSN services, included Messenger chat service.
Today Microsoft tries again with a new identity management and authentication platform: InfoCard.
The technology mimics our real life system of authentication badges: driving license, credit card, frequent flyer membership, gym membership, etc.
InfoCards are digital representations (in XML language) of that authentication badges. Plain and simple.
In an InfoCard architecture there are
Identity Providers (authentication providers issuing you an InfoCard, like banks, libraries, etc.),
Relying Party (service providers or authorities asking for you InfoCard before according you a service) and obviously the user.
In other words your computer becomes an electronic wallet, holding several InfoCards issued by several Identity Providers:
(image from Indentity Weblog)When a user ask for a service offered by a Relying Party (let's imagine accessing the authenticated part of Amazon), this one sends back a
security policy, detailing what kind of authentication informations are expected to grant access.
At this point an engine on the user platform (which is embedded in the operating system, not to be downloaded from somewhere), the
Identity Selector, chooses among all available InfoCards, selecting ones satisfying security policy requirements. User has the final word on which InfoCard, among selected ones, to present.
This point is identical to real life: to mitigate frauds some shops require you to provide credit card and national ID card or driving license, so the shop (Relying Party) is sending us a requirement (security policy) and we need to choose (Identity Selector) which document (InfoCard) to show.
What's next? When the user chosen what InfoCard to present another local system called
Service Requestor contact Identity Provider, asking for a security token to offer to Relying Party.
The user must authenticate himself against the Identity Provider with standard username/password, a Kerberos ticket, a X.509 digital certificate (installed on OS or inside a smartcard), or a self-issued ticket (if the Identity Provider accepts it).
The Identity Provider answers back with the requested security token, which is presented to Relying Party. This one will finally provide access to its service.
In real life world things happen in the same way: a shopper (Relying Party) checks our indentity waiting a positive answer from our credit card institute (Identity Provider), which grants for us.
Now why this system should be less risky than the password based one? Isn't possible to steal InfoCards and obtain valid security tokens for Relying Party services access?
First of all: InfoCards are empty (well, a sort of). They don't contain any real user information, but the link to Identity Provider
security token service (STS). To receive a working security token for Relying Party user needs to authenticate against Identity Provider. So if you even steal the password for authenticating against an Identity Provider, you still need the whole computer storing InfoCards.
Second: InfoCard system is isolated from userland desktop environment where viruses and trojans can hide. Reaching the Service Requestor and Identity Selector system for read, copy or hijack InfoCards is highly complex.
Users also receive protection from phishing in the InfoCard environment: when a Relying Party sends its security policy its also sends a signed X.509 digital certificate (showing company logo and URL), guaranteeing its identity.
The user sends back the security token required to satisfy Reliying Party security policy, encrypting it with the Relying Party public key embedded in the X.509 certificate.
As you can understand the whole system depends on a large interaction among several service providers (in real life a shopper must accept and trust credit cards institutes) and Microsoft is aware that can't revolutionize the whole world by itself. So it's seeking a large consensus and agreements with several major companies, from credit cards institutes to worldwide certificate authorities, without forgetting security vendors, called to action for implementing InfoCard support in all their products.
To obtain requested acknoledgement this time Microsoft planned the whole infrastructure on open standards (
OASIS Web Services Security) so that every vendor can implement from itself the InfoCard part it needs.
And the acknoledgement isn't arriving in late: Verisign just
announced will join the InfoCard crusade. And many other did, even if Microsoft won't disclose names until a more mature development stage.
InfoCard support will be implemented in the actual Windows XP (SP2) and Server 2003 (SP1 and R2), in the upcoming Windows Vista (expected for 2006 holidays) client operating system,
in Internet Explorer 7.0, and in codename Longhorn Server (expected somewhere in 2007). The latter OS will provide InfoCard
complete integration with Active Directory.
Be aware: InfoCard will be supported by Microsoft on its products, not owned by Microsoft. You'll no more see Microsoft in the middle of your transaction with your services providers or your customers.
You don't even need to see Microsoft at all if you don't want to, since InfoCard can (and possibly will) be supported on any operating system, on any browser, etc.
InfoCard is more than an ambitious project and implications are more than significant.
If you find the topic interesting you can start going deeper in a lot of places:
The best place anyway is the
Identity Weblog, maintained by Kim Cameron, Microsoft Identity and Access Architect behind InfoCard.
Be sure to check
his interview on Microsoft Channel 9.
Update: InfoCard has been renamed Windows CardSpace (WCS) as unofficially announced
here.