I just finished implementing BrowserID in an application that I am building. It is quick and easy to use. Perhaps 20 minutes to get it to work. I used OpenID before. OpenID is annoying and difficult. I spent 3 full days working on it.
I'm really excited about BrowserID. I think for the end user it makes more sense than OpenId which was doomed from the start because it was too difficult to understand what it was.
If only people owned their email addresses then this would be a truly decentralized (eventually) and portable identity system. I do think emails are the best global handle for users that we have currently - we should treat it as such.
I actually talked to Lloyd Hilaiel from Mozilla who worked on BrowserID and it's currently in alpha and they hope to move it to beta in a couple months. At that point they'd be committing to keeping it around.
The web needs this to be widely adopted. They've got some unique challenges to make it easy to integrate and easy to understand but I think they're on the right track.
OpenID kinda scares me, security wise. There's too many ways for developers to screw it up. Witness the ones who used Facebook names as unique user identifiers.
At least with email, provided by the email host, the string you get from them will be unique.
I do like their last point that the system is designed to be integrated directly into the browser. That avoids the issue of OpenID requiring that a popup be displayed to the user from their OpenID provider, which was a significant usability problem.
Having the browser handle the authentication makes for a much more seamless experience.
You can authenticate any way you want, so that's not a problem.
If NAT and firewalls weren't such PITA, browser could even act as an OpenID provider for itself (e.g. Opera Unite makes it possible).
The problem with OpenID is lack of discovery. AFAIK there is no way to advertise that website supports OpenID login and where it should be submitted, so browsers are unable to have integrated UI for it.
Since it isn't specified as part of the spec, browsers would potentially have a different implementation for each OpenID provider, so yeah, that's a problem.
Client<>Provider authentication method is not visible in the in OpenID protocol between Provider<>Consumer. Can you elaborate where the problem lies?
Why would different auth methods in browsers cause problems, when different provider's methods don't?
AFAIK client auth method is invisible and irrelevant, especially in the case where client and provider are the same thing (the browser).
In fact, in-browser OpenID (where browser is the provider) could skip client authentication completely and just say "yes" to every consumer (because browser knows and trusts its own identity).
I never understand why we keep drafting all sorts of identity mechanisms instead of using public key. It's easy to understand, very secure, and battle-field tested.
BrowserID is based on public key cryptography. It just provides a mechanism to (a) attach public keys to an identity (in this case an email address) and (b) enable easy, widespread adoption by websites and browsers.
Public-key crypto may be easy to understand and secure, but until now it's not had good browser integration, it's been hard for websites to manage, and there's been no adoption.
(For example, if you write your own public-key auth mechanism for a website, you need to program all the backup mechanisms in case the user loses their key due to browser failure, needs to recover their account because of a security problem, or whatever. BrowserID outsources that to email providers or secondary authorities.)
I hope and pray a single sign-on system that doesn't depend on a specific third party catches on. Any system, OpenID, BrowserID, I don't care. It's about time we do away with the insecure and complicated system of one password per site.
One use case I still am hesitant about for email-as-username is the situation where a family shares an email address for a household. I know that ISPs like Comcast still just provide a main email address when they set up the account, and I expect many people don't bother to make more for the rest of the family.
With all the free email options available I doubt this would be a serious problem. I also know some sites are requiring unique email addresses in their DB now. I simply wonder how many users still do this and if it would negatively impact them.
A lot of experienced users out there tends to provide each service a different email address (username+servicename@example.org, servicename@bar.example.org, etc.)
Speaking of such (which is a valid concern) I always use a nice feature from gmail which gives the ability to append +anything to your username. Mail will be forwarded to your inbox as usual where you can apply filtering to know whom as leaked your email. Hence you can use username+foobar@gmail.com while registering for foobar webapp.
This assumes that foobar webapp accepts + as a valid email local part character which is not always the case unfortunately (and against RFC) but that is another story.
Simple solution: give everyone address with "+suffix", and mark as junk any mail without it.
For stubborn services who don't accept "+" in email addresses use unique redirect aliases.
(Also, IIRC, Gmail ignores dots, i.e. "j.random.user@gmail.com" and "j.r.a.n.d.o.m.u.s.e.r@gmail.com" is the same address. Chose a canonical one with a dot somewhere, and filter the rest with exception for legimate senders.)
You can hide the + portion of a Gmail address behind redirects and forwards, if you feel so inclined. It's a lot of work, but it does let you use the "deliveredto" operator in Gmail to automatically sort and discard spam like that.
