13:57:18 RRSAgent has joined #wpwg 13:57:18 logging to https://www.w3.org/2019/09/05-wpwg-irc 13:57:27 Meeting: Web Payments Working Group 13:57:39 Chair: NickTR 13:57:41 Scribe: Ian 13:57:43 present+ 13:57:49 present+ Fawad_Nisar 13:58:13 agenda: https://github.com/w3c/webpayments/wiki/Agenda-20190905 13:58:15 agenda+ TPAC 13:58:32 agenda+ PR API 1.0 13:58:37 agenda+ PR API 1.1 new issues 13:59:17 present+ Florent_Lambert 14:00:22 present+ Nick_Telford-Reed 14:01:20 florent has joined #wpwg 14:01:39 rouslan has joined #wpwg 14:01:49 present+ David_Benoit 14:01:56 present+ nicktr 14:02:09 present+ Rouslan_Solomakhin 14:02:10 present+ Dean_Ezra 14:02:34 deanezra has joined #wpwg 14:02:49 vkuntz has joined #wpwg 14:02:59 present+ Vincent_Kuntz 14:04:01 -> https://github.com/w3c/webpayments/wiki/Agenda-20190905 Agenda 14:04:18 zakim, take up item 1 14:04:18 agendum 1. "TPAC" taken up [from Ian] 14:04:39 NickTR: I look forward to seeing you all in Japan 14:04:55 ...please note that registration has closed 14:05:20 present+ Danyao_Wang 14:05:33 https://github.com/w3c/webpayments/wiki/FTF-Agenda-201909#preparation 14:05:33 NickTR: We have a list of things to read: 14:05:35 https://github.com/w3c/webpayments/wiki/FTF-Agenda-201909#preparation 14:07:14 present+ Alex_Liu 14:07:28 ian: Group dinners 14:07:55 ... there are 41 members of the group registered plus observers 14:08:03 ...we may have 50-60 participants 14:08:26 ...we would like to have a dinner together on Monday evening 14:08:49 ian: anyone have preferences? 14:09:37 IJ: I expect to seek a Japanese restaurant 14:10:12 zakim, close item 1 14:10:12 agendum 1, TPAC, closed 14:10:13 I see 2 items remaining on the agenda; the next one is 14:10:13 2. PR API 1.0 [from Ian] 14:10:28 zakim, take up item 2 14:10:28 agendum 2. "PR API 1.0" taken up [from Ian] 14:11:07 IJ: I think we are one Safari fix away from implementation report 14:11:49 IJ: There is a proposed privacy enhancement: 14:11:49 https://github.com/w3c/payment-request/pull/873 14:13:14 present+ Adrian_Hope-Bailie 14:14:48 IJ: What are the opportunities lost by not advancing to Recommendation for another 8 months? 14:14:56 scribenick: nicktr 14:15:02 q+ 14:15:06 ack rouslan 14:15:08 IJ: I expect we will discuss at the F2F 14:15:10 scribenick: Ian 14:15:27 Rouslan: For us, the Recommendation status is not critical to us; draft spec is good enough for us to implement. 14:15:48 ...once the spec is modified to accommodate the needs of privacy reviewers, we will implement it in due time. But we will do so carefully. 14:15:54 benoit has joined #wpwg 14:15:56 q+ 14:15:58 ack nick 14:16:00 nicktr, 14:16:46 nicktr: From merchants I speak with, I think that not going to Rec can be a drag on adoption 14:17:57 q+ to talk about complexity of parallel work 14:17:57 IJ: Group motivation is another topic 14:18:01 ack AdrianHB 14:18:01 AdrianHB, you wanted to talk about complexity of parallel work 14:18:29 AdrianHB: Management of versions in parallel adds complexity and overhead. 14:18:30 q+ to ask about whether it has a bearing on rechartering? 14:19:00 AdrianHB: I think if we can continue working and forging ahead on new features we should do so as simply as possible. 14:19:12 nicktr: What is the impact of delay on rechartering? 14:19:23 Ian: I doubt it 14:19:50 q+ to clarify parallel work comment 14:20:11 ack me 14:20:11 nicktr, you wanted to ask about whether it has a bearing on rechartering? 14:20:36 ij: I don't think it's significant on rechartering 14:20:46 ack dan 14:20:46 danyao, you wanted to clarify parallel work comment 14:20:49 scribenick: Ian 14:21:27 danyao: As we develop Chrome we focus on backward compatibility, so that should assuage merchant concern. 14:21:38 ...I want to avoid feature creep 14:21:42 +1 to avoid feature creep 14:22:38 +1 to avoiding feature creep 14:22:47 Proposed: No other features than the privacy feature will be considered for PR API 1.0 14:22:51 +1 14:22:56 +1 14:22:59 +1 14:23:01 +1 14:23:09 clarifying comment: it is hard work for the group to manage parallel work on the specs if we have a v1.0 spec that is a trying to go to CR and another that is documenting new features 14:23:31 I strongly support this - we need the privacy improving feature to get through the CR milestone but nothing else 14:23:37 Danyao: We are committed to finishing PR API 1.0 features before we start on 1.1 features 14:24:56 q? 14:25:10 zakim, close item 2 14:25:10 agendum 2, PR API 1.0, closed 14:25:11 I see 1 item remaining on the agenda: 14:25:11 3. PR API 1.1 new issues [from Ian] 14:25:14 +1 for PR feature lock 14:25:16 zakim, take up item 3 14:25:16 agendum 3. "PR API 1.1 new issues" taken up [from Ian] 14:25:49 Issue 879: SKUs instead of totals 14:25:55 https://github.com/w3c/payment-request/issues/879 14:26:10 Rouslan: This is a new feature (so 1.1). We want to have better integration of Web sites with Google Play. 14:26:21 ...we want to expose the Google Play billing capabilities to Web sites 14:26:44 ...merchants enter information in a Google Play database; they get back SKUs. 14:27:04 ...when people want to buy things, merchants provide SKUs and the payment handler shows the price (that was stored in the database) 14:27:30 ...so a proposal for PR API is to include an alternative where total/currency is replaced by an SKU. 14:27:39 ...the SKUs would be origin-bound. 14:28:06 q+ can we just pass in a Promise as total that must resolve to a valid total object? 14:28:13 q+ to can we just pass in a Promise as total that must resolve to a valid total object? 14:28:26 ...so we'd need to add a method to PR API (e.g., getDisplayedItems) and would require us to make the total more complex, like "currency/amount OR SKU" 14:28:29 ack AdrianHB 14:28:29 AdrianHB, you wanted to can we just pass in a Promise as total that must resolve to a valid total object? 14:29:06 AdrianHB: If we wanted to make this slightly more generic...you are I believe getting a total asynchronously. Do you think we could decouple those further, e.g., pass in a promise for a total, and how the promise resolves is distinct from PR API. 14:29:57 Rouslan: We have considered that idea. There might be a server endpoint where the merchant could fetch the amount based on SKUs. However, we feel like it could make the world more complex since people would have to use a second API to translate SKUs. 14:30:05 will take comments to the issue - I think this moves PR away from payment and into a commerce API. It's hard to imagine a payment request that doesn't specify an amount and currency 14:30:49 IJ: I am guessing "list of SKUs" as input 14:31:18 nicktr: I think we need to think carefully about this; currency/amount are fundamentals of a payment. It feels like we might be moving farther away from a "payment request" 14:31:24 q? 14:31:52 https://github.com/w3c/payment-request/wiki#payment-flows 14:32:37 Issue 407: More restrictive hasEnrolledInstrument() for autofill data 14:32:43 https://github.com/w3ctag/design-reviews/issues/407 14:33:00 Rouslan: Chrome is currently the browser that implements Basic Card using its own autofill data. 14:33:06 ...in this data, Chrome is acting as a payment handler 14:33:46 ...in general we don't standardize UX 14:33:59 ..but there is one behavior we'd like to introduce that might alter the expectation about what Basic Card does 14:34:11 ..we are not sure if this is a browser-specific optimization or whether it should be standardized. 14:35:20 ..the behavior we'd like to change for Basic Card is, when you call hasEnrolledInstrument(), it will return false() unless the card is really ready to pay (e.g., all data is present, card has not expired, etc.) 14:35:41 ...we really want true() to represent a happy path and high chance of conversion. 14:36:14 -> https://gist.github.com/rsolomakhin/d6d242cbb9306864ada5a29de7ab271e Rouslan's explainer 14:36:56 ...so the request to the group is whether this behavior should be part of the Basic Card spec or whether it should be implementation-specific. 14:37:23 ..might be good to be in the spec for consistent UX 14:37:24 q+ 14:37:37 ..but if we put this in the spec, this ties browser hands 14:38:56 ian: first reaction, "What's the definition of hasEnrolledInstrument?". Is this payment method specific? I hadn't thought about it that way? 14:40:11 ian: you raise questions about variability that is related to how payment handlers behave. 14:40:31 ... how explicit would we be in sepcifying this behaviour? 14:41:25 q? 14:41:28 ack Ian 14:41:46 q+ to comment on hasEnrolledInstrument for basic-card 14:42:11 ian: If it's in Basic Card how would we define things like "valid billing address"? We have had issues in the past around determining things like card type from BIN 14:42:13 IJ: I would need to see definitions. 14:42:22 Rouslan: I am favor of NOT moving this into Basic Card. :) 14:42:25 ack Danyao 14:42:25 danyao, you wanted to comment on hasEnrolledInstrument for basic-card 14:42:38 q+ to ask if it makes any difference since basic card spec is a note 14:42:38 Danyao: My mental model is that Basic Card defines a schema. 14:43:06 Danyao: I think the minimum expectation is "true()" means the payment handler can return an instrument to the best of its ability 14:43:09 +1 14:43:34 Danyao:..what we are fixing in Chrome is that an expired card would not work, so we should allow the payment handler to make the decision. 14:43:46 +1 14:43:47 ...the spec should focus on data and allow the payment handler to do what it does best. 14:44:16 AdrianHB: I am agreeing with Danyao and Rouslan, although I would add to that that if we put any text in the Basic Card spec, we could do so as informative text. 14:44:39 ...I would take it further to say that it's probably appropriate for the behavior of a payment handler to be defined in the payment method spec. 14:45:27 q+ 14:45:32 ack AdrianHB 14:45:33 AdrianHB, you wanted to ask if it makes any difference since basic card spec is a note 14:46:07 AdrianHB: I think we should make clear in the PR API spec that there's no guarantee you'll get something back even if you requested it. 14:46:59 q+ 14:47:46 AdrianHB: If it's possible for a payment handler to return shipping address or email addresses, then it's impossible for them to reply to hasEnrolledinstrument() with true unless they have the data. 14:47:51 ack rouslan 14:48:05 Rouslan: This is a behavior we want to provide for autofill data only 14:48:13 ..it would not be relevant for third-party handlers 14:48:35 ...so maybe that's the decision-maker: if it's autofill specific, then it's not part of the spec 14:48:38 q+ 14:49:18 "The CanMakePaymentEvent is used to check whether the payment handler is able to respond to a payment request. " 14:50:16 IJ: I would add some verbiage to tell payment handlers that they should respond true when the user really is ready to pay. 14:50:26 ....and that may be payment method specific and rely on other circumstances 14:50:29 ack Dan 14:50:31 ack me 14:51:19 Danyao: I think Adrian's point is that the mediator should not be overly restrictive. I agree. But payment handlers should have flexibility to be more restrictive. 14:52:15 +1 to continue on GitHub. Can we log an issue or should we comment on Rouslan's Gist 14:53:05 Danyao: I am ok with with a non-normative note in PH API that says "ready to pay and may vary by payment method and context." 14:53:06 to danyao's earlier point, the payment method specs should define the data model and behaviour specific to each payment method, so the "right thing" should be defined there 14:53:12 Topic: Next meeting 14:53:19 Face-to-face! 14:53:37 Topic: Web Monetization 14:53:44 https://github.com/adrianhopebailie/web-monetization/blob/master/explainer.md 14:53:52 AdrianHB: We did a big update to the explainer. 14:53:53 https://github.com/adrianhopebailie/web-monetization/blob/master/sending.md 14:54:00 ...there's a nice synergy between the design and PR API 14:54:11 ...we plan to send monetized payments via PH API as-is 14:54:31 that's very exciting 14:54:32 -> https://www.w3.org/blog/2019/09/w3c-interview-coil-on-interledger-protocol-and-web-monetization/ Ian's interview with Stefan Thomas on Monetization 14:54:43 very cool 14:55:05 AdrianHB: See you in Japan 14:55:06 "coil hype machine" should absolutely be a thing ;) 14:55:08 RRSAGENT, make minutes 14:55:08 I have made the request to generate https://www.w3.org/2019/09/05-wpwg-minutes.html Ian 14:55:28 RRSAGENT, set logs public 14:57:11 rrsagent, bye 14:57:11 I see no action items