Background: Persona was a centralized, Mozilla-run auth service designed to bootstrap a decentralized protocol. In theory, after the protocol was widely adopted, Mozilla could shut down the centralized service. In practice, nobody adopted the protocol and the whole thing collapsed when Mozilla shut down the service.
I think the whole endeavor would have been more successful as self-hosted software. The downside is that each website would require separate email verification (until the protocol got adopted), but it would have been far less confusing to everyone and it most importantly it still would be running today. On the other hand building shrink-wrap cross-platform software is a lot harder than running a service and publishing some javascript, so I understand why they did what they did... but here we are dead in the water.
I would love to see Persona revived as a self-hosted auth library someday, and actually think it could still be successful in that role. It encapsulates the whole verify-your-email step; it leverages several existing federated login solutions to skip the roundtrip; it could still revive the decentralized protocol.
I haven't looked at this Payment Request API and I'm as skeptical as anyone, but if it doesn't rely on any kind of centralized service, it at least has a chance.
Sounds a lot like the Matrix chat protocol. Who’s using a private Matrix server?
I feel like a lot of these companies think they’ll handle the bootstrapping stage with economies-of-scale from having one central node; but in practice, having that one central node enables extra network effects (e.g. super-low-latency interactions with people on the same node) that make people resistant to eventually becoming more distributed.
I think WordPress.com represents a better model: it’s a first-party hosting provider, but everyone that signs up is signing up for their very own instance. (Maybe some things are shared under the covers—that’d certainly be good engineering—but everyone gets full control of their WordPress “engine”, with their own plugins, scheduled tasks, etc.) This way, people are used to the concept of these blogs being a loosely-federated network with pingbacks et al from the start, rather than everything being one server with one dashboard. Very easy from there to “lift” your instance out into a separate enterprise deployment; very easy for other cloud providers to spring up and offer you an import tool, to move “your server” from service X to service Y.
Why is that a problem, by the way? Wouldn't we expect something like Persona to be implemented in new software projects first, then gradually get adopted in existing software?
Nobody is going to gut their auth system to implement something shiny unless many are asking for it - i.e. by saying "oh it's so easy to sign into $rival_website because they use Persona, why can't we get that here?"
Similar timeline for browsers working on an implementation.
You've got to hate these short attention spans.
Seriously: Anything that's browser standards work moves on the time scale of multiple years. Yes, that goes for Persona too - launched in 2011, finally canned in 2016.
Just because your pet project doesn't launch doesn't mean there's "short attention span for difficult problems".
Any standard can get adopted in two ways: either imposed by a dominant player, who can effectively force others to follow; or pushed by a wholly-independent 3rd-party that is completely neutral. Persona could not follow any of those strategies, and it withered, predictably.
As for federated auth... Twitter, Facebook, Google and Github authorizations seem to work okay-ish. Integration is rarely good. Login, User and Account are three different things, and people tend to conflate them poorly, this causes issues down the road in most projects.
https://battlepenguin.com/tech/the-decline-of-openid/
(Super confusing name since it was also the name of a type of Firefox theme engine)
https://stripe.com/docs/stripe-js/elements/payment-request-b...
For example, the private key gets stored in hardware protection thus cannot be exported. So the UX is a non-starter if the user wants to log in from more than one device.
People will say that's a feature. But it's also why it's never going to replace passwords.
Yes I'll say not being able to get that symmetric key out of the hardware token is a feature, because it is. Without that feature you'll have to educate users about how to care for their symmetric key and every time you inevitably fail they get exploited.
Regarding export of private keys -- some crypto hardware wallets also support the FIDO[2] specs. -- so there you have the option to use the 12 words to setup a new hardware with the same private keys ...
Logins are often provided as part of whatever framework you're using.