Meeting minutes
See also 12 September minutes.
PR API 1.0 update
ian: we're going to talk about payment request and handler today
ian: we published Payment Request v1.0 and Payment Method Identifiers v1.0 last week
… organisational changes (TBL moving away) caused some delay to handling the formal objections
… TBL has delegated to Ralph Zwick, who reviewed the report that examined the formal objections
… and overruled the those objections
ian: the second thing that happened was that we published FPWD of V1.1 of Payment Request
… this was driven by feedback from browser vendors
… the changes were principally low level javascript issues
… but it was a strong signal that the browser vendors are actively maintaining the standard
… so today we're going to talk about what's next for payment request
… including privacy changes, usage, new features
smcgruer_[EST]: we have a list which includes handlers, addresses...
smcgruer_[EST]: PR API used to have support for collecting addresses. The WG removed the feature based on privacy review.
https://
smcgruer_[EST]: But the feature shipped in both Safari and Chrome. Browser vendors don't like when a web feature that is interoperable and shipping is not part of a Web standard.
… so we want to discuss how to handle this.
… should we fix shipping addresses?
<Zakim> nicktr, you wanted to ask implications of non-specced features
NickTR: I hear and understand that it's not good to have a feature live on the web without a spec.
… what are the practical implications of that.
Devin: Within Apple, people who are writing documentation about how to use the web, don't have anything to refer to.
… there is no source of truth.
NickTR: So documentation that devs use is based on specs not source code.
Devin: Correct. Developers care about the API surface.
smcgruer_[EST]: It is also important that APIs be documented so that other browsers (existing or new) can implement the API (and not have to look at two source code repos)
smcgruer_[EST]: One option is to bring it back as its own spec that says "this is deprecated"
rbyers: There is precedent for this (e.g., touch events)
… what you want to document is what developers need to know to implement the API
rbyers: I think for touch events it was an Appendix to the full spec.
rose: Does "deprecated" means it won't be implemented on the web in the future?
Devin: No, not in practice.
<Zakim> nicktr, you wanted to express heeby-jeebies about SPC...
nicktr: Are there lessons here for SPC?
… regarding SPC dependency on PR API?
smcgruer_[EST]: It's a fair concern. In a perfect world, this would likely happen after we would make a decision about the dependency on PR API
… we at Chrome commit to owning the deprecation in case we redesign the API
<Zakim> smcgruer_[EST], you wanted to respond
Devin: It's impossible to future proof specs; don't be dissuaded
1) Publish a spec for addresses and their semantics in PR API that calls them deprecated
2) Develop PR API to satisfy the privacy consideration (incremental address info collection)
Which do you prefer?
Devin: For idea #2, our goal is to have "what we had before written somewhere". We need the old thing documented in any case.
<nicktr> I am hearing 1) then 2) from Devin
Ian: Are you interested in enhancing the API?
Devin: We might be interested.
Ian: 1
<careyf> do 1, then 2
NickTR: I am hearing 1 then 2 in any case
3) Both in that order
<nicktr> I like 3)
<benoit> 3
ACTION: Ian to work with editors to draft a deprecated feature description.
<rbyers> FYI, some history on the TouchEvents precedent. We eventually were able to remove the API (document.createTouch) so it's now gone from any spec. https://
Ian: Any things about PR API from Apple perspective?
Devin: We've added about 6 or 7 features in past couple of years:
(to ApplePay.js)
1) Recurring payments
2) Deferred payments
3) Automatic reload payments (for transport cards, for example)
4) Order details (when an order is finished, the web site can provide the details of the order, which links to an "order bundle object" that contains information about the order, which is surfaced in the wallet app
5) Marketplaces / multiple-merchant experiences
6) Coupon codes.
… you will get events when user changes coupon codes.
… when the coupon code changes, the payment method changes.
… rather an event indicating some data changed
7) Shipping address variants (like pickup location)
8) Support for ApplePay in 3p webviews on iOS
… so ApplePay works in other browsers (using web views) on iOS.
Devin: We would like to see PR API take on these features.
[Nick provides a bit of history on PR API]
smcgruer_[EST]: What changes to the shape of the API would you like to see?
Devin: I think modifiers as specified are not helpful for some of these new features
… for example, it would be great to be able to add (extra) line items for a given payment method
smcgruer_[EST]: Lots today goes in the data object (to allow for innovation). But it would be interesting to have some additional structure. What is the incentive for a payment app to use API surface if it's easier to stick in a JSON blob?
<smcgruer_[EST]> https://
<smcgruer_[EST]> 'object data;'
Ian: What's the user benefit for these features?
… e.g., coupon codes benefit UX
Devin: I forgot one - shipping type ranges
Devin: Most of these changes have to do with clearer presentation in the UX.
Ian: Any thoughts from Google and Samsung on these features?
smcgruer_[EST]: We'd like to make this work for any payment app.
rbyers: The main value of structured data is to enable the browser to do something with it.
smcgruer_[EST]: Nobody uses the built-in browser sheet, so the coupon code can already be used in data object.
NickTR: We don't want to constrain the broader shopping experience; we want commonality around authentication.
magda_sypula: There had been conversation about creating a merchant cg.
Ian: We created a merchant cg but it did not gain traction
magda_sypula: Are people in the room interested in an IG or CG on shopping experience?
clinton: What's the goal?
magda_sypula: Shopping consistency across the web.
[Not much interest expressed in the room]
NickTR: The retail experience is a point of competition.
smcgruer_[EST]: We'd love a cg to hear from merchants
nickTR: Merchants are busy running their businesses.
Navigation tracking
Ben Kelly: I'm working at Google on "Bounce Track Mitigations"
… we want to increase privacy while not breaking things like payments.
[Ben explains navigation tracking as a work-around to storing cookies]
Ben: Navigation tracking can happen programmatically (does not require a user activation)
clinton: Are those separate domains on diagram on the screen?
Ben: yes
[What browsers are doing today]
Ben: Browsers are taking steps like deleting cookies set during detected bounce tracking or otherwise using ephemeral storage.
… Chrome team has published an explainer on what they'd like to do
https://
Ben: We'd like some convergence among browsers on how things work. Our initial proposal largely aligns with the Firefox solution.
… we are trying to detect "stateful bounces", then after some time delete storage for site that was bounced through, unless we can determine that the user has purposely chosen to use that site.
… e.g., previous interaction has taken place, or post-visit interaction before deletion time-out, or perhaps foreground view-time or other signals
[Slide on how this approach protects use cases we want]
Ben: Regarding payments, there are a large variety of flows. My understanding is that flows frequently use link decoration and server-side state management.
Ben: There are a few other use cases we are interested in (e.g., link shorteners)
Ian: Where are conversations happening on this topic?
Ben: Not yet sure where yet, but likely privacy CG
clinton: For these types of changes, many of these topics come back to third-party cookie access. Why is there no consumer choice for this type of behavior? E.g., a consumer chooses to allow a 3p cookie.
Ben: Storage Access API gives a site a way to prompt the user to consent to cookies.
Ben: There's a tension between lots of prompts (which people start to ignore when there are too many) and simply doing things on behalf of the user.
… how many users understand 3p cookies and bounce tracking?
… we are reluctant to show prompts that could scare user or that might be so insipid as to not communicate clearly what's happening.
… there are real UX challenges here.
… but perhaps there's a mode where the user can say "I don't mind being tracked." But we want the web to be safe by default.
clinton: If you have a payment methodology that works on every site and uses a cookie to recognize the user (in a 3p context). In the checkout flow, the user can say "Do you want to be remembered on this device?" Then they are not remembered, which is confusing.
smcgruer_[EST]: There is no concept of "payment flow" on the web.
… we've been trying to solve the classification problem
<nicktr> notes that there *was* no concept of payment flow on the web until V1.0 Payment Request!
smcgruer_[EST]: e.g., federated identity work allows the browser to protect the user and know what the user has consented to
clinton: The bounce tracking change will impact payments (as does getting rid of 3p cookies)
Ben: To clarify, if the user interacts with the site, we won't delete the cookie.
… we want to use the interaction as the intentional action by the user...I've seen that I'm on the site.
… I'm mostly interested in payments use cases where the user is redirected WITHOUT USER AWARENESS.
SameerT: even if interaction is happening in an iframe?
Ben: No, it would have to be in 1p
smcgruer_[EST]: And note that invisible bounces would have to set state
Ben: I don't know whether we've decided whether iframe in same TLD would be exempted.
SameerT: Two use cases in payments we care about: (1) user recognition (2) user interactions with a cross-origin iframe such as the issuer.
NickTR: But there is user interaction in that 3p context.
Ben: Is there a scenario with an invisible bounce from a cross-origin iframe?
<nicktr> ian: specific ux helps solve the classification problem
<nicktr> ...then the question becomes "how do we know that a problem that deserves UX"
<Zakim> wanderview, you wanted to respond
benoit: When a bank tries to recognize you (the issuer), typically they are looking to see whether you are using a device they recognize. Then in the subsequent purchase they may redirect you in the background to a site where they check to see whether this is the same device.
… there are also PCI issues that might be relevant to payments use cases.
<jeanluc> Could 3DS Method URL fall into this scope ?
Ben: In a scenario where there's only ever been an interaction in an iframe, I think that iframe partitioning will break the use case (rather than redirect)
… if the user interacts with the site during a step-up, then some storage would not be deleted.
clinton: Recognizing that you came into the room with a simple request, I think that there are some use cases ... unlikely we will solve today.
Devin: I would guess (without really knowing) that Safari is even more strict. If you already support Safari, may not notice.
rbyers: There's a principle here which is: when a browser sends information from one entity to another, users want to be able to intercede.
… where are there use cases where information is shared with invisible third parties.
… something like SPC is helpful to make clear where information is being shared
<Zakim> dezell, you wanted to ask about a historical lens
dezell: Back to the point about merchants participating in stds bodies, at NACS we do surveys. We hear different answers from developers and from business people.
dezell: Some pain points include hardware support, edge computing
dezell: One observation about the merchant BG is that we tried during COVID; might be worth trying again.
clinton: I think that there's a lot of need within the industry to create some level of consistency with payments. There's an option question about boundary between shopping and payments.
… there are many industry bodies trying to understand their scope.
… I could support a CG for merchants,.
magda_sypula: +1
… Apple would be interested.
[Coffee for 22 minutes]
Privacy issues related to PR API and Payment Handler
smcgruer_[EST]: Part of this presentation is about payment handlers, but also helps to communicate how Google his thinking generally about privacy
[Recap of payment handlers, and demo of payment handlers on Chrome]
smcgruer_[EST]: Some challenges with pop-ups - e.g., users lose them.
… payment handler creates a tab modal window ... you can't get back to window content unless you interact with the modal window.
… on mobile, the UX is very different...without payment handler, the only way you can get to a payment app is open a new tab which completely hides the underlying page
… but payment handler gives a native-like payment experience with a smaller modal window that takes up only a portion of the mobile screen
… note that payment apps are service workers with web pages; this will be part of the story.
… the payment handler is considered a 1p context (equivalent to a popup)
[Stephen revisits the payment handler architecture]
[Privacy Sandbox revisited]
[smcgruer_[EST] gives a rough definition of the anti-tracking goals of the privacy sandbox and similar efforts in other browsers]
SameerT: Cardholders sign agreements with banks that some data will be collected for fraud collection. Suppose that's an agreement with b.com.
… when the browse on a.com, the consent with b.com is not known in the browser.
… so is your expectation that the consent is limited to the browser context?
smcgruer_[EST]: It's blurry. The user can volunteer information to a site (e.g., email or cardholder) that is identifying. But in this case the user has volunteered the number. (But cf tokenization)
SameerT: Is the problem linking together ACS's collected data with the user-provided data?
smcgruer_[EST]: Those are related questions, mostly under anti-tracking efforts.
Ben: Cf the antifraud CG
smcgruer_[EST]: We are removing 3p cookies so that the iframe doesn't know anymore who it thinks the user is.
[Privacy Sandbox and Payment Handler concerns]
smcgruer_[EST]: At a high level with payment handlers, there are a series of concerns around silent sharing of data.
<wanderview> slides from previous talk on bounce tracking: https://
smcgruer_[EST]: so the question is: how do we build an ecosystem that works for users without allowing malicious parties sharing information that hurts the payments ecosystem.
… some other questions: should we drop payment handlers and rely on popups?
… or should we go further and make them more a part of the browser (but how to prevent malicious behavior)
… can we do isReadyToPay in a privacy protecting way.
Ian: isReady was mostly about only showing buttons when available
smcgruer_[EST]: There are new techs that exist now that do similar thing (e.g., FedCM is doing something like that)
… there's another one called a "fenced frame" that limits communications with parent site, and for that reason it is given more powers.
… but these fenced frames have to take up space on the page
… I am aware of payment apps that have isReadyToPay Apis (google pay, apple pay, shop pay)
<rbyers> FedCM explainer: https://
<rbyers> Google One tap sign-in: https://
[Some discussion of FedCM]
smcgruer_[EST]: People have N identities on the web
… not just one
Rose: With isReadyToPay, how do you know that the user is logged into a payment app?
smcgruer_[EST]: the canmakepaymentevent is fired to a service worker. It's a 1p context. It can make a network request to a parent web site to find out, e.g., whether the user is logged in
Rose: You wouldn't want to not show the button just because they are not logged in, right?
smcgruer_[EST]: Some merchants, I believe, want to only show buttons if the user is logged in
… but it's an edge case; some payment app providers always want the button shown
nicktr: Regarding opening the modal window, I think that only use case for that was the super-accelerated payment user experience.
smcgruer_[EST]: We are confident that we will require a window to be opened.
nick: If you have more than one instrument that you could pay with, you will always get a sheet to pick a handler.
nick: Payment handlers is the way we keep the ecosystem open
rbyers: Not only do we want an open ecosystem, our integration with Google Pay works as a payment handler
erhardbrand: Can I invoke FIDO within a payment handler?
smcgruer_[EST]: That *should* work.
smcgruer_[EST]: Not everything works in the payment handler modal window.
https://
Ian: What happens next?
smcgruer_[EST]: We are looking at making some changes in our implementation of PR API; some of those may not require changes to specs.
… for others we will do pull requests against (mostly) the payment handler API
… but the bigger question is: if we chip away at payment handler API, do we remove its value?
… as a reminder, think more broadly about how this topic (privacy sandbox) affects various payment flows.
Next teleconference: 29 Sep
Nick: Thanks everyone!
Joint Meeting with Other Groups
In the afternoon, the WPWG met jointly with the WPSIG, Antifraud CG, and Web Authentication WG; see minutes of joint discussion (also available as PDF version on w3.org.