Everybody is talking about OpenID. Big players are adopting it. But should you trust it for things that matter – financial transactions, for example?

Here’s an important post from Microsoft’s identity architect Kim Cameron:

So let’s think about this.  Where is the root of trust?  In conventional systems like PKI or SAML or Kerberos, the root of trust is the identity provider.  I trust the identity provider to say something about the subject.  How do I know I’m hearing from the legitimate identity provider?  I have some kind of cryptographic key.  The relevant key distribution has a cost – such as that involved in obtaining or issuing public key certificates, or registering with a Key Distribution Center.

But in OpenID, the root of trust is the OpenID URL itself.  What you see is what you get.  In the example above, I trust Francis’ web page since it represents his thinking and is under his control.  His web page delegates to his OpenID identity provider (OP) through the link mechanism in (5).  Because of that, I trust his identity provider to speak on behalf of his web page.  How do I know I am looking at his web page or talking to his identity provider?  By calling them up on DNS.

I’m delving into the details here because I think this is what gives OpenID its legs.  It is as strong, and as weak, as DNS.  In other words, it is great for transactions that won’t attract criminal attack, and terrible for those that will.

And here’s Cameron’s conclusion:

OpenID cannot replace crypto-based approaches in which there are trusted authorities rather than trusted web pages.  But it can add a whole new dimension, and bring the “long tail” of web sites into the identity fabric.

Note that Cameron is not opposed to OpenID. Apart from anything else, he recognizes that this may well be the beginning of an identity revolution – part of a process, at the end of which we get a safer, less spam laden, less criminal-infested internet.

At the same time, he’s right. The whole OpenID structure hinges on the URL routing to the correct machine on the Internet. In other words, DNS. Now do some research on DNS poisoning. Scary.

Now, it strikes me that you can largely fix this by requiring SSL connections. In other words, have the OpenID URL be an https:// URL, and have the relying party (the website where you want to log in) check for a valid SSL certificate. Note thought that SSL must be used at every stage. OpenID lets you use your own URL as the identifier, but redirect to another OpenID identity provider. Both URLs must use SSL to maintain integrity.

Another idea is to use an OpenID for non-critical logins, however you define those.

Note that this issue is different from the phishing risk, for which CardSpace strikes me as a good solution.