Computer Security Alert has done a nice frontpage feature on “What InfoCard is and isn't” in its May 2006 issue. The Alert is normally only available to members, but Robert Richardson has given me permission to let you download and reprint the PDF version, complete with sidebars – or you can read the main part of the story here:
Thereâ€™s little doubt that the Microsoft marketing engine will get itself geared up to tell the public at large what InfoCard â€œis,â€ but in the meanwhile, getting a handle on the next major security-related software introduction is remarkably difficult. Itâ€™s a slippery topic.
The place to start, however, is with the diagram below from an overview of the â€œIdentity Metaverseâ€ by Microsoftâ€™s identity guru Kim Cameron.
The box at the very bottom of the diagram is you, the subject. If you go to a Web site or an application that requires you to establish that youâ€™re authorized to use its services (where in the past youâ€™d have been challenged for a username and password), youâ€™ll instead be shown an interface where you can choose from what appear to be traditional â€œID cards.â€ Simply put, that interface is InfoCard. Thatâ€™s it.
Or, at least, thatâ€™s how to draw a line around it that differentiates it from everything else. Obviously, thereâ€™s more to it than that. For one thing, itâ€™s running in a different security context than the rest of your applications on whatever operating system you happen to be running. Itâ€™s supposed to be completely cordoned off in terms of memory access and the like. Other applications (and, say, viruses that have installed themselves unbeknownst to you) canâ€™t see memory thatâ€™s being used by the InfoCard interface.
Cameron does note that â€œif you get a rootkit, youâ€™re in trouble. But Vista makes it much less likely that youâ€™ll get one, because you almost always run in your own context (e.g. not at â€˜rootâ€™ privilege). A virus caught in your user context cannot see your InfoCard screen or memory.â€ There are other security gains as well, Cameron notes: â€œInfoCard protects against keyloggers because typing of shared secrets becomes obsolete. And social engineering attacks are mitigated because Web sites no longer control the user experience. Finally, sensitive information like a credit card number is never stored on the PC, or visible to a virus running there.â€
InfoCard presents your various credential possibilities to you in the form of â€œcards,â€ so not too surprisingly thereâ€™s also a mechanism for generating your own self-signed InfoCard and then issuing encrypted tokens when the card is used (in other words, thereâ€™s a tool for making yourself into an ID Provider, which Microsoftâ€™s documents often refer to as an IP, but which weâ€™ll call an IDP in the hopes of not creating confusion around the already overloaded â€œIPâ€ acronym)â€”this too is part of InfoCard.
Finally, thereâ€™s a strong sense that this is what Microsoft thinks every operating systemâ€™s authentication interface should look like: an isolated page where you pick from your various ID cards. This really isnâ€™t about Redmond wanting everything to look like a version of Windowsâ€”in fact InfoCard is trying to look a bit different than the rest of the Windows Vista operating system. Rather, itâ€™s supposed to look different from everything else altogether, so that you the user realize youâ€™ve entered one of those transitional moments where you may be handing over some of your personal information.
But other than these pieces, everything else in the identity management universe is something other than InfoCard. The part where the InfoCard interface talks across the network and exchanges information isnâ€™t InfoCard, but the WS-Trust standard. The server that creates a token that attests that youâ€™ve got authorization to use a certain service isnâ€™t InfoCard either, but something like a certificate authority (CA) or perhaps something a little more old-fashioned like a Kerberos server. The primary thing that InfoCard does is allow you to choose which of several identities you want to use in a given situation where youâ€™ve been challenged for ID.
The â€œcardsâ€ represent your various identities. The â€œcards,â€ itâ€™s vital to note, donâ€™t contain information about you, per se. You wonâ€™t find your name and address or your social security number stored in one of your cards. Instead, enough metadata is stored that when the appropriate moment arrives, InfoCard can communicate to the IDP to say who youâ€™re supposed to be. The IDP will confirm this by challenging you in one way or another (doesnâ€™t matter to InfoCard what that way isâ€”itâ€™s completely agnostic in this important respectâ€”but it may very well matter to the Web site that is requesting the information).
So the IDP plays an important role in this, but as we mentioned above, may in some cases actually be you, as self-provider of a card (this is the situation youâ€™ll find yourself in at a Web site that asks for a login name or e-mail address but otherwise doesnâ€™t care who you are). The other player (besides you, the user of all this splendor) is the Web site that wants to know who you are in the first place. In todayâ€™s pre-InfoCard world, this site would normally challenge you for a username and password and check up on your assertion that you are in fact you on its own steam. With InfoCard, this site becomes a Relying Party (RP) and actually gets its assurance that you are you by way of the IDP.
There are early releases of InfoCard in the hands of developers, and blog reports so far make it clear that itâ€™s pretty fragile just yetâ€”it takes just the right combination of operating system release, Explorer browser preview and InfoCard code to make the thing work. It does work if you get it all right, but would seem that there are only a handful of non-Microsoft people in the world whoâ€™ve managed to InfoCard their way into a site (such as Cameronâ€™s identityblog.com). As Cameron puts it, â€œitâ€™s new, itâ€™s evolving quickly, and it hasnâ€™t stabilized yet.â€
What happens bat game time
So with the various pieces in place, we can walk through the mechanics of an InfoCard transaction. Weâ€™ll talk here about going to a Web site, but clearly there are other use cases, such as internal applications that directly invoke the InfoCard interface to authenticate the user with an intranet application, perhaps built on a service-oriented architecture.
Arriving at the site
Iâ€™m an InfoCard-enabled user and I arrive at my bank, which has now implemented support for this interface. My arrival causes a page to be sent to my browser, as would always be the case. Indeed, the page my still contain all the usual paraphernalia for a traditional login.
Triggering the InfoCard process
Whatâ€™s also in the HTML page that is sent to my browser, however, is an HTML OBJECT tag. The browser, which also has to be up-to-date, recognizes that this object has a â€œtypeâ€ parameter that identifies it as an InfoCard request. It therefore triggers the InfoCard dynamic link library (DLL) module. The stage is set and the screen dims (Iâ€™m not kidding, it really does dimâ€”another way of differentiating this process from normal computing activities as well as a way of making the process harder to spoof).
InfoCard gears up
Among the parameters passed to the DLL from the OBJECT tag are the claims about the user that need to be proven. These might be things like the userâ€™s name, but on the other hand, the Web site may only need to know some anonymous piece of information, such as that the user is older than 21. Generally, the site should only have requested what it needs to know. The DLL compares the claim requests to the userâ€™s InfoCards to see what claims can be met by which cards, and then displays those that can meet the request (others are visible but grayed out).
The user picks a card and is challenged
This is an important moment if you think about it. The user may use any card that meets the requirements of the Web siteâ€™s request. A user might maintain different personas with different sets of proofs for different contexts. With the selection made, the DLL contacts the IDP via WS-Trust. The IDP then does whatever it needs to do to authenticate the user. Possibly it asks for a username and password; possibly a one-time password must be used or some biometric proof supplied.
A secure token is issued and reviewed
Assuming the user successfully authenticates with the IDP (not the Web site, which is the RP in this scenario, itâ€™s important to keep in mind), the IDP places the appropriate claims into an XML document and then uses the RPâ€™s public key to encrypt them. This is sent not to the RP but back to the userâ€™s InfoCard process, which displays the claims that are about to be sent so that the user can review them.
The approved claims are forwarded
If the user is comfortable with passing the information in the claims along to the Web site, they press a Submit button and the encrypted token is forwarded to the RP, which will now grant access to the user. The Web object in more detail Jumping back a step, notice that the mechanism for invoking the InfoCard interface really is pretty much as simple as it sounds. A snippet of HTML code is added to the rest of the material in the Web page, as in this example from Andy Harjantoâ€™s Infocard Weblog.Notice that this example shows a Web site that requires a SAML assertion for authentication. The RP may not get to dictate that Iâ€™ll provide my credentials or that Iâ€™ll provide a specific credential if there are several that meet the need, but it does get to dictate what kind of credential must be provided if itâ€™s to be considered sufficient. Specifically, the RP can make requests concerning:
- The issuer;
- The type of token that will be returned;
- What claims must be vouched for by the token;
- Requirements regarding the kind of proof used (symmetric, public key, etc), the size of the key used in authentication and other such details as might be required for high-security scenarios.
Itâ€™s worth underscoring that the RP only receives proofs of the specific claims it requests, not access to any kind of full profile of data about the individual. The user (or, at any rate, not the RP) gets to choose where data used for this particular userâ€™s authentications are stored. This ability to separate authenticated claims from specific identities is potentially a huge gain for Internet privacy. This would be true even in relatively small ways: one can imagine being able to post comments at a blog site anonymously, but only after proving that one had the reputation (from actions at other sites) of never posting spam. Anonymity is preserved while the social good of keeping out bad actors is upheld.
On the other hand, we shouldnâ€™t overstate how much may be gained in the real worldâ€”RPâ€™s may still very well want a full complement of information, including name, address and credit card numbers, before selling you their products. And once theyâ€™ve got the information, they may well decide to store it, even insecurely.
As an aside, Microsoft has taken the interesting step of essentially not providing any kind of normal application/programming access to InfoCards. They are stored in their own little world; there is no API to access them. The effect of this is that cards donâ€™t get deleted or modified or added without the userâ€™s direct involvement, because these steps must be taken through the InfoCard interface.
For the InfoCard interface to be invoked, of course, there has to be some software resident on the userâ€™s system. At present, it gets there by way of a purpose-built software file (a DLL file) that has to be expressly loaded along with Internet Explorer 7. These things will be part and parcel of Microsoft Vista, when itâ€™s released next year, but users who stick with XP will have to download these pieces in order to use InfoCard.
Given that migration to Vista is bound to take place at a measuredâ€”perhaps even downright reluctant, depending on the vicissitudes of the marketâ€”pace, one question is whether the requirement for additional specialized software will make Web site developers reluctant to get involved. Obviously, they can use pre-existing login routines for users who donâ€™t have InfoCard capability on their machines, but having two systems will just complicate life. Cameron says itâ€™s not all that much more complicated, however: â€œWeâ€™ve taken this into account so the changes to a Web site are absolutely minimal.â€
Organizations may or may not decide that dealing with InfoCard is worth the troubleâ€”it will have to move beyond its current proof-of-concept stage before anyone can decideâ€”but one thing organizations donâ€™t have to do, should they opt to use InfoCard, is run Windows servers. From the â€œMicrosoftâ€™s Vision for an Identity Metasystemâ€ white paper:
Non-Microsoft applications will have the same ability to use â€œInfoCardâ€ to manage their identities as Microsoft applications will. Non-Windows operating systems will be able to be full participants of the identity metasystem we are building in cooperation with the industry. Others can build an entire end-to-end implementation of the metasystem without any Microsoft software, payments to Microsoft, or usage of any Microsoft online identity service.
Just to prove that this is so, Cameron, whoâ€™s in charge of the InfoCard project, moved his identityblog.com over to non-Microsoft software (completely so: heâ€™s running the classic, open-source LAMP stack). The blog is running on WordPress (also open source) and heâ€™s written his own PHP scripts to handle the InfoCard login process. By Cameronâ€™s own admission, itâ€™s still a bit buggy and it lacks a certain degree of polish:
Some of the user experience is still pretty â€œbasicâ€. Like what happens if you click on InfoCard login and donâ€™t have InfoCards installed. When I have some time Iâ€™ll make that take you to a page that tells you what InfoCards are, how they work, how to install them, and that sort of thing. But for now, the behavior should appeal to lovers of cryptic error messages.
So at least in theory, the Linux and Macintosh systems of the world could implement compatible identity selectors, RPs and IDPs that were all compatible with InfoCard. And, really, itâ€™s only that itâ€™s Microsoft doing the developing that makes it seem like InfoCard is the driving force here. In point of fact, InfoCardâ€™s mission is to work with WS-Trust, an open standard (we could quibble about how open it is, but at least thereâ€™s nothing preventing anyone from using it). So the open standards for identity, such as WS-Trust, are really the driving force behind InfoCard. In any case, identity management seems to be entering something of a 2.0 phase, and thereâ€™s no question that InfoCard will play a significant role in whatever that turns out to be. â€” R.R.