12 ms·

Why Mozilla Persona is the right answer to the question of Identity

232 points by jalada 14y ago

hayksaakian 14y ago
As good as it may be, I have a hard time seeing this grow beyond Mozilla browsers, what with their reliance on browserid
- jalada 14y ago
  That's what the Javascript shim is for.
- scottlinux 14y ago
  Works in any modern browser. Check this out: https://developer.mozilla.org/en-US/docs/persona/Browser_compatibility https://developer.mozilla.org/en-US/docs/persona/Browser_com...
- ozten 14y ago
  Try it today on your iPhone, iPad, or stock Android browser. This is a cross-device, cross-browser solution.
yafujifide 14y ago
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?
- jalada 14y ago
  My first thought is that completely depends on browser uptake. Persona/BrowserID works whether the browser supports it or not.
- nodata 14y ago
  We had that, it didn't work. > Why involve the email operator? We involved CAs.
  - lazyjones 14y ago
    CAs would not be required at all for a simple certificate-signing scheme that could be implemented in a similarly user-friendly way.
    - nodata 14y ago
      How would it work on other people's computers?
      - peterwwillis 14y ago
        The same way it works with Mozilla Persona. If they're not using their normal browser, they don't have any cert data stored, so they have to 'log in' the traditional way to Mozilla Persona, which then gives the browser the cert data. The whole thing hinges on caching login credentials. The simplest way to support this without depending on a 3rd party (Mozilla) would be to use an e-mail reset to send you a temporary credential to log in from an "unsafe" computer. There would need to be lots of restrictions on its use of course.
        takluyver 14y ago
        Persona doesn't involve any hard dependency on Mozilla. The user can use another ID provider (or even run their own) and the site can verify the credentials without using Mozilla's webservice. Both are currently unlikely, but it's easy to imagine GMail being an ID provider in the future.
        baq 14y ago
        can i supply more than one so sites could check if one of the providers has been compromised or something similar? does it make sense to have more than one?
- sergiotapia 14y ago
  Because my mother doesn't give two shits about public/private key. She just wants to authenticate and the easiest way both logistically and mentally to do that is to just sign into her email. I fully support this idea from Mozilla and I hope it kills OpenID, as even that's a pain in the ass sometimes.
  - Ntrails 14y ago
    Surely the real win here is the massive reduction in password re-use on 'less secure' environments. Obviously google/microsoft etc are not immune to screwing up and having their database hacked - but I'd rather put all my eggs in that basket than having a single egg in lots of baskets with differing levels of security that subsequently enable access to all of my eggs anyway and... Yeah. So the eggs metaphor doesn't really work. Sorry.
  - drdaeman 14y ago
    Your mom can treat keypair as just another password thing. With the nice exception that she would never have to type it, just click on "sign in as (name)" button and browser/GPG agent combo would do the rest. I'd note there are tons of solutions involving key escrow, so synchronization and recovery are not problems.
- zerostar07 14y ago
  Because with browserID your email acts like a public key, and presumably the third party does a better job at securing your private key (with 2 factor auth, biometrics etc) than most people do on their own (the current password theft onslaught proves that). If this gets traction i m sure many hacker groups will come up with independent, noncommercial and nongovernmental authenticators.
- maxerickson 14y ago
  I think part of it is that sites want email addresses for their users. Making the email address part of the protocol lowers the bar for sites to join the ecosystem.
- rictic 14y ago
  Good question. This was actually implemented in Firefox a while ago, I even remember actually finding it in use in the wild once. The key issue there is how do users manage their certificates? Their 'passwords' are now a set of certificates stored somewhere. These certs need to be accessible from their phone, their work computer, their home computer, the cyber cafe, their friend's computer, and so on. I see two possible solutions to this. One is storing these certs in the cloud, the other is hard token like a flash drive. The problem with the physical token is that it can be lost, so it needs to be backed up somewhere. Where to back it up? The cloud seems the natural answer. How do you reliably authenticate this cloud cert storage system in a way that a person can't just lose or forget? And we're back to email. Persona reduces all of these things down to the email account. Assuming they did it right (I haven't gone into the details yet) then they're introducing no new attack vectors (someone with your email can own most of your accounts already) and they're eliminating the password from most places. Seems like a win to me.
  - drdaeman 14y ago
    So, we have two options: 1. Tie identity to email address. No means of backup (you just can't back up your email provider), no sensible migration possibilities, system is as vulnerable as your email account. 2. Tie identity to keypair. Let email provider (or other trusted third party) sign it, validating the email address. Then escrow the pair and allow recovery by passphrase and email validation, and/or put it on hardware token, and/or hide a piece of paper in a safe behind a cupboard. Simple means of migration (just authenticate with old key and new address), huge flexibility of choices between security and usability. Both options may have the same default UI/UX and they share very similar workflow. Generate keypair, let the provider perform the email validation, get the signature, give it to the consumer. The only difference is what's finally tied to your account — your address or your public key.
- drivebyacct2 14y ago
  Argh. Why am I so late to this thread? This is possible. Your BrowserID provider can do public/private key auth. You could have an identity that is provided for (you could do this yourself on your own domain) that you authenticate to via a private key. That's how flexible this protocol is. The provider has a huge range of discretion about how the account is authenticated.
  - drdaeman 14y ago
    The problem is, one can't own a domain, but only lease it for a time being. And one can't migrate between johnny@example.edu and john@example.org. That's how inflexible this protocol is, compared with a simple keypair.
lifeisstillgood 14y ago
This just beats OpenID hands down. And I will be very interested to see how fast Google et al support it. I think they may be a bit evil.
lazyjones 14y ago
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.
- dochtman 14y ago
  None of these have to go through Mozilla if you don't want them to. You can host your own copy of the JavaScript shim and setup your own identity provider to authenticate against and it will Just Work.
- jerf 14y ago
  Mozilla has the only implementation at the moment as they are still developing it, but the intention is that any email provider can provide this in the future. They have not written themselves into the spec. In fact they have commented that the more successful this standard is, the less important they become.
  - da_n 14y ago
    Commendable goals, but in my opinion somewhat conflicts with the 'Mozilla' prefix in the name, if they hope to make it a widely adopted standard they need to drop their branding and just call it 'Persona'.
    - whatusername 14y ago
      Read the article. The protocol is called BrowserID. The Mozilla service to try and help adoption is called "Mozilla Persona"
- masklinn 14y ago
  > don't want my e-mail address, password and website usage statistics transferred to Mozilla's servers in the US Isn't the whole point of Persona that... it's not? Or it doesn't have to at least? In fact, two of the main motivations of Persona are 1. decentralized identity provider (so you don't have to rely on Mozilla) and 2. that the identity provider should not know which websites you're using (so whoever you're relying on doesn't have to know you're looking at cat pictures)
csixty4 14y ago
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. 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?
- Yoric 14y ago
  I am not familiar with CardSpaces, but a considerable difference between OpenID and Persona is a matter of anonymity. With OpenID, your OpenID provider (e.g. Google) can track you as you log to your various accounts. By opposition, with Persona, the Persona provider does not get any meaningful information that can be used to blow your anonymity.
  - csixty4 14y ago
    tl;dr - Here's a video demonstration: http://youtu.be/0_6rC025sK0?t=34m16s http://youtu.be/0_6rC025sK0?t=34m16s CardSpace was a Microsoft project led by Kim Cameron, the godfather of digital identity. They originally wanted to make it part of Windows Vista, but it was dropped for lack of interest. It was an open standard, and there were browser plugins to make it work in other browsers and operating systems. Microsoft knew they couldn't make it a Windows-only thing if they wanted people adopting it. They just wanted to be at the forefront of security for once. A developer would add meta tags to a site's login page with a URL to post identity info to and a list of information it's requesting. That would trigger the browser (or plugin) to open a modal display of identity "cards", which the user could choose from. Then it would show what information the site requested and they could deny individual pieces of info. The data would be posted back to the site, along with a unique signature for that user & site. Cards could be self-issued or issued by a third party, like your employer or bank. They could have graphical backgrounds applied so they looked more like ID cards or credit cards. It was a great UI for identity, and easy for developers to use. But I think the Microsoft name tarnished it. I know people outside the identity community were making comments about how this was Microsoft's attempt to become Big Brother & so forth, even though Microsoft was completely out of the communication loop between the user and the site.
GregWright 14y ago
I would love to use this, but apps I work on are both web browser based and native clients. Persona does not yet work with native apps (Android, iOS native apps); it only supports browser based auth right now. 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. :-)
deleted 14y ago
[deleted]
alter8 14y ago
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. 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?
- romaniv 14y ago
  Password/hash thefts have been happening for as long as there have been systems with passwords. What changed recently is that we now have centralized services with huge numbers of important accounts. There are more service with large number of accounts and more services that affect multiple aspects of your digital life. When someone steals hashes from those, the press and people are more likely to notice. I think most people overemphasize the importance of the particular authentication scheme used and overlook the problems created by extreme centralization of stuff.
- ecaron 14y ago
  > Will Mozilla provide native support or an extension? They have a working native support - http://www.soeren-hentzschel.at/mozilla/persona/2011/07/15/mozilla-stellt-browserid-vor/ http://www.soeren-hentzschel.at/mozilla/persona/2011/07/15/m... - and expect it to see it natively in probably ~17. Their biggest push is for WebKit to adopt a similar solution based off the same tech.
ecaron 14y ago
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: * Logo is ambiguous and looks like a generic button * "Mozilla" in the name instantly steers away other browsers We've implemented it on LinkUp (https://www.linkup.com/account/ https://www.linkup.com/account/), 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.
- ncri 14y ago
  I just tried to login into your site without being registered with Persona. All works fine, I can choose a password, and receive an email with confirmation link. When I click it I see an info box from Persona, but after only 3 seconds or so I get redirected to your site - so that is buggy. I see then a notice that your site couldn't log me in, which is fine, as I don't have an account. However, your site then starts to log me in over and over again. Which seems an issue on your site. Hope this info helps. I'm using chrome on OS X.
  - ecaron 14y ago
    Thank you so much for the thorough details. I squashed this bug. Can you ping me at eric@linkup.com so I can send you a Starbucks giftcard for your help?
- stickfigure 14y ago
  There is a really easy way to explain Persona to users: "Sign in with your email address" At Voost (https://www.voo.st/ https://www.voo.st/) we have been using BrowserID since launch earlier this year. We just use this simple phrase and users "get it" right away. There's no need for complicated branding.
  - ecaron 14y ago
    Except this would only work if you: 1) Forced all users in your system, who already had email/password based accounts, to abandon their existing accounts and adopt Persona 2) Became fluent in quickly explaining to users how to reset their Persona password when they forget it 3) Don't mind losing all the users who say "I trust you, but not this company I haven't heard of before." Some users, especially jobseekers, won't let their circle of trust grow - and forcing adoption of a 3rd party causes abandonment. But so does a complicated sign-in process, so you just need to figure out if group A or group B is larger because you can't make everyone happy.
leetreveil 14y ago
I like the implementation but I don't like that it has a brand (Mozilla) attached to it. Stripe is doing this right, when you make a payment on a website you have no idea that you're using Stripe.
- shardling 14y ago
  I won't put credit card details into a site unless I have some trust in the system they're using. The lack of a brand isn't necessarily a good thing here. In any case, the brand is for marketing to developers right now -- once "Persona" becomes a thing in and of itself, this will be a nonissue.
peterwwillis 14y ago
tl;dr Uses an e-mail address to make public key crypto easier. Sounds nice. Unfortunately, most people fuck up PKI and now we're relying on a third party (Mozilla) to authenticate all our logins. 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)
- JackC 14y ago
  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. So the goal is basically: I have a computer at work, a computer at home, a computer in my pocket, and a computer I just borrowed to check something at a friend's house. I want to be able to go to the same random site on all four devices and have it recognize that I am the same person, without (1) remembering a special password for that site, or (2) trusting that site in any way. So there are two ways to do that. One involves generating a certificate on one of my devices and somehow communicating it to the others without a central authority. The other involves a central authority that each device can communicate with. The first way will be, let's say, extremely challenging to get working reliably across all devices and platforms in a way that average users can handle. So Mozilla went with an extremely flexible version of the second way. It goes like this: users remember a Username and URL, in the form Username@URL. They also remember a Password which is only shared with URL. When I want to identify myself to that random website on any of my four devices, Mozilla helps me get a verifiable statement from URL to send to the random website that I am Username@URL. There are two things mixed in to make it more likely this will take off. First, users are already used to remembering Username@Url / Password credentials, so they don't have to learn anything new to identify this way. And second, because existing Username@Url identities are email addresses, Mozilla can offer an intermediate identification service based on the ability to receive email, until other identity servers come online. TL;DR: By using an intermediate ID server and credentials that look like email addresses, Mozilla has created a path to cross-device, cross-platform user ID that solves the problems of user adoption, technical adoption, and independence -- it can be implemented in existing browsers, understood by existing users, and offers a clean transition to completely decentralized identification. Very cool.
po 14y ago
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'.
hackerboos 14y ago
Persona - An identity system by Mozilla Personas - Skins for the Firefox Web Browser This is an issue that needs to be resolved.
- ecaron 14y ago
  They've resolved it in planning (http://www.ghacks.net/2012/03/02/mozilla-personas-renamed-to-background-themes/ http://www.ghacks.net/2012/03/02/mozilla-personas-renamed-to...), but the implementation just hasn't been completed. Yet. "To sum it up: * BrowserID renamed to Mozilla Persona * Personas renamed to Background Themes * Themes are now Complete Themes"
  - petitmiam 14y ago
    Background Themes/Complete Themes - sounds like they just created a new problem. Throwing the word 'theme' in there for backgrounds is just asking for confusion. I think most people understand Wallpapers (Backgrounds) / Themes.
mtgx 14y ago
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. 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.
gwillen 14y ago
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. 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.
- StavrosK 14y ago
  Just use <somethinghere>@mockmyid.com. It doesn't even ask for a password. I don't think it would be too much work to create a Persona service like 33mail.com, which provides your own domain for email and authentication. That way, you would enter "myaddress@domain.33mail.com", the site would send you there for auth, 33mail would reply that you are logged in to your account (if you were, obviously), and that'd be all.
Perceptes 14y ago
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.
eddieroger 14y ago
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.
wccrawford 14y ago
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. 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?
- takluyver 14y ago
  As I understand it, you're identified to the site by an email address. So if GMail becomes an ID provider, you keep using the same identity, but with Google confirming it rather than Mozilla. I'm by no means an expert, though.
  - callahad 14y ago
    Exactly -- your provider's domain is always checked first. Mozilla only steps in as a fallback, and accounts can/will be transparently "upgraded" when a domain adds native support.
  - jarofgreen 14y ago
    I am also by no means an expert but that is also my understanding. What would change tho is the login procedure. Where once the user saw a Persona login box, suddenly they will see a Gmail login box. That has the potential to be really confusing unless handled well, no?
  - wccrawford 14y ago
    Okay, so there's no token being passed? If someone manages to spoof the system, they could be anyone and just accept my access request? I haven't thought it all through, but it feels like there's a weakness there that's just waiting to be exploited.
    - takluyver 14y ago
      I think there is a token being passed, but it's authentication, not identity. It's a signed declaration that you own that identity, and it must be either from the domain that issued it, or another source that the site you're visiting specifically trusts (i.e. Mozilla, at present). I trust Mozilla to have done a good job of this. If there's a weakness, it's not going to be anything so obvious that you can see it from my stumbling attempts to describe the protocol. If it sounds like there is, I'm probably describing it wrong. Have a look at the details here: http://lloyd.io/how-browserid-works http://lloyd.io/how-browserid-works
dreamdu5t 14y ago
Chrome, IE, and Opera need to natively incorporate browserid ASAP. Please, put your egos away and get this done for the sake of everyone who uses the web.
latchkey 14y ago
I really want to see HN adopt Persona.
- shardling 14y ago
  I'm a big fan of how they used to support OpenID but quietly dropped it, locking me out of my original account. No, wait, that was terrible!
ernesth 14y ago
> OpenID uses URLs as identities. True, the fact that URLs identify them confuses some people. However, http:// http:// being usually superfluous, I don't see why roger.example.com is more confusing than roger@example.com. > 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. And openId provides an email if the site asks for it. > OpenID is a jarring login process. The difference is that the provider page is a full page rather than a popup? > Both OpenID and oAuth allow your identity provider (be it Google, Facebook, Twitter) to track every website you sign in to. 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? > oAuth is complicated for developers to implement [...] several versions of the protocol, [...] 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
- saraid216 14y ago
  > True, the fact that URLs identify them confuses some people. However, http:// http:// being usually superfluous, I don't see why roger.example.com is more confusing than roger@example.com. Because "roger.example.com" is a webpage, whereas "roger@example.com" is an addressbook entry. Very occasionally, "roger.example.com" is a blog or personal webpage and thus probably refers to a single person. Maybe.
  - Arelius 14y ago
    additionally, it may be example.com/roger or example.com/openid/roger, the regularity of it is small, and people already know what their email addresses are.
- zerostar07 14y ago
  The big advantage is that users won't have to be 'trained' for anything new: they are all familiar with email / password signups. It's pretty obvious that the website will use your email so no privacy surprises. Switching between email identities is a snap. It's actually pretty pragmatic approach given that what most people do is first assess the website risk, choose whether to give their primary or secondary email (but wait which one? i have 5), type it in (what if they mistype / remember the wrong one) and then type one of their 3-4 rememberable passwords. If anything, browserID neatly simplifies the authentication process for the user. Also, developers only have an assertion to send; that's really really simple and less likely to break in future releases. Easier signups are important especially for small web utilities that just need a unique identifier and not much private information to work.
mightytightywty 14y ago
Tying email addresses to a user's identity is a terrible idea. - 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. - I use a unique email address for every site that needs one. - What if I want to start using a new email address?
- Arelius 14y ago
  I wouldn't actually say it's a terrible idea, for 99% of users it should work better, faster, and easier for them, since -very- few people have the same habits as you. However, having said that, I do otherwise agree with you, I also don't want to give my email out to all of them, and when I do, it may be one of a few address, depending on how much I trust them, or care about the responses. I'm given very little option in that regard.
  - nicolasp 14y ago
    > it may be one of a few address, depending on how much I trust them, or care about the responses. I'm given very little option in that regard. You are given the choice of which email address you want to use to log in. Isn't that exactly what you want?
- brendn 14y ago
  I'm curious about that issue, too. Here's a brainstorm: - An independent Identity Provider (IdP) uses some means of identification for the user (two-factor, iris scan, whatever) - The IdP provides an anonymized email address to each site that the user logs into. I'll have to read the spec a bit more to see if that's possible...
  - callahad 14y ago
    It's hard to do completely cleanly -- building an independent IdP that uses iris scanning or other two-factor systems is totally possible, and actually relatively easy. Providing anonymized addresses is harder, since your IdP wouldn't be contacted until after the user has selected an address. In that case, you'd want a browser extension that generated addresses conforming to some scheme @youridp.com and automatically filled or selected them in the dialog when using Persona. Totally doable, but that part requires getting out in front of the call to navigator.id.request.
jellicle 14y ago
A well-crafted solution desperately in search of a problem to solve.
- nine_k 14y ago
  If registering at yet another site (forum, online store, government site, etc) and remembering the password when you get back to it 2-3 month after is not a problem for you, I admire your memory. Or maybe you're not visiting these types of sites as much as I do.
  - Revisor 14y ago
    Another solution to this is a password manager, eg Keepass. It still centralizes your identity under one roof, in the encrypted DB, but only locally.
    - LeonidasXIV 14y ago
      But the overhead is much larger and let's be honest, this solution is only used by a tiny minority of (mostly tech) users. Mozilla Persona could be used by everybody because for the end user it is exactly as complex/easy as it is currently or even easier.
    - callahad 14y ago
      Password managers are necessary, but they're not enough. So long as there's an underlying password for every damn site you visit, then every damn site still has to store passwords securely and you have to maintain things when that site gets breached. Not to mention the stability of that password. If it gets sniffed once, it's possibly game over for months. If a Persona assertion gets sniffed in transit, it's only good for a few minutes in time.
  - luke_s 14y ago
    Or perhaps he is just doing what everybody _really_ does, which is to use the same username and password for every random site on the net and hope like hell they are not storing passwords in plantext. A hope, which has been dashed time and time again by bitter reality. It seems the only people lazier about password security than the actual end users, is the site owners ...
xyzzy123 14y ago
Some thoughts from a privacy perspective: 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. 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. 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. In this case, the email address (and equivalently the public key the browser holds for that email address) can be correlated between sites. 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: 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...) 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. A few other points: * 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. * 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. * 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). * 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.
drdaeman 14y ago
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." In BrowserID they do 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. OpenID was heavily 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 most of the same problems. 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.

232 points by jalada 14y ago

As good as it may be, I have a hard time seeing this grow beyond Mozilla browsers, what with their reliance on browserid

jalada 14y ago
That's what the Javascript shim is for.
scottlinux 14y ago
Works in any modern browser. Check this out: https://developer.mozilla.org/en-US/docs/persona/Browser_compatibility https://developer.mozilla.org/en-US/docs/persona/Browser_com...
ozten 14y ago
Try it today on your iPhone, iPad, or stock Android browser. This is a cross-device, cross-browser solution.

yafujifide 14y ago

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?

jalada 14y ago
My first thought is that completely depends on browser uptake. Persona/BrowserID works whether the browser supports it or not.
nodata 14y ago
We had that, it didn't work. > Why involve the email operator? We involved CAs.
- lazyjones 14y ago
  CAs would not be required at all for a simple certificate-signing scheme that could be implemented in a similarly user-friendly way.
  - nodata 14y ago
    How would it work on other people's computers?
    - peterwwillis 14y ago
      The same way it works with Mozilla Persona. If they're not using their normal browser, they don't have any cert data stored, so they have to 'log in' the traditional way to Mozilla Persona, which then gives the browser the cert data. The whole thing hinges on caching login credentials. The simplest way to support this without depending on a 3rd party (Mozilla) would be to use an e-mail reset to send you a temporary credential to log in from an "unsafe" computer. There would need to be lots of restrictions on its use of course.
      - takluyver 14y ago
        Persona doesn't involve any hard dependency on Mozilla. The user can use another ID provider (or even run their own) and the site can verify the credentials without using Mozilla's webservice. Both are currently unlikely, but it's easy to imagine GMail being an ID provider in the future.
        baq 14y ago
        can i supply more than one so sites could check if one of the providers has been compromised or something similar? does it make sense to have more than one?
sergiotapia 14y ago
Because my mother doesn't give two shits about public/private key. She just wants to authenticate and the easiest way both logistically and mentally to do that is to just sign into her email. I fully support this idea from Mozilla and I hope it kills OpenID, as even that's a pain in the ass sometimes.
- Ntrails 14y ago
  Surely the real win here is the massive reduction in password re-use on 'less secure' environments. Obviously google/microsoft etc are not immune to screwing up and having their database hacked - but I'd rather put all my eggs in that basket than having a single egg in lots of baskets with differing levels of security that subsequently enable access to all of my eggs anyway and... Yeah. So the eggs metaphor doesn't really work. Sorry.
- drdaeman 14y ago
  Your mom can treat keypair as just another password thing. With the nice exception that she would never have to type it, just click on "sign in as (name)" button and browser/GPG agent combo would do the rest. I'd note there are tons of solutions involving key escrow, so synchronization and recovery are not problems.
zerostar07 14y ago
Because with browserID your email acts like a public key, and presumably the third party does a better job at securing your private key (with 2 factor auth, biometrics etc) than most people do on their own (the current password theft onslaught proves that). If this gets traction i m sure many hacker groups will come up with independent, noncommercial and nongovernmental authenticators.
maxerickson 14y ago
I think part of it is that sites want email addresses for their users. Making the email address part of the protocol lowers the bar for sites to join the ecosystem.
rictic 14y ago
Good question. This was actually implemented in Firefox a while ago, I even remember actually finding it in use in the wild once. The key issue there is how do users manage their certificates? Their 'passwords' are now a set of certificates stored somewhere. These certs need to be accessible from their phone, their work computer, their home computer, the cyber cafe, their friend's computer, and so on. I see two possible solutions to this. One is storing these certs in the cloud, the other is hard token like a flash drive. The problem with the physical token is that it can be lost, so it needs to be backed up somewhere. Where to back it up? The cloud seems the natural answer. How do you reliably authenticate this cloud cert storage system in a way that a person can't just lose or forget? And we're back to email. Persona reduces all of these things down to the email account. Assuming they did it right (I haven't gone into the details yet) then they're introducing no new attack vectors (someone with your email can own most of your accounts already) and they're eliminating the password from most places. Seems like a win to me.
- drdaeman 14y ago
  So, we have two options: 1. Tie identity to email address. No means of backup (you just can't back up your email provider), no sensible migration possibilities, system is as vulnerable as your email account. 2. Tie identity to keypair. Let email provider (or other trusted third party) sign it, validating the email address. Then escrow the pair and allow recovery by passphrase and email validation, and/or put it on hardware token, and/or hide a piece of paper in a safe behind a cupboard. Simple means of migration (just authenticate with old key and new address), huge flexibility of choices between security and usability. Both options may have the same default UI/UX and they share very similar workflow. Generate keypair, let the provider perform the email validation, get the signature, give it to the consumer. The only difference is what's finally tied to your account — your address or your public key.
drivebyacct2 14y ago
Argh. Why am I so late to this thread? This is possible. Your BrowserID provider can do public/private key auth. You could have an identity that is provided for (you could do this yourself on your own domain) that you authenticate to via a private key. That's how flexible this protocol is. The provider has a huge range of discretion about how the account is authenticated.
- drdaeman 14y ago
  The problem is, one can't own a domain, but only lease it for a time being. And one can't migrate between johnny@example.edu and john@example.org. That's how inflexible this protocol is, compared with a simple keypair.

lifeisstillgood 14y ago

This just beats OpenID hands down. And I will be very interested to see how fast Google et al support it. I think they may be a bit evil.

lazyjones 14y ago

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.

dochtman 14y ago
None of these have to go through Mozilla if you don't want them to. You can host your own copy of the JavaScript shim and setup your own identity provider to authenticate against and it will Just Work.
jerf 14y ago
Mozilla has the only implementation at the moment as they are still developing it, but the intention is that any email provider can provide this in the future. They have not written themselves into the spec. In fact they have commented that the more successful this standard is, the less important they become.
- da_n 14y ago
  Commendable goals, but in my opinion somewhat conflicts with the 'Mozilla' prefix in the name, if they hope to make it a widely adopted standard they need to drop their branding and just call it 'Persona'.
  - whatusername 14y ago
    Read the article. The protocol is called BrowserID. The Mozilla service to try and help adoption is called "Mozilla Persona"
masklinn 14y ago
> don't want my e-mail address, password and website usage statistics transferred to Mozilla's servers in the US Isn't the whole point of Persona that... it's not? Or it doesn't have to at least? In fact, two of the main motivations of Persona are 1. decentralized identity provider (so you don't have to rely on Mozilla) and 2. that the identity provider should not know which websites you're using (so whoever you're relying on doesn't have to know you're looking at cat pictures)

csixty4 14y ago

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. 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?

Yoric 14y ago
I am not familiar with CardSpaces, but a considerable difference between OpenID and Persona is a matter of anonymity. With OpenID, your OpenID provider (e.g. Google) can track you as you log to your various accounts. By opposition, with Persona, the Persona provider does not get any meaningful information that can be used to blow your anonymity.
- csixty4 14y ago
  tl;dr - Here's a video demonstration: http://youtu.be/0_6rC025sK0?t=34m16s http://youtu.be/0_6rC025sK0?t=34m16s CardSpace was a Microsoft project led by Kim Cameron, the godfather of digital identity. They originally wanted to make it part of Windows Vista, but it was dropped for lack of interest. It was an open standard, and there were browser plugins to make it work in other browsers and operating systems. Microsoft knew they couldn't make it a Windows-only thing if they wanted people adopting it. They just wanted to be at the forefront of security for once. A developer would add meta tags to a site's login page with a URL to post identity info to and a list of information it's requesting. That would trigger the browser (or plugin) to open a modal display of identity "cards", which the user could choose from. Then it would show what information the site requested and they could deny individual pieces of info. The data would be posted back to the site, along with a unique signature for that user & site. Cards could be self-issued or issued by a third party, like your employer or bank. They could have graphical backgrounds applied so they looked more like ID cards or credit cards. It was a great UI for identity, and easy for developers to use. But I think the Microsoft name tarnished it. I know people outside the identity community were making comments about how this was Microsoft's attempt to become Big Brother & so forth, even though Microsoft was completely out of the communication loop between the user and the site.

GregWright 14y ago

I would love to use this, but apps I work on are both web browser based and native clients. Persona does not yet work with native apps (Android, iOS native apps); it only supports browser based auth right now. 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. :-)

deleted 14y ago

[deleted]

alter8 14y ago

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. 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?

romaniv 14y ago
Password/hash thefts have been happening for as long as there have been systems with passwords. What changed recently is that we now have centralized services with huge numbers of important accounts. There are more service with large number of accounts and more services that affect multiple aspects of your digital life. When someone steals hashes from those, the press and people are more likely to notice. I think most people overemphasize the importance of the particular authentication scheme used and overlook the problems created by extreme centralization of stuff.
ecaron 14y ago
> Will Mozilla provide native support or an extension? They have a working native support - http://www.soeren-hentzschel.at/mozilla/persona/2011/07/15/mozilla-stellt-browserid-vor/ http://www.soeren-hentzschel.at/mozilla/persona/2011/07/15/m... - and expect it to see it natively in probably ~17. Their biggest push is for WebKit to adopt a similar solution based off the same tech.

ecaron 14y ago

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: * Logo is ambiguous and looks like a generic button * "Mozilla" in the name instantly steers away other browsers We've implemented it on LinkUp (https://www.linkup.com/account/ https://www.linkup.com/account/), 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.

ncri 14y ago
I just tried to login into your site without being registered with Persona. All works fine, I can choose a password, and receive an email with confirmation link. When I click it I see an info box from Persona, but after only 3 seconds or so I get redirected to your site - so that is buggy. I see then a notice that your site couldn't log me in, which is fine, as I don't have an account. However, your site then starts to log me in over and over again. Which seems an issue on your site. Hope this info helps. I'm using chrome on OS X.
- ecaron 14y ago
  Thank you so much for the thorough details. I squashed this bug. Can you ping me at eric@linkup.com so I can send you a Starbucks giftcard for your help?
stickfigure 14y ago
There is a really easy way to explain Persona to users: "Sign in with your email address" At Voost (https://www.voo.st/ https://www.voo.st/) we have been using BrowserID since launch earlier this year. We just use this simple phrase and users "get it" right away. There's no need for complicated branding.
- ecaron 14y ago
  Except this would only work if you: 1) Forced all users in your system, who already had email/password based accounts, to abandon their existing accounts and adopt Persona 2) Became fluent in quickly explaining to users how to reset their Persona password when they forget it 3) Don't mind losing all the users who say "I trust you, but not this company I haven't heard of before." Some users, especially jobseekers, won't let their circle of trust grow - and forcing adoption of a 3rd party causes abandonment. But so does a complicated sign-in process, so you just need to figure out if group A or group B is larger because you can't make everyone happy.

leetreveil 14y ago

I like the implementation but I don't like that it has a brand (Mozilla) attached to it. Stripe is doing this right, when you make a payment on a website you have no idea that you're using Stripe.

shardling 14y ago
I won't put credit card details into a site unless I have some trust in the system they're using. The lack of a brand isn't necessarily a good thing here. In any case, the brand is for marketing to developers right now -- once "Persona" becomes a thing in and of itself, this will be a nonissue.

peterwwillis 14y ago

tl;dr Uses an e-mail address to make public key crypto easier. Sounds nice. Unfortunately, most people fuck up PKI and now we're relying on a third party (Mozilla) to authenticate all our logins. 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)

JackC 14y ago
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. So the goal is basically: I have a computer at work, a computer at home, a computer in my pocket, and a computer I just borrowed to check something at a friend's house. I want to be able to go to the same random site on all four devices and have it recognize that I am the same person, without (1) remembering a special password for that site, or (2) trusting that site in any way. So there are two ways to do that. One involves generating a certificate on one of my devices and somehow communicating it to the others without a central authority. The other involves a central authority that each device can communicate with. The first way will be, let's say, extremely challenging to get working reliably across all devices and platforms in a way that average users can handle. So Mozilla went with an extremely flexible version of the second way. It goes like this: users remember a Username and URL, in the form Username@URL. They also remember a Password which is only shared with URL. When I want to identify myself to that random website on any of my four devices, Mozilla helps me get a verifiable statement from URL to send to the random website that I am Username@URL. There are two things mixed in to make it more likely this will take off. First, users are already used to remembering Username@Url / Password credentials, so they don't have to learn anything new to identify this way. And second, because existing Username@Url identities are email addresses, Mozilla can offer an intermediate identification service based on the ability to receive email, until other identity servers come online. TL;DR: By using an intermediate ID server and credentials that look like email addresses, Mozilla has created a path to cross-device, cross-platform user ID that solves the problems of user adoption, technical adoption, and independence -- it can be implemented in existing browsers, understood by existing users, and offers a clean transition to completely decentralized identification. Very cool.

po 14y ago

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'.

hackerboos 14y ago

Persona - An identity system by Mozilla Personas - Skins for the Firefox Web Browser This is an issue that needs to be resolved.

ecaron 14y ago
They've resolved it in planning (http://www.ghacks.net/2012/03/02/mozilla-personas-renamed-to-background-themes/ http://www.ghacks.net/2012/03/02/mozilla-personas-renamed-to...), but the implementation just hasn't been completed. Yet. "To sum it up: * BrowserID renamed to Mozilla Persona * Personas renamed to Background Themes * Themes are now Complete Themes"
- petitmiam 14y ago
  Background Themes/Complete Themes - sounds like they just created a new problem. Throwing the word 'theme' in there for backgrounds is just asking for confusion. I think most people understand Wallpapers (Backgrounds) / Themes.

mtgx 14y ago

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. 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.

gwillen 14y ago

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. 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.

StavrosK 14y ago
Just use <somethinghere>@mockmyid.com. It doesn't even ask for a password. I don't think it would be too much work to create a Persona service like 33mail.com, which provides your own domain for email and authentication. That way, you would enter "myaddress@domain.33mail.com", the site would send you there for auth, 33mail would reply that you are logged in to your account (if you were, obviously), and that'd be all.

Perceptes 14y ago

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.

eddieroger 14y ago

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.

wccrawford 14y ago

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. 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?

takluyver 14y ago
As I understand it, you're identified to the site by an email address. So if GMail becomes an ID provider, you keep using the same identity, but with Google confirming it rather than Mozilla. I'm by no means an expert, though.
- callahad 14y ago
  Exactly -- your provider's domain is always checked first. Mozilla only steps in as a fallback, and accounts can/will be transparently "upgraded" when a domain adds native support.
- jarofgreen 14y ago
  I am also by no means an expert but that is also my understanding. What would change tho is the login procedure. Where once the user saw a Persona login box, suddenly they will see a Gmail login box. That has the potential to be really confusing unless handled well, no?
- wccrawford 14y ago
  Okay, so there's no token being passed? If someone manages to spoof the system, they could be anyone and just accept my access request? I haven't thought it all through, but it feels like there's a weakness there that's just waiting to be exploited.
  - takluyver 14y ago
    I think there is a token being passed, but it's authentication, not identity. It's a signed declaration that you own that identity, and it must be either from the domain that issued it, or another source that the site you're visiting specifically trusts (i.e. Mozilla, at present). I trust Mozilla to have done a good job of this. If there's a weakness, it's not going to be anything so obvious that you can see it from my stumbling attempts to describe the protocol. If it sounds like there is, I'm probably describing it wrong. Have a look at the details here: http://lloyd.io/how-browserid-works http://lloyd.io/how-browserid-works

dreamdu5t 14y ago

Chrome, IE, and Opera need to natively incorporate browserid ASAP. Please, put your egos away and get this done for the sake of everyone who uses the web.

latchkey 14y ago

I really want to see HN adopt Persona.

shardling 14y ago
I'm a big fan of how they used to support OpenID but quietly dropped it, locking me out of my original account. No, wait, that was terrible!

ernesth 14y ago

> OpenID uses URLs as identities. True, the fact that URLs identify them confuses some people. However, http:// http:// being usually superfluous, I don't see why roger.example.com is more confusing than roger@example.com. > 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. And openId provides an email if the site asks for it. > OpenID is a jarring login process. The difference is that the provider page is a full page rather than a popup? > Both OpenID and oAuth allow your identity provider (be it Google, Facebook, Twitter) to track every website you sign in to. 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? > oAuth is complicated for developers to implement [...] several versions of the protocol, [...] 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

saraid216 14y ago
> True, the fact that URLs identify them confuses some people. However, http:// http:// being usually superfluous, I don't see why roger.example.com is more confusing than roger@example.com. Because "roger.example.com" is a webpage, whereas "roger@example.com" is an addressbook entry. Very occasionally, "roger.example.com" is a blog or personal webpage and thus probably refers to a single person. Maybe.
- Arelius 14y ago
  additionally, it may be example.com/roger or example.com/openid/roger, the regularity of it is small, and people already know what their email addresses are.
zerostar07 14y ago
The big advantage is that users won't have to be 'trained' for anything new: they are all familiar with email / password signups. It's pretty obvious that the website will use your email so no privacy surprises. Switching between email identities is a snap. It's actually pretty pragmatic approach given that what most people do is first assess the website risk, choose whether to give their primary or secondary email (but wait which one? i have 5), type it in (what if they mistype / remember the wrong one) and then type one of their 3-4 rememberable passwords. If anything, browserID neatly simplifies the authentication process for the user. Also, developers only have an assertion to send; that's really really simple and less likely to break in future releases. Easier signups are important especially for small web utilities that just need a unique identifier and not much private information to work.

mightytightywty 14y ago

Tying email addresses to a user's identity is a terrible idea. - 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. - I use a unique email address for every site that needs one. - What if I want to start using a new email address?

Arelius 14y ago
I wouldn't actually say it's a terrible idea, for 99% of users it should work better, faster, and easier for them, since -very- few people have the same habits as you. However, having said that, I do otherwise agree with you, I also don't want to give my email out to all of them, and when I do, it may be one of a few address, depending on how much I trust them, or care about the responses. I'm given very little option in that regard.
- nicolasp 14y ago
  > it may be one of a few address, depending on how much I trust them, or care about the responses. I'm given very little option in that regard. You are given the choice of which email address you want to use to log in. Isn't that exactly what you want?
brendn 14y ago
I'm curious about that issue, too. Here's a brainstorm: - An independent Identity Provider (IdP) uses some means of identification for the user (two-factor, iris scan, whatever) - The IdP provides an anonymized email address to each site that the user logs into. I'll have to read the spec a bit more to see if that's possible...
- callahad 14y ago
  It's hard to do completely cleanly -- building an independent IdP that uses iris scanning or other two-factor systems is totally possible, and actually relatively easy. Providing anonymized addresses is harder, since your IdP wouldn't be contacted until after the user has selected an address. In that case, you'd want a browser extension that generated addresses conforming to some scheme @youridp.com and automatically filled or selected them in the dialog when using Persona. Totally doable, but that part requires getting out in front of the call to navigator.id.request.

jellicle 14y ago

A well-crafted solution desperately in search of a problem to solve.

nine_k 14y ago
If registering at yet another site (forum, online store, government site, etc) and remembering the password when you get back to it 2-3 month after is not a problem for you, I admire your memory. Or maybe you're not visiting these types of sites as much as I do.
- Revisor 14y ago
  Another solution to this is a password manager, eg Keepass. It still centralizes your identity under one roof, in the encrypted DB, but only locally.
  - LeonidasXIV 14y ago
    But the overhead is much larger and let's be honest, this solution is only used by a tiny minority of (mostly tech) users. Mozilla Persona could be used by everybody because for the end user it is exactly as complex/easy as it is currently or even easier.
  - callahad 14y ago
    Password managers are necessary, but they're not enough. So long as there's an underlying password for every damn site you visit, then every damn site still has to store passwords securely and you have to maintain things when that site gets breached. Not to mention the stability of that password. If it gets sniffed once, it's possibly game over for months. If a Persona assertion gets sniffed in transit, it's only good for a few minutes in time.
- luke_s 14y ago
  Or perhaps he is just doing what everybody _really_ does, which is to use the same username and password for every random site on the net and hope like hell they are not storing passwords in plantext. A hope, which has been dashed time and time again by bitter reality. It seems the only people lazier about password security than the actual end users, is the site owners ...

xyzzy123 14y ago

Some thoughts from a privacy perspective: 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. 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. 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. In this case, the email address (and equivalently the public key the browser holds for that email address) can be correlated between sites. 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: 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...) 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. A few other points: * 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. * 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. * 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). * 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.

drdaeman 14y ago

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." In BrowserID they do 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. OpenID was heavily 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 most of the same problems. 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.