Mozilla Persona

» see persona.org as it lived, on the wayback machine

~ the obituary ~

i missed persona. by the time i would have configured it as an identity option on anything i was building or signing into, the web had already settled on sign-in-with-google or sign-in-with-facebook as the default for any site that did not want to do its own password storage. persona was sitting in the mozilla labs side of things with a privacy story i would have cared about in principle but a button i never actually saw on a login page i used. i remember reading the launch announcement on hacker news in summer '11 and filing it away as a "good idea, will probably take" thing that turned out to be a "good idea, will probably not take" thing.

mozilla launched the system in july 2011 under the name browserid. the design was clean. an email address was the identifier. your email provider issued a cryptographic assertion that you owned the address, and a relying site verified that assertion against your provider's public key without the provider learning which site asked. the comparison the announcement made was to ssl client certificates, but with a workflow that did not require people to handle a certificate file. you typed your email, did a one-time verification, and from then on every persona-enabled site could log you in by asking your browser to hand it an assertion.

the team renamed browserid to persona in 2012 because the project had outgrown the working title and mozilla wanted a real brand on it. dan mills ran the early effort, ben adida did the identity protocol work. the foundation operated persona.org as a fallback identity provider so people whose email providers had not implemented the protocol could still use the system. that fallback was supposed to be temporary while the email providers themselves rolled out support. they mostly did not. gmail and outlook.com both stayed on their own oauth flows, which were the two providers persona most needed.

the practical result was that persona was a mozilla-operated identity service trying to look like a decentralized one. that gap between the spec and the deployment drained the momentum. by march 2014 mozilla pulled the full-time engineers off persona and moved the project to community ownership, which in mozilla labs language means "we are not actively investing anymore, the open-source community can carry it if they want." the community did not, much. the persona.org service kept running for another two years on minimal maintenance, then mozilla announced the formal shutdown january 12 2016 and turned the servers off november 30 of that year.

~ the case file ~

~ what it was ~

the technical design was sound in a way the deployment never matched. browserid used cryptographic assertions where your browser asked your email provider to sign a short token saying "the user controls this email at this time," then handed that token to whatever site you were signing into. the relying site verified the signature against your provider's published key. the provider never saw which site got the assertion, the site only saw an email and a valid signature. for anyone who had read the early openid privacy critiques about identity providers becoming surveillance points, the design solved exactly that problem.

the login flow itself was a popup window. you clicked a button that said "sign in with your email," the popup asked you to type your email and verify it once if it was a new persona, and from then on you got a clean two-click flow on any persona site. the ergonomics were not better than oauth, they were comparable. the win was the privacy property under the hood that most users were not going to evaluate.

~ the slide ~

the cracks were visible by 2013. the email providers persona needed for the decentralized model were not interested in implementing it. without provider support, the persona.org fallback identity service had to handle the email-verification flow for almost every user, which made persona a federated identity provider operationally even while the spec said it was not. that was not a fatal bug but it was the kind of thing that bleeds momentum from a project trying to convince sites to integrate.

the cracks on the relying-party side were just as bad. asking a site operator to add yet another sign-in button to their login page is hard, especially when the button has lower user recognition than google or facebook. the sites that did integrate persona were small or developer-focused: ting on the mobile side and the times crossword on the games side, neither one big enough to move the needle for the protocol.

~ what carried over ~

the persona.org shutdown november 30 2016 ended the running service. the spec lived on as an open document and the source code stayed on github, but with no operator running an identity provider on the persona.org domain, the protocol was effectively dead. the sites that had integrated persona had to migrate their login flows to oauth or roll their own email-and-password systems in the months before the shutdown date.

the inheritance is mostly in the privacy-conscious authentication ideas persona was an early implementation of. webauthn ended up as the dominant browser-native authentication primitive a few years later. it solves a different problem, hardware-backed credentials rather than email-based assertions. but it inherits the same instinct, that the browser should be a participant in the login flow rather than passing the user through to a third-party identity provider. persona was one of the projects that made that argument concretely enough for the standards bodies to listen.

@}-->--

              )
             (_)
            .-'-.
            |   |
            |   |
            |   |
            |   |
          __|   |__   .-.
       .-'  |   |  `-:   :
      :     `---'     :-'
       `-._       _.-'
           '""""""

« previous  ·  random  ·  next »