I'm very sad to see this announcement. I've been a big fan of persona since I first learned about it three years ago, and for a few months I tilted at windmills by writing to services I used, and asking them why they didn't support persona login.
After writing about four of these, though, I had a small epiphany; this is a ludicrously uphill battle, because Facebook and Google don't just make it easy to use their login because they're nice; the information that they gather from these logins is worth good money to them, and so of course facebook+google login is the most frictionless and butter-easy way to implement login.
Sigh.
Okay, I know this was totally obvious to everyone but me, but it does make me sad, and I can start to see the outlines of an internet that I'm somewhat less excited about than the one we have now.
I'll miss you, persona. Mozilla, keep up the good fight!
I was an early adopter of OpenID and still lament the loss. I'm familiar enough with Persona and IdP's that I could probably fork I'm flirting with the idea of offering LTS out-of-pocket as a public service if there is enough backing [e.g. demand by the geek community. Decentralized authentication is important and I feel strongly enough to engineer for free and/or offer corporate support through my corporation for Persona and use it to subsidize additional development].
I also am working on offering both a FreeDNS service with DNSsec both as an authoritative server for all end-users (services like GoDaddy mark this, as well as SSL certificates, as a "premium service" and that is sheer insanity; I have made it my personal goal to ruin services like this and "SSL watchers" which charge 20$/mo to ensure your cert doesn't expire). Also don't use OpenDNS, not only do they inject ads, but they break DNS by stripping DNSsec which is both unethical and a violation of the spec. I'll have a blog post up on that later this week.
If you have a web-site, don't have shell access but still want to put a cert up, https://www.sslforfree.com/ use these guys. They'll authenticate your ownership the same way Google Analytics does, then you associate the cert with your domain in the same way you would had you bought it from VeriSign.
[0] https://www.surveymonkey.com/r/VLFM7FD - please fill this out if you have either interest in Persona or that DNS service I mentioned (the latter of which is likely to go up this week, the former depends on demand)
A few people and I have been talking about Persona and possibly developing a next version, we're chatting on https://gitter.im/letsauth/LetsAuth, or #letsauth on Freenode. Feel free to join either, we'd love to brainstorm together.
I like the idea of maybe pursuing a extension-first plan for the next attempt at BrowserID. Some thoughts:
- There have been Persona extensions before for at least Firefox. It will probably be important to learn from them, even if I'm sure hardly anyone tried to use them.
- Edge's extension support can't come soon enough.
- The issue I could see with extensions is it is harder to trust the verified email addresses in "fallback" situations. The chicken and egg bootstrap problem here still seems to indicate that you still want some sort of trusted notary. Maybe a simpler fallback provider that is just a state-less "passwordless" (passwordless.net) proxy that would be easy to clone and some way to create an actively maintained whitelist of trustworthy clones?
- While we're looking at "extension-first", maybe find ways to make use of the browser's SSL client certificate infrastructure? Obviously, if you could build a good UX for bootstrapping (email-only) client certificates you could finally help people make good use of such an old, underutilized browser feature.
Thanks. Note that I tried to write an accurate roadmap based on the discussion, but it was not the only roadmap I could've written – early stage, goals still to define.
> There have been Persona extensions before for at least Firefox. It will probably be important to learn from them, even if I'm sure hardly anyone tried to use them.
With APIs that change arbitrarily, inconsistencies in the different implementations, tokens that expire after a few months for no good reason, I wouldn't exactly describe the social login experience as frictionless and butter-easy.
YMMV though, maybe I'm not approaching the social login from the right angle, I don't know.
I use Persona heavily, with over 300 sites and 50,000+ users depending on it.
The saving grace here is that what I hold for users is the email address and that gives me a path to switch to another provider so long as I get an email address back.
In many ways this is a blessing, at least I now know where I stand. No doubt my spare time is going to be used up over the next month or two.
Sorry about that. :( Can I buy you a pint when I'm in London next June?
We tried our best to ensure that there was never any lock-in with Persona, which makes a transition away possible, but not painless.
Now that we have a formal announcement, I'm hopeful that folks on the sidelines will take this as a cue to stop pining and start building. :)
EDIT: To curtail the "I'm in SF/BOS/etc." posts: I'm in Minneapolis. Maybe we should set up a Hangout or similar early next week? If you'd like in on that, subscribe to https://lists.mozilla.org/listinfo/dev-identity and I'll post details there.
If you're in SF I'm here until Friday at the CloudFlare office around the corner from one of the Mozilla offices (are there many?!) - down near 2nd and Townsend.
I wouldn't mind getting a brain dump of how you'd do it differently were you to build it now, as well as my sharing what I'm looking for... perhaps a Persona v2 design could rise from the ashes.
I'm not local (BOS based), but I'd also be interested in having this conversation with both of you. Persona's mission is too important not to continue.
Besides, isn't rising from the ashes what Mozilla does? "And so at last the beast fell and the unbelievers rejoiced. But all was not lost, for from the ash rose a great bird..."
The Persona code suffered from pretty serious feature creep. It's F/OSS, but I'd strongly suggest learning from Persona's design rather than directly re-hosting the code.
Heck, some of the code still dates back to when Node.js was only on version 0.4.5. :)
Maybe the persona team had better things to do than updating the codebase to each and every node.js release. It looks like node.js will become the new state of the art for crap web platform after PHP over some CGI. It's design changes a lot on a quick cadence, the community is based on coolness and fashion, its users and developers are mostly non-professional, inexperienced persons, and its use of the IO model is obsessive and single-minded.
Node has come a long way, and now has a responsible release cadence, including annual LTS releases, each with 30 months of security / critical patch support. The ecosystem is still crazy (especially with the ES6 features showing up in the Node 4.2 LTS), but Node itself seems to have matured nicely.
Persona may have been a bit premature in choosing Node, but we expected to share much of our code between the backend, frontend, and Firefox itself. Node offered a great opportunity to attempt that. Plus, the whole thing started as a side project between two engineers, so why not try out something crazy and new?
Comparing node to PHP is a little unfair.
Node has a great package system, JavaScript is an evolving language that run almost everywhere: in all browsers, server side, in devices.
PHP started as a simplified Perl, is a web page preprocessor that works well in that context: it can be used server side but almost nobody do it.
Having used both, Node's package system is horrific compared to PHP's Composer. Composer's built-in composer.lock system is something NPM sorely needs by default.
It exists (npm shrinkwrap [1]), but it's not enabled by default, and it has some warts, such as non-deterministic sorting of entries.
There's a third-party tool [2] that is supposed to solve many of the issues, but I haven't tried it.
Of course, if you do this, there's a decent chance that if you try installing it again in 6 months, your shrinkwrapped version of at least one of the dependencies won't be available any more...
Biggest wart I've encountered is I've got a package that installs fsevents (OSX-only) as one of its optional dependencies. When I shrinkwrap and attempt to install on a Linux server, that optional dependency is treated as a required one, and it can't install. I have to manually zap it from the JSON. :-/
One wonders, why shouldn't it be 'npm lock'... I'm not that into plastic packaging, and not a native speaker, so shrinkwrap gives me as much clue about what the command does as blinktap, or pricklywarp.
I disagree. I think node is unlike anything we've seen thus far. It's not php, it's not python and it's not ruby.
I, literally, cannot rebuild my application from a year and a half ago that is standard node + npm. The deps are broken...the code won't build with node-gyp...i mean node-waf...i mean who knows? What a mess and a HUGE regret.
> I, literally, cannot rebuild my application from a year and a half ago... The deps are broken...
Welcome to the Cloud Future Web 3.0, where every library you use is maintained like some random guy's personal homepage, and his robots.txt prevents you from caching a stable copy.
I don't understand this argument. If you know what parts of your site the deps will effect it should be trivial to update them incrementally and rollback the commit if one unexpectedly breaks your code.
Besides, there's no universal unwritten rule stating that you have to use the bleeding edge version of every dependency.
Keeping all dependencies up-to-date is mostly in the interest of widely used libraries not one-off applications.
Not sure what the OP's problem was, but I've had issues with old libraries where some dependencies have been removed from npmjs.com. It's totally ridiculous.
I solve such problem for our clients by packaging every dependency we use in project as independent RPM package, so whole application can be installed using single "yum install ..." command from local repository without need to connect to internet. It allows us to precisely control version of libraries we use and also allows to apply patches to them when a problem is found.
So it's not immutable? Blinkin' egg, I'm happy I only played with node.js now. On the other hand, I guess it's always better to vendor one's deps, at least those that are not packaged by the operating systems. The language specific package managers add a lot of complexity.
I went as far as pulling the node_modules directory from production and perfectly matching the node version on my local machine. Linux -> linux and the app won't run locally. I think it's because the node-gyp influenced deps need to be built locally and linked to the right libs.
I then spent a few hours downgrading each version to isolate the issue...found a few libraries that were hard-deprecated (which was nice), found some breaking changes in the node version I'm using and then I just gave up.
Sure, but--as the traditional rant (http://blog.codinghorror.com/the-php-singularity/) goes--it works like a claw hammer with two claws and no face: sure, you can turn it sideways and drive nails with the middle part, but wouldn't it be easier to just get a hammer?
Rails is a hammer with a normal head but no claw. Hammering nails in is the more common case, but if you need to do both you're better off with the two-clawed one.
The only people that say this kind of shit are the ones that don't use node. There are many large companies using node in production. Most community members I've interacted with are professional devs.
> The only people that say this kind of shit [...]
You do not even know how to interact with people like a proper adult. There are many companies, large or small, using PHP. Many popular blogs run on moveable type, that's Perl 5. Many companies run on Microsoft technology. And some popular websites run partially or wholly on Node.js. So what? Should I make my technology decisions with a « jump on the most brightly coloured bandwagon » approach? Node.js is a toy. A cheap chinese one.
But then I've taken on the maintenance and security of a system that I am not familiar with the internal workings of. That seems riskier than finding an alternative.
True. But, if persona has a large and active open source community, it might be better to use that than maintain homegrown solution in the hope of "security by obscurity".
There are some strong auth/auth open source communities - https://github.com/Jasig that serve millions of users.
The community will never be able to implement BrowserID in the browser without Mozilla's permission. This is the missing piece that would have made BrowserID awesome, without it, there's little point, you might as well use Google/Facebook/Twitter log-in.
I am not aware of anyone ever trying to implement it. There is not even a plugin from what I know. If someone would integrate the UI in a plugin, that works and people use it, I would be surprised if Mozilla would not accept a proper Patch to Firefox implementing that.
The proposed UI was not blocking anything, not even taking space.
It was incredibly easy to implement compared to other options and didn't require giving up a lifes worth of personal information to do so. I do believe that efforts like you are implying and others will push this forward to something that people will adopt.
What gets me is that even in this announcement, they place the blame on the community "due to low, declining usage", instead of owning up to the fact that they never implemented BrowserID in Firefox (desktop) as envisioned. With no carrot, why would they expect sites to jump on board?
That always depends on the market. While Chrome leads the US market like IE used to, Firefox is for example the most-used browser in Germany. Maybe it would have been a valuable approach for Mozilla to work with a specific market when introducing Persona, e.g. the big German webmail providers.
What if there was a way to "spin out" Persona from Mozilla? How many devs and how many resources would it take for a bare-bones Persona Foundation to get the job done?
Though this may sound harsh, the fact is Mozilla is abandoning projects left, right and center. From Thunderbird to Firefox OS and now Persona.
So why should anyone in their right senses bet on a Mozilla project in a serious way?
They have put themselves in a catch 22 situation. Abandoning projects because "people are not using them" and people will not use them because Mozilla abandons projects.
Interestingly, most of these abandoned projects were promising but I cannot recollect Mozilla ever changing course as a result of feedback given when they launched a project.
All companies do this. Google does it too. Facebook abandoned their login system for embedded systems, leaving some of us working in the digital TV sector up shit creek without a paddle. Look at what happened to the Twitter ecosystem as it locked its API down.
Bet on any third party service in a serious way and you are taking on risk that you cannot control. That's a fact of life.
frequency would be number of projects (with a certain amount of uptake) started divided by number abandoned.
That list isn't so simple. Accelerator isn't software/service, refine became open-refine, and wasn't a service. Wave didn't seem to get a great deal of uptake (I think), and is somewhat superseded by google+ in-chat. I'm not sure how checkout differs from wallet. etc.
So in those case, there is a marked difference as compared to, for example, when google discontinued reader.
I also wonder how many of these projects are abandoned in name, but not in copebase? Google+ probably rebrands some of those, with a slightly different mission statement (new feature, rather than standalone product).
That said, I do dislike some of the focus on social-media. The facebook effect, I guess... We probably need more protection from it...
I think the problem is that when a big brand like Mozilla back a project, everyone else in the community not directly involved with Mozilla sits back and waits for something to happen. Everyone assumes that "Mozilla" will do the work and that a project will magically appear, be maintained and continue to grow needed features, except for perhaps the odd drive-by contribution.
In fact, the opposite needs to happen. For a project to grow, it needs to attract core contributors, not repel them. This is especially true if the project's core contributors don't have an obvious business model to help pay for their time.
There's always a risk of abandonment, no matter the vendor. A more important question is what sort of lock-in you're facing. What are you left with if the project fails?
Mozilla tries its damnedest to avoid locking people in, and promoting open, standardized solutions.
Persona provided verified email addresses for your users, so there was no intrinsic barrier to migrating off of Persona and to, say, a traditional email + password login scheme. With Firefox OS, building an awesome FxOS experience was synonymous with building a great mobile web experience, because the foundation was in open, standard technologies. Even if FxOS went away, you're left with something great that works in other browsers.
Persona and Diaspora* are two projects the free-software/open-source community should have gotten behind in a very serious way. Myself included. These are two projects I've felt very pulled towards in the sense that I _ought_ to contribute, I _ought_ to help out because that's the kind of world I want to build because that's the kind of world I want to live in.
This shit is _important_.
GNU gave us the tool-chain, Linus+co. (and BSD!) gave us the kernel, Mozilla gave us the web client, Apace gave us the web server and so much more. For a few years there I thought that FOSS had delivered the software world I could live in.
But then came the era of the internet and my data and identity in the cloud. And tracking. And surveillance. And social everything. And why? Because of shiny pretty interfaces and convenience and humans being human.
Surely this is our `Stallman and the printer' moment for our generation. I know the FSF and EFF and others do a great job. But we're losing these battles.
I think the hard part about this current iteration is that, say, with GNU C there's the C language standard, with Linux there's UNIX. There's something you can strive to be compatible with. Where is the online identity management standard? There is none, because that's the whole point. Same with social.
These corporations are behemoths. Facebook/Twitter/Google/Microsoft, the list goes on and on. Before it was really just Microsoft on the desktop and a load of ageing UNIX vendors -- we've never seen the like of these new businesses. This is a sector that briefly had the most valuable corporation on the planet. This is an immense task. But it's doable. FOSS has won the server wars, has a viable desktop, has transitioned to mobile. But identity and social, you know, the stuff that makes us human, not so much.
I'd be soo happy if that announcement would reign in a new chapter for persona, one in which a new project is formed that continues to develop it, and gets ready in time to replace persona.org. Without all those websites, including mine, having to replace persona with something else.
Browserid was launched right when I was learning about loginsystems, and it was so nice to use it instead of fighting with hashes or certificates. I still think that it is the right idea, persona should not die.
Honestly, I almost want someone to fork Persona and keep it alive. Persona is at least a real service that people know how to integrate that has a solid concept. The yet-to-be-invented-hypothetically-better potential successor doesn't have that.
https://persowna.net/ it's still alive, no need to fork. It's going to suffer the same problem as OpenID though. I.e., with no big vendor behind it, you have even less of a chance of having hitting that 'critical mass' point where people will integrate it into their applications.
Right now there's a very, VERY good standard made by OASIS (standards body on par with IEEE/ISO/W3C)- SAML, which with a YubiKey[4] and a cell phone app for managing permissions gives you a really nice setup. The flow is basically plug-in your YubiKey off your key-chain, then authenticate once when you log-in at the start of the day, anything that implements SAML will now give you a SSO (similar to AD/LDAP) but it's two tokened with a focus of ease of use for Joe Blow (as simple as a Push notification to your phone (authentication comparment #3) saying "App Foo is asking for permission for you to log in. <Slide left/right for approve/deny> while giving you granular control for the power user. Again, chicken egg adoption problem, but its the most elegant I've seen.
I implemented a SAML2 IDP once when I worked at a University using Shibboleth (as both the IDP and SP).
SAML2 has a lot of heavy usage in academia or between industry systems. That being said, there were a lot of exceptions and rules that needed to be put into place for the plethora of broken SAML2 implementations. Some needed an attribute in two scopes, others had trouble with certain OIDs, etc. The Shibboleth mailing list is filled with things like, "oh if you're trying to connect to someone using Oracle SSO, add x y and z because their stuff is hopelessly broken."
I mean for the most part, it did just work. I see it as great when you want to build trust relationships, but in the general case, I think OpenID was simpler and better.
I still run my own OpenID. It gets me into ... StackExchange. It no longer works with Slashdot, gitorious, freecode and many other sites that have either stopped supporting it or gone under. Oh wait, it works with OpenStreetMaps too.
Yeah, my experience is precisely the same re: OpenID.
Is that SAML2 IdP code open?
Things have..slowly... improved within the SAML2 ecosystem, but if you've found a better alternative (SSO for the average Joe - preferably with 2FA a la YubiKey) let me know.
SimpleSAMLphp is quite straightforward; use the Yubikey auth source and you get their 2FA very easily. SAML2 will never be quite as easy to configure as OpenID in practice, but it's the least painful setup I've seen. (Yes, I include several of the big commercial authentication-as-a-service vendors in that comparison.)
Having the ability to easily manipulate attributes at a per-SP level makes integrating with semi-broken vendor implementations much more practical. There are modules available to add OpenID and OAuth; I use the OpenID module in production and have been quite happy with it.
As an example, I setup an NTP server a while back and found they used Bitcard.org as an authentication manager. I've been using it for years now and aside from the note on their website about running much of Perl.org, I've never heard of it being used anywhere else.
It's probably a reasonable service but I'd never implement it on my website because I know I'd be telling customers to go off and setup a Bitcard account, which they would have never heard of.
Core open protocols behind the Internet that we have today took years of development and refinements. It seems that in the current model, where projects are expected to be widely adopted within a short period of time, the development of such protocols is hindered.
With all the dollars pouring into Internet companies, we are unable to develop open protocols for crucial services, like verifying an email of a user, or having an encrypted connection to a server without the server owner paying x$/year for a certificate.
Thats because the core was laid either in academia or via military funding, both places that do not expect quarterly earnings to rise by 2% continually (or at least didn't, dunno about MBA driven academia these days).
Frankly barely anyone cared about the net until the dot-com boom made the web "shiny".
So I wasn't 100% sure what Persona was (why read the article, right?) and decided to Google for it…
Turns out neither the Mozilla Persona main page nor the developer docs linked therefrom mention this timeline. Shouldn't there be a huge banner at the top warning visitors that maybe starting a new project using this tech is a bad idea? Or at least some sort of link to this post?
What would a new Persona project need to do? I see three things:
0. Provide a drop-in replacement for persona.org, making it unnecessary to migrate to another loginsystem.
1. Rework the Persona code, so that it becomes possible and easy to selfhost it, also outside of the new project. All the feature-creep stuff callahad was mentioning should be purged.
2. Work on the browser integration. It would already be great if sites could specify in a meta-tag in the head "login via persona supported" and the browser would show a login UI, even if in the background nothing changes. Even if it would just load the JS and UI currently loaded, but from the plugin instead from the server, this would at least speed things up and be a good starting point.
3. Try to keep the gmail integration, extend it to other mail providers (I'm not sure about the current situation there).
What am I missing? I'm sure there is more, and it would be a big project already.
If you believe in the mission behind Persona—identities controlled by users, not social network silos—then come help us rebuild Persona on top of blockchains. Blockchains never shut down, and you'll be able to keep your identity even if you change email addresses.
Yes, they do. See this long list of failed altcoins.[1]
Minor cryptocurrencies can fail in some unexpected ways.[2] The classic 51% attack has happened in practice to several altcoins.[3] There's also a "burst mining" attack, which can happen automatically - a big mining pool's control system determines that it would be profitable to divert the pool to briefly mining some altcoins and get all the blocks for a while. Then the difficulty goes way up, and the big pool goes off to do something else. Now the difficulty is so high that no blocks get mined at all for a considerable period of time and transactions stall.
Also, guys, please do research before starting new projects. There are already MULTIPLE identity verification services out there specifically designed to use blockchains. By all means, work on new projects, but if there are formal standards out there, make your implementation 1) interact with those seamlessly, and 2) consider long and hard as to what you're bringing to the table over existing, more mature projects. It's counter-intuitive, but actually developing nothing is better for decentralization than developing a competing project w/r/t user adoption and community fracture.
https://okturtles.com/ is the most successful of them so far. I am not a crypto expert (even less of a blockchain expert) but the code looks pretty good, and the ecosystem is pretty mature.
It has 1) its own aux. DNS service which is tied to your key (somewhat like Tor routing via onion but with acceptable latency), 2) decentralized IdP via block chains, 3) a browser plugin, 4) a whole lot more (see the Github linked below.
Update
I’ve written a more-up-to-date technical overview of okTurtles, DNSChain, and Unblock.us. While the security model for DNSChain has improved, they are still misrepresenting the security parameters of their software.
I’m going to leave this up since it debunks what DNSChain was selling. I also think their resistance to outside security concerns is very troubling.
TL;DR
DNSChain erroneous claims to have passed a “peer review” process. However, its most important peers, Namecoin developers, have rejected it. This has been the reaction of every Namecoin developer who has evaluated the project (over four at this point). The project misrepresents its security model, its design is unfixable, it should not be used in any nonlocal capacity.
Can you please comment here (or set up a webpage anywhere), explaining the overall ideas and proposals?
If your idea of user-controlled identities is truly about something that users do possess (not just being provided), and you have any plan how to bring it to the world (without for users to need to install any software — that'd utterly fail — or do anything much besides clicking "log in as myself") — then I'm all for it.
___
¹) Although I do believe Persona screwed it badly, as identities weren't controlled by users there, but merely leased to them by third parties - I find the concept of "identity provider" to be very wrong.
Your identity will be a program on the Ethereum blockchain. That program has an address that will be the unique key for your identity. That program will indicate which keys can act on its behalf, and will provide a mechanism to revoke keys and recover the identity if your keys are lost.
Users will have to install something because browsers have no key signing mechanism. If you manage keys in a web page, that web page can access your keys. You'll need an extension or an app to manage keys for you.
This approach sounds like a stretch, right? No website is going to use an authentication mechanism that requires a separate install. If that were the initial use case for this, I would agree. The real use for these identities is within decentralized applications. These apps don't run on servers and don't force you to use middlemen when you interact with other people. Decentralized apps don't shut down. They don't care where you live. They connect you with other people on the planet that want to connect with you to trade, communicate, or interact in any way you want. The two of you choose your own rules, not those of the companies or governments that stand between you.
This is not a replacement for Persona, OpenID or "Log in with Google/Facebook/Twitter" buttons, which was what I hoped to see. And I'm not even sure how this is better than my PGP keypair (which is something way more widely recognized than Ethereum).
Is there any skilled and powerful necromancer out there that can revive and reanimate W3C WebID committee?
I controlled my persona identity, and I didn't even run my own mail-server; I owned a domain and let someone else run the mail-server, and handled the persona side of things myself.
Well, IANA does. Then, if it's a ccTLD, your NIR (controlled by your government) does. Then the registrar you've registered domain name with does. They all do lease it to you (although legal agreements sort of say you "own" it, it's not a true ownership), but in practice they can take away your identity at any time they see fit or forced to. Or impersonate you, without your consent or even knowledge. I think we've heard about enough domain name seizures to not assume they're something owned. And an identity that can be seized or revoked is something that's just not right.
I really want an identity system without need to trust any third parties to work. I walk in a store, I say "hi", they say "hi", and we're good. Just like it used to be with usernames and passwords, but without obvious issues passwords have. Notaries are absolutely useful, but they should assert identities ("yep, we know this dud, he's cool"), not provide them.
With PGP, key revocation is pretty straightforward: a self-authenticating revocation certificate gets published to the shared PGP database. This certificate could be kept in the clear in my safe deposit box, could be encrypted to a friend's key, could be M-of-N secret shared to N friends' keys, could be maintained by a third-party service that I've decided I trust, etc. As soon as that certificate is published, everyone sees it immediately.
> As soon as that certificate is published, everyone sees it immediately.
PGP key servers can refuse to relay your revocation. Blockchains are censorship-resistant. They also let you define your own authentication, revocation and backup logic.
PGP identities are keys. Blockchain identities are programs.
The censorship-resistance property here doesn't require a blockchain, just a Merkle tree. See the article and discussion here: https://news.ycombinator.com/item?id=10844612 (in particular my comment there).
Specifically, a miner can refuse to encode your transaction just as much as your first PGP server can refuse to accept the sent key. (PGP actually has a strong advantage here, since it's easy to push your revocation to all the servers on your own, immediately, but you yourself are extremely unlikely to mine a block with your own transaction, unless the network is otherwise broken security-wise.) So the primary thing to worry about is a server that refuses to provide information on the revocation, once it has hit the shared database. But that can be solved by just having cryptographic monotonicity, that no transactions can be removed once encoded; you don't need the blockchain's specific power to order transactions and resolve conflicts. And a Merkle tree provides monotonicity. Certificate Transparency works this way.
I agree that the PGP keyserver infrastructure doesn't currently provide this; I'm just asserting that it doesn't take a blockchain to provide it, and there are significant downsides (like waiting for a transaction to commit) to taking that approach.
One thing that a blockchain would provide is the ability to revoke one key in favor of another, and uniquely determine which key supersedes the old. But it's not clear how important that ability is and whether it justifies the tradeoffs of a blockchain approach.
You're right that a Merkle tree is sufficient for censorship resistance when the criteria in your linked comment are met. (I read that comment earlier and enjoyed it!)
So I'm changing my argument: I think key succession is very important and blockchains do it better. When you revoke a PGP key, you have to rebuild your web of trust from scratch, right? The key is your identity, and continuity is hard. With blockchains, a program is your identity. I can trust your new key immediately if the backup process your program encodes has been fulfilled.
PGP keys can't be used to build identities that are as permanent and resilient as state-issued identities. Blockchains can.
How do you publish a public key? Upload it to a server? What happens when that server goes down or someone takes it out? The blockchain can't be taken out.
The problem is that it's still not directly controlled by you, it's controlled by your key. Certain classes of mistake are impossible to fix with no one in charge.
On blockchains, your identity isn't just controlled by your key. It's controlled by a program. That program can grant access to a particular key, but it can also encode a backup mechanism: as long as three of five of your closest friends vouch for you, you can add a new key.
Decentralization doesn't mean no one's in charge. It means you get to choose who's in charge, and there's zero barrier to replacing someone you put in charge.
What sort of programs do you expect people to actually write/use?
This seems sort of like saying, "If you switch to OpenID, you can run your own provider on your own website." Wonderful, but in practice people use some third-party OpenID provider. (A couple people might run a static website with the appropriate link-rel tags, so they keep control of the name but they're still delegating the actual auth work to a third party.)
Is the standard program going to be to grant access to a key + 3-of-5 friends? How do you enroll if you don't yet have 5 friends on the system?
The most popular identity programs in the early days will have no backup or centralized backup. As more people establish identities, decentralized backups will be more feasible.
As the ecosystem iterates on identity programs, we'll converge on secure, reliable, decentralized backups.
Do you know of any identity systems, where identity are controlled by the actual user (not just credential holder), but don't allow any third parties (malicious but trusted notaries, like governments) to hijack or deny it?
I've had a discussion about this, admitted that credentials and identities are different matters, but were unable to remember or think of any sane solution to this problem. :(
For the same reason that they need an entire wiki page to explain how to set it up. The implementation isn't seamless because no one uses it because the implementation isn't seamless because no one uses it...
Seems like it was just a while ago I first heard of persona, and thought that it's a great idea.
Then, I did not hear of it again. Now, this. I have a couple of observations.
Branding this as "Mozilla Persona" makes it look like all the other corporate "one-time" login things out there. Apple ID, Microsoft Live, what have you. I don't need one more account controlled by a corporation. Mozilla looks like a corporation to me (maybe it is not, but it looks like one). I do not automatically trust everything with the Mozilla brand on it.
Adding Persona to a website is not that easy, from the developers' standpoint. I looked at it for a while, and couldn't be bothered. From the server side, it's just so simple to authenticate users with passwords (or access tokens derived thereof). It would be wonderful if the browser could just take care of everything, if all users really need is a way to securely authenticate. Currently, it seems to me like password managers are winning this game.
I'm hoping to see something where password managers are extended with protocols to allow more data and access to be shared to services I really use.
I was using it for years on our sites, IT IS very easy to implement for a developer, especially easier than dealing with oauth oddities from google,facebook,microsoft etc
Yes one can program own username/password etc login, but it is actually alot of work making a proper one with all the edge cases (, password strenght, email validation, verification, account recovery) and so on and so on. I know because I have done it dozens of time and each time the project has slightly different requirements
Mozilla Persona was dead easy to implement on the other hand! Also alot of people did not like and complained about having to login with Google, Facebook etc yet the same people had no issues trusting Mozilla due to the goodwill they built up with firefox and their fight for privacy
Persona is the easiest one I've worked with, including usernames and passwords, because getting that correctly working with the best practices of 2015, even with built-in support in most frameworks, is and will always be a PITA, and heavily dependent on fragile DB schemas specific to a given framework's whims.
I think that usernames and passwords are "easy" is something of a sunk cost fallacy, both for developers and users, and we tend to forget how much time and effort we "waste" on this year over year. My password manager is up to hundreds of different passwords I use, and I know a lot of users these days whose "password" starts with the now ubiquitous "Forgot Password" button (which is its own headache to setup and get right), as they are okay relying on the relative security of their email address over the fragility of their own memory.
Even when using a framework that has username/password authentication already, you have to worry about whether your confirmation emails are getting sent properly and are not blocked. So, no, it's not simple.
> Branding this as "Mozilla Persona" makes it look like all the other corporate "one-time" login things out there. Apple ID, Microsoft Live, what have you
I honestly thought that's what it was so had never considered it when looking at authentication. Whoops.
https://www.sslforfree.com/ Use this and you don't need to have any server alteration. (You authenticate via uploading a FTP file to your site, then SFF.com queries to see if you placed it there, if it exists, you get a cert and install it like you would had you bought it from Verisign.)
Sorry if this is off topic, but I have just tried sslforfree. You let it upload via FTP (or FTPS/SFTP) but the query to check if the file is there is done via HTTP. Why not just validate that the domain is mine if the FTP upload is successful? Or maybe even just redownload the file to see if contents match. I don't get it.
This is another dumb move from Mozilla, putting them further away from being the alternative to giants such as Facebook and Google on the open web.
With time, more and more users are going to wake up to the privacy issues with the current web, and a common login solution that is NOT Google or Facebook is critically important in order to avoid getting tracked online.
Persona should be improved to be a natural fit for Firefox users rather than to be shut down. The demand for common login is there and people pick Facebook and Google today because they dont understand the need for privacy. But sooner or later they will get quite tired of being tracked and want a good alternative. Mozilla should be there for them when they do.
The centralized persona.org service seemed like the weakest link in an otherwise interesting distributed authentication system; persona.org gave people a "transitional" way to associate logins with email addresses rather than federated IDs, but as far as I can tell, nobody ever used anything else. It makes me sad that Mozilla never followed through with the browser integration component of BrowserID.
Consider this for a browser-integrated login system:
- Browsers directly provide an API for sites to say they need to say "this site wants an account".
- When the browser sees such a request from an origin that the user doesn't have an account for, it provides browser UI to create an account and log in. Creating an account creates an origin-specific keypair in the browser and hands the site the public key; logging in uses a challenge-response protocol to prove ownership of the private key.
- When the browser sees such a request from a site the user has an account for, it provides browser UI to log in via the challenge-response protocol; that same browser UI can offer options like "keep me logged in".
- Both Firefox and Chrome have cross-system synchronization systems (e.g. Firefox Accounts/Sync), including to mobile browsers. Use those systems to sync the keypair across browsers controlled by the same user. Perhaps offer options to copy individual keypairs via QR code or similar, for the much smaller set of people who have systems of varying trust levels that should each have access to overlapping subsets of accounts.
- The browser can (at the user's option) provide an email address to a site. The site can (at the site's option) provide an option to register a new key for that email address, as the equivalent of a "lost my password" system but for "lost my computer or browser profile".
This implementation seems quite straightforward. About the only problem I know of that it doesn't solve involves throwaway accounts with memorized passwords used only with private browsing, where people don't want to leave a trace. If people care enough about that case, perhaps offer the option (such as when using private browsing) to compute a key from the origin, the user's email address, and an optional password, and throw it away at the end of the session. (For that matter, browsers could generate a completely transient key, for those times when you want to make a throwaway account that you'll never want access to again unless the site has an email-based recovery option.)
While this system provides some useful properties for highly technical users, it seems quite feasible to present it in an extremely simple manner for novice users.
As far as usability, at least U2F is amazingly frictionless; enrollment is 'put the dongle in and hit the button', login is 'put the dongle in and hit the button.'
Does anyone know of a similar project that I can use as a replacement to Persona? I was very pleased to be able to stop storing passwords and running an auth system and outsource it to a trusted third party whose motivations I trust.
For the moment Passwordless (http://passwordless.net) seems like the next closest option in terms of not storing password systems and keep auth work minimal. It doesn't have the "single sign on" benefits of cross-domain authorization that Persona could have provided and it does still require you to run your own SMTP or SMS connections (as opposed to relying on login.persona.org for that).
It certainly sounds like people are considering alternative providers to login.persona.org if you wanted to keep using Persona/BrowserID, but I'm not sure how well received any of them might be without a good branding stance like Mozilla Persona mostly [1] had.
[1] Arguably it is a failed brand at this point with almost no consumer recognition, but still better than no brand.
Persona has been great and I do hope that we figure out as a community how to move forward, whether to some "v2" or to figuring out how to break the chicken/egg adoption dilemmas.
I've wondered if a mistake with Persona was not trying to push it faster through W3C, WHATWG, OASIS or similar working group as a browser standard. It seems interesting to me that this was clearly a goal for the project (what with using navigator.id and everything) but it doesn't really look like there was much momentum to push this forward into any of the big "web apps standards tracks".
Particularly with the successes in things like Cordova and React Native/NativeScript helping to standardize "app features" like geolocation in browsers, things seem to be heating up in the web-based "apps" arena and maybe there is room there for pushing something like BrowserID as a useful "apps platform feature"...
Hopefully, Firefox Accounts[1] will have delegated authentication[2] available in time for users to do an automatic migration from persona.org before the shutdown.
This story shows how important a decentralized but federated Identity system is. Something we will build into CloudFleet https://cloudfleet.io [Disclaimer: I am one of the founders of CloudFleet]
After writing about four of these, though, I had a small epiphany; this is a ludicrously uphill battle, because Facebook and Google don't just make it easy to use their login because they're nice; the information that they gather from these logins is worth good money to them, and so of course facebook+google login is the most frictionless and butter-easy way to implement login.
Sigh.
Okay, I know this was totally obvious to everyone but me, but it does make me sad, and I can start to see the outlines of an internet that I'm somewhat less excited about than the one we have now.
I'll miss you, persona. Mozilla, keep up the good fight!