OpenID is a really useful protocol that allows users to login and authenticate — and I’m all for providing users with services based on it — but I’ve ultimately decided that it’s a bad idea when Registration is involved.
The reason is simple: in 99% of implementations, OpenID merely creates a consumer of your services; it does not create a true user of your system — it does not create a customer.
Allowing for OpenID registrations only gives you a user that is authenticated to another service. That’s it. You don’t have an authenticated contact method – like an email address, phone number, screen name, inbox, etc; you don’t have a channel to contact that customer for business goals like customer retention / marketing, or legal issues like security alerts or DMCA notices.
The other 1% of implementations are a tricky issue. OpenID 1.0 has something called “Simple Registration Extensions”, some of this has been bundled into 2.0 along with “Attribute Exchange”. These protocols allow for the transfer of profile data, such as an Email Address, from one party to another — so the fundamental technology is there.
What does not exist is a concept of verifiability or trust. There is no way to ensure that the email address or other contact method provided to you is valid — the only thing that OpenID proves, is that the user is authoritatively bound to their identity URL.
The only solution to this problem is for websites to limit what systems can act as trusted OpenID providers — meaning that my website may trust an OpenID registration or data from a large provider like MySpace or Facebook, but not from a self-hosted blog install.
While this seems neat on some levels, it quickly reduces OpenID to merely be a mechanism for interacting with established social sites — or, perhaps better stated, a more Open Standards way of implementing “Facebook Connect” across multiple providers. A quick audit of sites providing users with OpenID logins limited to trusted partners showed them overwhelmingly offering logins only though OpenID board members. In itself, this isn’t necessarily bad. My company FindMeOn has been offering similar registration bootstrapping services based on a proprietary stack mixed with OpenId for several years; this criticism is partially just a retelling of how others had criticized our products — that it builds as much user-loyalty into the Identity Providing Party as it does into the Identity Requesting Party. In layman’s terms – that means that offering these services strengthens the loyalty of the consumer to company you authenticate to as much as it offers you a chance to convert that user. In some situations this is okay – but as these larger companies continue to grow and compete with the startups and publishers that build off their platforms, questions are spawned as to whether this is really a good idea.
This also means that if you’re looking at OpenID as a registration method with some sort of customer contact method ensured, you’re inherently limited to a subset of major trusted providers OR going out and signing contracts with additional companies to ensure that they can provide you with verified information. In either situation, OpenID becomes more about being a Standards Based way of doing authentication than it is about being a Distributed Architecture.
But consider this — if you’re creating some sort of system that is leveraging into the large-scale social network to provide identity information, OpenID may be too limiting. You may get to work with more networks by using the OpenID standard, but your interaction will be minimal; If you were to use the network integration APIs , you could support fewer networks, however you’d be able to have a richer — and more viral — experience.
Ultimately, using OpenID for registration is a business decision that everyone needs to make for their own company — and that decision will vary dependent upon a variety of factors.
My advice is to remember these key points:
– If the user interaction you need is simply commenting or ‘responding’ to something, binding to an authoritative URL may suffice
– If the user interaction you need requires creating a customer, you absolutely need a contact method : whether it’s an email, a verified phone number, an ability to send a message to the user on a network, etc
– If you need a contact method, OpenID is no longer a Distributed or Decentralized framework — it is just a standards based way of exchanging data, and you need to rely on B2B contracts or published public policies of large-scale providers to determine trust.
– Because of limited trust, Network Specific APIs may be a better option for registration and account linking than OpenID — they can provide for a richer and more viral experience.