15:55:13 RRSAgent has joined #wpwg 15:55:13 logging to http://www.w3.org/2016/04/28-wpwg-irc 15:55:15 RRSAgent, make logs public 15:55:15 Zakim has joined #wpwg 15:55:17 Zakim, this will be 15:55:17 I don't understand 'this will be', trackbot 15:55:18 Meeting: Web Payments Working Group Teleconference 15:55:18 Date: 28 April 2016 15:55:24 dezell has joined #wpwg 15:55:28 regrets+ Ian 15:55:43 agenda: https://github.com/w3c/webpayments/wiki/Agenda-20160428 15:55:56 present+ dezell 15:57:38 zkoch has joined #wpwg 15:59:31 present+ manu 15:59:35 present+ 15:59:41 alyver has joined #wpwg 16:00:31 present+ dlongley 16:00:37 present+ AdrianHB 16:01:03 present+ alyver 16:01:05 adamR has joined #wpwg 16:01:30 zkoch has joined #wpwg 16:02:22 present+ 16:02:41 TIL you can use present+ without your nick if it’s the same! only took me 12 months to figure out 16:03:29 There are many secrets buried in RRSAgent... a read through the documentation is a very different experience from a read through the code. 16:04:20 “Age: 14 years” 16:04:36 wow 16:04:48 scribe: manu 16:05:07 Roy has joined #wpwg 16:05:23 nicktr has joined #wpwg 16:06:40 AdrianHB: There has been quite a bit of discussion on the list, lots of discussion to try and get ourselves aligned a bit in terms of priorities. 16:07:02 AdrianHB: We have a bunch of influencing factors on priority - lengthy discussion w/ chairs and staff and our proposal is to focus as described in the agenda. 16:07:11 MattS has joined #wpwg 16:07:24 present+ MattS 16:07:28 AdrianHB: we're very concious that there is a strong demand from the group wrt. extensibility of the ecosystem - the ability to have independent 3rd party payment apps as a part of the ecosystem. 16:07:35 maheshkk has joined #wpwg 16:07:38 present+ 16:07:50 AdrianHB: How would that work in terms of UA interfacing w/ payment apps. That's from a browser perspective, but there is non-browser perspectives as well. 16:08:23 AdrianHB: With the browser specs doing experimental implementations, we are going to prioritize this over next few weeks. Provide guidance on that, we expect that to become priority. 16:08:29 AdrianHB: Next is moving browser API forward 16:08:42 i/AdrianHB: There has been/Topic: Priorities/ 16:08:43 I am concerned that we end up with deployment that we feel we can't change as our work matures. 16:08:55 present+ nicktr 16:09:09 VincentK has joined #wpwg 16:09:16 Just a quick clarification: The PRs are from us as individual participants, not in our capacity as editors 16:09:22 AdrianHB: The vendors would like to start implement this API - how many parameters, where do parameters fit, how do specific things work - we'll try to address some of those things today. Issues on the list - address those issues diretly. 16:09:38 AdrianHB: We're going to try to move that stuff to the mailing list as possible. 16:10:18 AdrianHB: There is a proposal from the Web Payments CG around Core Messaging and HTTP API - there is also payment methods - while we would like those things to happen in parallel, the next few weeks will drive what we spend time on. 16:10:28 AdrianHB: Focus very much on issue resolution 16:10:37 nick_tr has joined #wpwg 16:11:37 Nick: I don't have much to add. Adrian and I are trying hard to balance priorities of the group - appreciate everyone's contributions on helping stay focused - arch and extensibility, moving browser specs moving forward, open and excited on other proposals but would like to focus call time over next few weeks on 3 priorities. 16:11:39 q? 16:11:56 VincentK_ has joined #wpwg 16:12:24 AdrianHB: Various hats that people working in the group - contributors/editors/chairs - I'm certainly going to continue to contribute as a contributor - as a developer I'm intending to contribute. It should be accepted that contributions to PRs and issues are, unless stated otherwise, contributions from members of the group. 16:12:33 q? 16:12:37 Nick: I'm fine w/ that position. 16:12:56 Topic: Face-to-face Meeting Update 16:13:20 Nick: Unfortunately dates conflict w/ Blockchain... we've put other dates up 16:13:20 Wednesday 13th July and Thursday 14th July 16:13:20 Monday 18th July and Tuesday 19th July 16:13:20 Tuesday 19th July and Wednesday 20th July 16:13:26 https://www.w3.org/2002/09/wbs/83744/F2F_London/ 16:13:35 present+ 16:13:42 phofmanntsy has joined #wpwg 16:13:53 q? 16:14:01 Nick: Please do fill in the questionnaire - we'll try to fill in the dates that are most helpful - want to see if people would like WPIG / ILP meeting at same time - any questions/comments on that? 16:14:02 present+ 16:14:03 present+ phofmanntsy 16:14:23 ChristopherA: The IETF thing starts on the 17th, SUnday - if there was something that was 14th and 15th I'd go to London and fly out to berlin. 16:14:38 Nick: Logistically, I can't host on the 15ht, but Wed/Thu works. 16:14:58 q+ 16:15:02 AdrianHB: The IG would like to co-host if they can - we might be able to do IG - venues for that are different - Nick can only do Wed/Thu. 16:15:47 dezell: Yes, we're actively thinking about having the face-to-face WPIG meeting w/ you around there - 16:15:52 Nick: I can't host Friday, 16:15:55 ack dezell 16:15:59 AdrianHB: We might be able to host 16:16:06 Brian: I might be able to host on Friday. 16:16:29 dezell: Yes we care and yes we're thinking about a WPIG meeting. 16:16:41 Nick: The questionnaire is open, we'll give you an update at the next meeting. 16:16:45 Topic: Proposals 16:17:07 Nick: Doubt we'll get through all of this today, but let's get started. 16:17:30 Subtopic: paymentrequest.complete() 16:17:52 AdrianHB: The intent was to pass information via complete - originally we asked about passing something to payment app - drop parameter all together? 16:18:27 AdrianHB: Push back on that to change parameter form boolean to enum - AdrianB updated - happy to drop my proposal w/ Adrian's counter-proposal. 16:18:30 https://github.com/w3c/browser-payment-api/pull/161 16:18:37 q? 16:18:52 jnormore has joined #wpwg 16:19:03 adrianba: A little bit more discussion in https://github.com/w3c/browser-payment-api/pull/161 today 16:19:35 adrianba: I'm open to a question about whether we want to talk about those proposals today or accept this PR or think about those more. 16:19:56 I think there is another proposal to do complete({status: “success”}); 16:20:14 +1 to accepting this as is, and then refining later with enums if we want 16:20:15 AdrianHB: We could accept PR as it is to accept new messaging as it is - additional PR to accept a newer proposal. 16:20:24 adrianba: happy to accept as-is and then refine it. 16:20:35 manu: Happy to accept as is and then do different PR. 16:20:39 dlongley: Yes, fine w/ that. 16:20:55 AdrianHB: proposal to accept PR 161 as is. 16:20:59 +1 16:21:00 +1 16:21:00 q? 16:21:02 Nick: Any objections? 16:21:10 +1 to accept PR161` as=is 16:21:14 \o/ 16:21:15 +1 16:22:03 AdrianHB: I put forward PR 133 that has a bunch of stuff in it - trying to do too much in a single PR - as a relative newbie to this process - there is a proposal to address total amount / merging of parameters - PR158 is a counter-proposal to part of that. 16:22:07 https://github.com/w3c/browser-payment-api/pull/158 16:22:23 q? 16:22:39 AdrianHB: In the current spec, we give special meaning to items in the final position in list. The total should stand on its own. 16:23:28 q? 16:23:28 AdrianHB: AdrianHB uses a PaymentItem object, whereas I used an array of currency items. I was trying to support multiple currency amounts. AdrianB's moved total out of items array, but keeps it on same object. In my proposal, I've moved it onto separate parameter - probably a good contrast of two proposals. 16:23:45 adrianba: I was trying to have discussion of multiple currency amounts and price and discuss those separately 16:24:01 AdrianHB: I'm happy to do that, if we address these things incrementally, we'll make more progress. 16:24:10 AdrianHB: Manu asked the question about why "label" 16:24:20 q+ to ask if that is a MUST be displayed... hard to do that. 16:24:39 s/AdrianHB: Manu asked/adrianba: Manu asked/ 16:25:07 AdrianHB: It does make sense to have some kind of label that we can have there. Rather than comparing the two, let's consider adrianba's and like that approach. 16:25:15 AdrianHB: There seem to be general consensus around it. 16:25:16 q? 16:25:58 Manu: What happens if a UA doesn't display? 16:25:59 q+ 16:26:03 ack manu 16:26:03 manu, you wanted to ask if that is a MUST be displayed... hard to do that. 16:26:36 maybe if the UA is going to display the list of items, they have to use all the labels 16:26:49 adrianba: Right now, it's a MAY show it. 16:27:01 Manu: My concern is that developers may be surprised if it's not displayed. 16:27:21 (or ... the UA may not pick and choose which labels to show) 16:27:29 Roy: Just wanted to say that I'm in favor of the PR - we may want to push other things like taxes. 16:27:45 AdrianHB: The proposal separates the total from display items. 16:28:06 AdrianHB: The UA may display that stuff - there is no MUST there - taxes, discounts, whatever other line items the merchant considers important. 16:28:11 Since we don't have UI in our scope, MAY is appropriate here 16:28:17 AdrianHB: Are you saying we should have specific tax amount in there... 16:28:22 q+ 16:28:26 Roy: It's interesting that you say that display items don't have to be displayed. 16:28:33 ack Roy 16:28:37 Roy: Going simply off of a string-based title on the items is error prone. 16:28:51 ack adamR 16:29:18 adamR: I don't want to go too far afield - do you mean that we have some messages that are going to impact the payment request? Or is this just for display purposes right now? 16:29:26 AdrianHB: Purely for display right now. 16:29:45 AdrianHB: Display items are for the UA to use in displaying the UA - pass request onto payment app. 16:29:49 rrsagent, draft minutes 16:29:49 I have made the request to generate http://www.w3.org/2016/04/28-wpwg-minutes.html manu 16:30:25 Roy: I think it's important to call out to the user what's going on - you need display items for that purpose - but there are other item types, inclusive vs. exclusive taxes - important line items, but affect total in different ways - we may want to call other items out. 16:30:44 AdrianHB: We need to clarify that and submit a new PR to add additional items outside displayItems list. Right now what we have is a step in right direction. 16:30:54 Nick: That sounds like consensus 16:31:05 AdrianHB: Any objections to that PR? 16:31:08 q? 16:31:13 I think it could be interesting to extend displayItems with an optional 'type' parameter and a dictionary of semantically meaningful types (to address Roy's concern) 16:31:18 +1 16:31:20 +1 16:31:21 PROPOSAL: Adopt PR153 as is. 16:31:22 +1 16:31:22 +1 16:31:23 +1 16:31:23 :) 16:31:24 +1 16:31:24 +1 16:31:28 +ian 16:31:33 RESOLVED: Adopt PR153 as is. 16:31:34 +1 16:31:57 @adamR: Yep 16:32:17 s/PR153/PR158/ 16:32:24 RRSAgent, make minutes 16:32:24 I have made the request to generate http://www.w3.org/2016/04/28-wpwg-minutes.html Mike5 16:32:59 Subtopic: Separation of payment parameters - PR #162 16:33:58 AdrianHB: Merge list of payment methods with payment method data - major difference is total is still details object - total and items list in details and then supported methods parameter and custom data for those - 2nd parameter which contains total and list of items - 3rd parameter that has options like "requestShipping" 16:34:22 AdrianHB: The difference is that middle parameter - total w/ supported method stuff - display items w/ options - biggest difference between the two. 16:35:14 AdrianHB: Since adrianba's is a step toward that - may submit another PR to get rid of details object and debate that separately - gist is to address a request w/ the TAG review and then issue raised before proposal was brought into WG - whether PMI should be passed as array of identifiers - or more complex objects. 16:35:35 AdrianHB: Looking at the thread, most people are agreed that this will work and it's a step in the right direction - any objections? 16:35:52 adrianba: One quick comment - role of this change was to remove antipattern of having two optional arguments . 16:36:09 q? 16:36:22 PROPOSAL: Adopt PR #162 as is. 16:36:24 +1 16:36:25 +1 16:36:27 +1 16:36:28 +1 16:36:28 +1 16:36:43 RESOLVED: Adopt PR #162 as is. 16:36:50 +1 16:36:52 RRSAgent, make minutes 16:36:52 I have made the request to generate http://www.w3.org/2016/04/28-wpwg-minutes.html Mike5 16:37:17 q+ 16:37:18 q+ to say modifications are coming 16:37:24 oop, q- 16:37:24 q- later 16:37:32 Subtopic: Change the way we request user data - PR #65 16:37:45 AdrianHB: This one is contentious... it has to do w/ how we pull in user data. 16:38:08 q? 16:38:11 AdrianHB: There have been multiple counter proposals - AdrianB - you had an argument against getting too generic. Can you explain why this is a bad idea? 16:38:17 q? 16:38:19 ack zkoch 16:38:19 zkoch, you wanted to say modifications are coming 16:38:55 zkoch: I don't think there is consensus around that PR - some good feedback - trying to make modification to it - probably not quite ready yet to be merged in yet. So, hoping we could punt it to the next call. 16:39:06 manu: Agree to punt to next call - no clear consensus yet. 16:39:16 AdrianHB: Let's talk about this PR, though. 16:39:19 q? 16:39:23 KuntzV has joined #wpwg 16:40:04 adrianba: Agree w/ Zach - was going to work w/ Zach on working on this PR - didn't anticipate that we'd make fast progress on previous 3 issues. 16:40:28 VincentK has joined #wpwg 16:40:48 adrianba: Counter proposal is to add request to options dictionary, specifically for email and phone number, but I don't like Zach's original proposal because it assumes that these are always boolean requests, merges them into a list. 16:41:03 adrianba: I think we should esign the API so we could protentially have things be required or optional 16:42:02 adrianba: we've had discussions - feasible around UI - is it something we need now? plan was to propose that we keep it simple to begin with - we have booleans in the same way we have requestShipping, requestEmail, requestPhone and show how that could be etensible and decide if we want to add required vs. optional. 16:42:05 q? 16:42:09 ack adrianba 16:42:56 AdrianHB: I get the sense that folks haven't followed this thread closely. From my perspective, what we have is effectively this spectrum of flexibility on one side where websites can ask UA to gather anything for them, what is gathered through UA - what it is they can ask for it. 16:43:08 q+ to ask that we design something generic/extensible - because that's where we're going. 16:43:39 AdrianHB: The other end of the spectrum is something fairly rigid. 16:43:45 AdrianHB: I'd prefer something flexible 16:44:00 q? 16:44:07 ack manu 16:44:07 manu, you wanted to ask that we design something generic/extensible - because that's where we're going. 16:44:20 i/I put forward/RESOLVED: Adopt PR #161 as is. 16:44:28 RRSAgent, make minutes 16:44:28 I have made the request to generate http://www.w3.org/2016/04/28-wpwg-minutes.html Mike5 16:44:36 manu: My concern is that we shoot for something fairly narrow and rigid and over time we're going to keep expanding the types of information that orgs will want from the UA and we'll end up in a position where this is a general customer data collection API. 16:44:58 q? 16:45:08 q+ 16:45:11 q? 16:45:25 manu: My preference is that we make it generic and generalized which is what AdrianHB is proposing because we'll end up in a situation where we have 10-15 things that we support over the last 5 years. To be clear, I wish this wasn't happening in the payment API and instead in another one, but I think we're setting ourselves up to collect email and coupon, and so on and so forth. 16:45:29 ack zkoch 16:45:30 ack zkoch 16:45:56 s/PR158/PR #158/g 16:45:58 zkoch: I don't like generic - I think that part of what we're doing here is an opinionated streamlined flow. I don't think we're trying to recreate the entire buy form experience. 16:45:58 RRSAgent, make minutes 16:45:58 I have made the request to generate http://www.w3.org/2016/04/28-wpwg-minutes.html Mike5 16:46:40 zkoch: We can only accommodate a certain set of use cases - if we have 15 different things you can request - we need to stop and reflect. The bar is limited to information you absolutely have to have for checkout flow... email and phone may be the bar. 16:46:44 q 16:46:46 q? 16:46:46 zkoch: We want to avoid massive expansion. 16:47:02 AdrianHB: If there are no other comments, we can move onto other issues. 16:47:30 We already have generic, it’s called a
:) 16:47:32 AdrianHB: If you want to submit an alternative proposal - please do. 16:48:13 nicktr has joined #wpwg 16:48:31 AdrianHB: We need to understand why not to do generic. We went through this on shipping address - made checkout experience better, if anything else makes checkout experience more efficient, we need to consider it. We need to think about privacy - how easy is it to farm user data? 16:48:31 q? 16:48:53 AdrianHB: What about other countries required stuff - like country-specific shipping information? 16:48:57 q? 16:49:15 AdrianHB: Maybe we should dive into one or two of the other issues that impact the shape of the API - stimulate proposals to come forward. 16:49:32 q+ to ask about how this will be deployed and how that affects how much handwringing may be done. 16:49:38 Topic: Other issues 16:50:06 AdrianHB: There are four other issues that we may want to talk about - happy to do them in that order or one in particular that anyone wants to discuss. 16:50:13 ack manu 16:50:13 manu, you wanted to ask about how this will be deployed and how that affects how much handwringing may be done. 16:51:06 manu: There's been talking about this API and implementing it in the browser, is the expectation that when this gets published (soon), will it be behind a flag? 16:51:35 q+ 16:51:45 q+ 16:51:50 manu: If collecting this information is behind a flag at first as an experiment, then I think people in the WG are much more likely to get behind it. Because if tons of people start using it then we have to keep it around. 16:51:57 +1 to a general concern about exposing experimental features to the public 16:52:03 ack zkoch 16:52:08 manu: Do you guys know how you'll do this first round of implementation, will it be behind a flag? 16:52:36 zkoch: We have two conflicting ideology - we want to get features out to get feedback, but we don't want to launch something that's unfinished. We have a couple of different things that we're looking to do. 16:52:40 +1 to behind a flag 16:53:20 q? 16:53:42 zkoch: You will probably see this behind a flag at first - problem with that is that it's difficult for a developer to use - what's the impact of this on conversion - so all users should enable flag. So another thing we're looking at as well that should solve this problem - how we can solve this problem from a Chrome perspective - origin trials - send out more details - way to launch experimental features, but expire them w/ use of tokens - there is a way for us 16:53:42 to turn this stuff off 16:54:09 zkoch: If we had an experimental thing, we can always put stuff behind another flag. Don't want to lock ourselves into an API that we're unhappy with, we will work hard to avoid that. 16:54:18 ack adrianba 16:55:12 adrianba: To echo what Zach said, we will implement this first behind a flag for the payments api - in Edge - not ready for people to experiment w/ people outside our team now. With every new feature, we have to figure out balance between stability of parts of spec and whether it's ready for people to use / experiment with - we'll definitely start behind a flag. 16:55:16 q? 16:55:22 I have to run to make another meeting, but happy to chat on this topic further if there are more questions 16:55:32 Thanks, all! 16:55:59 adrianba: One of the things we're going to look at wrt. changes in the API - if there is something where we see a potential change or something that we might implement incrementally, if you have this whole capability - lots of different aspects to it, we may only have resources to implement one of those things... how could web developer check to see if one capability exists, but others don't. 16:56:03 q? 16:56:26 adrianba: That's a core part of our philosophy for all APIs, want to focus on that - we don't want to lock the group to feel something is being decided w/o them. 16:56:32 adrianba: or break core API spec. 16:56:49 adamR: I don't have a position from a Mozilla perspective yet. 16:57:19 AdrianHB: I think that's a good perspective - I think that answered Manu's question. 16:57:25 manu: Yes, thanks 16:57:32 Topic: Next Week 16:57:56 Nick: I think we made good progress this week on browser API - would like to focus on extensibility next week - please read proposals. 16:57:59 https://github.com/w3c/webpayments/tree/gh-pages/proposals 16:58:23 AdrianHB: The key ones we will focus on next week are Core Messages, HTTP API, and Payment Apps. 16:58:53 AdrianHB: It may be just parts of it that we propose are browser-specific as opposed to generic payment apps thing - don't only read them, but comment on them - if you don't like them, submit a counter-proposal. 16:59:23 AdrianHB: I would love to see counter-proposals w/ differnt approaches to what's been put forward to date - There are 4 issues that are left not specific to particular PRs. Those issues impact the shape of the API some more than others. 16:59:41 AdrianHB: At least 3 of them were picked up during the TAG review - look at them, propose solutions to them, and close them out as soon as possible. 17:00:00 AdrianHB: we dont' want shape of API to change down the line. If impleemnters are happy and this is feasible, the sooner we get ther the beter. 17:00:23 AdrianHB: If people aren't happy w/ priority or labels - change them yourself or let me know. 17:00:24 please look at issues #2, #16, #19, 119 17:00:41 AdrianHB: Let me know what you think the priorities should be. 17:00:45 rrsagent, draft minutes 17:00:45 I have made the request to generate http://www.w3.org/2016/04/28-wpwg-minutes.html manu 17:01:00 alyver has left #wpwg 17:01:09 AdrianHB: I used a milestone for this week and will create milestones for next weeks calls. I would like if we have proposals to address these issues or any that affect the API. 17:01:53 Nick: Read those proposals before next week or comment on them. The more comments there are, the easier the discussion goes. I hope that by picking up some of the other proposals next week, we'll make the group more broadly inclusive. 17:01:57 Nick: Speak with everyone next week. 17:02:07 rrsagent, draft minutes 17:02:07 I have made the request to generate http://www.w3.org/2016/04/28-wpwg-minutes.html manu 17:02:13 nicktr has joined #wpwg 17:03:31 rrsagent, bye 17:03:31 I see no action items