This also opens up the door to more secure payments. The "basic card" handler is one where the browser might just store your raw card number. But you can imagine that your bank might implement a payment handler that requires you to enter a 2fa code before using your card.
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.
Interesting that the post says the term BIN (vs. IIN) isn't commonly used anymore, but it's practically the only thing I've heard them called in the last 10+ years of ecomm dev.
I've seen both. When I wrote the post all the docs from the gateways I had access to called then iin with a historical note on bin. I done have access to those docs anymore though.
I've seen both. When I wrote the post all the docs from the gateways I had access to called it the iin with a historical note on bin. I don't have access to those docs anymore, though.
Edit: I really need to check when posting from my phone
So there's now a protocol for the browser to transparently share payment data with websites but we still can't get something to let the browser transparently log us in to websites?
It's more than that, it syncs user login credentials across devices, and can auto-sign in users without them having to go through a login form.
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.
Does it by default generate a password or there is STILL a way for user to set their own? If the latter, then it won't change anything. We must hide pw field entirely from the user.
I believe they autogenerate the password, but the long-term strategy is to make OAuth as seamless as possible so users are encouraged to login to everything with their Google/Facebook etc account.
Mozilla Persona suffered from the problem that its developers abandoned it shortly after releasing it, rather than making any attempt to get it into browsers. The pop-up dialog wasn't how it was supposed to work, that was a fallback (and apparently a slightly confusing one) - there was supposed to be a little login widget in your address bar that you'd interact with, and it'd be fully integrated into your browser's UI.
Hmmm.. How would that work beyond Firefox if it wasnt a standard?
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..
> How would that work beyond Firefox if it wasn't a standard?
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/
The issue, of course, is that web technologies outright don't allow true decentralisation - there is no way for arbitrary web pages to ask the browser "who is the identity provider I should be talking to?", or to make a request of such an identity provider. This has been a problem for a number of years - the OpenID Foundation's hack is "Account Chooser", a centralised website that keeps a list of accounts for a given browser in localstorage.
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.
I'm not quite sure what you meant by "true decentralization", but even if some arbitrary ideal of maximum decentralization isn't possible on the current web, I think it's still worthwhile to strive for some degree of decentralization over none. And many technologies on the web do in fact offer varying degrees of decentralization through federation and interop, with email being the canonical example.
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.
> 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.
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.
> otherwise the user needs to tell every website their email address manually
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.
> if there was a bug in the target server's OpenID Connect implementation that somehow replaced "example.com" with "contoso.com"
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?
People did care and use Persona. Unfortunately, large organizations, such as Mozilla, expect that anything they launch will be mass-adopted within a short period of time, and kill promising projects that fail to quickly reach such adoption.
Supposed to, perhaps. But it's not going to happen. Kerberos is ridiculously complex (it's not named after Hades' three-headed dog for nothing) and hard to deploy. When used it is usually only done for company's own/internal apps. I don't think I've ever seen anything with Kerberos on the public internet.
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.
The W3C is run by the same peers who frequent this and other tech forums. You can help by contributing to the organization, or you could hope for some internet points with snarky remarks. Which do you want to be remembered for?
As bad as DRM is, EME is a good step towards killing Flash. And because of that, Netflix needs a replacement, and the studios aren’t just going to remove DRM requirements because Netflix says they won’t support DRM. I’m almost certain that if Netflix tried to remove DRM, the studios would balk and pull their content.
Or Netflix could take the route they took on iOS and just make native apps for everything.
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.
That goes against what throwaway284534 was implying.
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.
While he could've worded it better he did provide valid criticism. I'm sure he is not the only person here who has profiteering concerns for the various bodies who govern the internet.
> 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?
> The w3c seems to be run by people who make money on the web, not people who use the web.
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).
> However, most people would agree that the balance of power effectively lies with the browser vendors
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.
It's worth noting that while it costs money to join the W3C, W3C membership isn't a requirement to participate in most (maybe even all now?) WGs where you can simply join the mailing list or subscribe to the GitHub repo and contribute.
Not sure if this is still the case, but Marcos from Mozilla did a talk on this at CampJS earlier this year. Apparently Chrome will send data about the items purchased to Google, even if you’re using a payment provider completely unrelated to Google.
Unlike Chrome, Firefox will apparently not send data about what you purchase back to Mozilla.
> Unlike Chrome, Firefox will apparently not send data about what you purchase back to Mozilla.
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.
> 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.
Importantly, it _is_ different than what Apple Pay does.
Don't think there's recordings of CampJS for this year, but on the schedule [1] there's a talk about it listed by Marcos Caceres. You could probably ask the guy on Twitter (@marcosc).
Ahh, that completely changes the meaning. It's basically just like credit card processing in that case, but just for Android Pay (and probably Apple pay if/when they adopt the API). The transaction description/line item thing makes a lot of sense from a user perspective (granted, I am not, and do not intend on becoming, an Android Pay or Apple Pay user).
Yeah, seems to be limited to Google’s own payment services.
Just so you know, Apple doesn’t see nor store the item/s you purchase via Apple Pay, so if Apple Pay is accepted through this payment API, I think it’s unlikely to send purchase information directly to Apple.
Agreed. I'd also like to see the source for this, as I can't find it mentioned anywhere on the Chrome sites about PaymentRequest or any of the top sites talking about Chrome Payment Request.
Android Pay for the Web uses a version of the Payment Request API, I surprised by how similar it is to the Apple Pay for Web implementation. We implemented both for sending payment requests from our App, I found the Payment Request API to be much better documented and easier to implement than Apple Pay for Web and significantly easier to test.
I won't bore you with the history of the Payment Request API, but a sizable chunk of it was inspired by the native Objective-C / Swift Apple Pay API, which is why it's so similar.
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
Odd that none of the editors are, you know, actually from companies that do meaningful e-commerce. I'd be a lot more interested if it was obvious that folks like Amazon, Stripe, Paypal, Braintree, Ebay, etc. were working on this.
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.
> 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
> the main attraction is it gets rid of auto-fill - which is frequently clunky
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.
Not necessarily, depending on the method. For example, Apple/Android Pay is stored securely. Raw credit card data may be stored encrypted by the browser and decrypted at runtime or with the OS keychain, although I'm not sure if this is done now or not.
For example, Apple/Android Pay is stored
securely.
See this comment[0] for a more detailed description of Apple Pay (and I'm pretty sure Android Pay). In short, account holder information is not stored on client devices. Instead, a server-generated encrypted token usually is.
I'd be a lot more interested if it was obvious
that folks like Amazon, Stripe, Paypal,
Braintree, Ebay, etc. were working on this.
I can say all but Braintree, which may as well, process through one of the Paymentech platforms (owned by Chase) and have the ability to store customer billing information securely on PCI compliant servers provided by same.
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."
> Furthermore, the fraud exposure presented by this API will be difficult to be accepted by processors.
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.
The fraud exposure is due to identifying information, or access therein, being stored on and/or directly provided by the client in this model. Existing payment methods do not store billing information on the client devices as they are assumed to be untrusted.
Also, all major card networks - Visa,
MasterCard, AmEx - and many payment processors
- Stripe, Worldpay, etc - all actively
participate.
Card networks are not banks. Stripe is not a bank. Worldpay may be (I've never heard of them), but for the sake of discussion, I'll assume they are not a bank.
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).
> Existing payment methods do not store billing information on the client devices as they are assumed to be untrusted.
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.
No, Apple Pay does not. And I'm pretty sure neither does Android Pay. What Apple Pay does is produce encrypted tokens based on the account holder's information and the device(s) authorized to use it. It is only this encrypted token which is stored on a client device and it is verified on each transaction as well as periodically replaced by the servers.
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.
Big players such as Amazon doesn't want this, because it diminishes the value of their existing database of stored credit cards and evens the playing field for new merchants. Most people buy from Amazon because they already have an account there. Even if you find a product somewhere else, you go to Amazon to order it.
This is great! I've implemented the PaymentRequest API on a couple of my apps, and customers have really liked the user experience on mobile chrome. This is another positive step towards PWAs becoming more ubiquitous (I strongly believe PWAs will play a bigger part in the app ecosystem in the near future). I can imagine Apple will feel a bit more comfortable with web apps if they could conduit payments via apple pay more seamlessly - I hope things like this help remove some of the dev inertia on their side and make safari more suited to web apps.
After Stripe switched to iframes for payment forms, I am very happy to see this. Trying to wrestle a iframe credit card field to have same fonts and error handling as other fields in a form is a really annoying workaround considering how nice the plaintext tokenizers in the past were... Knowing that credit card fields might not be in our forms at all feels very cool
So currently, users are often redirected to the 3rd party payment service or interact with an embedded form offered by the 3rd party service and the user either has to register/login. Does this mean, in the case of PayPal, users will have to install the PayPal Payment API App on their browsers?
"At a high level, the API affects the front end (checkout), not back end. Therefore, merchant's should not have to make changes to backend processing of various payment methods."
I'm pretty sure it doesn't. It would just let Stripe add a "use credit card data from your browser" button that avoided making users type it in every time.
Not only that, but they can also register as a payment provider in the user's browser, allowing for a convenient checkout flow on any site that uses Stripe.
It's marginally bad for Amazon. If a shoe is a dollar cheaper from the Nike store, but Nike doesn't have a card on file, you'd probably just get it from Amazon. With this system, you're more likely to order from Nike.
I'd posit not at all, since accepting purchaser verifying information automatically provided by a browser (or any client-side program) will almost certainly be rejected by any ISO/VAR/processor having a fraud liability exposure.
I was referring to the client being the System of Truth. Auto-fill for some fields in an eCommerce transaction is allowed for convenience, true, but not all (PAN and CVV, for example).
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.
Pretty sure Chrome autofill will store CVV. I think for most people using Chrome autofill for CCs, Chrome is already the System of Truth for CC, to quite the same extent it would be under this new system. No banks or retailers seem to be complaining about it at present.
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 ...
Chrome, or any program running on a client device, is not a System of Truth due to the definition of same. A System of Truth is a trusted, authoritative, source of information in which services can rely on the information provided as being correct. In this context, a System of Truth is one which has exclusively its data from channels either controlled by the processor or secure feeds from partners.
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 the browser, no, there is none.
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).
True micropayments integrated in browser would be amazing. Imagine instead of ads or subscriptions, you could pay a few pennies for an article. It would revolutionize online content, in a good way. Nobody would be willing to pay for clickbait type stuff, but I think people would be willing to pay for quality content and journalism.
There's been a debate for a while now about this. Clay Shirky, Walter Isaacson, Jakob Nielsen, Norman Hardy, Kevin Kelley and others have expressed arguments for and against(mostly for) micropayments.
But there's yet to be a success story, most early implementations failed(BitPass, Ezcash, Peppercoin) but that was before cryptocurrencies. Now there's a new crop(Steemit, 21.co?, etc) that are trying again. Interesting to see how this will all pan out.
A micropayment system tied in to browsing history might make this possible. Otherwise it would require essentially a syndicated subscription system, which is server side, but would need enough content producers on board to make feasible, and they probably wouldn't be able to agree.
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.
Quality content costs money. How do you propose paying journalists to investigate and write? It's either ads, payments of some sort (micro or subscription) or state-sponsored media. My original comment was not out of fear, quite the opposite.
This would be perfect for me, and I suspect there are a lot of people in my situation: I would far prefer to pay for news than have intrusive and possibly dangerous advertising, and I do subscribe to a couple of news sites. I'm not going to subscribe to every paywalled news site that I might want to read, but I would be happy to pay for an occasional article.
If micropayments were ever to really take off, it would shift the balance of power on the internet in an interesting way.
"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."
https://github.com/w3c/payment-request-info/wiki/FAQ