I'd highly recommend taking a look at the talk "Designing for Failure" by Dan Callahan, a former Mozilla developer on Persona:
https://www.youtube.com/watch?v=3dDGkLHOldwIn it, he made a very compelling case on exactly why developers within Mozilla considered Persona's design to be fundamentally flawed beyond a point where it was worth expending the effort and resources to promote and pursue further:
Persona had a "intractable point of centralization" designed into the protocol in the form of the fallback relay that defaulted to login.persona.org. Eventually, the browser was supposed to integrate this functionality and act as this relay, and in a perfect world where Persona is standardized and available in every browser, the fallback relay could, in theory, no longer need to exist.
However, the harsh realities of the web platform unfortunately means that day may never come, even if Persona were to become reasonably successful. There will always be a significant portion of users who remain on older browsers that won't necessarily support the newest features, either by ignorance or by necessity, and very few serious web products are going to risk closing themselves off to such a significant potential source of visitors/revenue just to make use of a shiny new browser feature. This is why most web developers' adoption of ES2015+ are limited to those features where transpilers and polyfills are available (see the abyssmal adoption rate of ES6 Proxies, despite longstanding support in latest versions of major browsers, as an example: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...).
This means that Persona would need to have the login.persona.org fallback available and supported indefinitely in order to have any chance of widespread adoption by developers, which brings us back to the point on intractable centralization: Nobody asides from Mozilla can meaningfully host a fallback relay for Persona without having to also fork the Persona community, because Persona was not designed to allow for any possibility of fallback-relay negotiation between the client (the app the user is trying to authenticate with) and server (the server providing the Persona identity) directly, mainly out of the very noble intention to prevent any loss of user privacy that might result from allowing the client to exchange user info with the server directly (the browser or fallback relay was meant to serve also as an additional layer of security and a gatekeeper to confidential user info).
Ultimately, Mozilla had no choice but to become a single point of failure on a critical piece of authentication infrastructure for the internet if Persona were ever to gain widespread adoption, and this certainly didn't fit with Mozilla's vision for an open and decentralized internet. The team eventually realized this, and ended up winding down development and support for the Persona platform at least in a large part because of it, in hopes that other projects would learn from its mistakes and flourish. Unfortunately that hasn't happened yet, and I think it has a bit to do with the fact that the team's learnings got drowned out in a perfect storm of negative publicity in response to their dropping support for Persona. Apparently the concept itself was quite well loved among developers, despite issues in this particular actual implementation, which is really the silver lining here, and is what makes me really optimistic about the future of authentication on the web.
Dan lamented in the video that "if we hadn't been within Mozilla, we wouldn't have been so audacious as to have predicated the design, predicated the decentralization of the system, on the browser natively implementing our protocol... I honestly think this is something that could have been solved in a different way if we weren't a browser vendor. We were blinded by our context."
It's a really poignant point, in my opinion, and I completely agree that the right way to approach a problem like this is to first develop a solution that can stand on its own merits with or without browser support, then proving itself to be decentralized and open enough to support a rich ecosystem of competing service providers and implementations, and compelling enough to gain widespread adoption. While browser support could and should be obviously beneficial in terms of providing a more streamlined UX, predicating on it opens up the possibility for very severe failures of the imagination, as the Persona team has learned. And if a solution exhibits all the properties I just mentioned, then it becomes a very natural candidate to base a browser standard proposal on, because these are the very same properties that are often deemed most desirable in real web standards to begin with.
I personally can't wait to see what comes out of the current project Dan's working on, Portier, which is positioned to be a spiritual successor to Persona: https://portier.github.io/