17:00:54 RRSAgent has joined #wpwg 17:00:54 logging to http://www.w3.org/2016/06/09-wpwg-irc 17:04:10 rrsagent, make logs public 17:04:18 rrsagent, draft minutes 17:04:18 I have made the request to generate http://www.w3.org/2016/06/09-wpwg-minutes.html manu 17:04:35 rrsagent, make logs public 17:04:38 rrsagent, draft minutes 17:04:38 I have made the request to generate http://www.w3.org/2016/06/09-wpwg-minutes.html manu 17:33:00 nicktr has joined #wpwg 18:06:01 hober has joined #wpwg 18:14:17 Adam__ has joined #wpwg 19:17:00 Agenda: https://github.com/w3c/webpayments/wiki/Agenda-20160609 19:17:08 scribe: manu 19:17:15 Topic: Draft Agenda for Face-to-Face 19:17:19 https://github.com/w3c/webpayments/wiki/Web-Payments-Working-Group-FTF-Meeting-%28July-2016%29#agenda 19:17:25 rrsagent, draft minutes 19:17:25 I have made the request to generate http://www.w3.org/2016/06/09-wpwg-minutes.html manu 19:18:43 Meeting: Web Payments Working Group 19:18:59 Chair: NickTR, AdrianHB 19:19:27 nicktr: Happy to take any suggestions to that agenda 19:19:38 nicktr: Day 1 is security review and payment apps spec 19:19:42 nicktr: We'll try to pickup new payment methods spec during later part of day 1 19:19:46 nicktr: A number of our european colleagues are excited about the SEPA payment method spec. 19:19:50 matts: At the moment, we have a draft proposal - Ian has put it into ReSpec. I'm going to commit that to the new repos. The intent is we'll do a few revs of it during the meeting. Will present that at the face-to-face. 19:19:55 The spec is in the new repo: https://github.com/w3c/webpayments-methods-credit-transfer-direct-debit/blob/master/index.html 19:20:00 nicktr: Some feedback from members - they're not enthusiastic because we're not talking about stuff they're interested in... stuff like SEPA. For me, wearing my "engagement of wider group hat", I'm interested in doing that. 19:20:05 Some admin required on that repo to setup branches properly) 19:20:13 icktr: Second day - payment request API and basic cards spec - go into that a bit later today - look at HTTP API in the afternoon. Give ourselves a bit of a buffer at the end of the day. 19:20:17 nicktr: Feedback from anyone? 19:20:23 No comments on agenda - the group is either happy with the layout, or everyone is asleep. Those are the only possible states. 19:20:26 Topic: Multiple Pricing Options and Currencies in Payment Request 19:20:29 https://github.com/w3c/webpayments/wiki/Support-for-multi-price-and-currency 19:20:32 AdrianHB: AdrianB has also put in a pull request for that proposal. 19:20:39 Rouslan: Our proposal is what Shopify, Ian, and I have been talking about - not to be confused w/ AdrianB and Zach's proposal. 19:20:42 Rouslan: We want to support different line items for payment methods. Optionally, would provide total for particular payment method. Debit cards have a different total from credit cards - then we also were thinking about notifying the website when the user has expressed their preference to select a certain payment method. 19:20:48 Rouslan: At that time, we'd notify the website and the website could update the line item total - line items at this time would change - we've also decided in our group discussions to punt on multi-currency - our reasoning is that from the point of the website, if you are requesting GBP or Euro, you should be getting what you're requesting. If an app is not able to fulfill the request in GBP/Euro, it should reject the request. 19:20:54 Rouslan: Internally, ifi the app is dealing w/ bitcoin, the app can convert to the proper currency. Let's hear AdrianB's proposal as well. 19:20:58 AdrianHB: What Rouslan is saying is right, if we look at DCC today, it's specific to card payments. I think we shouldn't try to complicate the API with DCC - it's a feature of a payment method, so it's a payment method by implication. If you have a payment method that supports DCC, the payment method will define how that works. 19:21:13 dlongley: +1 to AdrianHB 19:21:22 Manu is in agreement w/ pushing DC off +1 to AdrianHB 19:21:26 adrianba: We had a few goals with this proposal - the first one was that while it is an important use case, we also think the majority case will not have that happen, in particular we want to avoid complicating the APIs in that common case while allowing the more complex case. If you don't care about different amounts for the payment method, you don't need to do anything differently. 19:21:30 https://github.com/w3c/browser-payment-api/pull/211 19:21:34 adrianba: Then we let people declare up front what the different totals would be for different payment methods. We've added that to payment details object. The first parameter lists the supported payment method and any specific payment method should be something that's constant through payment request, but you'd want to change total amount based on shipping amount, so this is an additive thing onto payment details. Payment methods use different total. 19:21:39 adrianba: It allows you to add on additional MISSED those additional things would allow you to have things appended - line item that says "this is a discount" or "this is a surcharge for debit/credit" and that would be added to display items. We wanted to avoid having event based on MISSED for the payment method, it's possible for UI to show ?? payment instead of having UI to present it. we propose that you display different totals in details. 19:21:46 ouslan: After reading through adrianba on his pull request - we should forego the event and use declarative methods. 19:21:50 Manu: +1 for using declarative methods. 19:21:59 dlongley: +1 for a declarative approach 19:22:04 AdrianHB: Question for clarity. 19:22:07 AdrianHB: There is a way for a merchant to add extra display items - where do those get inserted in the list? Is there a way to manage ordering of where those fit in? 19:22:14 zkoch: No, total is always specified 19:22:19 AdrianHB: The reason I ask - do we force user agent to calculate total or is the total always specified? 19:22:23 Zakim has left #wpwg 19:22:27 AdrianHB: Do we need to specify that amount and response was specified by merchant? 19:22:31 adrianba: You should expect that total amounts to appropriate one - this seems like a low-cost position for the avoidance of doubt. This is the payment method, this is the corresponding total that was selected, so we can be sure of what the user agreed to. 19:22:35 AdrianHB: I wonder if this is an unnecessary restriction, it assumes that payment methods can't calculate a total on the fly. I've already said DCC is a payment method specific thing, as a merchant I can get a response back that says I want to pay $60 CAD as a result back to the merchant if I say I accept CAD. 19:22:40 nicktr: As a merchant, if I specify an amount then I would be expecting to get that amount back in the response. 19:22:50 dlongley: payment method may even allow negotiation of some sort ... agree that we don't want to lock things down too much 19:22:55 AdrianHB: I don't think there is a need for us to put that in the API spec, I like the idea of having a field in the response - I don't think we need to say that something is going to correspond with the amounts in the request. 19:23:03 dlongley: +1 to AdrianHB 19:23:07 AdrianHB: I don't think we need the browser to enforce business rules. 19:23:26 If you can do declarative, it's better. Rule of Least Power: https://www.w3.org/2001/tag/doc/leastPower.html 19:23:44 s/If you can do declarative/dlongley: If you can do declarative/ 19:23:59 dlongley: If you can do declarative, it's better. Rule of Least Power: https://www.w3.org/2001/tag/doc/leastPower.html 19:24:15 AdrianHB: +1 to the PR with a change to remove a normative requirement for response total to be one of the request totals 19:24:23 zkoch: I think I’m fine removing total from the response 19:24:33 dlongley: We should be matching data to data, nothing more (hopefully) 19:25:35 manu: One of the things that has been bothering me lately is that we keep proposing these complex imperative solutions when a simple declarative one would provide more flexibility, would be easier to implement, and will thus hopefully create a better ecosystem for this stuff. +1 to declarative solutions, -1 to imperative solutions (in general). 19:25:42 nicktr: Yes, sounds good. 19:25:53 adrianhb: I think having the total there is fine just don't force it to be one of the request totals 19:25:58 rouslan: Do we have consensus on this? It appears that we do - Ian had a few minor nitpicks. I don't think we have objections, we want to hear from Shopify - one of the groups that were part of the imperative proposal. I think declarative proposal has traction. 19:26:07 adrianHB: In fact, I think having the total in the response is great 19:26:13 nicktr: I think what I'm hearing is let's not ask for consensus, but this PR is moving in the right direction. 19:26:19 adrianba: Ian... matching payment identifier... plan is to have pricing per payment method 19:26:22 adrianba: logic for payment method identifiers change, this will need to change too - orthogonal issue. I propose that we take the PR, whether to include total at all - provided total - my preference would be to take PR and open issue to discuss what we do about proposal - then it'll be locked down - PMI will be followed up by Ian. 19:26:25 nicktr: That's a concrete proposal from adrianba - accept the PR and then deal w/ that particular problem. 19:26:34 AdrianHB: +1 to merge and deal with response total via an issue 19:26:37 adrianba: Sounds like PR is in the right direction, minor details to iron out. 19:26:40 zkoch: +1 19:26:46 manu: +0 - haven't reviewed the PR in detail. 19:26:49 rouslan: +1 19:26:51 dlongley: +1 19:26:54 ShaneM: +1 19:27:42 Topic: PR 209 - abort if updateWith promise is rejected 19:27:46 https://github.com/w3c/browser-payment-api/pull/209 19:27:52 AdrianHB: AdamR, do you want to say something about proposed change? 19:28:30 i/Topic: PR 209/nicktr: adrianBA's proposal is accepted - accept PR 211/ 19:28:47 AdamR: Point I've raised in past coupel of calls - shutting down flow is something we have - but having something that says: We failed and here's the reason is important, but don't have counter proposal to current proposal. 19:28:54 dlongley: +1 to AdamR - same feelings. 19:28:59 AdrianHB: Unless there are any objections, we merge this - adam and dave's nuances - we raise them as new issues. 19:29:04 nicktr: Ok, we're pulling in PR209. 19:29:29 Topic: PR 210 - Remove special case handling for single shipping option 19:29:49 AdrianHB: Everyone seems to be happy w/ this - don't know if people have reviewed this - any objections? 19:29:56 adrianba: If the merchant was really using shipping option and using shipping address - we added special case support if you provide a single shipping option, then that one would be selected by default. Having no shipping options blocks the request, for example if you have an address that ... having a single option wouldn't require the user to select the single option, it allows you to create a payment request that flows simply through the experience. 19:30:07 adrianba: In order to make it possible to preserve a users option, if they have a different address, shipping, if you want to preserve that, we added selected field - this is one that's currently selected. 19:30:15 ShaneM: +1 to remove special magic 19:30:21 adrianba: select the defualt, included in the pricing for example - simply having that field, they can be explicit about what's being selected. We're proposing to remove the special magic from the spec. This way developers won't be surprised if single option was selected if they had a seelcted field that and users won't be surprised if developer makes a mistake, perhaps shipping option is expensive and you want user to be aware that they're selecting an expensive 19:30:32 ... option, that's the proposal - remove it. 19:30:44 rouslan: +1 remove the magic 19:30:51 dlongley: +1 19:30:54 zkoch: +1 19:30:58 AdrianHB: +1 19:31:07 AdrianHB: What this means is that we've implemented a fair amount of stuff into the API, there have been quite a few changes to the FPWD - browser vendors/group - how comfortable are we with publishing another WD of this spec soon? 19:31:15 AdrianHB: We know that Chrome already has some implementation of this API in its developer version w/o needing to polyfill - will that be updated soon? Implementations to follow? 19:31:23 adrianba: I was planning a new WD by next F2F meeting. I think I was proposing that we do that a week or so from now. 19:31:27 adrianba: show some progress, publish a new version. 19:31:31 nicktr: Makes sense to me, have a wd for next face-toface 19:31:38 Rouslan: There was a question - what's the status of Chrome - we're constantly updating API on trunk - in git - it has a new version - hasn't been pushed to dev channel yet - summer slack w/ people on vacation, probably - usually dev is once a week - delta once a week - every version you'll see that we're trying to keep up with latest changes to API. 19:31:46 rouslan: That being said, API is moving fairly quickly - opera and samsung is helping w/ API version - trying to keep it up to date, we're slightly behind now, so having another public working draft would be a good milestone/snapshot. Our goal is to b e on the bleeding edge. 19:31:52 AdrianHB: i.e. is there an impact on implementers if we are slow to publish WDs 19:31:57 zkoch: We don't need a WD to make progress, we follow as spec evolves, if there is consensus we implement. 19:32:02 adamR: We don't pay a lot of attention to WD/ED - we'll implement whatever the latest thing is. On Web Payments, while I have interest, we haven't allocated resources to implement this yet. 19:32:07 nicktr: Is there a nightly of Edge with Payment Request? 19:32:11 adrianba: We have an experimental implementation - but it's not really externally accessible - relies on a service to do part of the processing. We have internally experimented, API can be turned on w/ a flag - not quite useful yet to public. 19:32:20 AdrianHB: For non-implementers in the group, there are new folks - as we hit milestones, it's important to understand where implementations are. 19:32:24 AdrianHB: This is becoming very real, thanks for all the work from implementers on that. 19:32:28 nicktr: There is another dev that's joining from WorldPay - AdrianHB - keen to join Payment App breakout group. 19:32:33 AdrianHB: Only a few minutes left, let's not dive into anything too detailed. Go and look at F2F agenda - topics missing, flesh out, specific stuff you want to point out in that session. There is a Task Force that is working on a proposal for how payment apps might work in the browser - focused on what happens when payment request is received by a browser - call it a sibling spec to payment request API. 19:32:44 zkoch: Do you guys have a deadline for draft of payment app spec? 19:32:47 AdrianHB: It's being developed in proposals folder in core WG repo. Call is next week after this call. Our goal is to have something ready by face-to-face that we can adopt as ED at face-to-face. 19:32:50 AdrianHB: We want to adopt at end of day Payment Apps spec at face-to-face 19:32:56 nicktr: We want to have testing strategy on face-to-face agenda, I will do that. 19:33:01 zkoch: The final issue that we want to talk about is iframes and support for those - formal email to WebAppSec to ask what they recommend wrt. iframes. All of them have limitations, point to them see if they have a response. Issue #2 - we can get feedback from there. 19:33:04 https://github.com/w3c/browser-payment-api/issues/2 19:33:11 AdrianHB: +1 to resolve 19:33:16 nicktr: Yes, divisive issue in security community - we'll have to take position and see where we go. 19:33:19 AdrianHB: We want to have a proposal and give it to WebAppSec. We'll see what they have to say. 19:33:49 rrsagent, make minutes 19:33:49 I have made the request to generate http://www.w3.org/2016/06/09-wpwg-minutes.html manu 19:36:32 present+ AdrianHB, Dongwoo, dlongley, dlehn, manu, shaneM, AdamR, NickTR, Rouslan, MattS, dezell, zkoch, adrianBa, Kepeng, Roy 19:36:33 rrsagent, make minutes 19:36:33 I have made the request to generate http://www.w3.org/2016/06/09-wpwg-minutes.html manu 19:37:53 s/Topic: Multiple Pricing Options and Currencies in Payment Request/Topic: PR 211 - Multiple Pricing Options and Currencies in Payment Request/ 19:37:56 rrsagent, make minutes 19:37:56 I have made the request to generate http://www.w3.org/2016/06/09-wpwg-minutes.html manu 19:41:50 rrsagent, bye 19:41:50 I see no action items