15:01:19 RRSAgent has joined #wpwg 15:01:19 logging to http://www.w3.org/2017/03/02-wpwg-irc 15:01:21 RRSAgent, make logs public 15:01:21 Zakim has joined #wpwg 15:01:23 Zakim, this will be 15:01:23 I don't understand 'this will be', trackbot 15:01:24 Meeting: Web Payments Working Group Teleconference 15:01:24 Date: 02 March 2017 15:01:34 agenda: https://github.com/w3c/webpayments/wiki/Agenda-20170302 15:01:37 regrets+ AdrianHB 15:01:39 chair: Nick 15:01:41 scribe: Ian 15:01:56 present+ 15:02:03 present+ Laura 15:02:28 AlanMarshall has joined #wpwg 15:02:33 present+ 15:02:43 present+ 15:03:34 zkoch has joined #wpwg 15:03:35 present+ 15:03:53 present+ 15:04:01 present+ 15:04:57 present+ ChristianW 15:05:59 present+ Molly 15:06:11 present+ Alan 15:06:39 Manash has joined #wpwg 15:07:00 present+ Manash 15:07:05 zakim, who's here 15:07:05 Ian, you need to end that query with '?' 15:07:06 zakim, who's here? 15:07:06 Present: rouslan, Laura, oyiptong, adamR, Ian, spolu, zkoch, ChristianW, Molly, Alan, Manash 15:07:09 On IRC I see Manash, zkoch, AlanMarshall, Zakim, RRSAgent, rouslan, cweiss, spolu, betehess, pea13, canton, adamR, dlehn, nicktr, hober, slightlyoff, ShaneM, trackbot, Ian, 15:07:09 ... adrianba, Dongwoo, JakeA, emschwartz, oyiptong, davidillsley_, AdrianHB, mkwst_ooo, schuki, manu, dlongley 15:07:26 present+ Michel 15:07:30 present+ NickTR 15:07:43 topic: Introductions 15:08:05 regrets+ AdrianHB 15:08:19 regrets+ Andre 15:08:25 [Laura Townsend, MAG] 15:08:42 Laura: Seeking to identify a more tech person to participate 15:08:54 [Christian Weiss, Stripe] 15:09:06 Christian: Happy to join you 15:09:16 [Manash Bhattacharjee, Mastercard] 15:09:24 MattS has joined #wpwg 15:09:29 Manash: We just joined W3C, are in the process of joining the WG 15:09:33 pea13 has joined #wpwg 15:09:34 canton_ has joined #wpwg 15:10:00 IJ: MC joined W3C this week 15:10:02 [Michel Weksler (AirBNB)] 15:10:08 present+ MattS 15:10:21 I have made the request to generate http://www.w3.org/2017/03/02-wpwg-minutes.html Ian 15:10:33 present+ Ken 15:10:38 zakim, who is here? 15:10:38 Present: rouslan, Laura, oyiptong, adamR, Ian, spolu, zkoch, ChristianW, Molly, Alan, Manash, Michel, NickTR, MattS, Ken 15:10:41 On IRC I see canton_, pea13, MattS, Manash, zkoch, AlanMarshall, Zakim, RRSAgent, rouslan, cweiss, spolu, betehess, adamR, dlehn, nicktr, hober, slightlyoff, ShaneM, trackbot, Ian, 15:10:41 ... adrianba, Dongwoo, JakeA, emschwartz, oyiptong, davidillsley_, AdrianHB, mkwst_ooo, schuki, manu, dlongley 15:10:50 topic: 15:10:50 Payment Request API 15:10:55 topic: Payment Request API 15:10:58 Ken has joined #wpwg 15:11:15 https://github.com/w3c/webpayments/wiki/Agenda-20170302 15:11:26 Ian has changed the topic to: 2 March agenda => https://github.com/w3c/webpayments/wiki/Agenda-20170302 15:11:45 Molly has joined #wpwg 15:11:48 mweksler has joined #wpwg 15:12:04 IJ: Where are editors currently on billing address? 15:12:30 zkoch: Background is that in some locales the VAT needs to be calculated based on billing address or where you live 15:12:41 ...right now there's no way to get that via the API 15:12:47 ...for a digital good 15:12:55 ...without support, we eliminate some use cases 15:13:24 ...at this point if we can figure out this PR and issues with it, I'm ok to make this one of the last feature changes (before CR) 15:13:39 ..but as the PR stands now, the larger challenge (beyond the name) is the behavior 15:13:51 ..in case of billing address, there is no shipping options 15:13:59 ..if you pass back "empty" it indicates a problem. 15:14:05 ...we have to do the work to figure out how to treat this 15:14:16 ...this also extends to another issue: "store pickup" 15:14:22 issue: https://github.com/w3c/browser-payment-api/pull/409 15:14:23 Created ISSUE-1 - Https://github.com/w3c/browser-payment-api/pull/409. Please complete additional details at . 15:14:41 IJ: Should we talk about store pickup here as well? 15:14:47 zkoch: no; we can handle separately 15:14:58 IJ: What question would you ask the group? 15:15:16 zkoch: Do we think this use case is important enough to worry about? Our previous decision (about 1 year ago) was that it was not 15:15:30 ...but what's changed in the past year is that we didn't have shipping type affordance 15:15:35 ...we could do this if we think it's a priority... 15:15:38 ...so how important is this? 15:15:40 q? 15:15:45 q+ 15:15:48 nicktr: Any opinions on this? 15:16:01 q+ 15:16:01 ack adamR 15:16:22 adamR: The only thing that comes to mind here is if we separate shipping from billing address..it would be nice to have the question resolved before finalizing basic card spec 15:16:39 zkoch: not sure that's entirely the case...I don't think "billing address" is accurate. I think "VAT" is better 15:16:50 ..and different countries have different requirements about which address to use 15:16:57 ..so they are not always synonymous 15:17:10 AdamR: Let's avoid a 100% overlap with what basic card asks for ... if so, that's fine 15:17:12 lte has joined #wpwg 15:17:25 zkoch: You may also use a friend's credit card...so I think lots of cases where the addresses are disjoint 15:17:26 q? 15:17:32 ack spolu 15:17:33 ack spolu 15:17:55 Stan: Looking at the pull request - does this mean if you ask for billing you can't get shipping? 15:18:12 zkoch: VAT calculation is only an issue for digital goods (where you don't get a shipping address) 15:18:35 ..if you use basic card you'll get back address with basic card...but if you don't use basic card, there's no guarantee you'll get back an address. 15:19:04 stan: To give some context about how Stripe handles this - we did split the two and we recognize them as separate...billing address available for any payment address...it has served us well 15:19:17 ...I am concerned about conflation of shipping address for this purpose in some cases 15:19:30 zkoch: The way I look at this - the user agent presumably has a set of addresses for a user 15:19:53 ..what we are talking about here is (1) in the UI explain to a user what set of information is being requested (e.g., pickup address, delivery address, etc.) 15:20:07 ....and one of these things might be a VAT computation address (UA's will find the right string to educate users) 15:20:12 ...and (2) a set of addresses that show up for users 15:20:35 ...it could easily be that the VAT address you select is different from your credit card billing address 15:20:40 q+ to ask if the payment app can supply any addresses 15:20:58 stan: The canonical user experience we think about here is what you see on Amazon 15:21:11 ...Amazon did a fine job of understanding your previous billing and shipping addresses 15:21:38 ...I think the PR pushes user agents to conflate all addresses...I think that will lead to confusion 15:21:59 ...I think we need to have a clearer definition of billing address 15:22:05 q? 15:22:28 zkoch: I think you raised a few issues...e.g., sharing billing addresses with payment apps may be problematic 15:22:50 ..but our general stance here is that a lot of things you are mentioning are important, but they are user experience issues that will be handled by UAs 15:22:59 ...so while I agree, not sure we should specify the behavior 15:23:26 stan: As a developer experience, I've been PR API, I had a hard time to understand the PR.....I think it could be cleared up to be about VAT 15:23:27 q? 15:23:29 ack nicktr 15:23:29 nicktr, you wanted to ask if the payment app can supply any addresses 15:23:49 nicktr: Stan, would appreciate your input on GitHub list as well 15:23:57 nicktr: Can payment app provide the billing address? 15:24:14 zkoch: First answer is that for any payment app that is returning a basic card, you are expecting to pass back the associated billing address 15:24:22 q+ 15:24:29 ...the second answer is that apps can pass back whatever they think makes sense for their payment app based on payment method 15:24:48 ..but there is no mechanism for the payment app systematically to integrate addresses given event model 15:25:02 nicktr: What if payment app returns different address than what the UA knows about? 15:25:11 zkoch: You mean in general or in light of VAT computation? 15:25:27 ...billing address does not have to be same as VAT computation address 15:25:44 ...e.g., in EU, for digital goods, the VAT computation is based on your home address, which may not be the address on the card 15:26:11 q+ 15:26:23 q? 15:26:38 ack adamR 15:26:52 ack adam 15:27:07 AdamR: If a payment method is returning the information, you can't have payment method specific prices 15:27:17 ...or for the VAT to vary based on payment methlood 15:27:28 nicktr: So it has to be the mediator 15:27:33 ack Alan 15:27:34 ack AlanMarshall 15:27:48 AlanMarshall: Great discussion. Could you restate the core question 15:28:00 ...is it strictly around the address being used for the VAT? What's the issue that needs to be addressed? 15:28:30 zkoch: The problem statement is that for taxation you need to know VAT address for the user 15:28:31 Max has joined #wpwg 15:28:41 ..today in PR API there is no way to get an address from user to let you do this 15:29:03 ...so the user experience problem is that you can't show accurate total price 15:29:06 present+ Max 15:29:32 ...so there is a proposal for a new type (e.g., "VAT" or "billing address") that would allow the user to see in the user interface a place to see an address 15:29:51 ..there would be no shipping options, it would just be a way to send information to the merchant, and update the price 15:29:58 ...question is - should we accommodate in the spec for V! 15:30:04 s/V!/V1 15:30:24 PROPOSED: Support VAT info collection in V1 of the spec 15:30:29 +0 15:30:42 +1 15:30:47 +1 (AdamR distinction that these are the address that influence total amount is :100:) 15:30:48 +1 15:30:51 +1 15:31:03 +1 (but only if we can make it clear that it’s something other than shipping address) 15:31:09 q? 15:31:10 +1 15:31:16 Alan: I think this is important for the Korean market 15:31:35 zkoch: Hearing general support, I think the question we need to look at is how complex will this be. 15:31:47 ..it might also be some time until this is broadly support across user agents 15:32:05 zkoch: I will follow up with Roy 15:32:24 RESOLVED: There is support for VAT info collection in V1 15:33:13 Topic: Payment option filtering 15:33:28 nicktr: We had good discussion last week...want to check with implementers 15:33:44 https://github.com/w3c/browser-payment-api/pull/420 15:35:26 https://github.com/w3c/browser-payment-api/pull/420 15:36:08 q? 15:36:10 [IJ Summarizes the filter topic] 15:36:37 Laura: quick question - what you are talking about, from a merchant perspective 15:37:49 nicktr: We are focused on card payments - basic card is the payment method; the filter is about conditions under which you accept basic card 15:38:35 Laura: does this also mean filtering on payment apps? 15:38:56 nick: No. Which app is present is determined by the browser, looking at payment methods and filters and user's payment apps 15:40:04 q? 15:40:10 IJ: Implementers? 15:40:22 q+ 15:40:24 ack rous 15:40:43 Rouslan: The essence of the proposal is to do string set matching 15:41:06 ...the browser compares string sets provided by merchant and payment app 15:41:19 ..the major point of contention between firefox and chrome is how we should specify the filters 15:41:33 ...an important point for Google is backward compatibiliyt 15:41:45 ...don't want to change the shape of the API, only the behavior of the API 15:42:06 ...Mozilla is proposing to name filters explicitly (change shape of API) 15:42:21 ..Google is preferring to treat string sets as filters (but not requiring those filters to be explicitly named) 15:42:45 ...so the practical implication of we move to mozilla's proposal is that data would be moved to a new explicit field 15:42:56 ..Google could deprecate the old way of doing this over several months 15:43:06 q+ 15:43:10 Q? 15:43:17 q+ 15:43:19 ....Edge plans to support basic card...wanted to hear from MS about renaming filters => "filters" 15:43:27 q? 15:43:31 ack zkoch 15:43:33 ack zkoch 15:43:57 zkoch: I want to make it clear that the functionality exists for basic card 15:44:08 IJ: The heart of the question is whether to use this for other payment methods 15:44:10 q+ 15:44:19 ack adamR 15:44:46 adamR: To expand on Rouslan's comments. This is not a renaming of "data" to "filters" 15:44:52 ..there is still payment-specific data 15:45:12 ...the second part is that is a way to do this with backwards compatibility by allowing the specific 15:45:28 ...fields in basic card to appear in either place for a transitional period...this is not a breaking change 15:45:31 q? 15:45:32 ..this is an evolution of the API 15:45:42 ack Ian 15:45:55 http://w3c.github.io/webpayments-methods-credit-transfer-direct-debit/ 15:47:14 https://w3c.github.io/webpayments/proposals/tokenized_cards.html 15:47:55 q+ 15:47:57 q+ 15:48:12 https://www.w3.org/Payments/card-network-ids 15:48:48 q+ 15:49:16 ack adamR 15:49:29 IJ: So there are three payment method specs that want filtering AND regulatory issue of limiting string sets (cf https://www.w3.org/Payments/card-network-ids ) 15:49:54 ack zkoch 15:49:55 adamR: We are likely to also going to want to say something similar for future payment methods (e.g., cryptocurrencies where you accept different types) 15:50:26 zkoch: the last time the conversation came up we said that we thought this would only be relevant for WG specs... 15:50:35 q+ 15:50:37 ..I get why this is useful for tokenization 15:50:45 ..I also spec that you'll define that in the tokenization spec 15:51:00 ...I still don't see us in chrome doing generic string matching and hoping for the best on the UI 15:51:01 q? 15:51:03 q+ 15:51:05 q? 15:51:06 ack nicktr 15:51:36 ack adamR 15:51:40 nicktr: To clarify my comment - i was concerned there would be a competition issue... I want there to be a level playing field on filtering 15:51:42 ack Adam 15:52:02 AdamR: Can you say what you mean by user epxerience? This is just a rendez-vous function 15:52:16 ..the purpose of this is to allow the browser to determine which apps to display to the user 15:52:58 q? 15:53:24 ack Ian 15:54:00 q+ 15:54:14 IJ: My proposal is to say "let's use the same simple filtering language in those supported payment methods" 15:54:39 ack adamR 15:54:39 IJ: The rules for filtering are known in advance. The string values are not 15:54:57 AdamR: This is fundamentally a different view on how much work browsers should do to accommodate new payment methods 15:55:30 ..if you allow the specific to have a setup whereby browsers can simply adopt new methods without adding new code, browsers can still have their own whitelists to allow the ones they trust to work. 15:55:47 ...if you do the other way around, everyone always has to write new code to support a new payment method 15:55:50 q? 15:55:57 ...for browsers that only come out every 18months, this is problematic 15:56:01 zakim, close the queue 15:56:01 ok, nicktr, the speaker queue is closed 15:56:10 ...I would prefer to not require new code for each new payment method 15:56:14 Is this Issue #96 ? 15:56:36 Molly: I will check in and come back next week or by email 15:56:57 q+ to suggest we extend 10 mins 15:57:24 q+ 15:57:31 topic: FTF agenda 15:57:33 https://github.com/w3c/webpayments/wiki/FTF-March2017 15:57:34 Updated => https://github.com/w3c/webpayments/wiki/FTF-March2017 15:57:59 (Ian thinks this is near final) 15:59:06 topic: Next meeting 15:59:11 * More on filtering 15:59:16 * More on line items privacy 15:59:23 thanks! 15:59:57 RRSAGent, make minutes 15:59:57 I have made the request to generate http://www.w3.org/2017/03/02-wpwg-minutes.html Ian 16:00:00 RRSAgent, set logs public 16:00:26 thanks everyone 16:00:26 nickTR: Thanks again to new people; I or Ian happy to chat before FTF 16:00:29 RRSAGent, make minutes 16:00:29 I have made the request to generate http://www.w3.org/2017/03/02-wpwg-minutes.html Ian 16:02:01 q? 16:02:41 zakim, who is here? 16:02:41 Present: rouslan, Laura, oyiptong, adamR, Ian, spolu, zkoch, ChristianW, Molly, Alan, Manash, Michel, NickTR, MattS, Ken, Max 16:02:43 On IRC I see Max, lte, mweksler, Ken, canton_, pea13, MattS, AlanMarshall, Zakim, RRSAgent, cweiss, spolu, adamR, dlehn, nicktr, hober, slightlyoff, ShaneM, trackbot, Ian, 16:02:43 ... adrianba, Dongwoo, JakeA, emschwartz, oyiptong, davidillsley_, AdrianHB, mkwst_ooo, schuki, manu, dlongley 16:04:30 zkoch has joined #wpwg 16:08:23 Guest91 has joined #wpwg 16:22:36 Guest91 has joined #wpwg 16:26:11 Guest91 has joined #wpwg 16:35:16 zkoch has joined #wpwg 16:41:51 cweiss has joined #wpwg 16:58:31 cweiss has joined #wpwg 17:01:42 zkoch has joined #wpwg 17:31:57 betehess has joined #wpwg 17:42:44 Guest91 has joined #wpwg 17:44:57 zkoch has joined #wpwg 18:02:27 betehess has joined #wpwg 18:03:38 zkoch has joined #wpwg 18:05:44 Zakim has left #wpwg 18:45:47 zkoch has joined #wpwg 19:07:26 betehess has joined #wpwg 19:27:20 cweiss has joined #wpwg 20:01:20 cweiss has joined #wpwg 20:03:36 zkoch has joined #wpwg 20:26:17 zkoch has joined #wpwg 22:10:10 cweiss has joined #wpwg 22:21:52 betehess has joined #wpwg 22:30:16 betehess has joined #wpwg 23:57:42 betehess has joined #wpwg