OpenID. Really interesting system. It does use the classic "There and Back Again" approach to single sign on (re-directing user to Identity Provider and then back to Service Provider). It inherits most of the problems of LID and SXIP (see my old paper). That is quite expected.
What is not expected is that the guys cannot take the lesson. They do the basic Diffie-Hellman key agreement. But they do not think much about authenticating the keys. Which is ages old mistake with D-H algorithms. They expect that the when the key comes from the right location, it must be authentic. Well, to be honest there is a way how to authenticate the key, using HTTPS. Which in turns takes us to SSL/TLS and to X.509.
Now, let's have a look. We have Diffie-Hellman that is foolishly insecure without SSL. So we are going to use SSL. Now we have pretty much secure connection between relying party and OpenID provider. So why bother with Diffie-Hellman? Why we just cannot exchange shared secret directly?
I do not understand the inconsistencies in OpenID design. But regardless of that, it seems to work and gain acceptance. And it is so foolish simple thing, that it may become popular after all. King of the Fools. Such things just happens ... sometimes (read: all the time).
I'm not going to dig into trust issues of OpenID and HTTPS/X.509 today. Maybe later ...