15:51:21 RRSAgent has joined #wpwg 15:51:21 logging to http://www.w3.org/2016/06/16-wpwg-irc 15:51:23 RRSAgent, make logs public 15:51:23 Zakim has joined #wpwg 15:51:25 Zakim, this will be 15:51:25 I don't understand 'this will be', trackbot 15:51:26 Meeting: Web Payments Working Group Teleconference 15:51:26 Date: 16 June 2016 15:51:57 agenda: https://github.com/w3c/webpayments/wiki/Agenda-20160616 15:57:57 rouslan has joined #wpwg 15:58:07 Present+ Rouslan 15:58:46 present+ Ian 15:59:24 regrets: AdrianHB 15:59:30 present+ Dongwo 15:59:35 present- Dongwo 15:59:37 present+ Dongwoo 15:59:42 present+ DavidE 15:59:47 Present+ Manu 15:59:55 present+ Roy 16:00:02 present+ dlongley 16:00:03 zkoch has joined #wpwg 16:00:05 present+ Dongwoo 16:00:08 present+ BrianS 16:00:16 present+ dezell 16:00:23 present+ dlehn 16:01:19 present+ zkoch 16:01:33 maheshk has joined #wpwg 16:01:43 marta has joined #wpwg 16:01:46 Reminder about registration for FTF meeting -> https://www.w3.org/2002/09/wbs/83744/wpwgftf-201607/ 16:02:08 nicktr has joined #wpwg 16:02:18 scribe: Ian 16:02:19 BrianS has joined #WPWG 16:02:19 Present+ Marta 16:02:31 present+ mahesh 16:02:59 MattS has joined #wpwg 16:03:04 present+ Cyril 16:03:34 CyrilV has joined #wpwg 16:03:53 present+ nicktr 16:03:54 +present Cyril Vignet 16:03:54 -> https://github.com/w3c/webpayments/wiki/Agenda-20160616 16:04:04 present+ Cyril Vignet 16:04:22 Chair: NickTR 16:04:35 Topic: Face to Face - 7 & 8 July - London 16:04:55 draft agenda -> https://github.com/w3c/webpayments/wiki/Web-Payments-Working-Group-FTF-Meeting-%28July-2016%29#draft-agenda 16:05:36 q? 16:05:55 q+ 16:06:02 q- 16:06:07 https://www.w3.org/2002/09/wbs/83744/wpwgftf-201607/ 16:06:55 I note that another member of my team will attend (Conor Hackett) 16:07:12 q= 16:07:14 IJ: thanks Brian for seamless organization! 16:07:16 q+ 16:07:20 ack ni 16:07:32 nicktr: Do we have capacity limit? 16:07:44 BrianS: I checked that today with Ian...it's about 45 16:07:47 q+ 16:08:16 Ian: anyone that wants to invite people - check with me, please. 16:08:26 IJ: Please check with me for invitations as I'm coordinating attendance 16:08:37 ack C 16:09:10 CyrilV: I will send someone your way Ian. 16:09:12 Ian: +1 16:09:29 Cyril: I will put you in touch with them 16:09:31 Ian: Thanks! 16:09:40 q? 16:09:44 rrsagent, make minutes 16:09:44 I have made the request to generate http://www.w3.org/2016/06/16-wpwg-minutes.html Ian 16:10:00 Topic: Issues 16:10:18 nicktr: Adrian(s) have been working to triage the issues list notably around payment request API 16:10:21 Laurent has joined #wpwg 16:10:48 q+ to note that we're closing issues w/o having resolutions by the group or noting what the decision was. 16:11:02 ack manu 16:11:02 manu, you wanted to note that we're closing issues w/o having resolutions by the group or noting what the decision was. 16:11:17 Manu: I am noting that we are starting to close issues without saying why (e.g., resolution, or how we are addressing) 16:11:25 ...other issues were closed by saying "we plan to address the issue" 16:11:30 ...I think those are fairly bad ways to work 16:11:33 +1 to manu 16:11:55 ...if the group decides to address the issue, we expect to see a pull request on a spec...before closing it. 16:12:05 ...my concern is that we are not following a very good process at this moment. 16:12:16 q+ 16:12:44 Nicktr: From a process perspective, I think we should be more explicit about why. 16:13:13 present+ ShaneM 16:13:13 MattS_ has joined #wpwg 16:13:38 +1 for issues to only be closed when there is a clear resolution that is noted in the issue 16:14:07 q? 16:14:11 ack Ian 16:14:15 +1 to clear statements of rationale and pointers (which I endeavored to provide where I was aware of them) 16:14:28 +1 to clear statements of rationale and pointers 16:14:37 nicktr: I am hearing an action for chairs and staff contacts to review some issues and document rationale for closing 16:14:39 +1 to getting consensus from the group 16:14:42 Q? 16:15:13 We should also ping the initial person that submitted the issue to see if they understand the rational for why the issue is being closed (they're okay with it) 16:15:18 (just for the record) 16:15:38 IJ: I think that a minimum is to document rationale; I don't know that I would require official WG consensus as a prerequisite for closure. 16:15:48 Topic: PaymentRequest API issues 16:15:54 issue 215 16:15:59 https://github.com/w3c/browser-payment-api/issues/215 16:17:13 (Quick review of the issue) 16:17:17 IJ: There are three options on the table: 16:17:18 Leave the spec as is; or 16:17:18 Remove totalAmount from PaymentResponse; or 16:17:18 Leave totalAmount but remove the text that requires that the value be one of the provided totals. 16:17:26 IJ: IJ and AHB support option 3 16:17:34 q+ 16:17:36 nicktr: Manu raised a question about tampering 16:17:47 ..that's a concern we also see on other architectures. 16:18:02 ack zk 16:18:04 ack zkoch 16:18:04 q+ to elaborate on the security concerns 16:18:29 zkoch: The tempering problem is independent of this issue. It's a larger issue to discuss. I think we should focus the discussion on whether total amount should be in the response. 16:18:36 ...I think we should remove total amount from the response. 16:18:44 ...I think we'd be better off without it. 16:18:49 ...and weird wrt authorizations 16:19:09 Manu: I agree in general that the problems are a bit orthogonal, but the issue comes down to "how useful is total amount". it's not useful if the merchant can't trust it. 16:19:36 ...in the payment request API we have said that we support data signing, but not at the top level. 16:19:44 (IJ thinks the payment response overall can be signed) 16:19:57 q+ to ask why the payment response cannot be signed. 16:20:00 ack manu 16:20:00 manu, you wanted to elaborate on the security concerns 16:20:11 Manu: So problem is MITM attack. 16:20:30 ack Ian 16:20:30 Ian, you wanted to ask why the payment response cannot be signed. 16:20:44 IJ: what in payment request API prevents the payment app from signing the payment response? 16:21:34 q+ 16:21:56 IJ: What in basic card, for instance, prevents signing? 16:21:56 ack MattS_ 16:22:18 q+ 16:22:20 MattS: My understanding of the spec is that it does not support signatures. 16:22:35 ...for interop you would need to specify how signatures work 16:22:49 BrianS: Isn't there a separate issue about this: should there be a defined way of signing data? 16:23:00 q+ 16:23:01 MattS: There is, but right now the view is payment-method specific approach. 16:23:03 ack br 16:23:12 MattS: You could need a "card signed" payment method 16:23:13 q+ 16:23:20 q+ to note that we're talking about PaymentResponse 16:23:23 q+ 16:23:43 q+ to talk about HTTP approaches such as https://tools.ietf.org/html/draft-cavage-http-signatures-03 16:23:49 ack rouslan 16:23:54 q+ to note that there is misinterpretation going on here. 16:23:58 rouslan: I think Matt's interpretation is correct - does not support signatures 16:24:02 there are multiple layers here -- any layer you want to be able to trust will need a signature (or some other mechanism) 16:24:06 ..I'm open to pull requests on signing basic card responses 16:24:40 q? 16:24:42 We’ve drifted far from the initial topic... 16:24:42 ack manu 16:24:42 manu, you wanted to note that we're talking about PaymentResponse and to note that there is misinterpretation going on here. 16:24:51 https://w3c.github.io/browser-payment-api/#dom-paymentresponse 16:25:02 Manu: I think we are talking about payment response and "Total" in payment response. 16:25:12 ..there is no mechanism for signing a payment response as it stands 16:25:45 ...my understanding right now is that if you want to do payment method specific signing, it goes in the "Details"...and anything not in the details is susceptible to attack. 16:25:50 Nothing prevents signing those data too in the details right? 16:26:02 ...so Matt is correct - you can write a payment method to sign the DETAILS 16:26:07 q+ 16:26:09 q- 16:26:21 Manu: our concern is tampering with other data that is not in details 16:26:23 Laurent: Yes, but it goes in detail, merchants should not trust the other data (or should understand its level of trustworthiness) 16:26:35 q+ 16:26:40 q+ to note that this is why the community group specs were structured the way they were. 16:26:43 MattS_: I agree what MattS is saying...you could also hack a payment method to sign the non-details 16:26:46 ack matt 16:27:05 ack zkoch 16:27:13 zkoch: I think we have drifted far from the issue at hand. 16:27:25 ..for the current issue, I suggest we remove payment total from the response. 16:27:37 ..we can raise a separate issue on signing non-details of payment response 16:27:41 +1 16:27:47 PROPOSED: Remove TOTAL from payment response 16:27:51 +1 16:27:52 +1 16:27:54 +1 16:27:54 +1 16:27:55 +1 16:27:56 +1 16:28:03 +1 16:28:07 +1 16:28:09 q+ to PROPOSE remove everything else because it can't be trusted :P 16:28:10 +1 16:28:12 I absolutely agree with ian +1 16:28:18 I also want to talk about signing paymentResponse though (in a separate issue) 16:28:23 SO RESOLVED: to remove Total 16:28:49 Manu: Are we removing the Total because it cannot be trusted, then the same goes for other parts of the payment response. 16:29:07 ..I would have supported keeping it in there if we were able to sign the entirety of the response. 16:29:55 q+ to note that amount requested/charged are different being basis for removal. 16:29:56 zkoch: My desire to remove it has existed long before the signatures. I am not sure it's entirely relevant for a lot of situations (e.g., hotel authorizations where the amount of the registration is different from what is ultimately charted...or in credit card payments)...so I think the field itself is not valuable 16:30:36 ..I think we can remove it without thinking about the digital signature problem. 16:30:38 Manu: Ok 16:30:46 ack manu 16:30:46 manu, you wanted to note that this is why the community group specs were structured the way they were. and to PROPOSE remove everything else because it can't be trusted :P and to 16:30:47 ..sounds reasonable to me to remove for that reason 16:30:50 ... note that amount requested/charged are different being basis for removal. 16:31:11 nicktr: So believe this means it's incumbent on the merchant to validate data 16:31:24 Topic: Issue 3 16:31:25 Should it be possible to provide amounts in more than one currency #3 16:31:29 https://github.com/w3c/browser-payment-api/issues/3 16:31:49 q+ to start 16:31:53 ack zk 16:31:53 zkoch, you wanted to start 16:32:34 zkoch: To check - this is the question about multiple currency in request, right? 16:32:37 IJ: That is my understanding. 16:32:54 zkoch: Last week we agreed to support multiple prices per payment, and we proposed not to handle multi-currency 16:33:05 PROPOSED: Do not support multiple currencies per total 16:33:14 zkoch: Reasons include (1) adds a lot of complexity 16:33:16 q+ 16:33:46 (2) I view this largely as a dark pattern...I think that oftentimes there are things that are not transparent that can happen 16:34:06 (3) the merchant can do this anyway 16:34:19 would bitcoin be viewed as a different currency or a different payment method in this case? 16:34:21 q+ 16:34:21 (4) does not seem common case for v1 16:35:38 multiple totals (price/currency pairs) per payment instrument 16:35:39 Ian: After discussions w/ Rouslan and Shopify, I concluded that we don't need to support specifically multiple totals - price/currency pairs per payment instrument. 16:36:03 Ian: per payment instrument pricing - to answer Marta's question on IRC, this means merchant can say it costs $100 or 3 Satoshi. 16:36:07 ack Ian 16:36:46 https://github.com/w3c/webpayments/wiki/Support-for-multi-price-and-currency 16:36:47 Ian: One piece of the answer to why it's not necessary is that we solved some use cases per payment method pricing, the second is that Shopify did a nice job of writing up all of the ways that multiple currencies are handled in nature. 16:37:35 Ian: The conclusion was, payment request supports standard and multi-currency processing approaches... happening on merchant side. We get a lot already both in terms of multi-currency and in terms of multi-pricing, we wanted to leave multi-currency out of v1. 16:37:45 PROPOSED: Leave multi-total per payment method out of v1 16:37:49 q+ to request that we design it anyway and make sure we don't paint ourselves into a corner. 16:38:23 Ian: One of the ways that Rouslan wanted was a totals proposal - price currency pairs, would be a new feature that browsers would implement. 16:38:54 ack MattS_ 16:39:05 IJ: Rouslan came up with a way to do multi-totals per payment instrument in the future; so we do not box ourselves into a corner 16:39:19 Yes, spec is up to date 16:40:02 MattS: We are closing the use case of a payment method that supports multiple currencies 16:40:11 ---> https://github.com/w3c/webpayments/wiki/Support-for-multi-price-and-currency 16:40:44 IJ: We are not preventing the ecosystem from doing currency conversions...just not supporting it explicitly in the API 16:40:49 might be unpleasant user experience if you see the price in currency X in the browser UI ... and then pay with something else entirely in the payment app 16:41:31 q+ to -1 that approach requested currency and response currency should be the same? 16:41:47 "It is not clear to me that we have any control over anything through the api." My new favorite phrase. 16:41:47 NickTR: Yes, so this is like previous case of needing to check 16:41:48 q+ 16:42:18 ack manu 16:42:18 manu, you wanted to request that we design it anyway and make sure we don't paint ourselves into a corner. and to -1 that approach requested currency and response currency should 16:42:21 ... be the same? 16:42:34 q- 16:42:34 Manu: We are doing handwaving on how this works in the future. One way affects the API deeply, the other doesn't. 16:42:37 q+ 16:42:47 manu: I don't understand the case that Ian sketched 16:42:54 q+ to clarify v2 totals 16:44:02 q+ 16:44:08 ack Ian 16:44:08 ack rouslan 16:44:09 rouslan, you wanted to clarify v2 totals 16:44:16 q? 16:44:24 IJ: To say a bit more about Rouslan's proposal - was to provide a list of totals rather than a single total 16:44:33 q+ to note that this is how nasty cruft builds up in APIs. 16:44:39 I think the better method is to rely on feature detection 16:44:43 q+ to provide an alternate 16:44:43 Rouslan: Yes, so totals would be optional (not required) and the two would be mutually exclusive. And totals would be a list of totals. 16:44:46 I think there are multiple ways to support this in future 16:44:47 q- 16:44:54 IJ: So we are not boxing ourselves into a corner in terms of existing implementations 16:44:58 we could allow total to be a sequence 16:45:15 and we can feature detect the difference 16:45:17 q+ 16:45:18 Manu: That was not my concern. My concern is that we are creating a hack field. Could avoid it if we were to just make it a sequence not. 16:45:25 we will always have to feature detect new additions 16:45:30 Manu: Easy way is to make it a sequence today 16:45:39 ack manu 16:45:39 manu, you wanted to note that this is how nasty cruft builds up in APIs. and to provide an alternate 16:45:47 So would the spec say "Sequence but only one used today"? 16:45:49 Well, what Adrian is saying is that we can make it a sequence later and then it’s easy to feature detect for V2 16:45:58 q? 16:45:58 +1 to making it a sequence now. and yes, Ian 16:45:59 Ian, yes, it would. 16:46:05 there are already sequences in the API that cause developer confusion - i'd prefer not to add more that we won't even be supporting 16:46:34 Rouslan: I think putting in v1 a list that is required to have one element is more confusing than having 2 fields that are mutually exclusive. 16:46:45 I agree that it's more complex... but we either eat the complexity up front, or later down the road. 16:46:56 q+ 16:47:00 ack rous 16:47:04 ack adrianba 16:47:18 Ian: It sounds like we could make it a sequence w/o a big issue? 16:47:41 adrianba: We spent some time at MS thinking about how we might want to add this in the future. We came up with a number of different options. One is the proposal that's been discussed - allow the amount to be a sequence of totals with different currencies. 16:48:03 ...developers will need to do feature detection against the API to see whether they are running in a browser that supports the newer version 16:48:21 ...implementations role out new features more granularly than specs, so it's a good practice to feature detect. 16:48:35 ..there are a few ways we might support detection for sequence. 16:48:44 ...we feel comfortable that we can add sequence later 16:48:54 ...there are other issues around support for multiple currency that are more challenging. 16:49:06 ...so I support punting multiple currency to after v1. 16:49:32 ...some changes we've made regarding sequences, I think we have seen some confusion about why we have sequences...so I would prefer not to add sequences now 16:50:00 I'm fine w/ punting as long as the group agrees to the rationale to punt and understands what we're paying down the road for punting. 16:50:05 Yes 16:50:24 IJ: I am hearing that having a single name that can be reused would not complicate future development (which was Manu's concern about confusion). 16:50:27 So, we're agreeing to punt because we think the complexity added down the road isn't going to be a burden for developers. 16:50:49 I personally disagree with that, but defer to the group (and clearly can't make the implementers implement something they don't want to) 16:51:48 q+ 16:51:49 That sounds close to: "It's too complex and we'd probably never do it?" 16:51:54 IJ: I hear that there are multiple reasons for not doing it now (e.g., can be done via payment apps) and that fortunately we will not prevent future implementations from evolving to handle lists if we want to go there. 16:52:05 ack Mat 16:52:16 MattS: I know there's not much time left, but I have a question for the group. 16:52:23 ..we seem to be punting a lot down the road 16:52:30 ..I am uncomfortable with the amount we are punting 16:52:46 ...we are trying to create an open API but we only have one example of a payment method spec. 16:52:55 q? 16:52:57 q+ to support additional payment method specs 16:52:57 q+ 16:53:00 q+ to say yes-ish 16:53:13 +1 16:53:15 Ian: No particular view on punting - there are a lot of factors that play into decision on where to draw the line. 16:53:17 q+ to add if time 16:53:50 Ian: I've been wanting to have more payment method specs to road test the API - been talking w/ Alipay folks about payment apps... there is a proposal to do a Bitcoin one. 16:53:53 ack Ian 16:53:53 Ian, you wanted to support additional payment method specs 16:54:01 Ian: I know Adrian had already talked about Ripple payment method spec. 16:54:24 Ian: That may lead us to general conclusions about payment request API. 16:54:45 Ian: We have to tie up the payment request API and turn our attention to payment methods and payment apps - as part of road testing API. 16:54:54 Ian: This is more about prioritization than punting. 16:55:09 ack rouslan 16:55:14 i also feel concerned that we may be trying to rush a little bit too much so we have "something" vs. making sure all the things we want to support really work well with the API in general 16:55:37 Rouslan: Agree with Ian; need to design in waves; get basic thing in hands of developers and then get data based on experience. I do not think we are punting too much. 16:55:55 Manu: Thanks, Matt for the question. We are punting on a lot, and I agree we should do so and iterate rapidly. 16:56:01 ..the group has only so much bandwidth. 16:56:24 ...but for some things we are punting, I don't know that the group is clear on the reason we are punting...e.g., "that's a hard problem and we don't want to think about it now because we have other pressing issues." 16:56:55 +1 for avoiding designing into corners, don't have to do full designs and implementations but we should spend time thinking about things we want to do in v2 ... making sure we at least think we can do them. 16:57:01 q+ 16:57:03 ack zkoch 16:57:03 zkoch, you wanted to add if time 16:57:05 ack manu 16:57:05 manu, you wanted to say yes-ish 16:57:18 zkoch: I agree with most of what's been said. Product design is tough and hard to draw the line on occasion. 16:57:31 ...I think getting something out there to test is the best approach right now 16:57:38 +1 to zkoch 16:57:44 ...if we can get out there and demonstrate value, it will be easier to solve issues with momentum 16:58:09 zkoch: I do not anticipate all the different payment systems out there to write formal specs that the WG publishes; I expect more common will be developer documentation 16:58:36 zkoch: I am also excited about the current work on the payment app spec...we support it at Google...need to cover other regions of the world (e.g., where cards not widely supported) 16:58:41 ...so I feel good with where we are at. 16:59:03 ...also, Adrian B has been very conscious about designing such that we can add features in the future (and not box ourselves in) and feature detect them 16:59:04 ack matt 16:59:39 MattS: I feel "a little" more comfortable. But I'd like to make a proposal ... I am concerned that we are not capturing adequately the items we are punting. 16:59:39 +1 backlog 16:59:43 ...we need a clear backlog 16:59:43 +1 to keep track of punted items / backlog 16:59:44 +1 16:59:50 q+ 16:59:54 +1 sure - how about a v2 tag? 16:59:56 ack me 17:00:07 I think that's what the "Priority: Postponed" topic on the agenda was supposed to cover 17:00:08 IJ: AHB is using GitHub tags to mark things as postponed. 17:00:10 Ian: I know AdrianHB is using Github tags as postponed 17:00:50 Ian: The question is whether that is being done rigorously - Matt, you and I had discussed this issue previously - clearer vocabulary of postponed items - in theory we're trying to do that - good to keep chairs and team contact honest on whether or not we're doing well. 17:00:52 MattS: I have seen some things closed as not being in V1 17:00:55 IJ: Yes, that seems to be a bug 17:01:05 MattS: More formality would make me more comfortable. 17:01:29 PROPOSED: DO not add further support for multiple totals per payment instrument 17:02:07 rrsagent, make minutes 17:02:07 I have made the request to generate http://www.w3.org/2016/06/16-wpwg-minutes.html adrianba 17:02:08 PROPOSED: DO not add further support for multiple totals per payment method 17:02:21 +1 17:02:29 +1, defer to V2 17:02:36 -0.5 - I'm concerned that we have not considered the negative rammifications of this decision enough. 17:02:39 +1 17:02:45 +1 17:02:50 +1 17:03:00 +-0 17:03:05 Manu: I am not standing in the way of a decision 17:03:16 SO RESOLVED: DO not add further support for multiple totals per payment method 17:03:39 Topic: Next meeting 17:03:42 23 Jun 17:03:53 nicktr: We will take up PMI grouping/subclassing proposal at next week's call 17:03:57 rrsagent, make minutes 17:03:57 I have made the request to generate http://www.w3.org/2016/06/16-wpwg-minutes.html Ian 17:04:24 rrsagent, set logs public 17:09:22 Laurent has left #wpwg 18:25:09 Adam_ has joined #wpwg 18:44:10 Adam_ has joined #wpwg 19:05:18 Adam__ has joined #wpwg 19:09:56 Zakim has left #wpwg 19:24:01 adamlake has joined #wpwg 19:42:58 Adam_ has joined #wpwg 23:13:38 adamR has joined #wpwg