Windows Cardspace: An early attempt at identity management

Dominik Schiener
composui
Published in
4 min readAug 29, 2016

One of the most renown attempts to create an identity management system was Windows Cardspace. An excerpt from its whitepaper “the identity metasystem is an interoperable architecture for digital identity that assumes people will have several digital identities based on multiple underlying technologies, implementations, and providers. It lets users select from among a portfolio of their digital identities and use them at Internet services of their choice”. The goal of Cardspace was it to be the go-to solution for people to manage their digital identities. Through an agnostic protocol, that allowed for a secure communication through other technologies (such as LDAP, X.509, SAML and Kerberos), the identity owner could easily access the service provider with a predefined identity and thus be in control of what information gets shared.

The project was lead by some brilliant people, including Kim Cameron who has done some amazing work in the digital identity space and I encourage you all to check out his Laws of Identity. But it ultimately failed and is supposedly currently being replaced by UProve, a technology built by Stevan Brands who had influence in the development of DigiCash and Zero Knowledge Systems. The reason why Cardspace failed (apart from the neglect it received from Microsoft itself) ultimately comes down to mistrust and the different interests. Cardspace was adopted by a fair number of people that used it actively in the realm of Microsoft’s ecosystem (MSN, Hotmail etc.), but in the WWW outside of Microsoft it was rarely used. This is due to low adoption from service providers who didn’t see the clear benefits offered to them and perhaps even mistrusted the protocol and Microsoft itself. Additionally, Microsoft perceived Cardspace as a project to strengthen its product sales through a unique identification system that is part of its huge ecosystem. This made it apparent that Microsoft did not care so much for bettering the online experience of every user, but only for those who paid Microsoft for software and other products.

Lets describe some of the interesting details of it, since any future attempt at creating an identity metasystem can learn a lot from Windows Cardspace.

The Components

The metasystem is made up of five key components which we will describe briefly here:

Claims-based identities

Similarly to how JSON Web Tokens (JWT) are setup, the digital identities consist of various “claims” about your identity. You for example claim to be 2 meter tall, with no one to certify for that, it is hard to trust that claim. Which is why certified claims play an important role, where a third party asserts that a specific claim is valid.

Negotation

One of the most interesting parts of Windows Cardspace is its ability to negotiate between participants in the ecosystem and determine the right protocol to choose from in order to enable the participants to connect with each other. This is a huge step forward to creating an interoperable and agnostic identity layer that can be easily adopted by all service providers. As described in the white paper “if one party understands SAML and X.509 claims, and another understands Kerberos and X.509 claims, the parties negotiate and decide to use X.509 claims with one another.”

Encapsulating Protocol

Since the goal of Windows Cardspace is it to be completely technology-neutral (agnostic) and create an environment where service providers and identity holders can easily communicate with each other, the protocol needs to be able to exchange information and claims about identities between the parties without any interferences. This goes back to the negotiation process between technologies.

Claims Transformers

A very important part of the protocol is its ability to create new contextual meaning from identity claims. For example, your claim to be born on 01.01.1990 can be transformed into a credential OVER_18. This plays a huge role in protecting privacy since the service provider will no longer be supplied the identity claims, but a specific credential which was generated through your identity claims. This way a service provider will be supplied with the information that is relevant to it (that you are over 18 for example) and they do not have to worry about more personal details anymore (that you are born on 01.01.1990).

Consistent User Experience

By no longer leaving the identity provision to the service provider, but to the user himself, the protocol is able to offer a consistent user experience across all service providers. This means you no longer have to enter the same information on different service providers, but can use a predefined identity across all service providers, making identity much more convenient. Additionally, through such a system phishing attempts, privacy intrusion and general identity theft can be combatted.

InfoCards: Control for the user

Probably the most useful feature of CardSpace was InfoCards. An InfoCard is bascially an identity, therefore a collection of claims about that identity. These InfoCard’s could be easily chosen or switched during online communication with a service provider. Therefore, during an authentication request (e.g. signup to Microsoft.com), you were able to choose which InfoCard you wanted to use and represent yourself with on Microsoft.com.

This was a huge step forward in bringing control over ones identity back to the user. The user could decide which identity to authorize a service provider with. Below is a visualization of the signup process:

Conclusion

We’ve seen some of the innovation coming from Microsoft in regards to identity and how Cardspace could have been a truly amazing solution for identity. Sadly, the project failed but a successor will most certainly reign where Cardspace left off.

References

1:https://en.wikipedia.org/wiki/Windows_CardSpace
2:https://msdn.microsoft.com/en-us/library/ms996456.aspx
3:http://www.credentica.com/
4:http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html#RegisteredClaimName

--

--