OpenID and incentives

I mentioned OpenID in the previous post, leading me to wonder "Hey, whatever happened to OpenID?"

Well, it's still there, but perhaps not in the form its creators had in mind.

In OpenID, there are three main roles

• You
• The site you actually want to use (the relying party)
• The site that you'll log in to to convince the relying party that you're you (the provider)

I don't know about you, but my intuition was that it would be easier and more popular to be a relying party than a provider. That's more or less the situation with, say, SSL certificates. If you're a certifying authority (CA), you're vouching for each certificate that you sign and you have to pay great attention to keeping your keys safe and other such matters. If you're just using a certificate (like when you log in to your bank or some other site using https), all you have to do is decide what CAs to trust, and in practice your browser makes that decision and does all the checking behind the scenes.

In OpenID, if you're a provider all you really need to do is accept requests for your users to log in -- which you have to do anyway -- and tell whoever asked you to do that, "yep, that's them." Unless being an OpenID provider is your main gig, you really don't have to take any more care than you otherwise would. If no one trusts you, it's not the end of the world (but see below).

If you're a relying party, you have to decide whether to trust the provider. In particular, you have to trust that the provider will check identities at least as carefully as you would. If the provider is a bank (not that that seems likely) or is trying to make money solely off of providing OpenID, that's a pretty good bet. Otherwise, your milage may vary.

...

After working through that, I realized that there's a much simpler reason that -- unlike the certificate case -- parties tend to prefer providing to relying: If you rely on me, then your users will have to log in to my site, maybe see some of my advertising, be reminded that they use my service, and so on -- in order to use yours*. Sure, their account with you is still an account, but their account with me becomes the "real" account that the others are just sort of attached to. Which role would you rather play?

I like this analysis better. Providers do have an incentive to provide good service to relying parties, but unless users really care, no one has much incentive to be a relying party. Now that browsers are good at remembering passwords, having a single sign-on is less of an issue and people probably don't care so much. With a modern browser, you could give each account its own password if you like (and that's the more secure option) without having to keep all of them in your head.

* Providers can allow "checkid_immediate", where you don't have to log in to the provider, but that's not a popular option. Not only would providers likely prefer that users go through their login as often as possible, relying parties would probably prefer to know that the user actually logged in somewhere before letting them in.