9 ms·

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.

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

WilliamEdward 7y ago
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.
ancarda 7y ago
>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?"
- derefr 7y ago
  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.
ceejayoz 7y ago
Haven't several browser vendors already implemented this? https://stripe.com/docs/stripe-js/elements/payment-request-button https://stripe.com/docs/stripe-js/elements/payment-request-b...
- mixedbit 7y ago
  Persona was also implemented, the problem is to keep it supported and iterate on the solution for long enough to reach wide adoption.
Rafert 7y ago
Shopify tested it in production 2 years ago: https://engineering.shopify.com/blogs/engineering/shaping-the-future-of-payments-in-the-browser https://engineering.shopify.com/blogs/engineering/shaping-th...
buboard 7y ago
I don't understand mozilla killed it - and why it hasn't been resurrected; did ppl from google complain?
stickfigure 7y ago
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.
- derefr 7y ago
  > 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.
spankalee 7y ago
Was Persona ever worked on my other browsers? That seems very different from Payments API.
arkanciscan 7y ago
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?
- krossitalk 7y ago
  What problem is it solving? What's so bad about entering my credit card details?
  - apolymath 7y ago
    It isn't solving any problems. This payments API looks like a simple AJAX call. This API shouldn't even exist in my opinion.
- mixedbit 7y ago
  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.
101404 7y ago
Persona was just some Mozilla experiment. But WebAuthn is alive and well, as far as I know.
- hombre_fatal 7y ago
  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.
  - rene_kapusta 7y ago
    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 ...
  - convolvatron 7y ago
    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?
  - tialaramex 7y ago
    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.
toyg 7y ago
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.
- tracker1 7y ago
  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.
pbreit 7y ago
I'm optimistic. Already supported by Chrome, Safari, Firefox & Edge on both mobile and desktop including support for both Apple & Google Pay where possible.
djsumdog 7y ago
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/ https://battlepenguin.com/tech/the-decline-of-openid/ (Super confusing name since it was also the name of a type of Firefox theme engine)
groby_b 7y ago
Yeah. Totally. 4 years of work on the spec - here's the first commit: https://github.com/w3c/payment-request/commit/12cda4283ccf66380c814b6d17a4f664f5c098d0 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".
madeofpalk 7y ago
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.

WilliamEdward 7y ago

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.

ancarda 7y ago

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

derefr 7y ago
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.

ceejayoz 7y ago

Haven't several browser vendors already implemented this? https://stripe.com/docs/stripe-js/elements/payment-request-button https://stripe.com/docs/stripe-js/elements/payment-request-b...

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

Rafert 7y ago

Shopify tested it in production 2 years ago: https://engineering.shopify.com/blogs/engineering/shaping-the-future-of-payments-in-the-browser https://engineering.shopify.com/blogs/engineering/shaping-th...

buboard 7y ago

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

stickfigure 7y ago

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.

derefr 7y ago
> 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.

spankalee 7y ago

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

arkanciscan 7y ago

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?

krossitalk 7y ago
What problem is it solving? What's so bad about entering my credit card details?
- apolymath 7y ago
  It isn't solving any problems. This payments API looks like a simple AJAX call. This API shouldn't even exist in my opinion.
mixedbit 7y ago
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.

101404 7y ago

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

hombre_fatal 7y ago
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.
- rene_kapusta 7y ago
  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 ...
- convolvatron 7y ago
  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?
- tialaramex 7y ago
  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.

toyg 7y ago

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.

tracker1 7y ago
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.

pbreit 7y ago

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

djsumdog 7y ago

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/ https://battlepenguin.com/tech/the-decline-of-openid/ (Super confusing name since it was also the name of a type of Firefox theme engine)

groby_b 7y ago

Yeah. Totally. 4 years of work on the spec - here's the first commit: https://github.com/w3c/payment-request/commit/12cda4283ccf66380c814b6d17a4f664f5c098d0 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".

madeofpalk 7y ago

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.