14:00:40 RRSAgent has joined #wpwg 14:00:40 logging to http://www.w3.org/2017/06/08-wpwg-irc 14:01:14 zkoch has joined #wpwg 14:01:53 present+ Rouslan 14:01:55 present+ 14:02:01 Meeting: Web Payments WG 14:02:02 vkuntz has joined #wpwg 14:02:07 Chair: Nick 14:02:09 Scribe: Ian 14:02:21 Agenda: https://github.com/w3c/webpayments/wiki/Agenda-20170608 14:02:59 alyver has joined #wpwg 14:04:55 present+ Ken 14:04:58 present+ alyver 14:05:02 present+ adrianba 14:05:05 present+ roy 14:05:12 regrets+ adrianhb 14:05:14 Ken has joined #wpwg 14:05:24 present+ zkoch 14:05:26 zakim, who's here? 14:05:26 Present: Manash, Clinton, alyver, oyiptong, Ian, Steve, Olivier, mweksler, holger, Michel, (CC), Roy, Ken, rouslan, adrianba, zkoch 14:05:29 On IRC I see Ken, vkuntz, zkoch, RRSAgent, cweiss, rouslan, dlehn, adamR, ShaneM, Zakim, dlongley, manu, emschwartz, mkwst, Dongwoo, adrianba, hober, trackbot, schuki, Ian, 14:05:29 ... slightlyoff, oyiptong, nicktr, JakeA 14:05:35 zakim, bye 14:05:35 leaving. As of this point the attendees have been Manash, Clinton, alyver, oyiptong, Ian, Steve, rouslan, Olivier, mweksler, holger, Michel, (CC), Roy, Ken, adrianba, zkoch 14:05:36 Zakim has left #wpwg 14:05:37 Zakim has joined #wpwg 14:05:40 present+ vkuntz 14:06:03 present+ zkoch, rouslan, Ian, alyver, adrianba, roy, vkuntz, ken, christian 14:06:09 regrets+ adrianhb 14:06:21 zakim, who's here? 14:06:21 Present: vkuntz, zkoch, rouslan, Ian, alyver, adrianba, roy, ken, christian 14:06:23 On IRC I see Ken, vkuntz, zkoch, RRSAgent, cweiss, rouslan, dlehn, adamR, ShaneM, dlongley, manu, emschwartz, mkwst, Dongwoo, adrianba, hober, trackbot, schuki, Ian, slightlyoff, 14:06:23 ... oyiptong, nicktr, JakeA 14:06:49 Chair: Ian 14:07:04 Topic: Rupay 14:07:04 https://lists.w3.org/Archives/Public/public-payments-wg/2017Jun/att-0008/00-part 14:07:29 PROPOSED: Adopt Rupay in the network token list 14:07:40 present+ oyiptong 14:07:45 +1 14:07:46 alyver has joined #wpwg 14:08:03 IJ: Any objections to adding rupay to the list? 14:08:05 ::reading about rupay:: 14:08:41 +1 14:08:47 SO RESOLVED 14:08:59 topic: Payment Request API issues for WG discussion 14:09:32 present+ nicktr 14:09:55 ACTION: Ian to update the network id list with rupay 14:09:55 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., IFSF-EFT-WG-Lead, ijacobs, ijmad). 14:10:00 https://github.com/w3c/webpayments/wiki/Agenda-20170608 14:10:31 Pull request 536 https://github.com/w3c/browser-payment-api/pull/536 14:10:54 zkoch: For PR 546, I think that Marcos will issue a pull request for this. 14:11:13 s/PR 546/issue 546/ 14:11:29 zkoch: We did spent a chunk of time during editors meeting discussing PR 536. 14:11:41 ..I think the editors came to the following conclusion....the gist of this issue 14:12:11 ...is that there is a bit of disagreement whether, for specs that are like basic card, whether the browser does any validation on the data 14:12:25 ...concretely - what should happen if you call PR API with basic card and pass in a supported network of "bob" 14:12:31 ...and that's not on the list 14:12:55 ...there are different behaviors possible, e.g., browser does nothing v. browser validates data and throws error 14:13:24 ...I don't think the issue centers around WebIDL. I think our conclusion is this: the WG decided a long time ago that there are two ways to define payment methods. 14:13:45 ..and browsers have said that just because a payment app says they support a short string doesn't mean that browsers will match on it 14:13:56 ...it follows that browsers should validate on data for short string payment methods 14:14:03 ...in order to ensure the best user experience 14:14:23 ..if you don't want the browser to do validation and you want to treat the payment method data opaquely, the approach is to use a URL 14:14:25 q+ 14:14:37 ...that will ensure that (1) it's enabled by default and (2) the data is opaque 14:14:59 ...but our view is that for short string payment methods browsers will likely validate data that can be (easily) validated 14:15:14 ...there is some room for flexibility, but the goal is to give the users the best experience 14:15:18 ack me 14:16:30 q? 14:16:31 IJ: what might the spec say about browser validation? 14:17:59 IJ: e.g., basic card 14:18:20 q+ 14:18:31 zkoch: My understanding from yesterday is, when implementing a short string payment method, one can find things in WebIDL and it is a MUST to validate some things, such as well-known enums 14:18:45 q+ 14:19:08 molly has joined #wpwg 14:19:15 ...in the example you just gave, I don't understand whether expectations about browser implementation of the payment method is relevant. What's important is the user experience, and we should not pass broken data through knowing it will create a bad user experience. 14:19:19 ack nick 14:19:36 nicktr: Are we saying that "if there is a short string there needs to be a specification that says how to behave"? 14:19:40 zkoch: I think that's correct. 14:19:48 nicktr: That also maps to my understanding. 14:20:33 ack adrianba: I think that statement is true but I want to reiterate a point zkoch made earlier. For us to approve a short string (1) there needs to be a spec that is broadly agreed upon and (2) browsers need to take action to support that payment method 14:20:54 ...this is an important piece of preventing squatting strings 14:21:04 ...browsers take action to support matching on that short string 14:22:03 ...I wanted to answer ian's question about what spec should say what. I think it's necessary to say something in PR API. I think we need to indicate at what point that validation occurs...and what the consequence of failure to validate is...we need to be explicit about whether there is an exception (and its value) or failure of a promise. 14:22:30 ...it makes sense also that we would provide some information in the basic card spec. We need to decide whether the text we add to the basic card spec be explicit about the validation 14:23:08 q 14:23:10 ...as zkoch said, there is some flexibility about which fields are validated. It's possible for basic card to be explicit about which fields are validated. We need to decide whether we want to say that (and make it normative)...or more informative 14:23:10 q? 14:23:14 ack adrianba 14:23:24 ..the final piece is whether we say "must validate' or "may validate" 14:24:26 ...zkoch's comment on "best user experience" suggests to me "quality of implementation" and therefore room to distinguish oneself 14:25:16 ...there's a strong argument that says that we need to protect people from a quality of implementation issue. I am open-minded about must v. should v. may....but (1) we definitely need to say something in PR API about where validation occurs and (2) we should put something in basic card 14:25:44 nicktr: I am hearing that where there is a short string, PR API needs to say something about validation AND there needs to be a (W3C) specification for that short string that deals with validation rules specific to that method 14:27:10 q+ 14:27:15 ack adrianba 14:27:27 adrianba: The key thing is that we should not need to update PR API for new payment methods. 14:27:32 Ian: +1 14:29:14 IJ: Is WebIDL sufficient to say "what can be validated" or do we need to also say something in the prose? 14:29:32 AdrianBA: I think you could say it should be valid according to the WebIDL 14:30:08 ...but there could be additional validation that needs to occur (though not necessarily for basic card). E.g., there might be validation rules about relationship between two fields; that's not something that is expressible in WebIDL 14:31:05 IJ: Other than normative statements in basic card, is there anything special to say about validation? 14:31:15 zkoch: I don't think so 14:31:54 IJ: What should happen here since AdrianHB is not on the call? 14:32:50 IJ: Can we wait for AHB to get back and have a decision by the next call? 14:33:01 NickTR: What's the decision about? 14:33:08 zkoch: There's a concrete pull request about validation 14:33:12 https://github.com/w3c/browser-payment-api/pull/536 14:33:16 https://github.com/w3c/browser-payment-api/pull/536/files 14:34:01 nicktr: We can meet next week if needed. 14:34:17 zkoch: We were hoping to get closure today; I think we can wait until next week. 14:35:31 IJ: Should we do a straw poll today? 14:35:36 nicktr: +1 to straw poll 14:37:26 PROPOSED: For w3c-defined payment methods (i.e., those with short strings), PR API implementations (at least) may validate payment method request data. 14:37:42 q? 14:38:02 +1 14:38:03 +1 14:38:05 [Please say +1 if you support the proposal] 14:38:12 +1 14:38:15 +1 14:38:19 Roy has joined #wpwg 14:38:25 +1 14:38:50 PROPOSED: For w3c-defined payment methods (i.e., those with short strings), PR API implementations MUST validate payment method request data that can be validated economically 14:39:16 the PR suggests it must if the payment method spec requires it 14:39:40 +1 to must 14:39:51 nicktr: Makes sense to me to say "MUST" if the payment method spec says "MUST" 14:40:16 ...makes sense to me that if payment method spec says "MUST" then browser MUST enforce that validation 14:40:30 RRSAGENT, make minutes 14:40:30 I have made the request to generate http://www.w3.org/2017/06/08-wpwg-minutes.html Ian 14:40:33 RRSAGENT, set logs public 14:41:32 Topic: Tokenization 14:42:00 Mission => https://github.com/w3c/webpayments-methods-tokenization/wiki 14:42:04 ian: tokenisation task force meeting regularly and is working on network and gateway tokens separately 14:42:33 ... Mastercard are working on a revised explainer 14:42:41 https://github.com/w3c/webpayments-methods-tokenization/wiki/gateway_params 14:42:54 ... We have the beginnings of a gateway token spec 14:43:08 ... In short - good progress on tokens 14:43:20 q? 14:43:26 Topic: Credit Transfer 14:43:28 ..just met today 14:43:43 ... five issues being worked through 14:43:58 ... by mid-Jul, an update to teh WG 14:44:02 Topic: Payment Handler 14:44:13 s/teh/the/ 14:44:13 https://lists.w3.org/Archives/Public/public-payments-wg/2017Jun/0004.html 14:44:48 Ian: Thanks to Rouslan and Samsung for issues and PRs on implementation experience 14:44:57 ... and _even_ Zach 14:45:02 :) 14:45:10 q+ 14:45:14 nicktr: Good to hear the progress 14:45:18 ack zkoch 14:45:25 ack zkoch 14:45:52 zkoch: One quick comment - there's a lot happening in that spec, and I realize that it was in a task force to get started. Now that PR API has fewer issues, it could make sense to bring payment handler issues into the main call 14:45:54 nicktr: +1 14:46:29 IJ: Is the model that editors bring issues into the WG from time to time? 14:46:38 ...as with PR API? 14:46:53 q? 14:46:58 zkoch: Yes, but there are some issues I want to put before the full group such as "wallets"; but in general +1 to editor judgment on what to bring forth 14:47:03 Topic: Next meeting 14:47:24 15 June (to try to wrap up 536) 14:47:30 RRSAGENT, make minutes 14:47:30 I have made the request to generate http://www.w3.org/2017/06/08-wpwg-minutes.html Ian 14:47:34 RRSAGENT, set logs public 14:55:35 vkuntz has left #wpwg 14:56:41 alyver has joined #wpwg 14:59:16 alyver has joined #wpwg 15:15:12 alyver has joined #wpwg 15:20:15 betehess has joined #wpwg 16:06:48 betehess has joined #wpwg 17:02:22 betehess has joined #wpwg 17:15:07 Zakim has left #wpwg 17:51:49 betehess has joined #wpwg 18:03:13 betehess has joined #wpwg 18:37:23 cweiss has joined #wpwg 20:06:15 betehess has joined #wpwg 20:12:39 cweiss has joined #wpwg