Security Briefs
A First Look at InfoCard
Keith Brown
Contents
What is Identity?
The Spirit of InfoCard
InfoCard: An Identity Metasystem
Establishing Digital Identity with InfoCard
Message Flow
The Laws Revisited
Sharing My Reputation
Self-Issued Cards
Get Started Today
The Web can be annoying at times. I'm certain that I'm not alone in my frustration with filling out the same old forms on every Web site I visit. Like most other techies, I've acquired many tools over the years to help combat this repetition, and I even wrote my own password manager for my hundreds of different identities on the Web. To me this constant repetition is simply an annoyance, but to someone like my mom, it can be very confusing, and often confusion can lead to security vulnerabilities, such as using the same password everywhere.
Not only is this forced fragmentation of identity on the Web annoying, it's also really limiting the Web's potential. In this column, I'll introduce you to a system that I truly hope will be a uniting force for identity on the Web. It's called InfoCard, and it's planned to be available with Windows Vista™.
I am going to talk about InfoCard purely in the domain of Web services, because that's the only place you can use the prerelease bits as I write this column (see Microsoft Federated Identity and Access Resource Kit for Sept 2005 Community Technology Preview). But in the future it will also work with browser-centric Web apps. I've used Thawte and eBay as concrete examples because they're familiar. These examples are entirely fictitious—whether or not Thawte or eBay decides to implement InfoCard is entirely up to them.
What is Identity?
What is identity, anyway? The technical implications of this question are vast (never mind the philosophical implications). How should people be identified on the Web? How should entities such as services, companies, organizations, and the like be identified?
Take me, for example. My name is Keith Brown. I live in a suburb of Denver, and you can contact me via my Web site. I like rock music, vert skating, and Go. And I'm willing to share many of these details with Web sites that I trust, if I feel there's some benefit. These are all things that I can say about myself. But other people have things to say about me as well.
On eBay, I have a stellar reputation as a buyer and a seller. On Slashdot, my posts have been ranked "insightful," and I'm an upstanding member of a number of other communities. These reputations have value, but today they are stuck in silos. When I join a new community, there's no way to prove to people that I'll be an honest, intelligent, easygoing member. I have to start from scratch at every site, because there's no common way to share my eBay or Slashdot identity (with all the reputation I've worked hard to build). Sure, I can say, "I'm Keith over on eBay," but who is going to believe me?
I've made a bunch of statements about who I am. Do you believe them? Are they assertions of fact or merely claims? That really depends on who is making the statements and how much you trust that person or organization. For example, if you wanted to trade with me on eBay, you could easily discover that eBay says I have an excellent record for paying quickly. If you regularly trade on eBay, you probably have a reasonable degree of trust in their feedback system, so this is a claim you'll accept.
One approach that InfoCard takes is that it doesn't make any assumptions about the veracity of statements made about a given identity. It's up to you to decide whether you believe the claims I've made about myself, or the claims eBay makes about me. Thus the use of the word, "claim" as opposed to something stronger, like "assertion."
In fact, this leads directly to a definition of identity from the InfoCard perspective: A digital identity is a set of claims made by one digital subject about itself or another digital subject. This definition was proposed by Kim Cameron on his identity blog (www.identityblog.com). Kim is an architect at Microsoft working on InfoCard, and he's made many important contributions to the current thinking on identity.
Oh, and one more thing, in case you think you know where I'm going. The problem of having hundreds of identities today is not solved by merging them into a single identity that's used everywhere. That would introduce more problems than it solves. InfoCard allows you to have as many identities as you need. Looking into the future, you might have one identity that's issued by your government, one that's issued by your bank, and one issued by a Web community of which you're a long-standing member with a good reputation. You will likely have several self-issued identities, a few of which contain false information! I don't know about you, but I usually lie when a Web site asks me for personal information that I don't want them to have. I really don't live at 1313 Mockingbird Lane, Anytown, USA. But it satisfies the Web site and reduces my risk. InfoCard won't change your ability to do this.
The Spirit of InfoCard
Kim Cameron has postulated that there must be a set of objective laws that govern whether any given identity system will succeed or fail in a given context. No matter how an organization positions an identity system, if it breaks these laws, it will very likely fail in some way. Perhaps the failure will be a breach of security, allowing such mischief as identity theft. Or maybe people will simply reject the system because they don't feel comfortable with it. Regardless of the reasons, the InfoCard architects don't think they will succeed without adhering closely to these laws.
Seven Laws of Successful Identity Systems
The following laws are shaping the design and implementation of InfoCard. The architects of InfoCard simply don't believe that a system that ignores any of these laws could survive.
1. User Control and Consent The user should be in control of her information. She must be able to decide which bits of information to reveal to another party.
2. Minimal Disclosure No system that asks you for personal information is 100 percent secure, so the more you disclose, the more you expose yourself to identity theft and other attacks. 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. Let's say the context is you checking out a book at your local library. You shouldn't have to present your Social Security number, when the library can simply issue you its own unique identifier.
3. Justifiable Parties When applying for social services, it makes sense for me to present a government-issued ID card. But when I gamble online, I'm going to use a different identity. All parties involved must have a justifiable reason for being a part of the transaction. While it might make sense to use a Microsoft Passport when downloading MSDN® subscription content, I'd rather not use it for my PayPal account.
4. Directed Identity I value my privacy. I don't broadcast it for everyone to see. However, there are many public entities that need to be easily discoverable and therefore prefer to act like beacons. Amazon.com is a beacon. It broadcasts its identity to the world via its SSL certificate. But when I shop at amazon.com, I expect them to use a private identifier to track my activity at their site. Stable identity systems must support both omnidirectional identity (beacons like amazon.com) and unidirectional identity (my private relationship with amazon.com).
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. In order to succeed, the system must make it possible for many identity providers and technologies to work together seamlessly. No single identity system will rule them all, but there can be a system of systems (a metasystem) that presents a unified abstraction to users.
6. Human Integration The end user must be considered the endpoint of the authentication protocol. As an industry, we've done a fantastic job securing messages that travel over copper wires for thousands of miles. It's the last couple of feet between the computer console and the human where most bad things happen. Phishing and other social engineering attacks exploit the vulnerable user interfaces in use today. A stable identity system mitigates these threats to the greatest possible extent.
7. Consistent Experience A stable identity system presents an easy-to-understand abstraction to the user that is consistent no matter what underlying technology or identity provider is involved. The user must be able to select the most appropriate identity for a given context, and it should feel real. Digital identity shouldn't be an abstract thing to the user. It should feel as concrete as a library card in your pocket.
So to get a feel for the environment in which InfoCard has been incubating, let me take you on a brief tour of the seven laws. I have abbreviated them in my own words in the sidebar "Seven Laws of Successful Identity Systems," but you can take a look at the complete text at The Laws of Identity.
InfoCard: An Identity Metasystem
InfoCard encompasses a lot of different tasks. It orchestrates a few of the WS-* protocols to make the secure interchange of identity information feasible. It also presents a GUI that allows a user to choose among several digital identities, each of which is represented visually as a card. Figure 1 shows a very early "wire frame" UI. I'll talk a bit more about some of the other things it does later on, but first let me introduce the three players that are always involved in any InfoCard transaction.
Figure 1** Digital Identity Made Concrete for Users **
First is the subject. An example of a subject is a user who wants to represent herself digitally on the Internet. Second is the identity provider (IP), an organization that issues digital identities. A close analogy is a company like Thawte, the issuer of the secure sockets layer (SSL) certificate that I use to identify my company's Web site. Finally, there's the relying party (RP), which relies on digital identity for its operation. Most Web sites and Web services today allow users to submit some form of identity, anything from a simple e-mail address to a digital certificate or something more exotic.
In accordance with the fifth law of successful identity systems, InfoCard is a metasystem that establishes a few guidelines and protocols to make it possible for many different identity systems to play nicely together. Lots of people have been thinking about digital identity for quite some time, and lots of different techniques have emerged. LID, SXIP, Liberty Alliance, and Microsoft® Passport are just a few examples.
Establishing Digital Identity with InfoCard
At this point I'm going to introduce a concrete example that I can build on throughout the column. Imagine that Thawte has decided to become an identity provider for InfoCard. I visit the Web site at Thawte and use a Web Form over HTTPS to set up a digital identity that they will manage for me. I might provide an e-mail address, home phone number, snail mail address, and so on. In fact, I might even set up a few different identities that I could use in different contexts.
Depending on the type of identity I want to establish and the amount of money I'm willing to pay for their service, Thawte may authenticate me before issuing an identity. Authentication could be as simple as verifying my e-mail address, or as sophisticated as calling around to verify every detail of my identity.
For each of these identities, Thawte will send me an InfoCard, an XML document that acts as a reference to the particular digital identity I just established. How they send it to me isn't dictated by InfoCard; they could e-mail it or I could download it from their Web site. Once I receive the InfoCard, I import it onto any computers from which I want to use it. Note that the InfoCard itself doesn't actually contain any of my identity details. That phone number I gave to Thawte isn't in the InfoCard.
What the InfoCard does carry is metadata that describes the shape of the identity. This information includes what claims it has inside it, such as an e-mail address, a home phone, and so forth, and what identity technology it uses such as Security Assertion Markup Language 1.1 (SAML). It also includes who issued it (Thawte), and a unique identifier that Thawte can use to look up my identity and get the values of each of the claims. So while my actual digital identities are safely tucked away on a highly secure server at Thawte, the InfoCards I've imported onto my computer are really just a way to remember that I have those identities. An InfoCard gives you the means to use and manage a digital identity.
My corporate Web site uses Active Directory® Federation Services (ADFS) to act as an identity provider. I can sign up for another identity there. The Web site authenticates me using Kerberos and issues an InfoCard that I can use to access my corporate identity for use with partners on the Internet. I import this card onto my computer. Once I've got some cards, I can use them as long as they are valid. The Thawte identity might be valid for a year (or however long I want to pay to maintain it), and my corporate identity is valid as long as I'm employed there.
Message Flow
In order to get a feel for how an InfoCard transaction works, I'm going to walk through an example to show the flow of messages between the players. For now, I'm going to ignore an awful lot of details such as how messages are secured, which protocols are used, and so on, to make sure the basic flow is clear.
Imagine that eBay has a Web service that supports InfoCard (the relying party). I launch my eBay auction manager application, a rich client app that helps me manage the multitude of items I'm auctioning on any given day. My app knows that it needs to present a digital identity to eBay in order to manage my auction items, but it has no idea which identity I want to use. So it first asks eBay what shape of credential it supports, what identity providers it trusts, and what types of claims it needs. eBay responds:
Credential type: SAML 1.1 or 2.0 Identity Providers: Entrust, Thawte, Verisign Requested Claims: email address
My app then takes this information from eBay and hands it off to the InfoCard system on my laptop. Up pops up a dialog that displays a list of cards that could satisfy eBay's needs. This includes all identities I've registered with Thawte that include e-mail addresses. It does not include my work identity because eBay didn't list my company as an identity provider that it trusts. In this dialog, eBay's logo is prominently displayed. Along with other countermeasures, this helps me verify that I'm not sending personal information to an imposter. Figure 1 should give you an idea of what this looks like. I click on the card that I use to sell items on eBay, and the InfoCard system makes a request to Thawte to get the one claim that eBay cares about: the e-mail address. Thawte returns a SAML token with this information.
InfoCard now pops up a view that shows me exactly what information I'm about to disclose to eBay, which is the e-mail address in the SAML token. I consent by pressing Submit, which allows InfoCard to pass the token to my application so it can fire it off to eBay and get started managing my auction items.
A lot happened here, but from my perspective as a user, I found that the interaction was straightforward. When my application connected to eBay, I was prompted to choose an identity to present, asked to confirm the personal information I was about to disclose, and then I was able to immediately start working with my auction items. And I didn't have to bother with a password. Under the covers, the strong crypto specified by InfoCard was at work ensuring the authenticity of the transaction.
The Laws Revisited
Consider this interaction in light of the laws of identity. The first law was satisfied: as the user, I was asked for consent, and shown exactly the information to be disclosed. I was also shown the logo of the relying party, so I could make an informed decision.
The second law was also satisfied. My home phone number and snail mail address were not sent to eBay, even though they were part of my digital identity maintained at Thawte. Only the information needed for that particular interaction was sent: the e-mail address. And really even that wasn't necessary; InfoCard is happy to craft a unique, opaque identifier that a relying party can use to identify you without having to know any personal information about you at all. This is called a Personal Private Identifier (PPID), and is computed as a function of the relying party's public key, the InfoCard id, and a random salt value. As a relying party, you can request a PPID if you want to track requests for someone without tying your tracking data to their personal information. This is a great way to protect the privacy of your users.
What about the third law? When I use a Web service at work, I use my corporate-issued identity. But I don't trust the sysadmins with my eBay identity. So I choose to use Thawte to manage my external identities. They have a lot more to lose if they misuse my identity and get caught doing it! There is a little circle of trust that comes together here: me, Thawte, and eBay. All parties to the transaction are justified in being there.
The fourth law also came into play. Anyone who uses InfoCard to talk to eBay sees eBay's logo. That's an omnidirectional identity, a beacon. But my relationship with eBay is private. The InfoCard system on my laptop isn't broadcasting my e-mail address via Bluetooth. Even if it wanted to reveal my e-mail address, it doesn't store that information, remember?
Because I was able to choose my own identity provider and identity technology, the fifth law was satisfied. Granted, the identity provider and relying party must support at least one technology in common for this to work, but InfoCard in no way limited which type of credential (SAML or otherwise) I used. The fifth law is really all about freedom of choice, and I'm happy to say that InfoCard buys into it.
The sixth law talks about securing the channel between the user interface and the user's brain. By using certificates with logotypes (RFC 3709), InfoCard avoids confusing the user by forcing them to look at certificates, and instead uses images that the user can recognize to identify the entities involved. There are other countermeasures that happen behind the scenes as well. For example, the entire InfoCard UI is actually hosted on a separate, more tightly secured desktop (similar to the one that WinLogon uses when you press Ctrl+Alt+Delete). Note that it's up to the identity provider to ensure that a bad guy doesn't register a certificate with a logo that looks like another company's logo. But that's exactly the sort of service that an identity provider supplies, and companies that participate will pay for that service.
Finally, the seventh law is satisfied by presenting the user with something that appears concrete: the cards themselves. And no matter what type of credential is used with the card, the user experience is the same. The user is shown a text representation of every claim that's going to be sent to the relying party, no matter what type of token or what type of claim it is. How can this be possible? InfoCard can't possibly predict all the types of credential formats that might spring up in the future. To solve this problem, the identity provider can include an optional "display token" that accompanies the real token. The display token contains a simple name-value collection that can be used to display the contents of the token to the user in text, even if InfoCard can't parse the actual token itself.
Sharing My Reputation
I hinted earlier that it would be really neat to have the choice of sharing my reputation from one community to another. If I could prove that I have a great reputation on eBay and Slashdot, I could use that as currency for other communities that I might want to join so I wouldn't have to start from scratch. And I might want to be known by the same handle at a few different online communities, so my friends know who I am in all those places. It would be up to me to make these linkages, but having that flexibility would be incredibly powerful.
This can happen under InfoCard. Say eBay decided to become not only a relying party, but an identity provider as well. In this case, I could get an InfoCard from eBay stating that I'm a reliable buyer and seller with 99.8 percent positive feedback. That's simply a claim that eBay is making about me, but remember the definition of identity: a digital identity is a set of claims made by one digital subject about itself or another digital subject.
Web communities that care about reputation might support eBay and Slashdot as trusted identity providers for these types of claims. I could now sign up for an account at one of these communities using my Thawte card, and then immediately bump up my reputation with my eBay card. I can show as many cards as I want to a community.
The downside to this is that the relying party can now correlate any identity information I give it, but it's ultimately my choice. If I trust the community and want to share more information with it, I can choose to do so. And a well-designed relying party will ask for the smallest possible amount of identifying information. I'd feel perfectly comfortable disclosing a PPID for my Thawte identity along with my eBay reputation. Even someone malicious couldn't do much with that!
Self-Issued Cards
A lot of the infrastructure I alluded to in my examples simply doesn't exist today. There aren't many identity providers out there that support InfoCard. The current version of ADFS doesn't yet support it either. So the InfoCard team has supplied a built-in provider that allows you to issue your own InfoCards to yourself to bootstrap things. In fact, the example cards shown in Figure 1 are actually self-issued cards.
To understand how this works, consider a traditional Web site that allows you to register with a user name and password. If that Web site accepted self-issued InfoCards, you could use a self-issued InfoCard to register. There would be no password; just select a card when prompted, and the Web site would record your PPID and make a note of the long-term key sent in the token. That key would replace the traditional password, and would be unique for every site you visit. Under the covers this key would be computed as a function of a master key, which would be generated randomly for each self-issued InfoCard, and the public key of the relying party. It would be as if you'd chosen a unique password for each Web site you visit, without actually going through the hassle of managing all those passwords yourself.
Self-issued cards are a great way to get started with InfoCard. If you have a Web service and want to make it a relying party, you can get a quick start by simply testing with self-issued cards. But in the long term, using a third-party identity provider will be much more powerful, because it enables user-constrained sharing of personal information between different systems on the Web.
Get Started Today
InfoCard is right around the corner, and it has incredible potential. On the social Web, it will pave the way for all kinds of new innovations by individuals and companies. For corporations, InfoCard will make it much simpler to connect with partners online. But InfoCard will only succeed if there are innovative people like you who are willing to take the time to build interesting relying parties and identity providers.
Subscribe to Andy Harjanto's blog (blogs.msdn.com/andyhar) if you're interested in experimenting with InfoCard today. Andy, a member of the InfoCard team, has provided links to specs and downloads (blogs.msdn.com/495649.aspx), as well as code samples for building relying parties and identity providers using Windows® Communication Foundation (WCF).
I hope this has whetted your appetite for InfoCard. In my next column, I'll open the hood and show you what makes InfoCard tick. Stay tuned!
Send your questions and comments for Keith to briefs@microsoft.com.
Keith Brown is a cofounder of Pluralsight, a 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, which is available both in print and on the Web.