OpenID

We started talking about OpenID last night and I thought this might be a good place to post the discussion. I do think defacing the Wikipedia page might also be good -- for a laugh. You go first. So let's see...

Hmm I don't know if that's better than: Hey Bart, as I understand it there's a plug-and-play module for Drupal that would make it nicer for users to register on your server. As you're considering no more anonymous comments... why not turn it on?

OK there are two personal perspectives sufficient to get this conversation moving. As I look at it today, there are at least four interesting questions:

0) Why OpenID? What's it prove?

1) Why not be an OpenID consumer? For better or worse there does seem to be a lot of momentum here, why not join in?

2) Why not be an OpenID service? Integrating it into an existing offering does seem to add value, why not be a provider and let my users extend their identity to other services?

3) Why not register and enjoy OpenID? I'm seeing a few services here that *only* let you play if you've registered with Verisign or another provider.

A recent Slashdot discussion seems to hashed out a lot of issues. OpenID.net seems to be canonical?

And this post is plenty long but I'll go ahead and fill in an answer to my starting-point questions:

0) Why OpenID?

A: It doesn't seem to prove very much, by design. And perhaps that's OK depending on the application. At hand we have the purpose of making it super-easy to register before posting comments on a system that requires registration. The worst-case scenerio we discussed last night, finding your identity on somebody else's blog comment thread with comments attributed to you that you didn't post (because OpenID got hacked and chaos ensued)... I think I can live with that risk. Banking, of course not. Access to my email? Hmm. I just don't know, perhaps it'd be fine if the inbox (outbox!) was never authenticated any other way to begin with.

1) Why not be an OpenID consumer?

A: Given the option of requiring private registration, or using OpenID, or using Solution X (doesn't exist?)... and given there's some issue with the existing registration process as coded (for me it's the email challenge/response that we spoke of last night)... I don't see much of a downside since I need to spend some time on this part of my app anyway and since OpenID seems viable.

2) Why not be an OpenID service?

A: This is why I bother with typing a thread at all. It does seem a neat idea -- "hey kids, register and use my service and you'll also get an OpenID identity to use elsewhere". Lots of work but perhaps interesting given the alternative (those kids must register with Verisign to use XYZ, some service that provides a nice complement to what I'm doing). I could put a lot of time and effort into this and then be very sorry -- so I won't until you and I talk more.

3) Why not register and enjoy OpenID?

A: The silly way I asked the question provides its own answer -- today I'd reluctantly register if I really wanted to use a service that does not provide/accept private registration. Otherwise I'd probably stay away. Or create individual registrations per service.

OK I'm about done. As I type this I did come up with a new idea: maybe the right answer is to use OpenID to get the user's "identity" (name and email address), then turn around and send a confirmation email. If X is a compromised server, and Y was convinced to accept X's assurance that the user purporting to be Me is in fact me... fine, but when Y sends email to me@example.com and won't let me get too far without the challenge/response... isn't everybody happy? If X is in fact trustworthy then the email is just overkill. If not, no harm done.

Whew a lot of stuff, surely you can make sense of some of it and will have lots of great thoughts on the matter.

:)