I got a note recently from federation master Mike Beach – a man with a great deal of experience in terms of how users react to security:

Is it just me or does your site have an invalid cert.  When I attempt to
login using my new Infocard in IE7 I get the infamous “warning, go back, do
not enter, danger ahead” and things go all red (really more pink).

Given the primary drivers of Infocard are to save us from all the web evils
of today it would seem this is contrary reinforcement when I must ignore all
the security warnings to log in.

I thought, “That's weird.  I don't get that problem.”  – you know, the ancestral “That's funny.  It doesn't happen on MY box.”  But of course it really was happening to Mike, so I wrote back and asked if he could send some screenshots.  It turned out this wasn't necessary – he had already figured out the problem.

He had been visiting identityblog using this URL:  

When he clicked on Login he was redirected to  

But my certificate is limited to  Therefore IE (correctly) saw Mike's and the certificate's as being different – resulting in the redish bar.  It looked like this:


That's enough to confuse anyone.  So clearly, redirecting to something that isn't consistent with your certificate is a no-no.  I was setting up an experience that would undermine my user's understanding of what was happening to her, breaking law six.  I should have been checking and redirecting to even if the user didn't supply the “www”.  Strangely, I had done the Dashboard link correctly – it was only the Login link that had the error.

All of which goes to show there are a set of gotchas that we have to nail down in terms of establishing prescriptive guidance for how a site should deal with these issues in order to be consistent.  We need a checklist – or better still, a test plan.  A wiki would be a good way to elaborate this.

Another big takeaway is that an identity 2.0 relying party has an obligation to make sure it doesn't do things that send mixed signals (in my case, nice InfoCard experience but big red warning bar in IE).  Everyone has to co-operate with the goal of not confusing the user.

It's worth pointing out that none of this is primarily an InfoCard problem.  The same considerations apply to any use of https.  But in the InfCard case we want to make sure we have the deployment practices nailed down to a higher level than has previously been the case.

Published by

Kim Cameron

Work on identity.


  1. Mr Cameron, can you take a look at comments here and maybe provide feedback?

    I am very interested in “identity metasystem” and its implementations and I'd like to know whether this will be part of any standard anytime soon. Since Microsoft is already implementing CardSpace, it would be nice to enable other platforms with this capability (Identity providers, clients and relying parties). I know that Ping have implemented a Java based solution, but again, there are no concrete specifications available.

    BTW, how can a user without InfoCard leave a comment in your blog? The forms requires a user to login.

    Thank you,

  2. Mary Branscombe writes to say: vs if you had a wildcard certificate for it would cover both, along with and and anything else you wanted to do on the same domain and you wouldn’t have to sanitise redirects – which might be done by the server rather than the site. It’s very common for Web servers to configured to accept as a request for There are virtual farmed sites like With a wildcard certificate, those don’t throw up ‘Danger Will Robinson’ errors.. Sure, we want to be able to break identity up into bite-sized claims, but sometimes you need a wrapper on the whole chocolate bar.

    Kim Cameron replies Thanks Mary. In most cases that would the perfect answer. But without wanting to sound like too much of a skinflint, my certificate provider charges too much for an asterisk. Under the whip of Dick Hardt's admonishments I promised myself to run this site in keeping with its role as hair on the end of the long tail…

Comments are closed.