This seems much more one sided -- it's good for the user that doesn't use FB or Twitter but 'meh' for the website. I'm not sure we'll see fast adoption like we have for OAuth.
We also let you reach many, many more people, since you're not forcing users into joining an anointed social network. Everyone has an email address, and people understand what it means to reveal it.
Also, there's no lock-in, because we're not giving you an opaque, one-way identifier for your users. Instead, you always get a verified email address. Want to switch away from Persona? Add a 'password' column to your database and send a few emails.
Edit: I should also note that we're really, really easy to implement. Like, roll-your-own-integration in less than 3 hours with zero previous experience easy. I want to see us become the de facto auth solution for weekend projects, but we're also a really nice option to put alongside your social login. If you're already offering Twitter and Facebook, why not provide a vendor-neutral option, too?
Is there at least a way to change the email addredd associated with an account? I can't see anything about that.
If you're using an email provider with native support for Persona, the only password you have is with your email provider.
Would you tell the user to "just enter all email addresses you ever registered" and then send confirmation emails to all of them? I'd imagine this ending with one or two confirmed email addresses and maybe 3 additional unconfirmed ones.
When the user then tries to use one of the unconfirmed addresses to sign in — what do you do? Refuse log in because the address is not confirmed? Send another confirmation email to that account and ask the user to confirm it? List those confirmed addresses in the account and ask the user if he wants to sign in with one of them?
Assuming by "we" and "us" you mean Mozilla? Or do you also mean the other major browsers?
Why did you write it like that? Why not just say "Persona" instead of "we" and "us"? Surely Persona is much bigger than Mozilla or do you not think so?
Firstly, that kind of language does not inspire trust. It sounds very much "us" vs "them", instead of addressing the real problem, which is helping users by creating and managing more secure passwords.
Secondly, your marketing to users includes:
"Many sign-in systems carry your profile data with them; some even share that info with other sites and social networks. We believe you should control how your personal information is shared."
You seem to want to attract publishers and yet you show your distrust of them to users.
Also, from experience in Public Web Apps, and the fact that it's still not possible for a user to give raw and pure TCP, UDP or POSIX power to Web Apps (and WebSockets and IndexedDB are not at all the same), I don't think the issue is so much that the user has power, as it is that the browser should have power. As it is today, the user is given very little power at all by the browser. Very little trust. Most spec discussions seem to constantly worry about users shooting themselves in the foot, and are prepared to stop at that, rather than finding ways to empower users to give power to web apps.
At the moment, however, and Persona is a good example of this, the browser approach to innovation is very much top-down with high-level APIs like UndoManager, WebRTC, IndexedDB rather than bottom-up with low-level APIs like UDP, TCP and POSIX which would trust the developer community to do the rest. Browsers are just not very programmable when compared to platforms like mobile and native.
For example, if the user would be allowed by the browser to empower a web app with raw POSIX, then that would unleash an explosion of databases running in the browser, orders of magnitude better and faster than IndexedDB.
Sadly, this kind of innovation is currently locked up tight inside the various spec committees. For sure, developers can contribute to the mailing lists, but innovation should not be made to go through that kind of process at all in the first place. Innovation on the web needs to be decentralized not centralized. Ideally, Mozilla needs to start making that possible, by providing just the right OS-level APIs and a simple way for users to grant these to Web Apps.
It must be 1984 that one can use a browser, but not be allowed to give raw TCP or UDP or POSIX annointing to web apps that one trusts.
See Tim Berners-Lee on the subject: http://lists.w3.org/Archives/Public/public-webapps/2012JanMa...
In an ideal situation, both your browser (eg: Firefox) and your email provider (eg: Gmail) would support Persona. In that case, you don't have to click on any links to prove your email address, you don't have to create a new password, you don't have to trust Mozilla's servers to store a hashed version of your password correctly. The log-in dialog itself with be part of the browser chrome, training users to trust the browser and not the website, which is a good thing.
If your browser or your email provider don't support Persona, then Mozilla have provided fallbacks, which require you to click a link in an email and to create a new Persona-specific password.
https://github.com/mozilla/browserid-bigtentIt always takes me 5 minutes to integrate, doesn't require me to write any sort of "forgot password" functionality, doesn't require me to worry about storing passwords, and it's generally very easy to work with.
One problem is that users don't know if they're supposed to sign up or sign in, and that a Persona works for other sites, but I think this can be ameliorated with good copy.
I think Persona really needs to sort that out, it's completely non obvious.
Plus, twitter and facebook won't be here forever and may be a fad. Imagine if people used their myspace handle to login to their bank account today. And facebook accounts get disabled/hacked much more often than, say, gmail. E-mail is much more signup-and-forget and nobody considers giving their email address a privacy violation.
I see lots of complaints here about the technical aspects of browserid, yet i believe it's the most pragmatic approach one can take to rid the web from the dreaded password plague.
What really sucks about all solutions is that once the data has leaked, you gotta trust the service providers not to sell or give your data away.
Can't do that with all digital data, but you could with e.g. email addresses, cc's, addresses, maybe phone numbers.
Same with credit cards: my bank offers a free service where I can set up as many virtual CCs as I want. Until recently they were single payment only, but now you can choose if it's single or multiple.
Forwarding (physical) address exist too, 'though they seem to be mainly targeted at people outside the US who want a address there, and they cost you an extra shipping fee, of course.