http://norman.walsh.name/2006/10/20/identity 9 99 2006-10-20T08:29:17-04:00 $Date: 2006-10-20 11:29:15 -0400 (Fri, 20 Oct 2006) $ Norman Walsh 2006 Norman Walsh Actually, not so much who are you in any absolute sense, but sometimes I'd like to be able to distinguish you from everyone else. Using OpenID, for example, instead of yet another user name and password. George McGovern The whole campaign was a tragic case of mistaken identity. I have no particular expertise in security or identity issues, for that you want someone like Eve Maler . I thought I'd say that right up front. Nevertheless, I build web applications and sometimes I want those applications to be able to distinguish one user from another. When I built WITW, I employed what I expect is the most common mechanism for this purpose: user names and passwords. There are two problems (three actually) with user names and passwords: convenience and security. If every web application that wants to distinguish your identity from the identity of others asks you to provide a user name and password, you have two choices: create a whole raft of user name/password pairs, inconvenient for most people, or use the same user name/password pair for more than one application. Reuse exposes you to greater risk: it means that if any one of the applications you use is compromised, other applications are potentially compromised as well. When I built the photodata.org application, I decided to try something else: OpenID. The promise of OpenID is the ability to broker your identity through a common server. That common server can authenticate your identity to any number of web applications without requiring you to reveal any user name or password information to the individual applications. From the other side of the fence, to the application, user identity becomes a verified URI instead of a verified user name. I already expect to use URIs to identify things, so that's a win too. I'm currently using Verisign's personal identity server, but there are plenty of other OpenID servers out there. You can even run your own server, if you want. I'm giving Verisign a little free advertising here to reward them for outstanding service. The OpenID login stuff involves several redirects and some session caching and is a little complicated to setup. I wanted a Ruby implementation that wasn't designed to be part of a Rails framework, so I wound up having to hack my own from one of the example scripts. I got it wrong a bunch of times before I got it right which wasn't too surprising. What was surprising was that the technical director of the PiP program noticed my failed attempts in their server logs and contacted me to help. I thought that was pretty impressive. In case you too are looking for a non-Rails implementation, feel free to start with my efforts. You can also take it for a test drive, if you'd like. So far, my experience with OpenID has been all positive. I had no trouble explaining it to several early testers of photodata.org and they had no trouble going out and getting their own identities. I can tell users apart and I don't have to manage user names and passwords (I don't have to assign them, I don't have to store them, I don't have to help people who forget them, I don't have to worry about someone stealing them, etc.). Next time you build a web application that needs a login, consider OpenID.