The biggest problem with Mozilla's Persona is the branding of it. Until they are able to get a handle on the branding-related issues, it can't get off the ground:<p>* Logo is ambiguous and looks like a generic button<p>* "Mozilla" in the name instantly steers away other browsers<p>We've implemented it on LinkUp (<a href="https://www.linkup.com/account/" rel="nofollow">https://www.linkup.com/account/</a>), love the technology, and REALLY hope the adoption of it takes off - but until I can explain it to a user in 2 sentences, it won't claim the throne.
Have any of the other major browsers made any public statements about BrowserID or Persona? How about Paul Irish or other developer relations type people? Somebody has to have said something even if it was 'unofficial'.
I'm genuinely curious. I did my bachelor's thesis on the identity ecosystem. I was an early adopter of CardSpace, iNames, OpenID, and any other digital identity solution that came along and I watched them wither from lack of interest. I was continually told that passwords are good enough, and that nobody is interested in a digital identity solution.<p>Persona doesn't sound that different from solutions that came before it. It sounds really similar to CardSpace, especially with how easily you can integrate it into a site. So why would Persona have a chance at succeeding where so many others have failed? Is it just a matter of timing, coming after some major password leaks, or are they hoping the Mozilla name will buy them support from the developer community?
Some thoughts from a privacy perspective:<p>Technically, I think this is vastly superior to the currently available login solutions. But one of the things I never liked about centralised or even federated auth was all the links between accounts.<p>One thing I don't like: ideally, all a site should need to know is that I'm the same entity I claimed to be last time. I only want to be locally unique on the site, not a globally unique value which can be correlated between sites. Also, it should be my choice as to whether I disclose my email address to sites.<p>In practice, email addresses are usually required for signups, and it's easy enough to create throwaways. I can absolutely see why it was designed this way, but it would still be nicer if the protocol did not disclose more than it needed to.<p>In this case, the email address (and equivalently the public key the browser holds for that email address) can be correlated between sites.<p>I thought a bit about making a mailinator-like IDP (i.e. a convenient way to hack around this). Unfortunately, I can't see a good way right now to get both these properties at the same time:<p>a) The IDP doesn't know what site (RP) the user is logging in to
b) The IDP can auto-generate a persistent unique id for each site (RP) (e.g: <type-4-uuid>@idp...)<p>I guess the degenerate case would be an IDP which signs <anything@idp...>. Not super useful, but OK for sites where you didn't really want to have a login anyway, I guess... true mailinator style, but for logins.<p>A few other points:<p>* Would also be good to have a privacy option to force the browser to generate a fresh keypair every time a new user certificate is requested; at least then we can only be tracked by identity and not so much by device over time as well.<p>* There is the obvious timing attack, where if the RP doesn't cache the IDP's public key, it may disclose what site the user is logging in to, to the IDP.<p>* Also, verifier.persona.org will know who is logging in where, if you use their JS (since you pass the assertion and the audience via REST).<p>* I am not 100% sure at this stage what stops a malicious user from simply asking the browser to perform an identity assertion and grabbing email (or clickjacking the user into doing it) when they already have a user cert; haven't looked at it in depth though.
I worry about Persona, for exactly the same reason OpenID chose the design it did: It's a serious mistake to permanently tie email to identity.<p>It's still possible within the framework of Persona to fix this -- the browser / identity provider needs to support freshly-generated opaque "email addresses" for each new site that needs a login. This prevents tracking and spam problems, but will also require both providers and relying parties to downplay the 'email address' token in the UI, which I fear is far too much to ask.
I don't understand why this is better than just using a public/private key to represent identity. Why involve the email operator? Why can't I log in by having my browser sign a certificate, without involving a third party at all?
> OpenID uses URLs as identities.<p>True, the fact that URLs identify them confuses some people. However, <a href="http://" rel="nofollow">http://</a> being usually superfluous, I don't see why roger.example.com is more confusing than roger@example.com.<p>> Most sites would like at least an email address to be able to contact you, so will almost always require an additional step after logging in for the first time.<p>And openId provides an email if the site asks for it.<p>> OpenID is a jarring login process.<p>The difference is that the provider page is a full page rather than a popup?<p>> Both OpenID and oAuth allow your identity provider (be it Google, Facebook, Twitter) to track every website you sign in to.<p>So does mozilla persona as your identity provider is your browser ! I remember an opera unite app that acted as an openId provider. How is Persona different/better than that?<p>> oAuth is complicated for developers to implement [...] several versions of the protocol, [...]<p>That is true. And it will also be true of persona in two years when you will have to support firefox15 to 20, chrome 33 to 35, ie11, opera14, opera15, webkit-beta-nameless-browser, webkit-alpha-nameless-browser and others' own versions of persona
I would love to use this, but apps I work on are both web browser based and native clients. Persona does not <i>yet</i> work with native apps (Android, iOS native apps); it only supports browser based auth right now.<p>Browser only auth doesn't get me all the way there. I can look at wrapping UIWebKit, or whatever, in my apps, but I bet I am just asking for some hurt. :-)
The recent wave of password and hash theft might become an incentive to move to this login method. I was skeptic about the possibility of BrowserID catching on, thinking the Google/Twitter/FB wouldn't give up tracking users with their ID methods. But if there is a way to make this widespread (though I can't imagine how) I'd really like it to happen.<p>Will Mozilla provide native support or an extension? Or they feel like it would hurt if someone could implement a bad login page that still works if the browser has native support?
This Persona/BrowserID kludge makes me sick. I don't get why everyone is so optimistic about it. I believe there's absolutely no reason why one just can't be a source of their own identity (as it naturally happens), with so-called "identity providers" actually being "identity notaries."<p>In BrowserID they <i>do</i> generate keypair, but then tie identity not to it, but to an email address, something user lends, but never actually possesses. Completely the same as with OpenID, where identity is tied to URI. Actually, the only change is URI scheme part: http/https to mailto — which is nice UX-wise, but that's about all the advantages.<p>OpenID was <i>heavily</i> criticized for that (remember all those "did I sign up with Google or Facebook?", URI changes/account rename issues, identity providers being temporarily down, and so on?), and now those who criticized OpenID are praising system that have <i>most</i> of the same problems.<p>I can only hope Persona would silently fail and never gain any significant popularity, so users won't have to struggle with another hype wave, to only lose their trust (if there's any left) in non-centralized identity systems.
Chrome, IE, and Opera need to natively incorporate browserid ASAP.<p>Please, put your egos away and get this done for the sake of everyone who uses the web.
Tying email addresses to a user's identity is a terrible idea.<p>- I don't want to give my email address to every site I use. It should be available to the site only if I approve their request.<p>- I use a unique email address for every site that needs one.<p>- What if I want to start using a new email address?
I don't see a compelling reason, especially since I'm in the EU and don't want my e-mail address, password and website usage statistics transferred to Mozilla's servers in the US, where they can be accessed and possibly misused by authorities.
tl;dr Uses an e-mail address to make public key crypto easier. Sounds nice.<p>Unfortunately, most people fuck up PKI and now we're relying on a third party (Mozilla) to authenticate all our logins.<p>You could also just implement client certificates without a third party. Issue your users a cert when they register or log in. This would be similarly "automatic" authentication without relying on Persona to be stable and secure 24/7. I wonder why they didn't just make a browser plug-in that simplifies using client certificates (without the expense of supporting a highly reliable 3rd-party site and extra code to make it work)
I get that I'm probably not the target market for OpenID since I'm already more tech-friendly than the average user, but I've never thought it was super complicated or "jarring," to use the definition in the article. I set up the URL on my web server years ago (thus securing me as more technical, I know), but it's been great. I can change providers in the background, and I only need to remember one URL. No more usernames or anything. Sure, it could be easier and more widely adopted (chicken and egg), but I have thought it was relatively pleasant for a while.
I personally like OpenID, especially in combination with GMail. But if this is easier for most users (and it seems to be) then I could be fan of it as well.<p>One thing that I don't see is what happens if I sign up as a user now (with my GMail address) and then GMail later starts providing their own service, instead of the fallback. Do I lose my account on all the services I signed into?
If this ever becomes popular, I can imagine law enforcement agencies will want to link e-mail address to people even more, and mail vendors such as Google, Yahoo and Microsoft will become a much more popular target for subpoenas and such.<p>I just don't like the idea of all the passwords being centralized in one place and being so very easy to obtain by the US Government.
I am really hoping this takes off. I'm currently implementing it in an app and, although the API is a little awkward, it was pretty easy to do. The only snag I've run into is that it has issues in Chrome if third-party cookies are disabled.
I like the implementation but I don't like that it has a brand (Mozilla) attached to it.<p>Stripe is doing this right, when you make a payment on a website you have no idea that you're using Stripe.