13:40:48 RRSAgent has joined #wpwg 13:40:48 logging to https://www.w3.org/2021/04/29-wpwg-irc 13:40:54 Meeting: Web Payments Working Group 13:41:06 Agenda: https://github.com/w3c/webpayments/wiki/Agenda-20210429 13:41:10 Chair: Nick 13:41:12 Scribe: Ian 13:41:18 agenda+ hasEnrolledInstrument proposal 13:41:40 agenda+ Proposed changes to reduce scope of Payment Request API v1 13:46:28 I have made the request to generate https://www.w3.org/2021/04/29-wpwg-minutes.html Ian 14:00:15 present+ 14:00:19 present+ Mathieu_Hofman 14:00:22 present+ Tom_Bellenger 14:00:29 present+ Nick_Telford-Reed 14:00:32 present+ 14:00:42 present+ Jean-Michel_Girard 14:00:47 tm has joined #wpwg 14:00:56 present+ Bastien_Latge 14:01:04 present+ Anne_Pouillard 14:01:15 Bastien has joined #WPWG 14:01:28 present+ Gavin_Shenker 14:01:35 present+ David_Benoit 14:01:36 present+ 14:01:43 present+ Jean-Luc_Di_Manno 14:02:15 I have made the request to generate https://www.w3.org/2021/04/29-wpwg-minutes.html Ian 14:02:22 Gavin has joined #WPWG 14:02:57 present+ Stephen_McGruer 14:03:10 jmgirard has joined #wpwg 14:03:44 present+ Gerhard_Oosthuizen 14:04:00 zakim, take up item 2 14:04:00 agendum 2 -- Proposed changes to reduce scope of Payment Request API v1 -- taken up [from Ian] 14:04:05 present+ Vincent_Kuntz 14:04:14 scribenick: nicktr 14:04:36 -> https://github.com/w3c/payment-request/pull/955 Pull request 955 14:04:54 Gerhard has joined #WPWG 14:04:56 ian: we have a pull request that would substantially change payment request v1.0 14:05:14 Present+ 14:05:18 ...we had several things to wrap up: 14:05:30 ...1) oversharing address info 14:05:39 ...2) issues from i18n 14:05:55 vkuntz has joined #wpwg 14:05:57 ...we are working through the latter 14:06:14 present+ 14:06:16 ...and on the former, we are proposing removing the "check out" features of payment request 14:06:20 present+ Erhard_Brand 14:06:33 ...we don't think this affects the Webkit implementation 14:07:02 clinton has joined #wpwg 14:07:02 ...and on the chrome implementation, we believe that the checkout features are not much used 14:07:46 ...This pull request (955) would push browser-stored address data communication into the payment method specific implementations 14:08:25 ...which would only leave a handful of strings left in payment request which would require things like "lang" and "dir" 14:08:46 ...We think it's a good idea as it makes the payment request specification much slimmer 14:09:28 mhofman has joined #wpwg 14:09:44 https://docs.google.com/presentation/d/1TiUEAiX4h70cz6PYMyh51DAaNBlehVVO11txET4BoJI/edit?usp=sharing 14:10:02 ...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 present+ Clinton_Allen 14:10:34 ...with the hope that we would be done by the summer and then we can focus on SPC 14:10:36 [No objections heard] 14:10:39 q+ 14:10:43 ack G 14:11:16 scribnick: Ian 14:11:23 Gerhard: Generally favour in removing of address from the payment request spec 14:11:30 scribenick: Nicktr 14:11:35 ...removing PII is a good idea 14:11:51 ...I wanted to ask if this affected "Basic Card"? 14:12:30 ian: one of the features that was interesting was "total update" and that event remains in place in the API 14:12:56 ...but it's no longer based on browser stored information - so the payment handler would have to fire the event 14:13:32 ...we believe incremental updating is possible but this remains to be proven 14:13:46 ...which would allow merchants to incrementally ask for information 14:13:48 Fawad has joined #wpwg 14:14:30 q+ for Chrome's plans 14:14:36 ...However, Basic Card doesn't support incremental communication 14:14:41 q? 14:15:02 ...but we heard that Basic Card would be deprecated by Chrome 14:15:10 present+ Fawad_Nisar 14:15:30 Gerhard: so we're saying Basic Card would be removed? No default implementation? 14:15:54 ian: yes, that is correct. There wouldn't be a W3C recommendation for basic card 14:16:34 smcgruer_[EST]: Yes, it's our intention to deprecate Basic Card ,which has near 0 adoption 14:16:34 smcgruer_[EST]: We see almost no usage of basic card and it's our intention to deprecate 14:16:57 q+ 14:17:01 ack smcgruer_[EST] 14:17:01 smcgruer_[EST], you wanted to discuss Chrome's plans 14:17:06 ack nicktr 14:17:09 scribenick: nicktr 14:17:21 nicktr: I think that a slimmer API will be a better API. 14:17:30 ...will help with implementations (and maintenance) 14:17:37 ...smaller attack surface 14:17:39 q+ 14:17:53 ack Ian 14:18:17 ian: we need to merge the pull request and finish the i18n changes 14:18:26 ...we are also looking at modifiers 14:18:38 ...and we need to look at the data 14:18:44 q+ 14:18:58 ack smcgruer_[EST] 14:19:16 smcgruer_[EST]: we aren't sure how well used the modifiers are 14:19:57 ...and we're asking the people we know to have implemented 14:20:25 ACTION: Stephen to report back with some info on modifier usage (heuristics ok!) 14:20:33 q? 14:20:56 ian: modifiers would be a separate edit if we proceeded 14:21:06 PROPOSED: Merge pull request 955 14:21:13 +1 14:21:14 +1 14:21:18 +1 14:21:41 +1 14:21:43 I have made the request to generate https://www.w3.org/2021/04/29-wpwg-minutes.html nicktr 14:21:45 SO RESOLVED 14:21:48 +100 14:22:00 ACTION: Ian to work with editors to merge PR 955 and resolve remaining open I18N issue 14:22:06 zakim, close item 2 14:22:06 agendum 2, Proposed changes to reduce scope of Payment Request API v1, closed 14:22:08 I see 1 item remaining on the agenda: 14:22:08 1. hasEnrolledInstrument proposal [from Ian] 14:22:09 zakim, take up item 1 14:22:09 agendum 1 -- hasEnrolledInstrument proposal -- taken up [from Ian] 14:22:30 scribenick: Ian 14:22:41 AdrianHB: I assume we will wait for a pull request on modifiers? 14:22:56 Ian: also data from browsers on usage 14:22:57 ACTION: Ian to work with Editors on a pull request to remove modifier; pursuant to Stephen's action 14:23:56 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 ...the idea is motivated by the experience people have had implementing PR API 14:24:40 ...in PR API, the browser is the interop layer between merchant and user (+ instrument) 14:24:52 ...goals for this API include low friction and also strong privacy 14:25:07 ..the API should not leak information about who the user is, what sites they visit, etc. 14:25:16 ...there are a few invariants and assumptions: 14:25:20 1) origin security policy 14:25:25 JeanLuc__ has joined #wpwg 14:25:25 2) risk assessment based on data collection 14:25:37 3) Browsers limiting 3rd party access to cookies to prevent tracking 14:26:00 present+ Arno_van_der_Merwe 14:26:20 ...there are a couple of privacy considerations: 14:26:36 - merchant or 3p should not learn about the customer unless the customer is performing a payment action 14:26:55 - 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 Threats are fingerprinting and 3p tracking 14:27:31 I have made the request to generate https://www.w3.org/2021/04/29-wpwg-minutes.html nicktr 14:27:42 [Assumptions for customer] 14:27:56 * may have different types of payment instruments saved with merchant or in payment app or not saved anywhere 14:28:11 * customer may not want to save instruments in the browser (e.g., guest checkout at friend's house) 14:28:16 [Assumptions for merchant] 14:28:23 * merchant wants to support some of the customer's instruments 14:29:00 * 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 present+ John_Fontana 14:29:37 ...so merchant wants to show supported payment methods without requiring a user action. 14:29:49 ...in practice this means showing buttons for payment methods the user has that are ready to pay 14:30:47 ...merchants may want to avoid onboarding during a transaction 14:31:09 [Handler implementation constraints] 14:31:20 ...need to decide which if any instruments are available to when requested 14:31:38 ...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 [Example of merchant integration] 14:32:00 - show a list of branded card wallet buttons 14:32:06 - only display a button for which user has a card ready to pay 14:32:23 - merchant's processor integrates with 2-3 payment methods. 14:32:26 [Current situatino] 14:32:37 hasEnrolledInstrument() has a quota to prevent fingerprinting 14:32:52 ...as a result, this reuiqres merchants to choose between unbranded buttons or allowing instrument onboarding in all wallets 14:32:57 q? 14:33:12 ...with multiple methods behind a single click, the browser has to implement a selector ('the sheet') 14:33:27 [PROPOSAL PART I] 14:33:36 - introduce enumeratePayments 14:34:13 ....similar input data, but returns a list of opaque identifiers representing "AVAILABLE" payment methods 14:34:31 ...the merchant learns HOW MANY payment methods satisfy the constraints expressed by their input. 14:34:59 ...the browser generates unique ids. The payment handler helps inform that information by answering "yes" or "no" 14:35:09 [PROPOSAL PART II] 14:35:20 ...Display. The merchant needs to display usable UI 14:35:41 ...the merchant can display "wallet buttons" the reference the opaque identifiers returned by the browser. 14:36:02 ...and there's some generic information to inform the presentation of the button 14:36:37 ...through this flow, the merchant does not know which payment handler the user has selected. 14:36:58 ...once the handler has been selected, the user has expressed consent and information can begin to be shared. 14:37:10 WebComponent provides DOM encapsulation 14:37:14 ...some additional requirements: 14:37:27 a) No intrinsic size (from a CSS perspective) to shield information 14:37:45 ....the browser needs to render these buttons on behalf of the merchant. 14:38:00 ...reviewing how this proposal addresses privacy concerns: 14:38:07 a) drive by website has limited info about user 14:38:16 ..only how many compatible wallets are available 14:38:46 ...BUT a malicious payment handler could extract information about a website. 14:38:52 [PROPOSAL PART III] 14:39:02 ...replace service worker implementation of payment handler with a "workout" 14:39:13 ...grant PH only read-only access to storage 14:39:21 ...no network access or other communication channels 14:39:28 ...can only answer browser's invocation 14:39:38 ...after customer makes selection, payment handler has access to normal APIs 14:39:41 q? 14:39:57 -> https://developer.mozilla.org/en-US/docs/Web/API/Worklet Worklet 14:40:17 -> https://caniuse.com/?search=worklet CanIUse info on Worklets 14:40:34 ...supported in edge, firefox, chrome, opera, android, opera mobile, etc 14:40:42 ..but not fully supported in webkit 14:40:53 [Open Questions] 14:41:18 * how does modal window communicate with browser? Keep SW for this only? 14:41:35 * How do we standardized payment method presentation details? (Manifest? Worklet APIs?) 14:41:40 * Are payment details needed at enumeration time? 14:42:04 ...(don't know) 14:42:59 * 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 [Payment Instrument Enumeration] 14:43:42 ...I just talked about payment methods, but could we expand this concept to INSTRUMENT enumeration? 14:43:54 ...e.g., to allow the display of card on file? 14:44:02 ..but raises questions about de-duplication 14:44:17 q+ to ask about merchants displaying unsupported payment methods 14:44:20 ack nicktr 14:44:20 nicktr, you wanted to ask about merchants displaying unsupported payment methods 14:44:31 q? 14:44:49 nicktr: One use case you raised is "merchant only wants to display pay buttons for things that are supported" 14:45:17 ...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 mathieu: Let's say there are two wallets integrated with PR API, and another not integrated. 14:46:00 ...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_ has joined #wpwg 14:46:37 nicktr: How does the merchant de-dup them? 14:46:50 mathieu: I would suppose the merchant would only enumerate wallets they want to support through PR API. 14:47:26 nicktr: Edge case is "supported through PR API but the user doesn't have support for them in browser" 14:47:36 AdrianHB: The payment method could have an option "we support enrollment flows" 14:47:48 ..then it's up to the merchant to decide whether to accept the user enrolling during the transaction 14:48:34 q? 14:49:09 nicktr: Would wallets always want to be shown? 14:49:36 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 q? 14:49:51 mathieu: handlers can also lie today about whether they have enrolled instruments 14:50:28 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 I have made the request to generate https://www.w3.org/2021/04/29-wpwg-minutes.html nicktr 14:50:49 ...they get an opaque enumeration not a concrete list of devices. 14:50:56 mathieu: This proposal is based on the WebRTC work 14:51:09 q+ naive question about specificity of method types 14:51:12 q+ 14:51:34 q+ smcgruer_[EST] to ask a naive question about specificity of method types 14:51:38 ack smcgruer_[EST] 14:51:39 smcgruer_[EST], you wanted to ask a naive question about specificity of method types 14:51:50 smcgruer_[EST]: How many buttons would a merchant typically want to show? and how specific are the method types? 14:52:35 ...are we really hiding information? 14:53:04 mathieu: In the future when there are more wallets than just two, it becomes more important 14:53:44 smcgruer_[EST]: I think this is a good direction for this proposal 14:54:17 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 mathieu: It's similar to how some wallets tell you to display their buttons 14:55:27 ...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 ...iframe could be a mechanism to shield information. 14:57:02 IJ: Do WebComponents do the right thing already today? 14:57:12 mathieu: Shadow DOM does the shielding work 14:57:36 ...this was used by video player to render controls 14:57:40 ...shadow root is what you're talking about 14:57:47 q? 14:57:49 ack me 14:58:02 Ian: Next steps? 14:58:33 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 ...I have a document with some additional details. 14:59:04 ACTION: Mathieu to share document on this proposal publicly or let us know that's not possible 14:59:38 Topic: Next meeting 14:59:40 13 May 14:59:45 I have made the request to generate https://www.w3.org/2021/04/29-wpwg-minutes.html Ian 14:59:52 RRSAGENT, set logs public 14:59:53 Bastien has left #wpwg 15:00:00 tm has left #wpwg 15:00:16 rrsagent, bye 15:00:16 I see 4 open action items saved in https://www.w3.org/2021/04/29-wpwg-actions.rdf : 15:00:16 ACTION: Stephen to report back with some info on modifier usage (heuristics ok!) [1] 15:00:16 recorded in https://www.w3.org/2021/04/29-wpwg-irc#T14-20-25 15:00:16 ACTION: Ian to work with editors to merge PR 955 and resolve remaining open I18N issue [2] 15:00:16 recorded in https://www.w3.org/2021/04/29-wpwg-irc#T14-22-00 15:00:16 ACTION: Ian to work with Editors on a pull request to remove modifier; pursuant to Stephen's action [3] 15:00:16 recorded in https://www.w3.org/2021/04/29-wpwg-irc#T14-22-57 15:00:16 ACTION: Mathieu to share document on this proposal publicly or let us know that's not possible [4] 15:00:16 recorded in https://www.w3.org/2021/04/29-wpwg-irc#T14-59-04 15:00:18 zakim, bye 15:00:18 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 has left #wpwg