Anyone interested in identity on the web should read Tim Bray’s Federation Conversation. I disagree with many of the opinions expressed there but it is a great way to see what identity experts and interested parties think about the future of single sign-on and Internet authentication; it’s blogging in the best sense.
Here’s my own opinion on identity.
“Federation” usually implies multiple participants working together as equals. “Log in with Facebook/Google/Twitter/etc.” is not federation because it is one-sided. You can’t use Facebook to log in to Twitter, or Twitter to log in to Facebook. Anyone smaller than that is completely left out.
This gives the impression that the big players are in it for their own self-interest. Therefore, ordinary folks don’t trust them (see the comments on Tim’s blog). I agree with Tim that trust is the central issue.
Consequently, “Log in with Facebook/Google/Twitter/etc.” will never take off in a big way; the only universal solution is username/password.
Users can’t securely maintain usernames and passwords themselves, they need to outsource it in some way.
Email is the failsafe (reset your password by email). This has well-known problems but some kind of failsafe is necessary and I don’t see anything displacing this.
Therefore email addresses are identities/usernames.
Therefore any identity solution will be closely tied to email.
A central problem with today’s web services is that they see your password. This is what makes you vulnerable—you can’t use the same password for two services and a security breach at a service can leak your password.
We can resolve most of these password related issues with something like SRP. This needs to be baked into a standard, either HTTP or HTML/JavaScript, and the client side of the protocol will be implemented in the browser.
Users don’t want to trust any one service with all of their Internet activity. They want separate identities for work, home, and other roles.
Summary
My recommended solution is a browser-based identity manager closely tied to an email service. The email service needs to provide multiple emails to each user, on demand, for their various identity roles, and the browser needs to help separate these roles (e.g., via cookie management). Authentication is by email and SRP. Password reset is by email, suitably modified for SRP.
Mozilla’s Persona fails because it lacks the email service component and (ironically) does not help users keep their roles separate.
Ultimately the blocker is an appropriate standardization of SRP for HTTP or HTML/JavaScript.