GUIDANCE AND TEST PLAN FOR RELYING PARTIES

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:  https://www.identityblog.com/.  

When he clicked on Login he was redirected to https://identityblog.com/wp-login.php.  

But my certificate is limited to https://www.identityblog.com/.  Therefore IE (correctly) saw Mike's identityblog.com and the certificate's www.identityblog.com 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 www.identityblog.com 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.