I talk a lot in this blog about InfoCards, which is a codename for visual representations of digital identities that users can see and click on, and that are associated with various attributes (ultimately claims because they may or may not be true) like name, age, address, nationality – whatever one wants.
When we first came up with the idea of InfoCards we wanted a way for users to be able to see and manipulate digital identities, just like they can see and manipulate documents and files. In the days before folder and file icons it was hard for many users to relate to virtual storage. But the use of icons turned files and directories into “things” that could be easily imagined and grasped. We wanted to do the same thing with identities.
So to give a more concrete idea of what I'm talking about here and in other pieces, when I refer to an identity selector being used to select a digital identity, or an identity being “illuminated”, I'm referring to something that might look like the following (please remember this is just a sketch for the purposes of discussion and that the use of images and trademarks and the like is just to help others follow my proposed thought exercise).
The image shows a PC screen (though it could just as well show a different device) and on it an “identity selector” has appeared. In this “artist's rendition”, a single digital identity has been “illuminated” (the one corresponding to a credit card) because the others can't be employed in the current (purchasing) context.
You may notice the Identity Selector appears on a desktop that I hope will look “grayed out”. This represents the fact that applications running on the normal desktop cannot “see” into (read “steal from”) the identity selector: deep in the operating system the two desktops are segregated so the InfoCard surface is, compared to conventional programs, secure.
Our studies show it is best to leave the user's previous context visible but grayed out when the identity selector comes to the fore so the user understands the relationship between the identity selection what she was previously doing. This way she can also develop a sense of the relative safety of the identity selection environment.
The only InfoCard representations (e.g. Cards) that appear are ones the user has created or downloaded and installed, so the contents of anyone's identity selector are hard for an attacker to predict. Further, the user can customize the card images. Together these features distinguishe any given identity selector from any other, making it difficult for an attacker to social engineer a phony identity selector.
The InfoCard representations link to “metadata” containing the URL where an identity provider is located, the types of technologies it supports, what kind of authentication it employs, and the like. So there is no tangible identity data worth stealing in the InfoCard metadata itself.
Returning to the example of the credit card identity recently used as an example, here's a high-level view of how the different pieces work together:
In this example a shopping site wants a payment identity, and supports use of InfoCards as a way of submitting it (note: the site need not relinquish other tried and true mechanisms – like good old fashioned credit cards with billing address, secret numbers, and the possibility of phraud – in order to upgrade to InfoCards).
As well, in this example the bank has previously provided the user with a banking InfoCard for use in credit transactions (this could have been downloaded from the bank using existing credentials, or a one-time password).
The shopping site has embedded a few lines of html in its check-out page that cause the Identity Selector described above to pop when people decide to do a purchase (this html will not cause problems or be visible to clients that don't use InfoCards).
If the user chooses to proceed, the identity selector authenticates the user to the bank and then employs WS-Trust to request a token. (think of it as a coupon). In this example the coupon includes a one-time credit card number – meaning that it will only work during the transaction in which it is released.
The identity selector sends the coupon on to the web site, which can validate that the transaction completes but needn't concern itself with whether the user employed a stolen card – the bank has already done the necessary authentication.
One can imagine this scenario being done in dozens of other ways. For example, one-time credit cards need not be usedz. But I leave that as an exercise for the reader's imagination.
Note that the way the identity provider works, the type of token, the kind of authentication, the content of the coupon, the branding of the card, the crypto mechanisms employed, the way identifiers are used, and many other aspects are left up to the identity providers and relying parties. In other words, the system is a platform in which other systems can play and get wide distribution.
Also, for those who just arrived at the party, the software for the relying parties and identity providers can be written in any language on any operating system on any platform using WS-Trust and associated protocols. Similarly, I am hopeful people will build identity selectors embodying the ideas described here on other platforms and devices.
[tags: InfoCards, Identity Metasystem, Payment Card, Identity Selector]
