13:57:07 RRSAgent has joined #wpwg 13:57:07 logging to http://www.w3.org/2017/05/11-wpwg-irc 13:57:09 RRSAgent, make logs public 13:57:09 Zakim has joined #wpwg 13:57:11 Zakim, this will be 13:57:11 I don't understand 'this will be', trackbot 13:57:12 Meeting: Web Payments Working Group Teleconference 13:57:12 Date: 11 May 2017 13:57:33 AdrianHB has joined #wpwg 13:58:02 Agenda: https://github.com/w3c/webpayments/wiki/Agenda-20170511 13:59:02 present+ 13:59:26 jnormore has joined #wpwg 14:00:01 present+ Andras 14:00:21 present+ alyver 14:00:35 AnneP has joined #wpwg 14:00:49 present+ AnneP 14:00:50 alyver has joined #wpwg 14:01:34 present+ cweiss 14:01:42 present+ Adrianhb 14:01:56 -> https://github.com/w3c/webpayments/wiki/Agenda-20170511 Agenda 14:02:00 regrets+ NickTR 14:02:02 Chair: AdrianHB 14:02:10 present+ jnormore 14:02:21 present+ alyver 14:02:56 present+ Molly 14:03:20 zakim, who's here? 14:03:20 Present: Ian, Andras, alyver, AnneP, cweiss, Adrianhb, jnormore, Molly 14:03:22 On IRC I see alyver, AnneP, jnormore, AdrianHB, Zakim, RRSAgent, sam, cweiss, Dongwoo, adamR, davidillsley_, dlongley, manu, hober, dlehn, ShaneM, trackbot, schuki, Ian, mkwst, 14:03:22 ... slightlyoff, adrianba, oyiptong, nicktr, emschwartz, JakeA 14:03:59 Topic: Review Call for Consensus of Payment Handler API 14:04:11 rouslan_ has joined #wpwg 14:04:14 present+ 14:04:34 Expressions of support from Google, Ripple, Worldpay, Mozilla, Klarna, Shopify, Digital Bazaar, Canton Consulting, and NACS 14:04:34 No Formal Objections 14:04:34 Proposed change to shortname based on feedback: "payment-handler" 14:04:34 Two new issues raised; propose we add flags to the FPWD. 14:05:21 present+ adrianba 14:05:47 Any objections to changing the shortname to payment-handler? 14:05:50 ken has joined #wpwg 14:05:53 (We would update the repo accordingly) 14:05:58 present+ ken 14:06:08 Ian: We will change the short name! 14:06:11 +1 to name change 14:06:36 IJ: Propose we add 2 new issue flags 14:06:48 https://github.com/w3c/webpayments-payment-handler/issues/151 14:06:55 https://github.com/w3c/webpayments-payment-handler/issues/153 14:07:40 present+ oyiptong 14:08:11 present+ Carmen 14:08:36 IJ: IS there a decision to go to FPWD? 14:08:47 RESOLVED: Advance Payment Handler API to FPWD 14:08:52 molly has joined #wpwg 14:09:09 ACTION: Ian to close the CfC thread with a decision on behalf of the editors 14:09:09 '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:09:21 ACTION: Ian to work with editors to send a transition request to the director for FPWD 14:09:21 '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:09:36 I have made the request to generate http://www.w3.org/2017/05/11-wpwg-minutes.html Ian 14:09:54 topic: Payment Request API Check In 14:10:13 AdrianBA: The editors met yesterday and went through the pending pull requests 14:10:20 ...we merged a number of them 14:10:35 ...a few questions posed on one or two of them where we thought we needed to get answers before moving forward 14:10:48 ...there are comments in PRs for those 14:10:55 ...a few need tweaking; probably today 14:11:06 ...there are still a few issues in the CR milestones issue list that need to be resolved 14:11:13 ...our assessment is that there is forward progress on those 14:11:35 ...when I met with Marcos last we discussed the timeline 14:11:44 ...we thought we needed 2-3 more weeks to CfC 14:11:46 q+ 14:12:13 ...so we think we are 6-7 weeks from the CR publication (as of last week) 14:12:23 AdrianHB: Anything needed here? 14:12:46 https://github.com/w3c/browser-payment-api/pull/492 14:13:19 IJ: Did you have a chance to discuss Basic Card status? 14:13:24 Adrianba: Not yet 14:15:15 [AdrianBA reviews background of pull request 492] 14:16:10 AdrianBA: I think the feedback on the PR falls into two categories: 14:16:25 1) The need to declare "an extension point" here at all 14:16:44 ..thanks AdrianHB for the explanation. I think my comment still stands, but I might amend it to say 14:17:01 ...I think it may not be necessary for the browser to implement filtering logic...it depends on which payment apps are integrated 14:17:30 q+ 14:17:40 ..one option is for payment apps to do the matching 14:17:52 2) Second category of comments is about implementation of the extension point - how it appears in the mark-up/spec 14:18:00 ..and there was a sense that that was an unusual way to describe it. 14:19:12 ian: we reached a dead end on finding a way for payment apps to apply filters because of privacy 14:19:46 ... we then suggested that the payment app could provide lambda but there were technical issues with that 14:20:16 ... vendors then suggested doing in browser so we proposed a basic string based matching algo 14:20:47 ... when a generic algo was proposed this was pushed back by the browser vendors 14:21:08 ... current PR is result of that 14:21:31 q+ 14:21:40 ack me 14:21:46 ... agreement was for payment handler to define how apps inidicate their capapbilities 14:22:06 adrianba: I feel like the current proposal is to be silent. 14:22:29 q+ 14:22:42 adrianba: The algorithm ought to explain the process it goes through 14:22:49 ...if we are talking about filtering, we ought to have a description 14:22:53 ..and where it happens 14:23:16 ack adr 14:23:19 q+ to suggest two possible routes forward 14:23:55 ian: don;t think text is silent, It says matching takes into account filters 14:24:17 ... haven't defined the algorithm because implementors have not liked that 14:24:33 ... do I hear you say that that would be preferrable? 14:24:54 ... rousal and I wrote out the algo but got no traction 14:25:51 AdrianHB: I think to get to cr we should consider adding matching algo or getting rid of matching 14:26:01 q+ 14:26:06 (IJ: I feel matching is essential for adding payment apps) 14:26:08 ack Ian 14:26:09 I think this is a primarily spec lawyering problem not a technical issue 14:26:09 ack AdrianHB 14:26:09 AdrianHB, you wanted to suggest two possible routes forward 14:26:10 ack rouslan_ 14:26:22 dezell has joined #wpwg 14:26:22 AdrianHB: I don't have strong feelings (with my chair hat off) 14:26:42 rouslan_: I don't understand the logic for saying we can't use an extension point here 14:27:02 AdrianHB: If you define it in the payment method specs, you create work for browser vendors for every payment method spec 14:27:25 q+ 14:27:52 Here is rouslan's original proposal => https://github.com/w3c/webpayments-payment-handler/issues/96#issuecomment-276423629 14:28:06 q+ 14:28:11 q- later 14:28:23 ack rouslan_ 14:28:34 rouslan_: I think this will be a long discussion again (like last time) 14:28:54 ..to summarize my opinion, I would say that from an engineering perspective it's fine to add a parameter where we have only filters 14:29:17 q? 14:29:22 ack adrianba 14:29:47 adrianba: It seems strange to me that we would say "we do not want payment apps to be responsible for the filtering because of some privacy or other concerns" 14:30:11 (MAY I CLARIFY?) 14:30:26 ...and push to payment method spec 14:30:34 ...I think this is a spec issue not a practical implementation issue 14:30:41 ..what should be in PR API v other spec 14:30:53 ..where we delegate to other specs, how specific we should be about that delegation 14:30:54 q+ 14:31:47 ..even if you decide that it's ok to delegate the modifications to matching to the payment method specs, then I still think we can be more specific about what is being delegated 14:32:35 ian: let me clarify. PM specs would not define new matching algos but would define the names of the filters. 14:32:38 q+ 14:33:01 ... they wouldn't define how the matching takes place just the data 14:33:13 adrianba: that's not how the PR reads 14:33:21 ian: then that's a bug in the PR 14:33:52 q+ 14:33:57 ack me 14:34:02 ... we don't want elaborate algos. Basic string set matching seems to provide all the functions needed by the existing payment methods 14:34:12 IJ: The goal was just to let payment method specs provide static data (e.g., string sets) 14:34:29 AdrianHB: Part of the reason we have this complexity is that filters are mashed in with other data that might not be for filtering 14:34:36 (IJ thinks that's an orthogonal issue) 14:35:00 q+ 14:35:15 q- later 14:35:31 q? 14:35:35 ack AdrianHB 14:35:37 ack me 14:35:51 rouslan_: I think a compromise could be the following: 14:36:22 a) Leave matching logic in PR API as is. Add a Note that the information that is necessary from a payment method spec is the list of parameters that are filters. 14:36:33 ...so in Basic Card we could state clearly which fields are filters 14:36:59 ..that will enable us to not disturb deployments 14:37:25 ..the logic in the browser, when adding new short string payment method identifiers would be not just to add the identifier of the new payment method, but also add a list of params that should be treated as filters 14:37:48 AdrianHB: +1 14:37:56 q? 14:37:58 ack rous 14:38:03 ack adrianba 14:38:17 adrianba: Sorry for jumping in the middle of things discussed at length during my absence. :) 14:38:23 AdrianHB: Not agreeing with rouslan's proposal, but I do understand it :) 14:38:32 q+ to make a counter proposal to Rouslan 14:39:01 adrianba: To Ian's point...he's imagining that this will work on static data. The current pull request does not match what has been discussed today. That's the root of the issue with this pull request 14:39:14 ...on rouslan's description, I think that's along the lines of what I had in mind. 14:39:40 ..something where we say that "this part of the matching is more specific when it's basic card"...rather than having an open-ended thing 14:39:53 ...my impression from marcos is that one issue he has with the PR is the open-ended nature of it 14:39:58 q+ 14:40:16 ...we would typically define an anchor where there is more processing at a point 14:40:30 ..often what you want to do is say between steps 7 and 8 do these additional things 14:40:48 ..the problem in general with that is that when the spec you are linking to changes and they renumber steps, it no longer makes sense 14:40:57 ...broken links are a spec problem 14:41:17 ack Adr 14:41:17 AdrianHB, you wanted to make a counter proposal to Rouslan 14:41:26 AdrianHB: I have a counter proposal to Rouslan's.... 14:41:45 ...if your primary concern is around existing ecosystem, perhaps a solution is to deprecate the data member and introduce two new members 14:41:58 ...method-data (replacing data) and method-filters 14:42:02 ..which would be a set of filters 14:42:10 q+ 14:42:23 ack rous 14:42:34 rouslan_: -1 to deprecating "data"; seems like overkill 14:42:48 ...I think we can accomplish what we want with the existing API 14:42:55 ack me 14:42:57 +1 - this is a spec issue 14:43:20 ian: we have two other payment method specs in dev both of which use filters 14:43:39 ... we should not say all we know about is basic card 14:44:04 ... I like Rouslan's idea, it seems helpful 14:44:35 AdrianHB: How do vendors implement Rouslan's idea? It requires them to do explicit implementation of each payment method spec 14:45:06 .ian: Where in the merchant provided data the filters are described is muddying the waters 14:45:08 q+ 14:45:40 ... at this point in the algorithm the browser has the data and its underspecified what they do with it 14:45:59 ack AdrianHB 14:46:01 ... this helps us get security feedback too 14:46:13 AdrianHB: I have two concerns that we seem to be glossing over 14:46:45 ..when we say what which fields are filters, browsers needs to pick out of data those fields and that's an implementation burden 14:47:00 ..if browsers say "ok" that's fine, but that's an implementation burden and makes the short string conversation harder. 14:47:13 (IJ thinks it would be easier that way than it is under the current underspecifiation) 14:47:37 q+ 14:48:26 AdrianHB: Having filters separate from data reduces the implementation burden; browser vendors no longer have to modify code to determine what's a filter 14:48:32 ack AdrianHB 14:48:34 ack Ad 14:49:03 adrianba: I think that at the basic level, my proposal around how we might make this be an extension point as written in the PR, that 14:49:41 ..instead, we say there's a precise matching algorithm (what is in the spec) that should be used..a.nd in practice what happens is that when filtering is applied, it may remove things further from the list. 14:50:13 ..i'm saying that we should say that "this is the algo and in the absence of filtering, this is what happening, and for payment methods with filters, you will potentially reduce the set further" 14:50:17 IJ: I'm ok 14:50:45 adrianba: The second part is that we are sort of glossing over some things as AdrianHB said 14:51:19 ...I don't think we can specify an open-ended filtering mechanism that is going to necessarily going to be payment method specific that doesn't require either browser to add something in order to support those payment methods OR to actually have the payment app be part of filtering 14:51:35 ...because basic card is integrated into the browser, we don't see the distinction between those things 14:51:51 ...we can kid ourselves that the browser is doing the filtering, but you could also say it's the payment apps 14:52:00 q+ 14:52:16 Q+ to propose we look deeper at the idea of the lambda 14:55:00 q+ 14:55:30 ian: I imagined that each time a browser added support for a payment method they'd do so thoughtfully. If there is a conscious decision to provide support for every short name then it should be as easy as possible. 14:55:31 q+ to talk about adding support for short strings and the decisions there and how it might impact filtering 14:55:47 .. I hear 2 axis to this @@@ 14:56:21 ... when vendors choose to add support it could be just adding the short-string to an enum or also adding the filters too 14:56:43 ... I see the specificity as reducing implementation burden 14:56:47 ack ain 14:56:53 ack ian 14:56:56 IJ: My axes that I hear are (1) reusable filtering algo (2) automatic identification of filter fields 14:57:01 ...those are separable 14:57:24 AdrianHB: I propose to close the PR and add an issue; and ask the editors to add text (e.g., AdrianBA's text) they are comfortable with 14:57:47 ..namely filtering against payment methods happen, then there may be payment method specific filters may reduce the set further 14:58:18 AdrianHB: I think the lambda option is elegant if we can find a way to make it work; I think we've not explored deeply enough. 14:58:20 (UGH) 14:58:22 q? 14:58:24 ack AdrianHB 14:58:24 AdrianHB, you wanted to propose we look deeper at the idea of the lambda 14:58:29 ack adrian 14:58:29 adrianba, you wanted to talk about adding support for short strings and the decisions there and how it might impact filtering 14:58:58 adrianba: To Ian, I think that when Zach is talking about the burden of adding support for a new short string, that's more about avoiding arbitrary short strings 14:59:29 ..that's very different from there being an implication that we have to make other coding changes 14:59:40 ...so I think Zach's comment is just about the short strings 15:00:21 topic: Face-to-face meeting? 15:00:28 Next meeting is in November 15:00:34 (M/T of TPAC) 15:01:24 IJ: I wanted to get more definitive info on whether or not to have a FTF meeting in July or Aug 15:01:33 AdrianHB: Please all give that some thought and we can return to this next week 15:01:37 Topic: Next meeting 15:01:39 18 May 15:01:41 RRSAgent, make minutes 15:01:41 I have made the request to generate http://www.w3.org/2017/05/11-wpwg-minutes.html Ian 15:01:47 RRSAgent, set logs public 15:01:58 alyver has left #wpwg 15:05:27 adrianba has joined #wpwg 15:25:46 cweiss has joined #wpwg 15:28:50 emschwartz has joined #wpwg 17:01:44 Zakim has left #wpwg 17:16:17 cweiss has joined #wpwg 18:45:30 cweiss has joined #wpwg 18:59:48 cweiss_ has joined #wpwg