Hacker News Reader

Comment by mixedbit | Hacker News Reader

I'm skeptical. Browser vendors have too short attention span to work on difficult problems like this until the solution becomes good enough and widely adopted. One of the recent examples of this was Persona - an attempt to standardize login flow across browsers, also difficult problem, but easier than payments. Persona was killed, not because the solution was not working or couldn't be further improved, but because it wasn't widely adopted after relatively short time (somewhere between 1-2 years if I recall correctly).

View on HN

I was an early adopter of Persona (my website was one of the canonical examples). I share your sentiment and dismay that Persona was shut down, although ultimately I think the way it was implemented was fundamentally flawed.

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.

> In theory, after the protocol was widely adopted, Mozilla could shut down the centralized service. In practice, nobody adopted the protocol

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.

>it wasn't widely adopted after relatively short time

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

You can even compare it to OpenID, where it languished mostly-unused—but still actively-maintained!—for 5-10 years before OpenID Connect (a hybrid of the ideas of OpenID and OAuth) became the basis for all the major Single Sign-On services in use today. I doubt OpenID Connect would have inherited any OpenID-like functionality (e.g. profile discovery) if OpenID had been deprecated a year after its drafting. They probably would have instead (badly) reinvented it with no knowledge of the prior art, because there wasn’t an existing (if small) install-base to prove out the practicality of the various features.

Yeah. Totally. 4 years of work on the spec - here's the first commit: https://github.com/w3c/payment-request/commit/12cda4283ccf66...

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

Shopify tested it in production 2 years ago: https://engineering.shopify.com/blogs/engineering/shaping-th...

I'm optimistic. Already supported by Chrome, Safari, Firefox & Edge on both mobile and desktop including support for both Apple & Google Pay where possible.

My understanding is that the Payment Request API is just the standardisation of Apple's Apple Pay API for web, which has reasonable adoption. The browser vendors - Apple and Google - have a vested interest in making sure this works because it supports their other businesses/platforms.

Persona was a Mozilla project first and foremost. Nobody is going to just hand over one of the most critical parts of web-apps to their competitor, especially not a minor one.

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.

That's my opinion of Auth0 and similar services, no offense to Auth0, but people still use them.

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.

I did a post recently on the end of classic Open ID and briefly talk about Persona:

https://battlepenguin.com/tech/the-decline-of-openid/

(Super confusing name since it was also the name of a type of Firefox theme engine)

Haven't several browser vendors already implemented this?

https://stripe.com/docs/stripe-js/elements/payment-request-b...

Persona was also implemented, the problem is to keep it supported and iterate on the solution for long enough to reach wide adoption.

Persona was just some Mozilla experiment. But WebAuthn is alive and well, as far as I know.

Webauthn was weirdly impractical when I looked at it.

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.

In a typical WebAuthn scenario the Private Key is actually being stored by the Relying Party, they just don't know that because it's encrypted with a symmetric key. That symmetric key is baked inside the hardware token.

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.

You can register multiple hardware tokens for a service (if the site supports that).

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

this really isn't the best thread to ask, but I've been quite curious if there are any other, less secure, key stores under consideration (i.e a filesystem or remote sso service) under CTAP?

I don't know the specifics of persona so i cannot make a comparison, but payment processes are way harder to set up, and money is on the line, so more people should adopt this.

Logins are often provided as part of whatever framework you're using.

I don't understand mozilla killed it - and why it hasn't been resurrected; did ppl from google complain?

Was Persona ever worked on my other browsers? That seems very different from Payments API.

Just because one spec failed you are suspicious of all specs? If it solves a problem people will use it. If it doesn't they won't. Are you saying you don't think that payments are a problem that people want to solve?

I'm suspicious of specs that require long term browser vendors support. Payments are definitely a problem that people want to solve, but my estimate is that it would require 5-10 years of continuous commitment from browser vendors to solve this problem, which I doubt will happen.

What problem is it solving? What's so bad about entering my credit card details?

It isn't solving any problems. This payments API looks like a simple AJAX call. This API shouldn't even exist in my opinion.

Reply on news.ycombinator.com