That, and the whole federated/shared/social login space is confusing! First there was OpenID, but then everyone jumped to OAuth. But wait, OAuth isn't really about authentication?! Throw in xAuth and all of Eran Hammer's rants, and you quickly realize that anything resembling consensus is pretty tenuous, at best.
Persona looks solid, though -- here's hoping browser developers jump on board quickly. I'm concerned that OAuth's delegated authentication mechanism might remain king for a lot of free web apps, though. The ability to require permissions to post (spam) to your users timeline/wall (even if it's not actually needed by your application) is probably pretty tempting for someone trying to work every angle possible to make money from their application. Every angle other than actually charging for their service, that is.
Also, people recognize Facebook and Google as brands they already have accounts with. When a user sees a big blue/red Sign In With Facebook/Google button, that's an easier decision than hand-keying your credentials (especially on a tiny and slow mobile keyboard). Moreover, users trust Facebook and Google to know how to secure their passwords better than randomsiteijustfound.com, so they may believe OAuth is safer than trusting that randomsiteijustfound.com's developer knows how to properly hash a password.
That said, many of the applications that feature "sign in with Facebook", don't actually need access to my Facebook account. They may just be trying to make it easier for the user to sign in, but they also sometimes abuse that trust, and start posting things on your behalf.
Frankly, I'd much rather generate a random password for randomsiteijustfound.com and not worry too much about their password-hashing policy than trust them to do the right thing with access to my Facebook account.
This is why I like Persona -- if a site really just wants to make it easy for me to sign in, they'll use Persona, and I won't have to worry about them abusing my trust, because I'm not granting them access to anything else. Once I feel like they're trustworthy or useful enough, I can consider granting them OAuth authorizations to my Facebook account.
Play Brave[1] is a game from the Born This Way Foundation, which uses Persona.
Mineshafter[2] is a free alternative to using the main Minecraft online services.
The Times[3] (UK) Crossword puzzle uses Persona to make switching between Desktop and Mobile easy.
[1] http://www.playbrave.org/gallery/ [2] http://mineshafter.info [3] http://crossword.thetimes.co.uk/
Because all they've published so far is API specs and fluffy PR sites that try to portray it as "oh so much better" without offering any insight about why it is better. They can claim "more privacy" all day long, but without any details about what gets stored where and why it is supposed to be safer, they don't make a compelling case.
Look at this page for example: https://login.persona.org/about (the "how it works" page) - it has 0 details about these claims and unfortunately, we're already tired of reading how Google and FB respect our privacy. From "outside", it looks like we need to give Mozilla our (existing) credentials and trust them to handle them with care. Why should we? I feel safer making pwgen passwords for every new site I need to register at.
As far as the architecture of the overall thing, there are also http://identity.mozilla.com/post/7899984443/privacy-and-brow... and http://identity.mozilla.com/post/11145921163/browserid-desig... and a technical specification at https://github.com/mozilla/id-specs/blob/prod/browserid/inde... that describes the exact data flow involved.
And if you read those, it should become pretty clear _why_ this is better for privacy than the FB or Google login systems. For one thing, the identity provider is never told that you're logging in.
There are tons of technical docs on our MDN page: https://developer.mozilla.org/docs/Persona
You can start with a high-level explanation of why Persona is different and awesome: https://developer.mozilla.org/en-US/docs/Persona/Why_Persona
From there, you can dig as deep as you'd like--we have docs to help with building an identity provider, integrating Persona into an existing site, even a list of pre-written open source plugins in a ton of languages/frameworks.
If none of that works, drop by #identity on mozilla IRC and tell us our docs suck, so we can prioritize making them better.
Mozilla needs to make a very compelling case to web site owners for adoption, because FB and even Google has more users and oauth is at least roughly understood.
a) certificates are stored in localStorage for https://login.persona.org. They are very short-lived (hours), so that we don't have to deal with revocation, since that would likely be impossible on a per-user scale.
b) there's no way you can prevent an identity provider from misusing your identity. They're your identity provider. You chose them because you trust them to credential you and not let other folks impersonate you.
b') browser extensions already have full control over your life. That's something that should be addressed longer term, but Persona is not making this any worse.
b'') other entities cannot access the localStorage for login.persona.org, so that should be okay.
c) you're not just entering an email address. You're also proving you own it, for example by being logged into your Yahoo.com account, or by clicking the confirmation link we send you. What we're doing is minimizing the number of steps you have to take to prove you own an email address. But you still have to own it.
You should check out our documentation, which is quite thorough:
https://developer.mozilla.org/en-US/docs/persona
I think we've provided a lot of hard data and docs to back our claims, but we're happy to provide more, of course.Assuming you're saying other people have access to your email account already, it's game over: practically every site will send password reset procedures on demand to the email you used to create your account.
Alternatively, if you're saying other people know your email address, that's not really relevant. They need to either be able to read email on your account (see above), or be able to implement an Identity Provider on your email domain.
If an unauthorized party is able to implement an IdP on your email domain you have an even worse problem: your email provider apparently is unable to control basic aspects of their own domain.
to actually implement an IdP, your email provider must publish a https://domain.com/.well-known/browserid file. If a rogue third party can do this at will, I'd say your email provider has horrible security and your security assumptions are probably broken anyway.
What is my identity tied to? The browser and the given e-mail address? Can anyone who has access to these fake my identity? What countermeasures can I take if that happens? A simple password change is probably out of the question. Such are the questions I'd like to be able to answer, but with the provided, easily accessible information, I cannot.
Let's see if I can help.
Your identity is tied to your ability to prove that you own an email address. You can do that by clicking a confirmation link we send you. Or, as of Beta2 (today!), you can do that by having your domain implement the Persona Identity Provider API, where your domain publishes a public-key and issues certificates to you based on that public key, which you can then use to sign into web sites. Also as of today, we do that for Yahoo users by bridging to Yahoo OpenID, so basically Persona is an OpenID client to Yahoo, gets Yahoo to vouch for your email, and based on that issues you a Persona certificate (backed by our public key) for your email address.
But whatever way you go, it's about proving you own an email address and obtaining a certificate for it.
Yes, someone who has access to your browser can fake your identity if you don't lock your browser/OS, but that's nothing new. In fact, the simple password change is how we mitigate that. As soon as you change your password, we invalidate all sessions on all devices. Certificates last only a few hours, so they'll be disabled quickly too.