Mike (one of those who need no sleep) blogged about Fun Communication's openid idtheft site and I encourage you to read Mike's post and try your personal idtheft immediately.
Back here?! Well, you knew all this already, didn't you?
But seeing it in action is another thing, I guess.
So where does this lead us? Remember the "openid dogfight" from September 2007? I too think that we need a spectrum of solutions. I agree that openid is for when an RP has "trivial" security requirements, but I think that trivial is not easy to define. At first your openid might be good enough for trivial things but its value grows with time. The more you use your openid the more valuable it becomes and then the risk you take by using the openid protocol becomes too great to accept. So let us all improve openid through e.g. PAPE. But why? To end up with another secure and inconvenient system? Thanks, no.
- back channels are bad (privacy, user consent). (SAML artefact)
- browser redirect protocols are bad (phishing). (openid protocol, SAML HTTP redirect binding)
Are CardSpace, Higgins' id selector, DigitalMe and openinfocard the solution? Not yet.
I think that the most important things that the Microsoft's vision of the Identity Metasystem until now has brought us are:
- thinking in claims instead of thinking of "login"
- identified the need for a unified user experience when PII is involved
- a client component to achieve the former two
Paul writes that his sxipper prevented the phish. This is a client component like CardSpace and the other id selectors.
We could integrate openid into the id selector and call it "identity agent" or whatever makes this idea stick. But then... Why use openid at all? This is so close to the origin of the security axis that we would need logarithmic scaling to make it visible.
Let us build this identity agent. Let us integrate openid and passwords into the client, but only as a migration path to a convenient and secure alternative.
Down with browser forms for claims/attributes. The browser is your friend.