15:55:51 RRSAgent has joined #wpwg 15:55:51 logging to http://www.w3.org/2016/06/02-wpwg-irc 15:55:53 RRSAgent, make logs public 15:55:53 Zakim has joined #wpwg 15:55:55 Zakim, this will be 15:55:55 I don't understand 'this will be', trackbot 15:55:56 Meeting: Web Payments Working Group Teleconference 15:55:56 Date: 02 June 2016 15:56:28 zephyr has joined #wpwg 15:59:48 agenda: https://github.com/w3c/webpayments/wiki/Agenda-20160602 16:00:27 present+ dezell 16:00:59 present+ AdrianHB 16:01:25 present+ 16:01:35 present+ Dongwoo 16:01:41 present+ 16:01:42 present+ ShaneM 16:01:42 Roy has joined #wpwg 16:01:51 rouslan has joined #wpwg 16:01:58 present+ rouslan 16:02:05 present+ dlongley 16:02:05 present+ dlehn 16:02:13 scribe: Ian 16:02:45 present+ manu 16:02:53 zkoch has joined #wpwg 16:03:21 MattS has joined #wpwg 16:03:28 present+ zkoch 16:03:39 Regrets: Nick 16:04:04 present+ Mahesh 16:04:04 https://github.com/w3c/webpayments/wiki/Agenda-20160602 16:04:17 present+ Roy 16:04:21 thanks! :D 16:04:34 topic: Face-to-face meeting 16:04:36 present+ MattS 16:04:39 adrianhb: Please register 16:04:41 JasonYANG has joined #wpwg 16:04:45 https://www.w3.org/2002/09/wbs/83744/wpwgftf-201607/ 16:05:10 adrianhb: Suggest candidate topics 16:05:14 q+ 16:05:56 q- 16:06:10 q+ adopt as an ED or publish as a FPWD? 16:06:18 I’m behind on email and everything is a mess, can you link to the current registration spec? 16:06:49 there is no current spec 16:06:52 stay tuned 16:06:53 alyver has joined #wpwg 16:07:22 Ian: My expectation is that, given availability and holidays, we won't be in a position to get to FPWD by the face-to-face meeting. Step 1 is to get a document so the group has something to look at. That's the first order of business. 16:07:29 q? 16:07:40 Topic: GitHub organization update 16:07:50 +1 to AdrianHB and triag'ing! :) 16:07:51 adrianhb: Did some issue triage and maintenance...moved specs into their own repos 16:08:16 I like the re-org :) 16:08:20 ...PMI and Card specs now in their own repos 16:08:22 not clear to me why this is better - why do we need to scatter issues all over GitHub? 16:08:59 Yeah, I think what I was looking for is current editor draft 16:09:17 IJ: That spec is not up to date with what we have been discussing 16:09:24 https://github.com/w3c/webpayments/wiki/PaymentApp_Notes 16:09:31 Ian: A couple of notes - that spec is not up to date w/ what we've been discussing, once place to look in particular is that wiki (above) 16:09:36 Got it, thanks 16:09:41 Ian: We'd move some of that material into the spec, that hasn't been done yet. 16:09:48 Task force has: Roy, Dongwoo, AHB, Jason, Adam, Ian 16:10:05 Yeah, I’ll follow up 16:10:07 adrianba: pros and cons to both approaches, the group resolved to follow most other W3C groups and have a repo per sepc 16:10:12 Ian: We've also tried to see if we can get a Google person into that group. 16:10:36 Ian: I've also gotten interest from other companies on 3rd party payment app spec. 16:10:40 yay 16:11:08 adrianhb: Yes, I recognize the github migration means more issue lists to follow 16:11:14 ..I would like to make this easier through a dashboard 16:11:22 ...I will take an action to look into getting a view of those issues 16:11:37 ACTION: AdrianHB to look into creating an aggregate view of issues across issues lists 16:11:37 Error finding 'AdrianHB'. You can review and register nicknames at . 16:11:42 :( it's common in groups where specs are either unrelated or being worked on by different people 16:12:07 Topic: Issue 4 16:12:38 Per payment method pricing 16:13:00 MattS: I think we should be able to distinguish debit from credit. 16:13:29 ..there's the real world use case: biggest online train ticket in the UK has a surcharge. 16:13:40 ..the other use case is @@ 16:14:03 I have made the request to generate http://www.w3.org/2016/06/02-wpwg-minutes.html Ian 16:14:07 q? 16:15:10 adrianhb: You need to know the surcharge up front. if you pick, for example, apple pay...you get a surcharge if you pick your card within apple pay 16:15:13 Kepeng has joined #wpwg 16:15:22 ...this may cause you to cancel your payment and pick another instrument 16:15:34 ...this is a smaller use case today than the other 2 I mentioned (in the UK) 16:15:45 MattS: Another use case is "bitcoin". 16:16:09 ...how can you construct a payment request when you have a value in Sterling and a value in Bitcon 16:16:14 q+ 16:16:41 q+ to ask if we could hear from people opposed to supporting varying amounts depending on payment method? 16:17:01 adrianhb: My assumption is that users want to know about the surcharge up front 16:17:03 maheshk has joined #wpwg 16:17:49 MattS: In my case, we are talking about a (native) payment app 16:17:56 q? 16:18:05 ack ian 16:18:07 q+ 16:18:33 Ian: I've begun to think about this, had a good conversation about Rouslan and Jason about it. Do we want to dive into this? 16:18:48 Ian: Or I could go off and look at framing. 16:18:57 ==== 16:18:58 * What data should the merchant provide? For instance, should the merchant and customer somehow reach agreement 16:18:58 on the currency BEFORE the API is invoked, so that only the “final data” is sent to the API? Or should there be all the 16:18:58 data necessary to display different prices and currencies? 16:19:07 Assuming “all the data” is given to the API, how should we do that? Today the API supports a single (global) CurrencyAmount. 16:19:08 But since we have payment method specific data, we could change the API to support an additional CurrencyAmount per 16:19:08 payment method. The per-payment-method data would override the global data. 16:19:14 * Furthermore, there may be more than one CurrencyAmount per payment method (“you can pay me this much in USD and 16:19:14 this much in Euros”). Therefore, we might want to change both the global and “local” CurrencyAmount to “CurrencyAmount list”. 16:19:20 * The next question that arises is: how are the different CurrencyAmounts displayed to the user? Presumably the user would want 16:19:20 to know, for each payment method, the available CurrencyAmounts. This is a UI challenge for browser vendors and we need to 16:19:20 chat with them about it. 16:19:26 * When I choose a particular CurrencyAmount, I want to see an updated “Total”. This means that the API would need to support 16:19:26 updates to the PaymentDetails based on the selected payment instrument’s CurrencyAmount. 16:20:17 Ian: This is a mix of thinking about it and design ideas. It sounds like we have a need for per-payment methods for pricing methods - today there is one global currency amount. One way to manage this is to keep a global currency amount - maybe we could add a local currency amount that overrides the global one. 16:20:38 Ian: Adrian Bateman has pointed out that this would make the data different - private data today, could be public. 16:21:24 q+ 16:21:27 Ian: X GBP, Y BTC - if we wanted to do that both globally and locally - if we have a list of pairs both globally and locally - that might go a long way, a number of implications - display gets harder - hearing whether it's tractable to do that - whether User should know about implications on price. 16:22:17 Ian: Need to display info - with payment instrument available to me - when I choose it, user shouldn't get surprised by price change. Update possibility for shipping address. Adrian Bateman has mentioned it, Matt has mentioned it - key topics - rudimentary proposals, how to deal with display - need to be discussed. 16:22:21 q+ 16:23:11 present+ Kepeng 16:23:22 ack manu 16:23:22 manu, you wanted to ask if we could hear from people opposed to supporting varying amounts depending on payment method? 16:23:24 present+ JasonYang 16:23:45 Manu: Anyone opposed to supporting the use case of per-payment-method pricing? 16:24:13 Might not going to support this in v1 implementation 16:24:53 AdrianHB: There have been some near proposals but not formal enough to make a yes/no decision yet. 16:25:04 ack rouslan 16:25:08 yes 16:25:20 ...Rouslan had a good way of thinking about this 16:25:31 rouslan: Per method pricing is an important topic. We need to handle it. 16:25:37 ..I'm ok if it's only in v2 16:26:05 ..I think AdrianBateman had a concern that if we specify pricing in payment method data we need to define it more than currenly. But I believe that we can make the "local data" a sibling 16:26:19 +1 for sibling 16:26:21 ...Ian mentioned that we might need a way for the site to update the total. That's something to consider 16:26:47 + for making local data a sibling to payment app data 16:26:48 ...what I mentioned on GitHub yesterday was a way to think about payment app registration and how they specify different ways to invoke the app 16:26:59 q- 16:27:00 ..that's a separate topic (for the payment app task force) 16:27:15 +1 to sibling 16:27:27 ..I have been thinking about how to do this on Android and would like to make it similar for Web 16:27:41 ...I will publish info related to Android that should allow (platform-specific) integration 16:27:43 q? 16:28:09 adrianhb: In Rouslan's post, there was something that interested me as a different approach from what we've discussed so far. 16:28:48 ...users choose a payment app when there's a payment method match 16:28:59 ...Rouslan's idea is interesting and solves another problem that's not yet been articulated. 16:29:13 ..namely, there are benefits or side effects of picking a payment INSTRUMENT within a payment app 16:29:24 ...suppose I choose an app that has a bitcoin balance and a visa card. 16:29:30 ...I might choose one or the other based on price 16:29:39 ..but Visa offers me "buyer protection" 16:29:59 ...as a User I need to know which payment instruments are available 16:30:05 ShaneM has joined #wpwg 16:30:15 ...rouslan's proposal gives us the benefits of choosing a payment app (merchant doesn't know what you have installed) 16:30:25 +1 for the merchant not having to know, capture it all in the payment request message 16:30:25 ...but the user experience is closer to Adrian Bateman's demo 16:30:31 ....where options look like payment instruments 16:30:42 ...how they look and how they are invoked is determined by the payment app 16:30:55 ...so the payment app still manages the flow, but the entry point can be instrument specific 16:31:05 ...that would resolve the "display issue" 16:31:15 q? 16:31:55 zkoch: I have come around to the use case of per method prices 16:32:06 ...it's less of a use case, but I'm convinced it's a real use case that we need to support. 16:32:14 ...I still want the majority use case to be easy to support 16:32:29 q+ to agree w/ zach - note that he thinks it's a real, minority use case - but if we don't do in v1, we might paint ourselves into a corner for v2. 16:32:30 ...I am also in the camp that this might be for v2 16:32:32 ack zkoch 16:33:10 adrianhb: I am on the fence re: v1 or v2...but I think that if we see a proposal that is not wildly diverging from what we have right now, I would say it's worth doing 16:33:20 I'm interested in seeing proposals - I also think we should consider outlining how to do it but accept that initial implementations might not actually support it 16:33:24 manu: I think this is a real use case; even if minority. 16:33:30 I'm concerned that adding it later might be difficult to feature detect 16:33:32 (IJ is interested in writing the proposal with Rouslan) 16:33:54 However, we ought to have a defined escape for implementations that don't do it 16:33:55 I don't agree that it's a minority use case - maybe in the US 16:34:01 manu: I'd be ok if we put a proposal forward and said "yes, that's the way we WOULD do it" but not do in v1 16:34:08 q? 16:34:10 ack manu 16:34:10 manu, you wanted to agree w/ zach - note that he thinks it's a real, minority use case - but if we don't do in v1, we might paint ourselves into a corner for v2. 16:34:12 That sounds reasonable to me 16:34:22 interested in seeing a proposal, not sure about *how* we should do it (lots of trade offs to consider), agree it's an important use case 16:34:33 Ian: +1 16:34:39 ACTION: Ian to work with Rouslan on a proposal 16:34:40 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., ijacobs, ijmad). 16:35:13 I have made the request to generate http://www.w3.org/2016/06/02-wpwg-minutes.html Ian 16:35:57 topic: Grouping semantics 16:36:12 adrianhb; I think that grouping semantics may also bear upon pricing 16:36:22 ...as in "cards cost this much, but this card costs this much more" 16:36:27 https://github.com/w3c/webpayments-method-identifiers/issues/1 16:36:37 q+ 16:36:39 q- 16:36:48 adrianhb; Let me summarize a chat I had with MattS and Ian on grouping/subclassing 16:37:19 https://github.com/w3c/webpayments/wiki/PMI_Notes#matching 16:37:34 AdrianHB: Overview of the topic 16:38:30 ...one idea is to start to look at "payment method identifiers + constraints" 16:38:52 ..so for example to say "I support this particular sub-brand of cards only" or "I only support this version of bitcoin" 16:39:04 ...so you would identify a payment method BUT ONLY WITH THESE CONSTRAINTS. 16:39:17 ...we are still exploring the topic 16:39:30 (e.g., expressing constraints as opt-in/opt-out) 16:39:34 q+ 16:39:46 ack Ian 16:40:07 Ian: The high-level idea is to get the additional nuance that we may want, include some constraints - a few questions arise. 16:40:11 Ian: What does it mean to match? 16:40:39 Ian: If you have a merchant-side identifier, and a user-side identifier and constraints - how do you tell what's a match and the resulting constraints are. No proposal yet, just introducing the topic. 16:41:02 Ian: How do you write those constraints down? Different ways you can do it w/ a URL - with query parameters, accompany PMIs, some other questions... 16:41:29 Ian: When I want to express a number of constraints for the same payment method - accept all credit cards except this one - what's the easiest/most straightforward way to do that? 16:41:30 sounds like a DSL to me ... which, IMO, would be good as a helper library, but not necessarily baked into the API. 16:41:51 Ian: In this wiki - no one would want a complex constraint language - this is one of those topics that could end up being v2. 16:42:09 q? 16:42:11 q+ 16:42:14 A DSL would be useful but the underlying format must still support the features we need 16:42:24 +1 to that 16:42:26 Ian: We have clear documentation that these are real world use cases - people talking about exactly these sorts of things. We're having this discussion, hope to have a proposal to beat on by F2F meeting or sooner. Simple proposal - can't be complicated. 16:42:43 i'm saying we may be able to push the complexity to a helper library, but have it convert to a simple format that machines can do something useful with 16:43:01 (machines being mediators and apps) 16:43:05 q+ to ask about the actual use case and why the current proposed mechanism is onerous? 16:43:37 Ian: Let's not discuss this anymore - not a proposal yet, let's not dive into it. 16:43:38 q- 16:44:16 q+ to be opposed to the concept in v1. 16:44:38 matts: One reason I support this is that it addresses the issue we have of getting card scheme producers more involved 16:45:08 ...the proposal of "cards" + constraints to describe scheme allows us to make progress on identifiers for v1 16:45:35 ack mtt 16:45:39 manu: I agree with MattS that it would be good to get the card vendors more involved 16:45:39 ack matt 16:45:39 ack matt 16:45:45 ack manu 16:45:45 manu, you wanted to be opposed to the concept in v1. 16:45:54 ...will people not use the API if we don't have this? I don't see it as such 16:46:05 ...we have proposed a way around this (via a library) 16:46:15 ...and we can experimenet 16:46:22 (IJ: The library does not address the problem) 16:46:34 (...because there is no relationship (e.g., subclassing) among PMIs) 16:46:48 manu: I don't think we have the data we need to come up with a solution for v1. 16:46:49 q? 16:46:50 q? 16:46:56 I have made the request to generate http://www.w3.org/2016/06/02-wpwg-minutes.html Ian 16:47:20 Topic: Issue 157 16:47:25 Browser API Issue #157 Should the payment mediator pass all payment method data to the payment app or just relevant data? 16:48:03 adrianhb: Question raised - what is the information that payment apps need to do their job? 16:48:03 ...one answer is "send info as-is to the payment app" 16:48:03 ...some believe that's the right thing to do; others do not (e.g., privacy issues) 16:48:15 ...so another way to do this is for the mediator to send the data that the payment app can do something with 16:48:29 ...one motivation for that choice is for the payment app should not farm information from merchants 16:48:41 q+ 16:49:07 rouslan: I think payment apps should be able to distinguish themselves based on privacy support 16:49:13 ..they should be able to say what information they require 16:49:50 ...I think the user agent should be able to invoke the payment app with the information that the payment app requires 16:50:19 ack rous 16:50:29 ...I think this should be discussed more in the payment app task force 16:50:35 q+ to say "all payment method data is passed" - I'd rather not have to define complex logic in the browser/http API that says what should and shouldn't be forwarded on. If we want there to be a distinction between public vs. private data, we should pass it in two objects. 16:50:46 -1 to passing all the data to the payment app 16:50:59 ack manu 16:50:59 manu, you wanted to say "all payment method data is passed" - I'd rather not have to define complex logic in the browser/http API that says what should and shouldn't be forwarded 16:51:02 ... on. If we want there to be a distinction between public vs. private data, we should pass it in two objects. 16:51:07 q+ to offer another argument 16:51:25 ...among other reasons, it makes it easier to write payment apps, saves bandwidth, improves privacy 16:51:25 q+ 16:51:38 q+ 16:51:39 manu: If we are going to say "we are not going to pass data, we are going to pass subset" we need to define that in the spec. 16:51:41 q+ 16:51:42 ...I am hearing complex decision algorithms. 16:52:03 wouldn't the algo to pick the set of data be the same as the one used for matching? 16:52:16 ...one easy way of doing this is to say "here's data that goes to the payment app" and that's object 1 and "here's data that does not go to the app" and that's object 2 16:52:32 q+ 16:52:47 q- 16:53:03 -1 to passing all the shopping cart data to the payment app. Merchants and platform providers usually don't want this information shared. 16:53:09 oh, I didn't understand the question as that. 16:53:15 +1 to Manu's discussion 16:53:50 dlongley: I don't know how much I buy the privacy argument; it's the method that's chosen by the merchant... 16:53:57 ...I don't think the mediator knows all the info the app might use 16:54:16 ...e.g., user might not have balance to pay...the apps should be able to free to innovate and do what they want. 16:54:59 ...apps could provide the best experience 16:55:12 q? 16:55:19 ack dlongley 16:55:19 dlongley, you wanted to offer another argument 16:55:20 q? 16:55:29 Bad audio 16:55:34 Can’t make out any words 16:55:47 ack me 16:56:17 ack zkoch 16:56:23 IJ: Rationale - save bandwidth...also save payment apps from having to do more work 16:56:27 to be clear +1 for sending all the core payment request data -- that doesn't mean sending the shopping cart data to the app. 16:56:34 zkoch: I think I favor not sending all data to the payment app 16:56:38 ...first it seems unnecessary 16:57:05 ...we should limit info to the set the app needs to return a payment credential 16:57:06 ...I don't think this would be complex; should be simply choosing set of data we think is important 16:57:06 zkoch: I haven't thought about this too deeply - we don't need to pass all data to the payment app - it seems unnecessary, user has chosen something specific. I acknowledge the notion of complexity - this is simple - just pick set of data that's important. 16:57:12 ...there's a user experience argument as well 16:57:27 q+ to say there's potentially more complexity in changing the data model or pinning representations down to WebIDL and so forth. 16:57:40 ...the payment app might want to say "We also support X, Y, Z" and prompt users to install new methods; but that's not a good user experience 16:57:46 zakim, close the queue 16:57:46 ok, AdrianHB, the speaker queue is closed 16:57:56 zkoch: There is a User Experience argument - this is a strength that a payment app has - more control - still working this out in my head. I'd like to give payment app limited data to process the transaction. This isn't so much about giving payment apps the ability to upsell you. 16:57:58 ..this is about processing transactions and NOT giving payment apps the upsale role 16:58:16 q? 16:58:18 I have made the request to generate http://www.w3.org/2016/06/02-wpwg-minutes.html Ian 16:58:29 ack adamr 16:58:38 adamr: I agree broadly with Zach's point. First I don't think it will be complicated to implement by the mediator 16:58:41 q+ to clarify 16:58:53 ...I think we need to do privacy improving things in v1 16:58:56 To be clear - I misunderstood what AdrianHB was asking. 16:59:06 I agree w/ what Zach and Adam said... 16:59:14 dlongley: By effectively putting our fingers more into the data, we need to standardize more about the data 16:59:22 ...all of those things put constraints on extensibility 16:59:24 I thought we were talking about picking and choosing data out of the payment method data itself. 16:59:35 I have made the request to generate http://www.w3.org/2016/06/02-wpwg-minutes.html Ian 16:59:39 so, for visa - pick and choose data out of the visa payment method data... that's what I was opposed to. 17:00:00 jnormore has joined #wpwg 17:00:05 manu: +1. I think we're thinking about the same idea. 17:00:09 adrianhb: I am hearing stronger support for "just send data for supported methods" but not ready yet to resolve 17:00:21 adrianhb: I would like to close that issue soon; please put comments in the wiki 17:00:29 Topic: Next meeting 17:00:37 9 June 17:00:40 I have made the request to generate http://www.w3.org/2016/06/02-wpwg-minutes.html Ian 17:00:44 digitally signing payment requests ... could be a problem if you break them up. 17:00:49 adds complexity there too, potentially. 17:00:53 (or more signatures per method) so on. 17:01:48 AdrianHB: I seem to have misplaced the bridge for the apps spec discussion 17:48:02 Adam__ has joined #wpwg 18:23:21 ShaneM has joined #wpwg 19:06:03 Zakim has left #wpwg