April 2006


InfoCard takes great pains to change the way that people interact with identity information so that they learn good security practice. That is a tall order in a world where users have been trained for years to click OK. Site does not match the certificate? OK. Site only works if you download something? OK. Site would like you to post your credentials over an unsecured transport? OK. Whoops, this site is guilty of that one at the moment. Feel free to mock.

While InfoCards cannot fix all potential security issues when people surf the internet, it does have the opportunity to fix some of them. Clearly Kim Cameron and his team have thought long and hard about the link in the security chain that is always the weakest: us. To save us from ourselves InfoCard first requires a secure transport in order to protect our information in transit. Second it darkens the screen around the applet, putting the user on notice that something security related is happening and to pay attention. Third it provides a single interface with which the user shall become accustomed and more likely to notice when it does not look quite the same. Fourth it represents the available identity information as groupings of claims in infocards which appear in the same order, have user entered descriptive text, and may be customized with a graphic. When put together it would appear that this is an almost impenetrable combination that would defy even the most talented spoofer.

However, the fine art of phishing, along with spamming, is one of the most pertinent examples of the benefits of scale. Both phishing and spamming are profitable because the effort of scaling is similar to the effort required for one attempted attack. One attack which has a high chance of failure is unfortunate but not a serious problem. Scale that to thousands or millions of attacks and the high chance of failure can be discounted because the small percentage of successes is all that is required to make the attack worth while.

With that in mind lets take a look at how we might play the numbers with InfoCards. I shall assume a compromised web browser process or some other method of executing unauthorized code. That might seem like a harsh test, but really it is simply a realistic one. Even when the user is running with limited privileges, as they should be, rarely do those privileges lack the ability to execute a process!

Secure transport

The only way the average user knows a secure transport is in use is by the application that they use making a claim that it is. A compromised process simply lies. Few, if any, users will break out the network sniffer and check.

Darkened screen

The same methods that allow games and screen savers to take control over the entire screen are available to a spoofing process. The interesting thing about this is that even the spoofer will be required to provide the cue to the user that they should be paying attention.

Familiar interface

A familiar interface is also familiar to the spoofer. By the same principal that the darkened screen spoofable, so are the mechanics of, and look and feel of the applet itself.

Customized data representation

This really should be the coup de grĂ¢ce. Having achieved spoofing all other aspects of the interface the spoofing process is now required to spoof the customized infocards. The problem for the spoofer is that there is no way to get at any information that would allow them to do so. No way at least if this were a single attack on a single target. As we already know, scaling reaps the rewards of the small probability. All the spoofer has to do is come up with a reasonable set of cards and play the numbers. Currently I see a flaw in the customization scheme that makes this easier to do: for the cards to have this property of customization the user must have previously taken action to do so. In their default state all infocards look the same. Guess what the spoofers will spoof - a non-customized self asserted card with a likely name (My info?).

Here’s my suggestion: make the default customization non-default. On creation of each infocard select at random a graphic from a sufficiently large available set and use that in the absence of direct user customization. This will substantially reduce the effectiveness of any attack based on playing the numbers for infocard spoofing.

You might ask what a spoofer could do once the user has been convinced that they are interacting with the InfoCard - after all, no data has been compromised at that point. Well, I will leave that to the spoofers, but it is not hard to conceive of ways to convince the user to give up information voluntarily. Simply by playing on the trust in a particular site that the interaction has engendered or through the spoofed interface itself the user could be duped. After all, users fall for less sophisticated attacks all the time. While we’re here, we might as well plug that hole.

Johannes Ernst says “If user-centricity is really what we are after, it follows that I am my own identity provider in many circumstances, doesn’t it?” I think the answer to that is, to begin with. Digital identity for the internet is a bootstrap problem. Not much can be demanded or expected to begin with, and third party asserted claims are definitely a lot to ask right now.

However given a generally accepted system of identity claims assertion for the internet, I would expect that over time many of those claims would be expected to be backed up by a third party. For sure, some things will never require that: my favourite movie and other such trivia. But a lot of claims are generally self asserted now because they have to be, like my nationality, my employer, my professional affiliations, people I know, and many others may well naturally become third party claims about me, and expected to be.

User-centric identity does not imply user asserted identity, that is merely the initial expected state in order to garner adoption. Nothing more. I fully expect there to be higher level of trust in the identity claims asserted in the future, not merely the status quo.

I have been pretty busy recently, which is why Kim Cameron managed to sneak by a tutorial and demo of InfoCard that also revealed the WordPress relying party PHP code for the LAMP stack. It includes a short demo video which walks through how InfoCard works when logging in to a site that is useful to review before actually reading the tutorial. Excellent!

Now if I might be so bold Kim, could we have the code released under an open source license?

A while back I got a Linkedin invitation to link up with someone who I didn’t know who claimed to be from Google. At the same time the same person sent me inmail about opportunities in Google. Sure enough, the person’s (who shall remain nameless) Linkedin page showed that they did indeed claim that they currently work for Google. Smashing. Just one little niggle - they used a hotmail email address… Far be it from me to doubt the trustworthiness of this person, after all, I am sure they are quite honest and just slipped while choosing their email account provider for work related activities. Yes, that must be it.

I wonder how many people imbue some level of elevated trust in the self asserted claims of Linkedin pages? It would be cool to have a trust mechanism for the web, where claims on static pages can be verified in a decentralized, scalable manner. To be able to be assured of the accuracy of claims right on the web page that is making them without having to interact with some trusted third party. As far as I am aware, nothing currently in use achieves this.

In user-centric identity most of the thinking has been about user presentation of identity data in an interactive fashion, but this isn’t the whole story. Sometimes one would like to make a claim that is persistent and non-interactive that out lives our brief time on line. For example, our friend at Google could have their claim of employment by Google signed by Google, thereby validating the claim if you trust Google not to lie about who it employs. Perhaps that is sufficient for some applications.

It seems to me that this ought to be possible in an internet scale fashion using current technology. It is just a matter of everyone agreeing on which technology pieces are to be used and stitching them together. Given that services like Linkedin are becoming more important to how business is conducted, I expect to see something like this happen in the not too distant future. I bet it ends up being a SAML profile too.

The Identity Gang lit up this morning when someone asked, in the event of the generic, cross platform, ubiquitous identity meta-system “what does that little button on the website say?” As was pointed out this is really a marketing question that is ideally suited to not being solved by perfection minded techies. That said, this does mirror a conversation I had with Johannes Ernst a while back when I pointed out the need for a generic term that isn’t a Microsoftism. The meta-system needs a brand.

So when we do get to identity nirvanna what are we going to call it? How will grandma know of what we speak?

Answers on a post card please.