CardSpace support for Firefox

CardSpace, is Microsoft’s identity management system, a way of reducing the hassle of having as many identities (username/password credentials) as services we use and isalready listed as a requirement for Firefox 3.

Kevin Miller who has released Identity Selector, a Firefox extension that adds CardSpace support, tells us what his extension does and what identity management in general is about and what can users expect from this and other alternatives currently in development. For the record, Kevin notes he doesn’t work for Microsoft.


Mozilla Links: What exactly CardSpace is and how it works?
CardSpace is the method of implementing what Kim Cameron calls an Identity Metasystem. I would describe an Identity Metasystem as a protocol definition, or a pattern for secure identification on the internet trying to solve three problems:

  1. Phishing attacks
  2. Lack of trusted identity
  3. Proliferation of personal information

I don’t think we need to discuss phishing attacks. By now everyone should be familiar with them.

The second point, lack of trusted identity, is a bit more difficult. Web sites seeking to authenticate users have very few good options. They may require credit card numbers, which are verifiable. However, most users are reluctant to give their credit card numbers to just any site on the net. They may require a digital certificate, but these are difficult for the average user to maintain and verify.

For consistency with the documentation, I will refer to web sites as Relying Parties (RPs). I will refer to the users as users, although the Microsoft documentation calls them subjects. Please keep in mind that the users could be individuals, companies, or other computer systems. The RP need not be a web site. It could be a Windows client, a web service, or nearly anything.

The third point, proliferation of personal information, is a side-effect of the second point
first two items, and also contributes to identity theft. Because the RPs require users to register, they typically ask for a large amount of personal information, whether they need it or not. They may be selling this information, or they may be using it for marketing purposes. Or, they may just be collecting it because everyone else is and they think they might need it in the future. The problem for the users comes either from the sale of this information, or in the compromise of the servers (or laptops) on which this information is stored.

Now, the Identity Metasystem goes the distance on resolving all these issues.

  • Users now have easy-to-manage cards (InfoCards), instead of difficult to manage certificates.
  • The RP can ask for information relevant to the security level of the site.
  • For simple web sites, they may allow a self-generated card. This might be typical for many news sites where the company only asks users to register. Instead of typing the information into a form on the website, the user can self-generate a card and use it at multiple sites.
  • If the RP requires real authentication, they may accept cards from a number of valid Security Token Servers. These are third parties that host cards for users. The third parties must be trusted by both the user and the RP. This is similar to the concept of escrow. The user and the RP do not need to trust each other as long as they trust the third party.
  • The RP publishes the claims required for access.
  • The user decides what information to deliver. If the RP is asking for too much, the user can decline.
  • The user doesn’t have to fill out endless web forms.
  • The RP can customize the InfoCard request.
  • The user can customize the InfoCard response.
  • The RP can choose any available server implementation.
  • The user and site can agree on any Security Token Server.
  • The user can choose any Identity Selector.

All of these components can be provided or consumed in any language, browser,
or operating system, as long as they support the necessary components of the
Identity Metasystem.

This system directly answers points two and three, above, and indirectly reduces phishing attacks. It is also hoped that the trend will be for users to hand out less information, and the RP to ask for less. For example, consider two companies sharing information.

  • Company A has an information library that Company B wants access to.
  • Company B is willing to pay for the information, but doesn’t want to have to administer a list of user accounts. They also don’t really want to tell Company A the names of the employees accessing the data.
  • If Company A and Company B can agree on a common Security Token Server, Company B can simply provide valid InfoCards that indicate the user is an employee of Company B. The user can have access to Company A’s library without divulging any other information.

This is a bit of a contrived example. A real-world example may be a bar. The bar must make sure that you are of legal age to get in. The mechanism that most use now are driver’s licenses. In addition to your age, the license contains medical conditions, name, address, and description. Add to this the fact that some bars are now photographing licenses and storing the data. This means that now you are at risk of identity theft just to enjoy a night on the town. In an InfoCard world, you could simply provide an InfoCard validated by the government STS, and the bar would know that you are of legal age. No further information given or at risk.

Mozilla Links: How does CardSpace compares to OpenID, an open source identity management proposal?

There is only the most superficial comparison with OpenID. They both use third party sites to validate users. CardSpace, however, is all about authorizing and authenticating the user. OpenID provides only a unique ID (based on a URI). It does allow the third party to provide a variety of information, but does not provide the user an easy way
to preview the information prior to each transaction. OpenID also relies on the honour of the implementers. There are no checks and balances to recover from a rogue provider.

CardSpace is designed to give both sides of a transaction (one or both of which may behave poorly given a chance) a way to verify the information requested and provided. Now, CardSpace won’t force an eBay seller to put your iPod in the mail, but at least you could get validation that you are dealing with a specific user.

Mozilla Links: What does your extension, Identity Selector, do?

My extension really does only a couple of things.

  • It parses the parameters representing the required and optional claims, and other key parameters.
  • It invokes CardSpace (or an alternative, such as Chuck Mortimer’s Identity Selector)
  • It passes the parameters from the web page back to CardSpace.

There’s a fair amount of validation, and some interfaces to allow developers to provide alternative implementations, but those three functions are the key pieces of the extension.

Mozilla Links: Why does Firefox need an extension to support CardSpace?

An extension is required in order to get the appropriate information from the browser and invoke CardSpace. Without the extension, Firefox has no mechanism to invoke CardSpace. We could theoretically generate some SAML code based on a web interface and hand that back to the relying party, but it would provide little benefit, at a large cost of effort.

CardSpace is hardened against attacks, provides a simple mechanism for choosing cards, and allows the user to verify the relying party. CardSpace also provides all the “plumbing” for handling and reading certificates, basic encryption, and writing SAML.

Mozilla Links: How much support does CardSpace have currently?

I’m not sure how many pages support this at the moment. The three I’m familiar with are the xmldap.org site, Kim Cameron’s sample page, and the official CardSpace sandbox (which, unfortunately, only supports IE 7. I’ve talked to some folks about sorting that out).

Essentially, xmldap.org allows you to create a managed card (or select a previously used one from the site), and then use that card to log in. If you’ve logged in correctly, you get a page that displays the SAML code sent, and displays the claims in the InfoCard. It doesn’t look very flashy, but trust me, the code underlying all this is very cool, and exciting to us security types.

Thanks to Kevin. If you want to learn more visit CardSpace web site.

2 Comments

Comments are closed.