14:59:47 RRSAgent has joined #wpwg 14:59:47 logging to http://www.w3.org/2016/12/08-wpwg-irc 14:59:49 RRSAgent, make logs public 14:59:49 Zakim has joined #wpwg 14:59:51 Zakim, this will be 14:59:51 I don't understand 'this will be', trackbot 14:59:52 Meeting: Web Payments Working Group Teleconference 14:59:52 Date: 08 December 2016 14:59:59 Agenda: https://github.com/w3c/webpayments/wiki/Agenda-20161208 15:00:45 zakim, who's here? 15:00:45 Present: (no one) 15:00:47 On IRC I see RRSAgent, oyiptong_, frank, MaheshK, pascal_bazin, adamlake, collier-matthew, emschwartz, adrianba, Dongwoo, schuki, hyojin, mkwst, slightlyoff, JakeA, davidillsley_, 15:00:47 ... AdrianHB, nicktr, canton_, pea13, dlehn, manu, dlongley, ShaneM, trackbot, Ian 15:00:50 present+ AdrianHB 15:00:53 present+ Frank 15:00:55 present+ Mahesh 15:00:58 present+ MattSaxon 15:01:00 present+ Max 15:01:02 present+ Olivier 15:01:03 rouslan has joined #wpwg 15:01:04 present+ Pascal 15:01:11 present+ Rouslan 15:01:14 present+ Ian 15:01:24 zakim, who's here? 15:01:24 Present: AdrianHB, Frank, Mahesh, MattSaxon, Max, Olivier, Pascal, Rouslan, Ian 15:01:27 On IRC I see rouslan, Zakim, RRSAgent, oyiptong_, frank, MaheshK, pascal_bazin, adamlake, collier-matthew, emschwartz, adrianba, Dongwoo, schuki, hyojin, mkwst, slightlyoff, JakeA, 15:01:27 ... davidillsley_, AdrianHB, nicktr, canton_, pea13, dlehn, manu, dlongley, ShaneM, trackbot, Ian 15:01:30 regrets+ NickTR 15:02:10 present+ Manu 15:02:17 present+ Manu 15:02:27 present+ Andre 15:02:30 MattS has joined #wpwg 15:02:35 present+ zkoch 15:02:51 alyver has joined #wpwg 15:03:26 dezell has joined #wpwg 15:03:41 Agenda: https://github.com/w3c/webpayments/wiki/Agenda-20161208 15:03:43 present+ dezell 15:04:17 present+ Shane 15:04:26 present+ MattS 15:04:38 agenda => https://github.com/w3c/webpayments/wiki/Agenda-20161208 15:04:41 Topic: Editor update 15:05:06 AdrianHB: Marcos Caceres will become an Editor of PR API (and associated) 15:05:24 ...Marcos has contributed a lot via issues list; this will allow us faster progress. Thanks to Marcos! 15:05:35 ..and thanks to the existing Editors for including him in the process. 15:05:38 (IJ: +1) 15:05:47 topic: Payment Request API 15:05:48 scribe: Ian 15:06:07 See pull request on detecting payment method availability: https://github.com/zkoch/zkoch.github.io/blob/master/pr-detect-avail.md 15:06:22 zkoch: We need one more change in the pull request, which I will explain 15:06:37 ...we didn't have consensus from MS a couple of calls ago; we've now figured out what we want. 15:06:43 ..we changed the name and the algorithm a bit 15:06:54 ...last call we got consensus on the general direction 15:07:12 ...but where I think we should get consensus is that for now there will be ambiguity about what this function means. 15:07:22 ...there will be ambiguity 15:07:57 ..for chrome, we see this as an active check => we want to return true if ready to make payment; edge not comfortable with "active" 15:08:04 ...secondly there are concerns around fingerprinting. 15:08:18 q+ to discuss proposal from Dave Longley that addresses privacy concerns... 15:08:23 ...we think that it's "difficult enough" and not easy to do. 15:08:32 ..every merchant we've spoken to (more than 50) has asked for this 15:08:56 ..this API remains one of the compromises; note that the function returns a boolean, and we can modify the meaning of the function over time 15:10:01 sorry 15:10:03 ...I'd like wg to voice support for the function; we still need to update the pull request to reflect the fact of the ambiguity 15:10:17 ack manu 15:10:17 manu, you wanted to discuss proposal from Dave Longley that addresses privacy concerns... 15:10:23 https://github.com/w3c/browser-payment-api/pull/316 15:10:34 zkoch has joined #wpwg 15:10:35 manu: Dave Longley has a proposal 15:10:43 https://github.com/w3c/browser-payment-api/pull/316#issuecomment-265218908 15:10:52 present+ zkoch 15:10:58 ...Dave asks whether we need the function at all. 15:11:11 ...we could modify the call to show() so that the merchant provides a URL for their checkout flow 15:11:38 ...so if the user does not have any payment instruments set up, they can always just click with "pay with *Pay" button 15:11:48 ...this approach has fewer privacy downsides 15:12:19 ...the merchant is not asking "can the API be used" but the question is whether "do I need to take them to my flow or will the browser handle it for me" 15:12:20 q+ 15:12:32 ack zk 15:13:02 zkoch: I actually don't agree that that's what merchants want (from speaking with them). 15:13:37 ..many merchants don't want to put people through flows unless they are confident that there is a payment method available ready to go 15:13:56 ...I do think that the proposal would solve one problem but not the core problem. 15:14:00 ...there is also a branding issue. 15:14:16 ...some merchants will use a button that says something like "quick checkout" 15:14:25 ...they only want to show that if they are confident that a user has something available 15:14:38 ...see the list of problems/merchant requests in the explainer 15:15:01 ...we had thought of one option where in the payment request API of declaring whether to include a "manual add" flow, but that wasn't fundamentally what merchants wanted. 15:15:04 q+ 15:15:22 Ian: q about the ambiguity 15:15:43 Ian: Is it possible to be more explicit in the call so that merchants know what they're going to get back. 15:15:47 ... is it possible to be more explicit in the API call so that merchants know what they're going to get back 15:16:29 Ian: Is there some way for merchants to have more certainty of what will happen independently of the implementation details. Can you get rid of the ambiguity by being more explicit? 15:16:46 AdrianHB: I don't think we are at a position to say "this is ready to go" but it's fair for zach to make this a last call for issue 15:17:11 zkoch: the last call was last week 15:17:14 (IJ agrees with zach) 15:19:21 q+ to ask if anyone else has asked merchants about the flow if we have a "forward to checkout page" approach? Shopify? WorldPay? 15:19:30 q+ 15:19:32 zkoch: I am looking for consensus for the pull request as-is (in what it is proposing) but with some editorial changes (and addition of mention of ambiguity) 15:19:34 q- 15:19:39 ack manu 15:19:39 manu, you wanted to ask if anyone else has asked merchants about the flow if we have a "forward to checkout page" approach? Shopify? WorldPay? 15:20:52 q+ 15:21:08 Manu: To clarify the flow in Dave's proposal: you would see sheet and if user doesn't have the support the merchants want, there would be one button to take them to the merchant traditional checkout flow 15:21:19 ..I'd like to hear from Worldpay or Shopify whether this would be interesting 15:21:30 q? 15:21:49 ack Matt 15:22:15 MattS: one of my colleagues (Matt Devaney) has commented on the thread...Matt is talking about one of our particular flows. 15:22:29 ...I don't disagree with Zach about some merchant requests 15:22:52 ..but the particular PR request problems I have are (1) doesn't allow Dave longley flow and (2) 30-minute window challenge 15:23:09 ..I think that Dave's proposal is viable, but not viable for all merchants 15:23:15 I don’t think the PR says anything about 30 min 15:23:40 adrianhb: I think that Dave's proposal could still be added in the future as a feature 15:23:53 +1, I agree this could be a feature 15:23:54 ...so that PR API provides a way to get to the page 15:24:01 “Checkout w/ traditional merchant flow" 15:24:09 AdrianHB: I think we could add this 15:24:11 ack alyver 15:24:25 alyver: I agree that Dave's proposal is a nice feature, especially where we don't have payment apps for lots of payment methods 15:24:39 ..I think there's a need for the user to be able to exit gracefully to a legacy checkout flow 15:24:56 ...I still agree with zach that there is a use case for knowing "user can make a payment right now" to place a quick checkout button on a product page 15:25:18 ..I think Dave's proposal is a useful feature but that canMakePayment() is still needed 15:26:12 Ian: There may be some editorial changes, which is fine. 15:26:27 Ian: We may live with the ambiguity, but if we can do better and reduce ambiguity, we can do that. 15:26:41 q+ 15:26:42 AdrianHB: Is anyone opposed to the PR given that (1) there may be some editorial changes and (2) at worst it will be ambiguous (and documented as such) but if we can make it better we will 15:26:53 adrianHB: I want to avoid browser sniffing 15:27:03 ack zkoch 15:27:41 zkoch: I wish I had a clearer answer. Safari supports "active" with ApplePay. Chrome views this as "Active". I don't know about Firefox. Edge is not ready to treat it as "active" 15:27:47 ...merchants are telling me they have to have it 15:27:55 ...mainly because Apple has set precedent 15:28:03 rouslan has joined #wpwg 15:28:16 q+ 15:28:37 ack Ian 15:28:40 q+ 15:29:10 Ian: To remove the ambiguity, all we have to do is tell the merchants what we know. One answer is "Yes, and I'm sure", or "No, and I'm sure", and the last one is "I don't know". 15:29:26 Ian: Then the merchant can decide what to do based on "I don't know"... 15:29:37 Assuming "i don't know" also means "I won't say" 15:29:48 Ian: There are ways where smart people can reduce ambiguity which seems to be the main solveable problem. The privacy issues are not solveable. 15:30:14 Ian: If we can get a provisional yes for the proposal if we can address ambiguity. 15:30:17 AdrianHB: +1 to Ian...I would prefer that we have definitive answers to the function 15:30:33 ...browsers can return "I know yes/no" and Edge can still be compliant by saying "I don't know" (at least for now) 15:30:45 ...as a merchant I know what to expect from the query 15:30:50 ..and can make my own choice 15:30:56 ..so to me that's more desirable 15:31:03 rouslan: +1 to "I don't know " option 15:31:18 ...we have something similar when canMakePayment() when exists with quota exceeded error 15:31:25 ...so we could so something similar when browser is not sure 15:31:55 ..another thing that we can do is stay that a browser does not support this functionality because of platform restrictions can not expose that function on the request 15:32:07 ...and so the web developer can check whether the feature is available and use only if available. 15:32:22 AdrianHB: Also a a fair proposal. 15:32:37 When is our next meeting? 15:32:51 Ian: Can we move forward by saying we can reduce ambiguity, there are two proposals on the table, let's get editors to update proposal to include that. 15:33:27 Ian: There is canMakePayment() and Dave Longley's proposal. Let's distinguish those. 15:33:36 Ian: There are remaining questions aroudn privacy, are we okay with those? 15:33:58 zkoch: I think the two proposals are Dave Longleys...we could thing of this as an independent proposal. 15:34:07 ...having an escape hatch is a nice idea 15:34:23 ..the other idea here is to remove ambiguity by introducing a new option (or rouslan's proposal). 15:34:32 ...the "i'm unwilling to say" is a privacy escape hatch 15:34:47 AdrianHB: I like the idea that it aligns with "exceeded quota" approach 15:34:54 zkoch: That seems fine to me 15:35:00 ...we have to figure out whether throwing is the right thing to do here 15:35:04 ..I'll talk to DominicD 15:35:11 ...so the general idea is yes/no/otherstate 15:35:22 zkoch: Here's my proposal: 15:35:26 1) WG meets next week 15:35:35 2) We agree that Dave Longley's proposal is worth its own pull request 15:35:44 +1 for a PR to explore Dave's idea 15:35:53 (the escape hatch to the traditional flow) 15:35:53 +1 - we've been exploring that idea too 15:35:59 zkoch: good idea to do separately 15:36:07 ...let's look at that as a core feature to add... 15:36:15 Manu: I will let dave know 15:36:31 3) The editors will go back to look at reducing ambiguity 15:36:53 4) The other issue I'm hearing is from Matt Saxon which is about limitation... 15:37:05 ...note that you are not required to canMakePayment() 15:37:11 i don't think the "i don't know" will reduce ambiguity - i think it increases it 15:37:14 zkoch: We vote next Thursday 15:37:41 adrianba: I think we should accept the proposal 15:37:49 ..that is CURRENTLY on the table 15:37:57 ..we can add "I don't know" if there is consensus for that 15:38:06 PROPOSAL: 15:38:21 1) Accept the current PR (which implies editorial changes and ambiguity) 15:38:35 2) Editors will work to see if they get agreement on how to reduce ambiguity but the answer may be they can't 15:38:45 3) They will report back on their changes on the 15 dec call 15:39:02 Yes 15:39:24 q+ 15:39:35 ack rouslan 15:40:07 rouslan: Regarding JS snippets, there were some issues cited by Matt. It's a viable proposal but it might not serve some interests. 15:40:11 ack Matt 15:40:23 MattS: Rouslan made the point I was going to make. 15:41:08 ...we have many merchants. There are thousands of small merchants like this. The more difficult it is to integrate, the more risk it will not be adopted 15:41:41 q+ to ask if WorldPay's problem would be address by Longley's proposal? If not, whitelist? 15:42:17 ..if we have to go out to 1000s of changes and require them to make page changes upstream 15:42:30 ack manu 15:42:30 manu, you wanted to ask if WorldPay's problem would be address by Longley's proposal? If not, whitelist? 15:42:46 Manu: Are browsers open to whitelisting to allow some companies to call the API as many times as they want? 15:42:56 zkoch: We tend to frown upon whitelists in Chrome 15:43:32 ...to understand that I know the use case - user is on 2 sites with hosted web pages...within 30 minutes they try to make a purchase on both sites 15:44:04 AdrianHB: Is there any wording in the proposal about "30 mins" or is it up to the browser? 15:44:11 zkoch: it's up to the browser; there are no hard requirements 15:44:27 ...the general idea here is to start conservatively ... we have flexibility to adjust over time 15:44:38 AdrianHB: I think that discussion is (or should) be independent of adopting the proposal 15:44:48 ..since there's no specific wording that is creating the concern that Worldpay worked 15:44:48 q+ 15:44:54 s/worked/expressed 15:44:57 ...so we can continue to work on that 15:45:12 ack matt 15:46:15 MattS: The longer the window, the easier for fraudsters. But the shorter the more difficult for payment providers 15:46:22 ...I am ok to accept the PR but don't want to close the issue 15:46:50 ...I think Dave Longley's proposal could solve, or white list could solve. I don't want to take a step backwards. 15:47:02 ...this issue still needs to be resolved. 15:47:18 i think we should adopt the current proposal recognizing that we're converging but there is still discussion to be had 15:47:20 PROPOSAL: 15:47:20 1) Accept the current PR (which implies editorial changes and ambiguity) 15:47:20 2) Editors will work to see if they get agreement on how to reduce ambiguity but the answer may be they can't 15:47:20 3) They will report back on their changes on the 15 dec call 15:47:20 4) The specific mechanism for limiting access to the API is still up for discussion 15:47:25 and that we'll have concrete text to modify 15:47:30 +1 15:47:32 +1 15:47:34 +1 15:47:34 +1 15:47:35 +1 15:47:38 +1 15:47:44 SO RESOLVED 15:47:46 +1 15:47:48 +1 15:47:55 +1 15:48:19 topic: Push payments 15:48:31 https://github.com/w3c/browser-payment-api/issues/224#issuecomment-263995469 15:50:22 Pull request for transaction id => https://github.com/w3c/browser-payment-api/pull/292/files 15:51:09 +1 to this PR 15:52:24 https://w3c.github.io/webpayments/proposals/method-practice/#network 15:53:08 +1 to transaction id 15:53:34 https://github.com/w3c/browser-payment-api/issues/224#issuecomment-263995469 15:53:44 PROPOSED: 15:53:48 1) Adopt the paymentRequestID PR 15:54:12 olivier: I'd like to speak about this ID 15:54:25 ...allows us to keep conversation with user in the face of exception 15:54:47 ...doesn't matter if merchant-provided or user agent generated; it will help us maintain a streamlined experience (even after paymentRequest API) 15:54:54 q? 15:55:33 IJ: Can we hear from AdrianB and Zach on the user-agent generated part of this? 15:55:45 AdrianBA: I don't object to adding this to the spec; may not appear in our first implementation 15:56:09 zkoch: I don't object to this; I suspect we'll get some interesting discussion about the shape of the ID...but ok to insert as is 15:56:16 +1 15:56:16 AdrianHB: Support for the proposal? 15:56:18 +1 15:56:19 +0 15:56:19 +1 15:56:23 +0 15:56:25 +1 15:56:31 +1 15:56:44 +0 15:56:46 _0 15:56:48 0-- ! 15:56:53 \)/ 15:56:54 SO RESOLVED 15:57:05 Topic: next meeting 15:57:07 15 December 15:57:21 ..then 5 January 15:57:35 Telecofn proposal: 15:57:35 https://github.com/w3c/webpayments/wiki/Meeting-Proposal-20161128 15:58:21 Autopublishing: 15:58:26 https://lists.w3.org/Archives/Public/public-payments-wg/2016Dec/0011.html 15:59:08 FTF meeting 15:59:17 tentative: Chicago 23-24 March 15:59:32 week before the IETF meeting in Chicago 16:00:32 AdrianHB: Thanks all! 16:00:35 rrsagent, make minutes 16:00:35 I have made the request to generate http://www.w3.org/2016/12/08-wpwg-minutes.html Ian 16:00:37 rrsagent, set logs public 16:00:41 byee 16:00:46 alyver has left #wpwg 16:21:00 rouslan has left #wpwg 16:23:00 zkoch has joined #wpwg 17:45:56 oyiptong_ has joined #wpwg 17:57:59 stan has joined #wpwg 18:19:12 Zakim has left #wpwg 19:07:55 zkoch has joined #wpwg 19:10:32 zkoch has joined #wpwg 20:24:33 stan has joined #wpwg 20:36:10 Adam_ has joined #wpwg 20:37:25 collier-matthew has joined #wpwg 21:15:55 zkoch has joined #wpwg 21:16:04 stan has joined #wpwg 21:58:14 adamlake has joined #wpwg 22:04:45 zkoch_ has joined #wpwg 23:15:19 adamlake has joined #wpwg 23:30:48 stan has joined #wpwg