IRC log of wpwg on 2021-04-29

Timestamps are in UTC.

13:40:48 [RRSAgent]

RRSAgent has joined #wpwg

13:40:48 [RRSAgent]

logging to https://www.w3.org/2021/04/29-wpwg-irc

13:40:54 [Ian]

Meeting: Web Payments Working Group

13:41:06 [Ian]

Agenda: https://github.com/w3c/webpayments/wiki/Agenda-20210429

13:41:10 [Ian]

Chair: Nick

13:41:12 [Ian]

Scribe: Ian

13:41:18 [Ian]

agenda+ hasEnrolledInstrument proposal

13:41:40 [Ian]

agenda+ Proposed changes to reduce scope of Payment Request API v1

13:46:28 [RRSAgent]

I have made the request to generate https://www.w3.org/2021/04/29-wpwg-minutes.html Ian

14:00:15 [Ian]

present+

14:00:19 [Ian]

present+ Mathieu_Hofman

14:00:22 [Ian]

present+ Tom_Bellenger

14:00:29 [Ian]

present+ Nick_Telford-Reed

14:00:32 [AdrianHB]

present+

14:00:42 [Ian]

present+ Jean-Michel_Girard

14:00:47 [tm]

tm has joined #wpwg

14:00:56 [Ian]

present+ Bastien_Latge

14:01:04 [Ian]

present+ Anne_Pouillard

14:01:15 [Bastien]

Bastien has joined #WPWG

14:01:28 [Ian]

present+ Gavin_Shenker

14:01:35 [Ian]

present+ David_Benoit

14:01:36 [Bastien]

present+

14:01:43 [Ian]

present+ Jean-Luc_Di_Manno

14:02:15 [RRSAgent]

I have made the request to generate https://www.w3.org/2021/04/29-wpwg-minutes.html Ian

14:02:22 [Gavin]

Gavin has joined #WPWG

14:02:57 [Ian]

present+ Stephen_McGruer

14:03:10 [jmgirard]

jmgirard has joined #wpwg

14:03:44 [Ian]

present+ Gerhard_Oosthuizen

14:04:00 [Ian]

zakim, take up item 2

14:04:00 [Zakim]

agendum 2 -- Proposed changes to reduce scope of Payment Request API v1 -- taken up [from Ian]

14:04:05 [Ian]

present+ Vincent_Kuntz

14:04:14 [nicktr]

scribenick: nicktr

14:04:36 [Ian]

-> https://github.com/w3c/payment-request/pull/955 Pull request 955

14:04:54 [Gerhard]

Gerhard has joined #WPWG

14:04:56 [nicktr]

ian: we have a pull request that would substantially change payment request v1.0

14:05:14 [Gerhard]

Present+

14:05:18 [nicktr]

...we had several things to wrap up:

14:05:30 [nicktr]

...1) oversharing address info

14:05:39 [nicktr]

...2) issues from i18n

14:05:55 [vkuntz]

vkuntz has joined #wpwg

14:05:57 [nicktr]

...we are working through the latter

14:06:14 [vkuntz]

present+

14:06:16 [nicktr]

...and on the former, we are proposing removing the "check out" features of payment request

14:06:20 [Ian]

present+ Erhard_Brand

14:06:33 [nicktr]

...we don't think this affects the Webkit implementation

14:07:02 [clinton]

clinton has joined #wpwg

14:07:02 [nicktr]

...and on the chrome implementation, we believe that the checkout features are not much used

14:07:46 [nicktr]

...This pull request (955) would push browser-stored address data communication into the payment method specific implementations

14:08:25 [nicktr]

...which would only leave a handful of strings left in payment request which would require things like "lang" and "dir"

14:08:46 [nicktr]

...We think it's a good idea as it makes the payment request specification much slimmer

14:09:28 [mhofman]

mhofman has joined #wpwg

14:09:44 [mhofman]

https://docs.google.com/presentation/d/1TiUEAiX4h70cz6PYMyh51DAaNBlehVVO11txET4BoJI/edit?usp=sharing

14:10:02 [nicktr]

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

14:10:29 [Ian]

present+ Clinton_Allen

14:10:34 [nicktr]

...with the hope that we would be done by the summer and then we can focus on SPC

14:10:36 [Ian]

[No objections heard]

14:10:39 [Gerhard]

q+

14:10:43 [Ian]

ack G

14:11:16 [Ian]

scribnick: Ian

14:11:23 [nicktr]

Gerhard: Generally favour in removing of address from the payment request spec

14:11:30 [Ian]

scribenick: Nicktr

14:11:35 [nicktr]

...removing PII is a good idea

14:11:51 [nicktr]

...I wanted to ask if this affected "Basic Card"?

14:12:30 [nicktr]

ian: one of the features that was interesting was "total update" and that event remains in place in the API

14:12:56 [nicktr]

...but it's no longer based on browser stored information - so the payment handler would have to fire the event

14:13:32 [nicktr]

...we believe incremental updating is possible but this remains to be proven

14:13:46 [nicktr]

...which would allow merchants to incrementally ask for information

14:13:48 [Fawad]

Fawad has joined #wpwg

14:14:30 [smcgruer_[EST]]

q+ for Chrome's plans

14:14:36 [nicktr]

...However, Basic Card doesn't support incremental communication

14:14:41 [AdrianHB]

q?

14:15:02 [nicktr]

...but we heard that Basic Card would be deprecated by Chrome

14:15:10 [Ian]

present+ Fawad_Nisar

14:15:30 [nicktr]

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

14:15:54 [nicktr]

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

14:16:34 [Ian]

smcgruer_[EST]: Yes, it's our intention to deprecate Basic Card ,which has near 0 adoption

14:16:34 [nicktr]

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

14:16:57 [nicktr]

q+

14:17:01 [nicktr]

ack smcgruer_[EST]

14:17:01 [Zakim]

smcgruer_[EST], you wanted to discuss Chrome's plans

14:17:06 [Ian]

ack nicktr

14:17:09 [Ian]

scribenick: nicktr

14:17:21 [Ian]

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

14:17:30 [Ian]

...will help with implementations (and maintenance)

14:17:37 [Ian]

...smaller attack surface

14:17:39 [Ian]

q+

14:17:53 [nicktr]

ack Ian

14:18:17 [nicktr]

ian: we need to merge the pull request and finish the i18n changes

14:18:26 [nicktr]

...we are also looking at modifiers

14:18:38 [nicktr]

...and we need to look at the data

14:18:44 [smcgruer_[EST]]

q+

14:18:58 [nicktr]

ack smcgruer_[EST]

14:19:16 [nicktr]

smcgruer_[EST]: we aren't sure how well used the modifiers are

14:19:57 [nicktr]

...and we're asking the people we know to have implemented

14:20:25 [Ian]

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

14:20:33 [nicktr]

q?

14:20:56 [nicktr]

ian: modifiers would be a separate edit if we proceeded

14:21:06 [Ian]

PROPOSED: Merge pull request 955

14:21:13 [nicktr]

+1

14:21:14 [smcgruer_[EST]]

+1

14:21:18 [Gerhard]

+1

14:21:41 [AdrianHB]

+1

14:21:43 [RRSAgent]

I have made the request to generate https://www.w3.org/2021/04/29-wpwg-minutes.html nicktr

14:21:45 [Ian]

SO RESOLVED

14:21:48 [AdrianHB]

+100

14:22:00 [Ian]

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

14:22:06 [Ian]

zakim, close item 2

14:22:06 [Zakim]

agendum 2, Proposed changes to reduce scope of Payment Request API v1, closed

14:22:08 [Zakim]

I see 1 item remaining on the agenda:

14:22:08 [Zakim]

1. hasEnrolledInstrument proposal [from Ian]

14:22:09 [Ian]

zakim, take up item 1

14:22:09 [Zakim]

agendum 1 -- hasEnrolledInstrument proposal -- taken up [from Ian]

14:22:30 [Ian]

scribenick: Ian

14:22:41 [nicktr]

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

14:22:56 [AdrianHB]

Ian: also data from browsers on usage

14:22:57 [Ian]

ACTION: Ian to work with Editors on a pull request to remove modifier; pursuant to Stephen's action

14:23:56 [Ian]

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.

14:24:08 [Ian]

...the idea is motivated by the experience people have had implementing PR API

14:24:40 [Ian]

...in PR API, the browser is the interop layer between merchant and user (+ instrument)

14:24:52 [Ian]

...goals for this API include low friction and also strong privacy

14:25:07 [Ian]

..the API should not leak information about who the user is, what sites they visit, etc.

14:25:16 [Ian]

...there are a few invariants and assumptions:

14:25:20 [Ian]

1) origin security policy

14:25:25 [JeanLuc__]

JeanLuc__ has joined #wpwg

14:25:25 [Ian]

2) risk assessment based on data collection

14:25:37 [Ian]

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

14:26:00 [Ian]

present+ Arno_van_der_Merwe

14:26:20 [Ian]

...there are a couple of privacy considerations:

14:26:36 [Ian]

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

14:26:55 [Ian]

- 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

14:27:05 [Ian]

Threats are fingerprinting and 3p tracking

14:27:31 [RRSAgent]

I have made the request to generate https://www.w3.org/2021/04/29-wpwg-minutes.html nicktr

14:27:42 [Ian]

[Assumptions for customer]

14:27:56 [Ian]

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

14:28:11 [Ian]

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

14:28:16 [Ian]

[Assumptions for merchant]

14:28:23 [Ian]

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

14:29:00 [Ian]

* Wants to increase conversion...by offering options user likes, reducing friction, and keeping user in the experience controlled (and potentially optimized) by the merchant

14:29:11 [Ian]

present+ John_Fontana

14:29:37 [Ian]

...so merchant wants to show supported payment methods without requiring a user action.

14:29:49 [Ian]

...in practice this means showing buttons for payment methods the user has that are ready to pay

14:30:47 [Ian]

...merchants may want to avoid onboarding during a transaction

14:31:09 [Ian]

[Handler implementation constraints]

14:31:20 [Ian]

...need to decide which if any instruments are available to when requested

14:31:38 [Ian]

...you likely have your own proprietary logic that needs to be run at transaction time and would not be offloaded to the browser

14:31:55 [Ian]

[Example of merchant integration]

14:32:00 [Ian]

- show a list of branded card wallet buttons

14:32:06 [Ian]

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

14:32:23 [Ian]

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

14:32:26 [Ian]

[Current situatino]

14:32:37 [Ian]

hasEnrolledInstrument() has a quota to prevent fingerprinting

14:32:52 [Ian]

...as a result, this reuiqres merchants to choose between unbranded buttons or allowing instrument onboarding in all wallets

14:32:57 [nicktr]

q?

14:33:12 [Ian]

...with multiple methods behind a single click, the browser has to implement a selector ('the sheet')

14:33:27 [Ian]

[PROPOSAL PART I]

14:33:36 [Ian]

- introduce enumeratePayments

14:34:13 [Ian]

....similar input data, but returns a list of opaque identifiers representing "AVAILABLE" payment methods

14:34:31 [Ian]

...the merchant learns HOW MANY payment methods satisfy the constraints expressed by their input.

14:34:59 [Ian]

...the browser generates unique ids. The payment handler helps inform that information by answering "yes" or "no"

14:35:09 [Ian]

[PROPOSAL PART II]

14:35:20 [Ian]

...Display. The merchant needs to display usable UI

14:35:41 [Ian]

...the merchant can display "wallet buttons" the reference the opaque identifiers returned by the browser.

14:36:02 [Ian]

...and there's some generic information to inform the presentation of the button

14:36:37 [Ian]

...through this flow, the merchant does not know which payment handler the user has selected.

14:36:58 [Ian]

...once the handler has been selected, the user has expressed consent and information can begin to be shared.

14:37:10 [Ian]

WebComponent provides DOM encapsulation

14:37:14 [Ian]

...some additional requirements:

14:37:27 [Ian]

a) No intrinsic size (from a CSS perspective) to shield information

14:37:45 [Ian]

....the browser needs to render these buttons on behalf of the merchant.

14:38:00 [Ian]

...reviewing how this proposal addresses privacy concerns:

14:38:07 [Ian]

a) drive by website has limited info about user

14:38:16 [Ian]

..only how many compatible wallets are available

14:38:46 [Ian]

...BUT a malicious payment handler could extract information about a website.

14:38:52 [Ian]

[PROPOSAL PART III]

14:39:02 [Ian]

...replace service worker implementation of payment handler with a "workout"

14:39:13 [Ian]

...grant PH only read-only access to storage

14:39:21 [Ian]

...no network access or other communication channels

14:39:28 [Ian]

...can only answer browser's invocation

14:39:38 [Ian]

...after customer makes selection, payment handler has access to normal APIs

14:39:41 [AdrianHB]

q?

14:39:57 [Ian]

-> https://developer.mozilla.org/en-US/docs/Web/API/Worklet Worklet

14:40:17 [Ian]

-> https://caniuse.com/?search=worklet CanIUse info on Worklets

14:40:34 [Ian]

...supported in edge, firefox, chrome, opera, android, opera mobile, etc

14:40:42 [Ian]

..but not fully supported in webkit

14:40:53 [Ian]

[Open Questions]

14:41:18 [Ian]

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

14:41:35 [Ian]

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

14:41:40 [Ian]

* Are payment details needed at enumeration time?

14:42:04 [Ian]

...(don't know)

14:42:59 [Ian]

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

14:43:27 [Ian]

[Payment Instrument Enumeration]

14:43:42 [Ian]

...I just talked about payment methods, but could we expand this concept to INSTRUMENT enumeration?

14:43:54 [Ian]

...e.g., to allow the display of card on file?

14:44:02 [Ian]

..but raises questions about de-duplication

14:44:17 [nicktr]

q+ to ask about merchants displaying unsupported payment methods

14:44:20 [Ian]

ack nicktr

14:44:20 [Zakim]

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

14:44:31 [AdrianHB]

q?

14:44:49 [Ian]

nicktr: One use case you raised is "merchant only wants to display pay buttons for things that are supported"

14:45:17 [Ian]

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

14:45:29 [Ian]

mathieu: Let's say there are two wallets integrated with PR API, and another not integrated.

14:46:00 [Ian]

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

14:46:05 [Fawad_]

Fawad_ has joined #wpwg

14:46:37 [Ian]

nicktr: How does the merchant de-dup them?

14:46:50 [Ian]

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

14:47:26 [Ian]

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

14:47:36 [Ian]

AdrianHB: The payment method could have an option "we support enrollment flows"

14:47:48 [Ian]

..then it's up to the merchant to decide whether to accept the user enrolling during the transaction

14:48:34 [Ian]

q?

14:49:09 [Ian]

nicktr: Would wallets always want to be shown?

14:49:36 [Ian]

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

14:49:38 [nicktr]

q?

14:49:51 [Ian]

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

14:50:28 [Ian]

AdrianHB: There is some precent here about how hardware is made discoverable ... e.g., webrtc needs to know what hardware you have.

14:50:39 [RRSAgent]

I have made the request to generate https://www.w3.org/2021/04/29-wpwg-minutes.html nicktr

14:50:49 [Ian]

...they get an opaque enumeration not a concrete list of devices.

14:50:56 [Ian]

mathieu: This proposal is based on the WebRTC work

14:51:09 [smcgruer_[EST]]

q+ naive question about specificity of method types

14:51:12 [Ian]

q+

14:51:34 [nicktr]

q+ smcgruer_[EST] to ask a naive question about specificity of method types

14:51:38 [nicktr]

ack smcgruer_[EST]

14:51:39 [Zakim]

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

14:51:50 [Ian]

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

14:52:35 [Ian]

...are we really hiding information?

14:53:04 [Ian]

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

14:53:44 [Ian]

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

14:54:17 [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?

14:54:38 [Ian]

mathieu: It's similar to how some wallets tell you to display their buttons

14:55:27 [Ian]

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

14:55:55 [Ian]

...iframe could be a mechanism to shield information.

14:57:02 [Ian]

IJ: Do WebComponents do the right thing already today?

14:57:12 [Ian]

mathieu: Shadow DOM does the shielding work

14:57:36 [Ian]

...this was used by video player to render controls

14:57:40 [Ian]

...shadow root is what you're talking about

14:57:47 [Ian]

q?

14:57:49 [Ian]

ack me

14:58:02 [Ian]

Ian: Next steps?

14:58:33 [Ian]

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.

14:58:50 [Ian]

...I have a document with some additional details.

14:59:04 [Ian]

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

14:59:38 [Ian]

Topic: Next meeting

14:59:40 [Ian]

13 May

14:59:45 [RRSAgent]

I have made the request to generate https://www.w3.org/2021/04/29-wpwg-minutes.html Ian

14:59:52 [Ian]

RRSAGENT, set logs public

14:59:53 [Bastien]

Bastien has left #wpwg

15:00:00 [tm]

tm has left #wpwg

15:00:16 [Ian]

rrsagent, bye

15:00:16 [RRSAgent]

I see 4 open action items saved in https://www.w3.org/2021/04/29-wpwg-actions.rdf :

15:00:16 [RRSAgent]

ACTION: Stephen to report back with some info on modifier usage (heuristics ok!) [1]

15:00:16 [RRSAgent]

recorded in https://www.w3.org/2021/04/29-wpwg-irc#T14-20-25

15:00:16 [RRSAgent]

ACTION: Ian to work with editors to merge PR 955 and resolve remaining open I18N issue [2]

15:00:16 [RRSAgent]

recorded in https://www.w3.org/2021/04/29-wpwg-irc#T14-22-00

15:00:16 [RRSAgent]

ACTION: Ian to work with Editors on a pull request to remove modifier; pursuant to Stephen's action [3]

15:00:16 [RRSAgent]

recorded in https://www.w3.org/2021/04/29-wpwg-irc#T14-22-57

15:00:16 [RRSAgent]

ACTION: Mathieu to share document on this proposal publicly or let us know that's not possible [4]

15:00:16 [RRSAgent]

recorded in https://www.w3.org/2021/04/29-wpwg-irc#T14-59-04

15:00:18 [Ian]

zakim, bye

15:00:18 [Zakim]

leaving. As of this point the attendees have been Ian, Mathieu_Hofman, Tom_Bellenger, Nick_Telford-Reed, AdrianHB, Jean-Michel_Girard, Bastien_Latge, Anne_Pouillard,

15:00:18 [Zakim]

Zakim has left #wpwg