Payment Request API
w3.org
w3.org
"In one sentence, how does it work?
Payment Request API enables a user to complete a transaction more easily by reusing information stored in the browser or third party payment apps."
When it comes down to it, a credit card number is kind of serving double as a username and password for online payments right now. This new API has the potential to significantly improve upon the security of raw PANs.
Edit: I really need to check when posting from my phone
https://www.mastercard.us/en-us/issuers/get-support/2-series...
https://developers.google.com/web/fundamentals/discovery-and...
Example scenario: user signs up for a site on Chrome desktop. When they visit the site from their phone, they're automatically signed in, they don't even see a login screen.
Gotta start somewhere. Proposals that come with a working prototype probably fare much better than those that are purely theoretical.
Persona was a good nobel idea, but like many Mozilla endeavors without a commercial goal it was doomed to failure, a few devs and devops costs money (a lot in the US, let's say 3 devs - 2 devops, office space, benefits etc.. easily 1m). Slightly OT beyond Firefox has Mozilla done anything commercially successful? Mobile software failure (cant imagine Android FF pays for itsself), device failure, SSO failure. How much revenue % is accounted for beyond the Google search integration?
Update: Just thought they made Rust and Servo that's pretty cool and my post sounds a little shitty, Rust seems awesome, but commercial avenue (back to reality) seems extremely limited here..
Done properly, it hopefully would've been. (There was even some branding around the vague hope that it would eventually be a standard - "BrowserID"). As it stands... the Persona devs never even tried to create an extension for Firefox to show what they were trying to do (there's some early mockups that explain some of it), nor did they attempt to standardise it. The project was mismanaged to failure.
> has Mozilla done anything commercially successful?
Mozilla is primarily a non-profit organisation, "commercially successful" is not the goal. Mozilla Corp, the wholly owned tax-paying subsidiary, is simply a legal tool to make it less difficult to sell things like search integration, not to be a commercial success.
The question is whether much of their work successfully furthers their goals as outlined in their mission statement and manifesto.[0]
In 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/
Being able to click "log in" and have logged in, and having functional single logout, with a decent UX over the whole thing, is the holy grail. Facebook has the current solution, and browsers don't. Portier does not even attempt to solve the same problem as Persona did, and by being a "self-hosted" application, it can't.
And the use case you mentioned, for an arbitrary web page to ask the _user_ (because there's no reason why the browser absolutely needs to be an intermediary here. More on this in a bit) who it should be talking to in a decentralized manner, has been a solved problem for quite a while in the form of the WebFinger standard, whereby the user simply needs to provide an email address from a provider that implements the protocol on its domain (though it's not often used as a standalone protocol, it is actually quite well adopted as the discovery mechanism behind OpenID Connect, and I have used it in practice through the remoteStorage project: https://remotestorage.io/).
Portier certainly doesn't claim to be trying to copy Persona's approach to authentication on the web exactly, and specifically it makes a conscious effort to avoid predicating the system's usefulness and any of its fundamental design considerations on native browser support (that's of course not to say that they would refuse to integrate with browsers if the opportunity does eventually present itself), a decision that stems from the lessons learned from the failures of Persona: https://github.com/portier/portier.github.io/blob/master/Non...
At the end of the day, Portier strives to succeed Persona as an authentication mechanism, not as a browser-integrated authentication mechanism. And Facebook's current "holy grail" UX around authentication is living proof that you don't need explicit browser support to provide a great auth experience for the end-user. Whether Portier can be successful in replicating an experience like Facebook's while providing a useful degree of decentralization and user privacy as its mission statement declares remains to be seen, of course.
Except that you do - otherwise the user needs to tell every website their email address manually, and every website needs to run its own instance of Portier or else you wind up with horribly confusing messaging in the authentication flow - "I'm trying to log into example.com, why is Google asking me to allow access to contoso.com?". Both of these are dealbreakers for something that is supposed to solve the problem of identity on the web.
The bit of Persona that was at all interesting was that it was to be integrated into the browser, Persona would remember identities, and it was a very simple API that didn't involve running a heavy server to handle. You could authenticate against Persona with a handful of lines of javascript and a handful more of PHP, and if the user was already logged in to their identity provider, it was one click to authenticate to a new website.
Portier provides absolutely nothing interesting over an OpenID Connect client + fallback auth mechanism - it's a simple broker.
Form autofill for email is available in just about every major browser, which makes this process as almost as seamless as clicking a Facebook sign-in button, when the user would like it to be, but still offers users the option to provide any arbitrary identity from any OpenID Connect provider for each site if they choose.
> every website needs to run its own instance of Portier or else you wind up with horribly confusing messaging in the authentication flow - "I'm trying to log into example.com, why is Google asking me to allow access to contoso.com?"
I'm not sure how this scenario can ever come about, since Portier is just a dynamic broker for OpenID Connect. Portier itself is only responsible for the "I'm trying to log into example.com" part of the flow, by associating the user's email to a OpenID Connect capable server responsible for performing authentication for that domain. The hypothetical "why is Google asking me to allow access to contoso.com?" part of the flow can only occur if there was a bug in the target server's OpenID Connect implementation that somehow replaced "example.com" with "contoso.com", which has nothing to do with whether or not that server is running Portier itself.
I feel like there may be some misunderstanding on what role Portier performs in the auth flow. But if not, we'll probably just have to agree to disagree on the assertions that the only interesting part of Persona was that it was integrated into the browser, and that Portier offers nothing interesting over static OpenID Connect providers + fallback. Dynamic discovery of authentication providers based on an email was by far the most interesting part of Persona for me, because it meant users can use any arbitrary identity provider they chose, without the developer having to explicitly implement support for every single one of them, as long as the identity providers spoke a common protocol (Persona Identity Provider for Persona, or OpenID Connect for Portier). And this is exactly the part of Persona that Portier is attempting to replicate, except with an already well-adopted protocol that works well without any explicit browser support.
No, because in this case, Portier is running on contoso.com and the website I'm actually trying to auth to is example.com - from the target server's perspective, contoso.com is the site trying to auth against it.
> Dynamic discovery of authentication providers based on an email was by far the most interesting part of Persona for me
OpenID Connect does this as well.[0] If IDPs don't support it, why would they support Portier?
[0] http://openid.net/specs/openid-connect-discovery-1_0.html
One of the best-case scenarios for Portier is if WebFinger/OIDC were to become widespread and Portier itself somehow obsolete.
I am affiliated with the project but have been putting in much less time than I'd like, admittedly.
The description on Wikipedia for Cerberus/Kerberos is pretty apt when applied to the protocol too:
> Cerberus was the offspring of the monsters Echidna and Typhon, and usually is described as having three heads, a serpent for a tail, and snakes protruding from parts of his body.
For example, no amount of contribution would have stopped Netflix et al from pushing through EME as a web standard.
Or, perhaps more likely, browser vendors would continue to not kill Flash until 2020 (at the earliest) when Adobe ends support, and then browsers would drop support for the insecure plugin and then Netflix would go the native apps route.
If everyone is a "peer" and an enormous number of those peers make a succinct, persuasive argument that EME is incompatible with W3C's mission statement of "Web for All" and "Web for Rich Interaction"[1], one would think that would make a difference in the direction the W3C takes.
Instead I'm eating popcorn watching players with deep pockets choose tactics in their battle to control an industry. And that battle is what shapes this web API.
So the claim of, "your peers are listening and they value your feedback," is about as convincing as a hold message from Comcast.
They just seem to continuously standardize things that are very user hostile and only serve content distributors.
Example Nr 1 you are going to quote is the DRM stuff (understandably, it's the most controversial for good reasons, both inside and outside W3C). What other very user hostile examples are there?
Not really. Anyone can join the W3C, and anyone can participate in a working group / contribute to a standard.
However, most people would agree that the balance of power effectively lies with the browser vendors. You can propose a standard all you like, but if you can't get a browser to adopt it then it's not going to get any traction. And although it's true that some browser vendors make their money off the web (Google) others very much don't (Apple).
It lies with two groups: the implementers (as nothing can become a standard without implementations, though there's plenty of precedent for using obscure ones!) and the W3C Members (i.e., the paying organisations who pay to get a seat; not those who contribute on mailing lists/GitHub/whatever, not those who are officially on the working groups as "invited experts") who ultimately vote on the proposed standard (and there Google has as much say as the BBC and Boeing and the University of Edinburgh.
Starting at ~10 000 USD per year, sure
Unlike Chrome, Firefox will apparently not send data about what you purchase back to Mozilla.
Edit: https://twitter.com/chrismorrisorg/status/896352427426799618
It sounds like something has been lost in translation. If not, Marcos is conflating two very different things.
If you use Payment Request in Chrome with Google Wallet or Android Pay then yes, Google is going to have a description of what you bought and where you bought it. But you used their payment service. This is no different to what PayPal or a dozen other payment services are doing.
If you use Payment Request in Chrome as a replacement for auto-fill - that is, you're just using it with regular card numbers, or with another non-Google payment instrument then nothing is being sent back to Google. Go check the source code, it's all implemented in Chromium (indeed, other Chrome based browsers that integrated Payment Request like Samsung's own mobile browser or AliPay are using Google's implementation).
The reason that the standard asks for a description of what you bought is that it's useful to display to the user in a standardized way as part of the payment process so you can reconfirm exactly what it is you're paying for.
I sat on the Payment Request Working Group until about three months ago and I didn't hear any of these concerns from Mozilla then. I don't really know what Marcos has been saying, and since the talk itself isn't online I'm going to assume he's been mis-quoted.
Importantly, it _is_ different than what Apple Pay does.
I’ll get back to you!
But the same API should also be able to let us choose which wallet to pay cryptocurrencies from.
With regards to Android Pay being easier to test - that's primarily because Apple Pay implements a much stricter security standard that requires a challenge/response to take place before starting the transaction.
It's actually pretty easy to shim the Apple Pay API to Payment Request. If you didn't know about this already you might kick yourself, but there's even a Google supplied shim that allows you to just write the code once using Payment Request: https://github.com/GoogleChrome/appr-wrapper
I'm also wary of an API that tries to be all things to all people--as evidenced by the shoehorning in of shipping and delivery options.
EDIT:
Also, we see stuff like so:
> The PaymentRequest API does not directly support encryption of data fields. Individual payment methods may choose to include support for encrypted data but it is not mandatory that all payment methods support this.
What problem is this solving again? How does this make developers' lives easier than existing solutions? I'm kinda thinking it doesn't.
One way it makes developers' lives easier is by providing a single API through which you can offer multiple payment services (Apple Pay, Android Pay, PayPal, etc), rather than requiring separate integrations and code for each service.
However, the main attraction is it gets rid of auto-fill - which is frequently clunky - and replaces it with a unified check-out process. The benefit there is for the user, not the developer.
> Odd that none of the editors are, you know, actually from companies that do meaningful e-commerce.
Being an editor of a spec doesn't really mean much in terms of defining it. It just means you're the point person for a ton of administrative work.
The group has very active participation from a number of eCommerce players, including all the major card networks, AirBnB, Shopify, Stripe, Tencent, Worldpay, and Yandex. There's a lot of eCommerce interest: https://www.w3.org/2004/01/pp-impl/83744/status
Not only is auto-fill clunky, it's also tricky to implement securely. Moving these semantics into a dedicated API should help get the browsers out of these sorts of cat-and-mouse games.
See previous discussion: https://news.ycombinator.com/item?id=13329525
For a super quick gist, watch 15 seconds of this video starting at this time: https://youtu.be/NDZw7vtoYnU?t=514
The problem it solves is reducing friction on checkout.
For example, Apple/Android Pay is stored
securely.
I'd be a lot more interested if it was obvious
that folks like Amazon, Stripe, Paypal,
Braintree, Ebay, etc. were working on this.
Furthermore, the fraud exposure presented by this API will be difficult to be accepted by processors.
EDIT: Stripe is an ISO with FDMS, owned by Wells Fargo. They got the transactional system from Paymentech in "the divorce."
I'm confused by what you mean. The API doesn't have any additional fraud exposure. It uses existing payment instruments and methods. Also, all major card networks - Visa, MasterCard, AmEx - and many payment processors - Stripe, Worldpay, etc - all actively participate.
The API doesn't have any additional fraud exposure.
Also, all major card networks - Visa,
MasterCard, AmEx - and many payment processors
- Stripe, Worldpay, etc - all actively
participate.
Banks are the CC account issuers and the processors "on the rails" of payment networks (Visa, MasterCard, Amex). Whether or not an ISO/VAR/merchant (Stripe, PayPal, eBay, Apple, Google, Amazon, etc.) wants this type of API is immaterial. If the banks aren't comfortable with it, someone is going to eat their discount rate hike (yes, ultimately this is the customer, but I'm talking about entities directly impacted by the hike).
Except this is exactly how Android Pay and Apple Pay work: they store the billing information on the client side. A large part of the impetus behind Payment Requests is to open up Android Pay and Apple Pay to the web. And all(?) major browsers support autofilling card details already, which means storing the billing information on the client side and exposing the web to that fraud risk.
And, heck, a conforming Payment Requests payment handler doesn't need to store anything locally: one based on payment cards could require you to enter the card details on every transaction.
Except this is exactly how Android Pay and
Apple Pay work: they store the billing
information on the client side.
The PAN and related data is stored securely on Apple's servers (or, more likely, PCI compliant servers provided by Paymentech). This is why merchants have to accept these payment methods specifically and not treat them as "regular" card-not-present transactions.
I know this because, for example, the shipping API exists at all--that being something that a lot of companies have very particular use-cases about.
My point is more that it isn't obvious that
any engineers who actually do this for a
living day in and day out are giving useful
feedback.
(Disclosure: I'm the host of the podcast)
It appears to do a lot more than just the financial amount for payment as a request.
Plus, processors apply significant fraud detection on transactions from merchants performing card-not-present transactions and will frequently require escrow accounts for merchants lacking a proven low-chargeback frequency or for those who do incur chargebacks. Also, some processors will give a better discount rate for merchants who require customers to enter billing information manually (or as manual as the merchant system can reasonably enforce).
So the fact that browsers support auto-fill is immaterial to the processors. What is important is that data provided by a customer in a card-not-present transaction is verified against the System of Truth, in addition to other verifications of course.
I don't see the difference between browser filling in these details with auto-fill, or browser filling in these details with a Payment Request API. Are you suggesting there is a significant one?
... Chrome is already the System of Truth for CC ...
I don't see the difference between browser
filling in these details with auto-fill,
or browser filling in these details with a
Payment Request API. Are you suggesting
there is a significant one?
From the perspective of a transaction processor, they will see the client request the same and treat it as being untrusted until verified against their System(s) of Truth as well as satisfying ancillary verifications.
As such, a client device can never qualify as being authoritative due to its assumed compromised state (from the perspective of a processor).
Something tells me that having a default secure way to pay is much better than everyone implementing (often poorly) their own solutions
You might want to check out Brave, a Chromium-based browser with micropayments built-in: https://brave.com/publishers/.
First they try to make HTTP impossible to use (nag pop up) to limit the websites, then they try to introduce pay-per-view model and subscription model.
Welcome back to the pre-1999 AOL/MicrosoftNetwork/Compuserve/BTX/Minitel/etc - closed networks where pay-per-page-view was prevailing - then the free open WWW won, supported by advertising.
The good thing, it only takes other websites that provide the same or comparable content for free.
If micropayments were ever to really take off, it would shift the balance of power on the internet in an interesting way.