Web Payments Working Group

Proposed changes to reduce scope of Payment Request API v1

<Ian> Pull request 955

ian: we have a pull request that would substantially change payment request v1.0
… we had several things to wrap up before advancing on the Rec-track:
… 1) privacy issue raised about oversharing address info
… 2) issues from i18n
… we are actively working through the latter
… and on the former, we are proposing removing the "check out" features of payment request
… we don't think this affects the Webkit implementation
… and on the chrome implementation, we believe that the checkout features are not much used
… This pull request (955) would push browser-stored address data communication into the payment method specific implementations
… which would only leave a handful of strings left in payment request which would require things like "lang" and "dir"
… We think it's a good idea as it makes the payment request specification much slimmer
...In practise, if there is consensus, we would merge the pull request, clear up the test suite (because we would be removing features), go back through Candidate Recommendation for the slimmer spec, then after a small pause, go through proposed recommendation
… with the hope that we would be done by the summer and then we can focus on SPC

Gerhard: Generally favour in removing of address from the payment request spec
… removing PII is a good idea
… I wanted to ask if this affected "Basic Card"?

ian: one of the features we wanted to maintain in PR API is the ability to make dynamic total updates; the API retains that ability through an instrument selection update event. We also think that "incremental data retrieval" that was part of the original issue from Sam Weiler is supported by the retry() capability combined with a payment app redispatching the instrument update event. However, a payment method would have to support this behavior, and Basic Card does not currently do so. Therefore we are also proposing to "Deprecate" Basic Card as a specification. In addition, Chrome has announced they are deprecating their built-in support for Basic Card.

Gerhard: so we're saying Basic Card would be removed? No default implementation?

ian: yes, that is correct. There wouldn't be a W3C recommendation for basic card

smcgruer_[EST]: We see almost no usage of basic card and it's our intention to deprecate

<Ian> nicktr: I think that a slimmer API will be a better API.

<Ian> ...will help with implementations (and maintenance)

<Ian> ...smaller attack surface

ian: we need to merge the pull request and finish the i18n changes
… we are also looking at removing modifiers
… because that would further simplify the API. But we need to hear more about the extent of their usage.

smcgruer_[EST]: we aren't sure how well used the modifiers are
… and we're asking the people we know to have implemented

Action: Stephen to report back with some info on modifier usage (heuristics ok!)

ian: modifiers would be a separate edit if we proceeded

<Ian> PROPOSED: Merge pull request 955

<nicktr> +1

<smcgruer_[EST]> +1

<Gerhard> +1

<AdrianHB> +100!

<Ian> [No objections heard]

<Ian> SO RESOLVED

Action: Ian to work with editors to merge PR 955 and resolve remaining open I18N issue

<nicktr> AdrianHB: I assume we will wait for a pull request on modifiers?

<AdrianHB> Ian: also data from browsers on usage

Action: Ian to work with Editors on a pull request to remove modifier; pursuant to Stephen's action to get data about modifier usage

hasEnrolledInstrument proposal

[Presentation by Mathieu Hofman]

Mathieu: I'd like to introduce an idea for changing enumeration of payment methods in a more privacy-preserving way. Please note I am now an Invited Expert, but worked on this idea while at Stripe.
… the idea is motivated by the experience people have had implementing PR API
… in PR API, the browser is the interop layer between merchant and user (+ instrument)
… goals for this API include low friction and also strong privacy
… the API should not leak information about who the user is, what sites they visit, etc.
… there are a few invariants and assumptions:

1) origin security policy

2) risk assessment based on data collection

3) Browsers limiting 3rd party access to cookies to prevent tracking

There are a couple of privacy considerations:

- merchant or 3p should not learn about the customer unless the customer is performing a payment action

- payment handler should not learn about which merchants the customer visit, unless the customer performs a payment action with an instrument managed by the handlers

Threats are fingerprinting and 3p tracking

[Assumptions for customer]

* may have different types of payment instruments saved with merchant or in payment app or not saved anywhere

* customer may not want to save instruments in the browser (e.g., guest checkout at friend's house)

[Assumptions for merchant]

* merchant wants to support some of the customer's instruments

* Wants to increase conversion...by offering options user likes, reducing friction, and keeping user in the experience controlled (and potentially optimized) by the merchant
… so merchant wants to show supported payment methods without requiring a user action.
… in practice this means showing buttons for payment methods the user has that are ready to pay
… merchants may want to avoid onboarding during a transaction

[Handler implementation constraints]
… need to decide which if any instruments are available to when requested
… you likely have your own proprietary logic that needs to be run at transaction time and would not be offloaded to the browser

[Example of merchant integration]

- show a list of branded card wallet buttons

- only display a button for which user has a card ready to pay

- merchant's processor integrates with 2-3 payment methods.

[Current situation]

hasEnrolledInstrument() has a quota to prevent fingerprinting
… as a result, this requires merchants to choose between unbranded buttons or allowing instrument onboarding in all wallets
… with multiple methods behind a single click, the browser has to implement a selector ('the sheet')

[PROPOSAL PART I]

- introduce enumeratePayments
… similar input data, but returns a list of opaque identifiers representing "AVAILABLE" payment methods
… the merchant learns HOW MANY payment methods satisfy the constraints expressed by their input.
… the browser generates unique ids. The payment handler helps inform that information by answering "yes" or "no"

[PROPOSAL PART II]
… Display. The merchant needs to display usable UI
… the merchant can display "wallet buttons" the reference the opaque identifiers returned by the browser.
… and there's some generic information to inform the presentation of the button
… through this flow, the merchant does not know which payment handler the user has selected.
… once the handler has been selected, the user has expressed consent and information can begin to be shared.

WebComponent provides DOM encapsulation
… some additional requirements:

a) No intrinsic size (from a CSS perspective) to shield information
… the browser needs to render these buttons on behalf of the merchant.
… reviewing how this proposal addresses privacy concerns:

a) drive by website has limited info about user
… only how many compatible wallets are available
… BUT a malicious payment handler could extract information about a website.

[PROPOSAL PART III]
… replace service worker implementation of payment handler with a Worklet (CanIUse info on Worklets)
… grant PH only read-only access to storage
… no network access or other communication channels
… can only answer browser's invocation
… after customer makes selection, payment handler has access to normal APIs

[Open Questions]

* how does modal window communicate with browser? Keep SW for this only?

* How do we standardized payment method presentation details? (Manifest? Worklet APIs?)

* Are payment details needed at enumeration time?
… (don't know)

* Merchant verification. There are handlers that don't want their buttons to be visible if the merchant is not allowed to. So how do you say "this origin is not allowed to use this wallet" without leaking information about the user?

[Payment Instrument Enumeration]
… I just talked about payment methods, but could we expand this concept to INSTRUMENT enumeration?
… e.g., to allow the display of card on file?
… but raises questions about de-duplication

<Zakim> nicktr, you wanted to ask about merchants displaying unsupported payment methods

nicktr: One use case you raised is "merchant only wants to display pay buttons for things that are supported"
… with this proposal, the browser displays in its own interface..but I don't think this solves for the merchant showing buttons not supported by PR API.

mathieu: Let's say there are two wallets integrated with PR API, and another not integrated.
… the enumeration would return 2 opaque APIs and the page would include 2 enumeration buttons. And before or after that, they would display the non-PR API button

nicktr: How does the merchant de-dup them?

mathieu: I would suppose the merchant would only enumerate wallets they want to support through PR API.

nicktr: Edge case is "supported through PR API but the user doesn't have support for them in browser"

AdrianHB: The payment method could have an option "we support enrollment flows"
… then it's up to the merchant to decide whether to accept the user enrolling during the transaction

nicktr: Would wallets always want to be shown?

AdrianHB: I hear from some wallet providers that in practice they would not always want to be shown for enrollment; don't want risk of bad UX

mathieu: handlers can also lie today about whether they have enrolled instruments

AdrianHB: There is some precedence here about how hardware is made discoverable ... e.g., webrtc needs to know what hardware you have.
… they get an opaque enumeration not a concrete list of devices.

mathieu: This proposal is based on the WebRTC work

<Zakim> smcgruer_[EST], you wanted to ask a naive question about specificity of method types

smcgruer_[EST]: How many buttons would a merchant typically want to show? and how specific are the method types?
… are we really hiding information?

mathieu: In the future when there are more wallets than just two, it becomes more important

smcgruer_[EST]: I think this is a good direction for this proposal

<nicktr> ian: can you say more about the display of the buttons? They are presumably not in the DOM and the merchant is not learning about them?

mathieu: It's similar to how some wallets tell you to display their buttons
… WebComponents shields the details...the merchant cannot probe the details, but can still learn about the display (e.g., size, color) and so some work has to be done to shield displayed information
… iframe could be a mechanism to shield information.

IJ: Do WebComponents do the right thing already today?

mathieu: Shadow DOM does the shielding work
… this was used by video player to render controls
… shadow root is what you're talking about

Ian: Next steps?

Mathieu: I won't have many more chances to champion this. I've presented this to a few people; Google has been evaluating the proposal.
… I have a document with some additional details.

Action: Mathieu to share document on this proposal publicly or let us know that's not possible

Next meeting

13 May