{"id":435,"date":"2006-04-21T18:54:45","date_gmt":"2006-04-22T02:54:45","guid":{"rendered":"\/?p=435"},"modified":"2006-04-21T18:57:22","modified_gmt":"2006-04-22T02:57:22","slug":"what-infocard-is-and-isnt","status":"publish","type":"post","link":"https:\/\/www.identityblog.com\/?p=435","title":{"rendered":"WHAT INFOCARD IS AND ISN'T"},"content":{"rendered":"

Computer Security Alert<\/a> has done a nice frontpage feature on “What InfoCard is and isn't<\/strong>” 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<\/a>, complete with sidebars – or you can read the main part of the story here: <\/p>\n

There\u00e2\u20ac\u2122s little doubt that the Microsoft marketing engine will get itself geared up to tell the public at large what InfoCard \u00e2\u20ac\u0153is,\u00e2\u20ac\u009d but in the meanwhile, getting a handle on the next major security-related software introduction is remarkably difficult. It\u00e2\u20ac\u2122s a slippery topic.<\/p>\n

The place to start, however, is with the diagram below from an overview of the \u00e2\u20ac\u0153Identity Metaverse\u00e2\u20ac\u009d by Microsoft\u00e2\u20ac\u2122s identity guru Kim Cameron.<\/p>\n

<\/p>\n

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\u00e2\u20ac\u2122re authorized to use its services (where in the past you\u00e2\u20ac\u2122d have been challenged for a username and password), you\u00e2\u20ac\u2122ll instead be shown an interface where you can choose from what appear to be traditional \u00e2\u20ac\u0153ID cards.\u00e2\u20ac\u009d Simply put, that interface is InfoCard. That\u00e2\u20ac\u2122s it.<\/p>\n

Or, at least, that\u00e2\u20ac\u2122s how to draw a line around it that differentiates it from everything else. Obviously, there\u00e2\u20ac\u2122s more to it than that. For one thing, it\u00e2\u20ac\u2122s running in a different security context than the rest of your applications on whatever operating system you happen to be running. It\u00e2\u20ac\u2122s 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\u00e2\u20ac\u2122t see memory that\u00e2\u20ac\u2122s being used by the InfoCard interface.<\/p>\n

Cameron does note that \u00e2\u20ac\u0153if you get a rootkit, you\u00e2\u20ac\u2122re in trouble. But Vista makes it much less likely that you\u00e2\u20ac\u2122ll get one, because you almost always run in your own context (e.g. not at \u00e2\u20ac\u02dcroot\u00e2\u20ac\u2122 privilege). A virus caught in your user context cannot see your InfoCard screen or memory.\u00e2\u20ac\u009d There are other security gains as well, Cameron notes: \u00e2\u20ac\u0153InfoCard 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.\u00e2\u20ac\u009d<\/p>\n

InfoCard presents your various credential possibilities to you in the form of \u00e2\u20ac\u0153cards,\u00e2\u20ac\u009d so not too surprisingly there\u00e2\u20ac\u2122s also a mechanism for generating your own self-signed InfoCard and then issuing encrypted tokens when the card is used (in other words, there\u00e2\u20ac\u2122s a tool for making yourself into an ID Provider, which Microsoft\u00e2\u20ac\u2122s documents often refer to as an IP, but which we\u00e2\u20ac\u2122ll call an IDP in the hopes of not creating confusion around the already overloaded \u00e2\u20ac\u0153IP\u00e2\u20ac\u009d acronym)\u00e2\u20ac\u201dthis too is part of InfoCard.<\/p>\n

Finally, there\u00e2\u20ac\u2122s a strong sense that this is what Microsoft thinks every operating system\u00e2\u20ac\u2122s authentication interface should look like: an isolated page where you pick from your various ID cards. This really isn\u00e2\u20ac\u2122t about Redmond wanting everything to look like a version of Windows\u00e2\u20ac\u201din fact InfoCard is trying to look a bit different than the rest of the Windows Vista operating system. Rather, it\u00e2\u20ac\u2122s supposed to look different from everything else altogether, so that you the user realize you\u00e2\u20ac\u2122ve entered one of those transitional moments where you may be handing over some of your personal information.<\/p>\n

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\u00e2\u20ac\u2122t InfoCard, but the WS-Trust standard. The server that creates a token that attests that you\u00e2\u20ac\u2122ve got authorization to use a certain service isn\u00e2\u20ac\u2122t 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\u00e2\u20ac\u2122ve been challenged for ID.<\/p>\n

The \u00e2\u20ac\u0153cards\u00e2\u20ac\u009d represent your various identities. The \u00e2\u20ac\u0153cards,\u00e2\u20ac\u009d it\u00e2\u20ac\u2122s vital to note, don\u00e2\u20ac\u2122t contain information about you, per se. You won\u00e2\u20ac\u2122t 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\u00e2\u20ac\u2122re supposed to be. The IDP will confirm this by challenging you in one way or another (doesn\u00e2\u20ac\u2122t matter to InfoCard what that way is\u00e2\u20ac\u201dit\u00e2\u20ac\u2122s completely agnostic in this important respect\u00e2\u20ac\u201dbut it may very well matter to the Web site that is requesting the information).<\/p>\n

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\u00e2\u20ac\u2122ll find yourself in at a Web site that asks for a login name or e-mail address but otherwise doesn\u00e2\u20ac\u2122t 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\u00e2\u20ac\u2122s 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.<\/p>\n

There are early releases of InfoCard in the hands of developers, and blog reports so far make it clear that it\u00e2\u20ac\u2122s pretty fragile just yet\u00e2\u20ac\u201dit 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\u00e2\u20ac\u2122ve managed to InfoCard their way into a site (such as Cameron\u00e2\u20ac\u2122s identityblog.com). As Cameron puts it, \u00e2\u20ac\u0153it\u00e2\u20ac\u2122s new, it\u00e2\u20ac\u2122s evolving quickly, and it hasn\u00e2\u20ac\u2122t stabilized yet.\u00e2\u20ac\u009d<\/p>\n

What happens bat game time<\/strong><\/p>\n

So with the various pieces in place, we can walk through the mechanics of an InfoCard transaction. We\u00e2\u20ac\u2122ll 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.<\/p>\n

Arriving at the site<\/em><\/p>\n

I\u00e2\u20ac\u2122m 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.<\/p>\n

Triggering the InfoCard process<\/em><\/p>\n

What\u00e2\u20ac\u2122s 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 \u00e2\u20ac\u0153type\u00e2\u20ac\u009d 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\u00e2\u20ac\u2122m not kidding, it really does dim\u00e2\u20ac\u201danother way of differentiating this process from normal computing activities as well as a way of making the process harder to spoof).<\/p>\n

InfoCard gears up<\/em><\/p>\n

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\u00e2\u20ac\u2122s 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\u00e2\u20ac\u2122s 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).<\/p>\n

The user picks a card and is challenged<\/em><\/p>\n

This is an important moment if you think about it. The user may use any card that meets the requirements of the Web site\u00e2\u20ac\u2122s 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.<\/p>\n

A secure token is issued and reviewed<\/em><\/p>\n

Assuming the user successfully authenticates with the IDP (not the Web site, which is the RP in this scenario, it\u00e2\u20ac\u2122s important to keep in mind), the IDP places the appropriate claims into an XML document and then uses the RP\u00e2\u20ac\u2122s public key to encrypt them. This is sent not to the RP but back to the user\u00e2\u20ac\u2122s InfoCard process, which displays the claims that are about to be sent so that the user can review them.<\/p>\n

The approved claims are forwarded<\/em><\/p>\n

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<\/strong> 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<\/a> from Andy Harjanto\u00e2\u20ac\u2122s Infocard Weblog.<\/p>\n\n\nNotice that this example shows a Web site that requires a SAML assertion for authentication. The RP may not get to dictate that I\u00e2\u20ac\u2122ll provide my credentials or that I\u00e2\u20ac\u2122ll 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\u00e2\u20ac\u2122s to be considered sufficient. Specifically, the RP can make requests concerning:  <\/p>\n