13:54:36 RRSAgent has joined #wpwg 13:54:36 logging to http://www.w3.org/2017/05/25-wpwg-irc 13:54:38 RRSAgent, make logs public 13:54:38 Zakim has joined #wpwg 13:54:40 Zakim, this will be 13:54:40 I don't understand 'this will be', trackbot 13:54:41 Meeting: Web Payments Working Group Teleconference 13:54:41 Date: 25 May 2017 13:54:45 Chair: NickTR 13:54:59 Agenda: https://github.com/w3c/webpayments/wiki/Agenda-20170525 13:55:04 Regrets+ alyver 13:55:08 regrets+ Molly 13:58:58 present+ 14:00:32 AdrianHB has joined #wpwg 14:01:38 zkoch has joined #wpwg 14:01:44 present+ 14:01:48 present+ 14:02:03 rouslan has joined #wpwg 14:02:19 lol 14:02:23 “yeah right" 14:03:21 present+ Ken 14:03:26 scribe: Ian 14:03:30 mweksler has joined #wpwg 14:03:37 mweksler has joined #wpwg 14:03:43 Ken has joined #wpwg 14:03:54 present+ 14:04:56 present+ Andros 14:05:03 present+ michel 14:05:06 present+ matts 14:05:09 MattS has joined #wpwg 14:06:04 present+ Roy 14:06:07 present+ NickTR 14:06:10 present+ dezell 14:06:16 topic: Payment Request API 14:06:16 q+ 14:06:28 topic: Web Platform Tests 14:06:31 ack rous 14:06:36 hang on 14:06:46 rouslan: Defining common tests that can be run on all browsers 14:07:04 ...goal is to share HTML+JS tests across browsers 14:07:10 ...we started doing this in payment request 14:07:15 ...challenge around user interaction 14:07:37 s/hang on// 14:07:38 ...what we've decided to do among the implementers is to introduce web-platform-test payment method with params that tell the browser what to do 14:07:57 ...browser can "act as though there were user interaction" 14:08:04 zakim, who is here? 14:08:04 Present: Ian, AdrianHB, zkoch, Ken, rouslan, Andros, michel, matts, Roy, NickTR, dezell 14:08:05 ..and then the JS can look at the result 14:08:06 On IRC I see MattS, Ken, mweksler, rouslan, zkoch, AdrianHB, Zakim, RRSAgent, dezell, adamR, dlehn, jungkees, emschwartz, dlongley, manu, mkwst, Dongwoo, adrianba, davidillsley_, 14:08:06 ... hober, ShaneM, trackbot, schuki, Ian, slightlyoff, oyiptong, nicktr, JakeA 14:08:14 ...this approach came from Marcos 14:08:23 ...I think that I will add support to this into Chrome 14:08:54 ...I think Marcos has a small (payment method) spec he has written up. 14:08:59 present+ oyipton 14:09:04 q? 14:09:14 present+ 14:09:31 q? 14:09:34 q+ 14:10:16 IJ: I have asked Mike Smith to document this process 14:10:36 ... Mike has said he will create a resource for this 14:10:47 ack Ian 14:11:15 ... During CR as the suite is fleshed out, will changes to the spec be accompanied by changes to the test suite? (Question to editors/implementors) 14:11:28 q? 14:11:32 IJ: Are editors moving in direction of test-driven changes during CJR? 14:11:36 s/CJR/CR 14:11:41 zkoch: We have not discussed yet 14:11:52 q? 14:12:52 Topic: Payment Method Data 14:13:06 adrianhb: Don't want to spend much time on today's call but it's an important issue to address. 14:13:15 ...I think there is misunderstanding about the WebIDL in payment method specs 14:13:46 ...the question came up a long time ago about whether the spec needed to be written in WebIDL or, since ignored by the browser, we were using it because it is a widely liked data model formalism. 14:14:03 ..it seems that a lot of the recent developments around PR API and basic card suggest that is not a shared understanding 14:14:22 ...I think we need to decide what we want, and for other payment method specs as well 14:14:44 ...if browsers plan to do data validation, then we are creating an implementation burden on browsers and making them gatekeepers. 14:15:02 ..Marcos indicated that he thinks that what should happen for al payment methods, which I think flies in the face of expectations about distributed payment methods. 14:15:26 ...but even if the scope is just W3C-defined payment methods, we need to clarify whether browsers have to implement the WebIDL, do validation, etc. 14:15:42 ..the debate is somewhat complicated by the filtering discussion.... 14:15:57 q+ 14:16:27 ack Ian 14:16:48 => https://github.com/w3c/payment-handler/issues/157 14:17:24 ian: current thinking is to move payment handler matching back into handlers 14:17:47 ... let's focus on "should browsers look at this data" 14:17:49 q? 14:18:24 AdrianHB: I think the implementers need to give us direction and tell us what is practical 14:18:34 zakim, who is here? 14:18:34 Present: Ian, AdrianHB, zkoch, Ken, rouslan, Andros, michel, matts, Roy, NickTR, dezell, oyipton, oyiptong 14:18:37 On IRC I see MattS, Ken, mweksler, rouslan, zkoch, AdrianHB, Zakim, RRSAgent, dezell, adamR, dlehn, jungkees, emschwartz, dlongley, manu, mkwst, Dongwoo, adrianba, davidillsley_, 14:18:37 ... hober, ShaneM, trackbot, schuki, Ian, slightlyoff, oyiptong, nicktr, JakeA 14:18:48 ...we need to determine whether using WebIDL with no expectation of data validation is ok. 14:19:00 ...marcos seems to think this is a bad idea; I asked this very question 2 calls ago 14:19:17 ...we need vendors to figure out whether they are going to treat data as opaque. 14:19:34 ...IMO PR should not involve data validation 14:19:59 ...I think there is currently a disagreement among the editors 14:20:06 ..or may be 14:20:13 nicktr: Zach, thoughts? 14:21:25 q+ to agree with Zach but suggest that shoudl stay out the spec 14:21:25 zkoch: I think it's nuanced. Suppose you call basic card and have your supported type as "banana"...nobody can fulfill that...so it seems strange to let user go through experience if a failure can be detected in advance. Or similarly, if the merchant has a typo 14:21:33 q+ to suggest "MAY" 14:22:17 q? 14:22:17 zkoch: Enum types can be validated by browsers for well-defined payment methods....of course this does not apply for proprietary methods 14:22:50 ack adrian 14:22:50 AdrianHB, you wanted to agree with Zach but suggest that shoudl stay out the spec 14:22:54 ack AdrianHB 14:23:21 adrianhb: I agree with what Zach said...anything the browser can do to avoid bad UX makes sense, but I don't think it should be part of PR API. PR API should leave that open and browsers can add validation logic if they want. 14:23:33 ...I don't think PR API should make assertions about data validation 14:23:40 zkoch: I think the problem is interop. 14:23:51 ...you don't want an exception on one browser and not on another. 14:24:07 adrianhb: In my mind, that relates to browser implementation of basic card handler 14:24:29 ...I submit a payment request to the browser...the first thing the browser does is call its known handlers that support those PM's. 14:24:39 ...browser passes data and handler responds yes/no 14:24:51 ..you are saying that for basic card, the browser does it in its capacity as a payment handler 14:25:29 ...marcos is proposing changes to PR API...my interpretation is that all payment methods have to define their request methods in WebIDL and browsers must validate, etc. 14:25:39 zkoch: I don't understand it that way. 14:25:40 ack me 14:25:40 Ian, you wanted to suggest "MAY" 14:27:28 IJ: Would it make sense to clarify in PR API that user agents may validate data for some payment methods. 14:27:42 AdrianHB: I may not understand Marcos' perspective completely about support for opaque data. 14:28:11 ...but on interop, new payment methods will lead to different user agent behavior . 14:28:29 zkoch: Not quite...what we want to avoid is two known / implemented payment methods that are supported differently. 14:28:42 ...basic card merits special consideration 14:28:50 ..I will talk to Adrian and Marcos about this issue 14:29:12 q? 14:29:15 I emailed editors about testing and CR, to which Marcos replied: “Damn straight we are:) no test no (normative) change. Them's the rules.” 14:29:15 nicktr: Let's get clarity among the editors and come back to this on another call. 14:29:31 Topic: Payment Handler FPWD 14:29:44 nicktr: Congrats to the WG, I'm really pleased to see this happen! Thanks to all who helped get us there. 14:29:47 q? 14:30:57 +1 nice job at Google I/O zkoch and max 14:31:36 ian: Great Google i/O preo from zkoch and co. Specifically mention of Paypal involvement and desktop implementation 14:31:41 IJ: Thanks to Google for extending PR support and to Rouslan for beginning to implement Payment Handler 14:31:46 don’t worry, i can irc and drive! 14:31:47 ....next up for us: implementations, issues 14:31:51 (jokes, on shuttle) 14:31:58 topic: Interledger update 14:32:11 AdrianHB: draft payment method spec => https://w3c.github.io/webpayments/proposals/interledger-payment-method.html 14:32:28 ..the way it is structured may change based on conversations since today it is WebIDL'y .. and has complex types 14:32:39 ..but if it were just to be JSON, it would change into, e.g., URL-encoded strings 14:32:55 ...it gives you a flavor of what we've been playing with for how inter ledger could work with PR API and payment handlers 14:33:03 ...I'd like to take it up within the WG 14:33:17 ..the payment method takes two forms 14:33:30 ..when you submit a PR you can either submit a URL that points to a "simple payment setup endpoint" 14:33:48 ..and the handler will fetch data about how to do the payment, then submit the payment and ultimately send a proof of payment in the response 14:34:10 ..the second method is an inter ledger payment request, with merchant-prepared data...and all the payment app does is submit the data to an inter ledger note 14:34:12 s/note/node 14:34:23 ...we are having a 2-day workshop 1-2 June in Berlin; this will be on the agenda 14:34:29 https://interledger.org/workshop 14:34:38 ...at hackathon we want to get the bobpay demo working with interledger 14:34:45 q+ 14:35:00 nicktr: The spec has been available for review for some time..have reviews happened? 14:35:03 (IJ reviewed it) 14:35:04 ack Ian 14:36:02 https://github.com/w3c/webpayments-methods-tokenization/wiki 14:36:23 ian: q around payment methods specs is "Who will implement?". Lots of activity in tokenization and credit transfer for example 14:36:47 ... what is expectation for implementors around Interledger 14:36:56 q? 14:36:56 IJ: who would implement? 14:37:03 adrianhb: Anybody! 14:37:33 ...anybody can implement. .... currently there is a network of about 20 people running inter ledger nodes as an experimental network (with real money, though) 14:37:45 ...there is also a project around bringing inter ledger to mobile money networks 14:38:17 ..there needs to be more people accepting inter ledger payments before we see lots of payment apps 14:38:28 ...I concede it is not currently as popular as credit cards. :) 14:38:36 nicktr: I encourage people to have a look at the spec. 14:39:14 q? 14:39:17 AdrianHB: I note that both tokenization and credit transfer were taken up prior to implementer interest...I don't mind if we decide that's our bar for acceptance, but I would point out it has not been our bar historically 14:39:52 Topic: Meetup in August (non-w3c event) 14:40:25 mweksler: 8 August meetup at Airbnb...650-person meetup group...about 50 have already RSVP'd 14:40:29 https://www.meetup.com/Bay-Area-Billing-and-Payment-Engineers/events/240044104/ 14:40:38 ...the range of topics is pretty diverse (agenda in flux) 14:40:54 ..probably about 2 hour agenda with several 10-15 min presentations on payments, billing 14:41:02 ...might be a good platform for someone from our WG to talk about PR API 14:41:24 ...e.g., as zach did at Google I/O...this would be a smaller audience but a very focused one on payments 14:41:35 ...since I'm hosting I would prefer not to host 14:41:40 s/host/present 14:41:49 ..anyone else interested in presenting 10-15 mins? 14:42:11 stan has joined #wpwg 14:42:21 nicktr: Thanks, Michel! 14:42:41 mweksler: If interested, please contact me 14:42:55 topic: Pre-TPAC FTF? 14:43:05 q+ to say we're having a similar meetup in SA in July 14:44:14 IJ: Should we meet? 14:44:20 ack adrianhb 14:44:20 AdrianHB, you wanted to say we're having a similar meetup in SA in July 14:44:22 ack AdrianHB 14:44:35 NickTR: My sense is that nothing has changed since Chicago. 14:44:44 ..anyone want a FTF before TPAC in Nov? 14:44:52 [Nobody indicates they want a meeting before TPAC] 14:45:01 RESOLVED: Next FTF meeting will be at TPAC. 14:45:20 ...specifically: 6-7 Nov 14:45:44 -> https://www.w3.org/2017/11/TPAC/ 14:46:16 Topic: Adrian's meetup in South Africa in July 14:46:26 AdrianHB: There is a payments company that wants to host an event on 27 July 14:46:32 ...with a section dedicated to our wokr 14:46:50 ....if any of you have engineers in the region who are interested in participating, let me know 14:46:56 ...I will send more information to the list 14:47:07 s/Andros/Andras 14:47:26 q? 14:47:26 nicktr: Maybe we should explicitly call out next FTF meeting of WPWG in standalone email 14:47:29 topic: Next meeting 14:47:42 q? 14:47:51 Proposed: 1 June 14:47:56 NickTR: Regrets for 1 June 14:48:12 q? 14:48:13 Proposed: 8 June 14:48:19 +1 14:48:21 +1 14:48:25 +1 14:48:33 RESOLVED: Next call 8 June 14:48:43 RRSAgent, make minutes 14:48:43 I have made the request to generate http://www.w3.org/2017/05/25-wpwg-minutes.html Ian 14:48:46 RRSAgent, set logs public 14:57:02 stan has joined #wpwg 16:07:26 stan has joined #wpwg 17:01:00 Zakim has left #wpwg 17:45:25 stan has joined #wpwg 18:14:54 stan has joined #wpwg 18:34:45 stan has joined #wpwg 19:19:38 stan has joined #wpwg 20:19:36 stan has joined #wpwg 20:29:56 stan has joined #wpwg 20:49:09 stan has joined #wpwg