Excellent Google Code session on open authentication and more

In this excellent discussion by Joseph Smarr of Plaxo, he touches on quite a few topics around social media and (perhaps more relevant to this blog) open identification and authentication technologies.

One of the challenges that every user (and developer) faces when implementing a new site or service is the question of identify and security.  How do you uniquely identify a user?

Common ideas:

• User names - great for personalizing, bad for scale (who wants to be coolguy43424?)
• Email addresses - great for unique identifiers, and easy to remember. Bad for portability. (What if I want to use different addresses at different sites, what if I change my email, or lose access to it?). SPN currently uses email addresses, and of course has the requisite abilities to update them or reset passwords when needed
• Random alpha/numeric identifiers - Not good for anything other than someone who likes randomizing algorithms…
• RSA or other cryptographic tokens - Users get a piece of hardware (usually a keyfob or similar) and it generates a code that they input into the website when they want to login.  Great for spy movies and highly secure datacenters, no real penetration in the personal/SOHO space.

Some up and comers:

• Phone numbers  - generally cell phone numbers, and generally used for social networking or SMS enabled services. Same basic issues as using email addresses
• OpenID - Gaining a lot of popularity, allows you to associate yourself to an OpenID provider (for example get one from Yahoo.com) and then any site that supports OpenID can “handshake” to your OpenID provider and let you login without creating a new set of credentials. Currently it suffers from a bit of usability, but this is changing, and security has yet to be fully proven.  I’d like to do a follow up post on OpenID in the future to delve into a bit more detail
• Oauth - Less of an “identity” provider and more of an authentication mechanism between sites and applications to allow the exchange of data without having the user “log in”.

While SPN is not a social networking application, it is a platform that will continue to grow and provide many additional and varied services. As more users come aboard, and start to use our services in conjunction with other providers and services, we want to ensure that you are able to easily subscribe and integrate our services into your daily routine.

So I’d like to hear from you. What are your thoughts on the new wave of identity services? How would you and your users (and customers, for our partners) to authenticate to SPN in the future? Would you find it useful to automatically be able to import user and profile information from other services?