Identity & Access Management

The InfoCard Identity Revolution

Keith Brown

At a Glance:

• What is InfoCard?
• Important laws of identity
• The future of identity on the Web

Are you tired of managing and securing an ever-growing port­folio of usernames and passwords? Are you tired of filling out endless user profiles for Web sites that want to glean some personal

information from you? Would you like to make it easier for users to log onto your Web sites and services? Are you worried about identity theft and phishing? If so, stay tuned. I’ll introduce you to a new identity layer for the Internet, which will be exposed to end users through a GUI currently code-named "InfoCard."

An Identity Metasystem

InfoCard helps you manage and share personal information, and whenever you start talking about systems like this, privacy concerns surface. No single identity technology or identity provider will make everyone comfortable in every situation. Passport works really well when I want to connect to Hotmail® or MSDN®, but I don’t necessarily want to use it for non-Microsoft properties like my online banking system.

Back in November 2004, Kim Cameron, identity and access architect at Microsoft, began a discussion on his blog about what he dubbed the laws of identity. Kim’s goal was to have the identity community at large agree on a set of laws that would describe a stable identity system—one that people would feel confident using for all of their digital identity needs. This fascinating public discussion among identity industry luminaries, most of whom were not associated with Microsoft, resulted in seven laws of identity. (Both the sidebar here and Joshua Trupin’s article in this issue provide more on these essential laws.)

The Seven Laws of Identity

1. User Control and Consent The user should be in control of her information and be able to decide which information to reveal.
2. Minimal Disclosure Stable identity systems don’t disclose more information than necessary in a given context, and they use identifiers that are designed specifically for the context.
3. Justifiable Parties All parties involved must have a justifiable reason for being a part of the transaction.
4. Directed Identity Many public entities need to behave like beacons, broadcasting their identities to the world. However, I expect them to use a private identifier to track my personal activity, so stable identity systems must support both omnidirectional identity (beacons) and unidirectional identity (my private relationship).
5. Pluralism of Operators and Technologies No single identity system is going to suffice in all contexts, and no single identity provider is going to be justifiable in all contexts.
6. Human Integration Any successful digital identity solution must empower its human users to consistently make understandable and correct choices on their own behalf. The last couple of feet between the computer console and the human is where most bad things happen. Phishing and other social engineering attacks exploit the user. A stable identity system mitigates these threats.
7. Consistent Experience A stable identity system presents an easy-to-understand abstraction to the end user that is consistent no matter what underlying technology or identity provider is involved.

You can read the full text of these laws at: Kim Cameron's Identity Weblog.

Interestingly, the fifth law makes it clear that no one identity system can suffice in all contexts. Instead, an identity metasystem is needed that makes it easy for you to choose the identity providers and technologies you want, and not feel locked into one vendor’s solution.

To be of any use, participants in the metasystem need to agree on a basic encapsulating protocol. Remember how the Internet blossomed when the industry converged on TCP/IP as the standard communication protocol? We’ll see the same explosion of innovation when the industry agrees on an identity protocol. Kim calls this the Identity Big Bang, and it’s exciting to think about.

This identity proposal is centered around the WS-* suite of protocols, the core of which are WS-Security and WS-Trust. This makes sense because these protocols allow any type of security credential to be used; you can represent any type of data in XML.

Digital Identity and Claims

In the identity metasystem, identity is represented as a signed set of claims. A claim is something someone says about you, or something you say about yourself. Just like in real life, you’ll judge the veracity of a claim based on who made that claim, or in the case of the metasystem, based on who signed the claim.

Do self-signed claims make any sense? Sure! In fact, I’d be willing to bet that the vast majority of the identities you use on the Internet are purely self-asserted. When you sign up for an account at a Web store, no third party checks up on you to ensure you enter the correct phone number in your user profile. It’s you who enters your name and e-mail address when you create your user profile, not a third party.

When you access a resource on your corporate network, however, you’ll probably need to supply credentials that a third party can verify, for example, a Kerberos ticket from your domain controller. Kerberos tickets include a section called a Privilege Attribute Certificate (PAC). Inside the PAC is a list of Security Identifiers (SIDs) that describe your user account and the domain groups of which you are a member. The PAC is signed with the domain controller’s key, so that any server that receives your Kerberos ticket can verify the signature of the domain controller and therefore develop trust in the claims (in the form of SIDs) in the PAC.

In the identity metasystem, there will be many parties that rely on claims about your identity. Some, like resources on your corporate network, will require a trusted third party to provide claims about your identity. Others, like the Web store I mentioned earlier, will simply take your word for it. In the metasystem, you’ll see trust relationships pop up all over the place, between the subject (you), the relying party (the resource), and the identity provider. Figure 1 shows these players in the identity metasystem.

Figure 1** Identity Relationships **

I would imagine that many ISPs, which effectively already provide millions of identities, as well as others who currently work in the identity space will eventually become identity providers in the metasystem, and some of the more widely known will be trusted by many different companies. That’s a valuable service, because it allows you to have a single identity that you can use all over the Internet. As long as both you and the relying party agree on an identity provider, there shouldn’t be any friction: the third law (justifiable parties) has been satisfied! Each relying party exposes a policy listing the identity providers that it trusts and the security token technologies that it implements. This is part of the negotiation between players that occurs in the metasystem, and it’s required in order to satisfy the fifth law (pluralism of operators and technologies).

The Identity Selector

The last two laws relate to human integration. The metasystem needs to be presented to users as a concrete concept. This is where the InfoCard identity selector comes in—it’s the Microsoft user interface to the metasystem. Each identity is represented graphically as a card, just like the plastic cards you carry with you every day. And no matter what underlying technology is used to represent the signed set of claims, be it Kerberos, the Security Assertion Markup Language (SAML), X.509, or something else, the cards themselves work the same way. The image on the card will likely reflect the issuer and the type of data the card represents, but the cards will feel the same to the user. This is important to satisfy the consistent experience requirement of the seventh law.

The user interface is called the identity selector, and it’s implemented on a separate, highly secure desktop just like the WinLogon desktop you see when you log into Windows. When you visit a Web site or use a Web service that acts as a relying party in the metasystem, the identity selector will pop up, lighting up a selection of cards appropriate for the current context. When you select a card, you can see a text representation of each claim that is going to be sent to the relying party, and you can cancel the transaction if you’d rather not disclose the information requested. Imagine if a bulletin board asked for your passport number, for example. You’d be wise to decline that request. Putting the user at the center is what InfoCard is all about, and this also helps to satisfy the first law.

InfoCard aligns with the sixth law (human integration) by involving the user in the process in ways that help him make good choices on his own behalf, with no special training required. For example, the first time you use a Web site or service that acts as a relying party, you’ll be shown a dialog with a graphical depiction of the target’s certificate and information about whether the certificate appears to represent a legitimate business.

This is made possible by a feature called logotypes (described in RFC 3709). Certificates with logotypes have URLs inside them that point to images on the Web. These images represent recognizable branding for the subject and issuer, which allows the user to evaluate a certificate visually. Each image URL comes along with a hash of the image, which InfoCard checks to ensure the image hasn’t been tampered with since the certificate was issued. The point of this exercise is to get you more involved in the authentication protocol. (How often do you check the target’s certificate before sending personal information?) You must make a choice when shown this dialog: trust or don’t trust. If you decide to trust the target, you’ll be asked to choose a card, and you won’t be asked this trust question again for the site unless you do something that indicates a decline in trust, such as deciding not to select a card when prompted.

What’s In a Card?

In the metasystem, identity is represented by signed sets of claims, which are carried around in little XML buckets known as security tokens. WS-Security makes it possible to transport many different types of tokens this way, from binary tokens like Kerberos tickets to SAML tokens.

You need a security token in order to transmit claims to a relying party, but a card doesn’t have these claims inside it. The card is simply a data structure on the user’s client machine that tells it how to contact the identity provider to get a token if one is needed. The card also describes the shape of the token you’ll get: SAML, Kerberos, X.509, or something else entirely, along with the claims that the user agreed that identity provider can release to the relying party.

This metadata coupled with the policy exposed by relying parties makes it possible for the identity selector to light up cards that make sense in a given context. For example, when checking out at a Web store, the identity selector will light up your credit card (see Figure 2). And if you think about it, given that the protocol contacts the bank each time it needs a token, the bank could easily issue a one-time credit card number for that transaction. That sort of transparency is key in order for InfoCard and the identity metasystem to work.

Figure 2** The Identity Selector in Action **

When you select a card with identity data you want to send to a relying party, the identity selector will make a secured request to the identity provider, asking for the set of claims that the relying party needs. The identity provider may choose to authenticate you before issuing the token, asking for an InfoCard, a password, a smart card, or some other form of credentials to help ensure that an imposter isn’t sitting behind your console.

Once the identity provider issues the token, you get a second chance to look at the card, and now you can see the exact claim values that are going to be sent to the relying party (see Figure 3), and decide whether or not you still want to proceed with the transaction. If you decline to send the token, the local identity selector notes this choice (which could represent a decline in trust) and will pop up the trust dialog the next time you visit the site.

Figure 3** Verify What You Share **

How Many Cards Will I Need?

If I think about my own personal habits, I know I’m going to need at least three cards. My anonymous card, a self-issued card with a whole raft of generic and utterly false personal information, will be used at Web sites I don’t trust. If they ask for personal information that they don’t really need, they’re going to get generic data, like an address of 1234 Main Street, Anytown, USA. My second card will be issued by a widely recognized identity provider such as VeriSign. I’ll use that with sites that I do trust. And my third card will be self-issued, with truthful personal information. I’ll use it at trusted sites that only accept self-issued identities.

While these three cards will suffice for the vast majority of relying parties, I know I’ll need a number of more specialized cards. I’ll have bank-issued cards that represent my credit lines. I hope to have a set of reputation cards issued by companies like eBay, where I have a stellar reputation as a buyer and seller (100 percent positive feedback). Although reputation claims are only just being talked about, imagine the power for bootstrapping your reputation in a new Internet community.

Self-Issued Cards

Microsoft is actively working to get many different industries involved in the metasystem. From major e-commerce sites to existing identity providers like VeriSign, to financial institutions that provide credit cards and online banking services, there is a lot of excitement around InfoCard. But adoption won’t happen all at once; companies will have to ramp up to support it. In the meantime, there is a self-issued provider that ships with the identity selector. It runs in a separate, highly privileged process and acts as any identity provider would, except that it’s local. And because the claims for self-issued cards will be stored in an encrypted form on your hard disk, it’s limited to only publicly available information such as your phone number, snail and e-mail addresses, and so on. You won’t be able to store credit card numbers on your hard disk using this provider.

Because the self-issuing provider stores this data on your hard disk, it’s not very mobile. Sure, you can export the data behind a self-issued card and import it onto another machine, but in the long term, there are plans to have a portable version of this provider that could run, say, on a USB device you carry with you, or on your cell phone. Your computer could connect to this device via Bluetooth to request tokens. This is an important issue for users who want to roam with their identities.

Getting InfoCard?

The identity selector ships with WinFX®, so as soon as you install the WinFX runtime components you’ll see a new applet called Digital Identities in your Control Panel. Running this applet opens the identity selector and allows you to create new self-issued cards and manage your identities.

WinFX is expected to ship with Windows Vista™ sometime around the end of 2006. What if you’re still running Windows® XP? No problem. WinFX also runs on Windows XP, as does the identity selector. You’d be better off running on Windows Vista because of the other security features it offers, not the least of which is the user account control feature that helps you run with least privilege. Developers can use Windows Communication Foundation to implement relying parties and identity providers. If you want to take a look at InfoCard from a developer’s perspective, see my articles on the subject in the April and May 2006 issues of MSDN Magazine.

Keith Brown is a cofounder of Pluralsight, a premier Microsoft .NET training provider. Keith is the author of Pluralsight’s Applied .NET Security course, as well as several books, including The .NET Developer’s Guide to Windows Security, available in print and on the Web. Learn more at www.pluralsight.com/keith.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.