OpenID 2.0 security

When I was at Sun, swallowed up in the JavaSoft madness (hey, we were doing the Java Electronic Commerce Framework which you just knew was going to so totally change the world, and then the Java Card spec, which, oh my, it just couldn’t fail!) the mantra was

“To ask permission is to seek denial”

This meant we did pretty much whatever we wanted, both on the team as well as on the corporate level. Anyone who remembers who were the dot in .com knows this approach was rather successful.

At least for a while.

Try finding the JECF now. It’s not there. It never really was released externally. It never went FCS. Java Card fared a bit better.

Lately I’ve been doing a lot of Web2.0 security work. For single sign-on, OpenID is quite interesting. It’s proposed as a simple authentication protocol positioned against the real protocols’ enormous luggage of committee-induced debauchery of ever-swelling specs. The authors of OpenID just wanted something that worked for the use-cases they could see. Nothing more, nothing less.

OpenID is gaining momentum. People are interested. They look at it, kick its tires, and tinker with implementations. It seems to be working. OpenID popularity is soaring.

But popularity brings people. Things change and the swelling begins. Something needs to be done, and this is a tough task.

The right balance here is difficult. OpenID needs to grow up, but it has to watch out to maintain its youthful zest and inddependence.

A few days ago I posted some security considerations. I wanted to describe the security variants we had identified and later I followed up with concrete security profiles that define modes that you can run OpenID in.

The discussions have started. It will be most interesting to see where OpenID ends up.