13:48:30 RRSAgent has joined #wpwg 13:48:30 logging to http://www.w3.org/2016/10/06-wpwg-irc 13:48:32 RRSAgent, make logs public 13:48:33 Zakim has joined #wpwg 13:48:34 Zakim, this will be 13:48:34 I don't understand 'this will be', trackbot 13:48:35 Meeting: Web Payments Working Group Teleconference 13:48:36 Date: 06 October 2016 13:48:44 Agenda: https://github.com/w3c/webpayments/wiki/Agenda-20161006 13:56:42 adamlake has joined #wpwg 13:59:32 present+ Ian 13:59:42 MaheshK has joined #wpwg 14:00:30 present+ AdrianHB 14:00:35 present+ Pascal 14:01:12 present+ Manu 14:02:02 present+ adamR 14:02:04 present+ MaheshK 14:02:23 pascal_bazin_ has joined #wpwg 14:02:43 -> https://github.com/w3c/webpayments/wiki/Agenda-20161006 Agenda 14:03:41 zkoch has joined #wpwg 14:03:45 present+ zkoch 14:04:11 present+ nicktr 14:04:18 dezell has joined #wpwg 14:04:28 present+ AndreL 14:04:28 present+ dezell 14:04:47 alyver has joined #wpwg 14:04:47 scribe: Ian 14:05:06 zakim, who's here? 14:05:06 Present: Ian, AdrianHB, Pascal, Manu, adamR, MaheshK, zkoch, nicktr, AndreL, dezell 14:05:08 On IRC I see alyver, dezell, zkoch, pascal_bazin_, MaheshK, adamlake, Zakim, RRSAgent, shepazu, manu, davidillsley_, adamR, collier-matthew, ShaneM, dlongley, pea13, canton, hober, 14:05:08 ... hyojin, JakeA, mkwst, adrianba, emschwartz, slightlyoff, Dongwoo, AdrianHB, nicktr, schuki, dlehn, Ian, wseltzer, trackbot 14:05:21 present+ AdrianBa 14:05:44 I have made the request to generate http://www.w3.org/2016/10/06-wpwg-minutes.html Ian 14:05:50 present+ Ken 14:05:52 I have made the request to generate http://www.w3.org/2016/10/06-wpwg-minutes.html Ian 14:06:03 -> https://github.com/w3c/webpayments/wiki/Agenda-20161006 Agenda 14:06:20 topic: Post TPAC priorities 14:06:29 Close issues on PR API and PMI (etc.) (led by Editors). What issues require WG attention over the next few weeks? 14:06:29 Review and advance payment apps API to FPWD (led by Payment Apps task force) 14:06:29 Push payments proposal (led by Roy) 14:06:29 Advance test suite (led by Shane) 14:06:43 betehess has joined #wpwg 14:07:40 q+ to note issues raised w/ Rouslan/Zach at F2F and more (minor) issues forthcoming - only one sizeable one - digital signatures. 14:07:50 present+ dlongley 14:07:54 Ian: [Reviews priorities listed in Agenda] 14:08:08 q? 14:08:11 ack manu 14:08:11 manu, you wanted to note issues raised w/ Rouslan/Zach at F2F and more (minor) issues forthcoming - only one sizeable one - digital signatures. 14:08:12 ack manu 14:08:22 manu: We reviewed PR API.... 14:08:32 ...before the FTF and I chatted with Rouslan about some concerns 14:08:40 ...we have a decent list of mostly editorial/minor issues 14:08:44 present+ ShaneM 14:08:51 ...one sizable issue around the use of digital signatures 14:09:03 ...Rouslan and I worked out something but we need to get it into the issue tracker. 14:09:11 ...and one other issue related to algorithms. 14:09:20 ...we are hoping to do PRs on editorial issues in the next week 14:09:42 ...so the only major concern we have after review is around digital signatures 14:09:43 q? 14:10:05 ASAP 14:10:10 IJ: Editors, any preferred timing re: issues? 14:10:11 :) 14:10:14 zkoch: ASAP 14:10:45 AdrianHB: Let's set a target date for issues 14:10:46 q+ 14:11:03 ack me 14:11:28 Ian: I think having a date is good, but from a broader process perspective, we need to solicit wide review with groups from whom we have dependencies. 14:11:30 not too worried about editorial issues - they can be added at any time - need to prioritise normative changes 14:11:46 Q? 14:11:58 q+ to propose that at a minimum we set a date in the near future to publish a new revision that we send for wide review 14:12:06 agreed, editorial is less of a concern - just wanted to give the editors a heads up that we have some coming their way and want to do PRs for them, but having trouble finding the time. 14:12:14 Ian: We have gotten some review, but need more. 14:12:25 ack AdrianHB 14:12:25 AdrianHB, you wanted to propose that at a minimum we set a date in the near future to publish a new revision that we send for wide review 14:12:39 IJ: We have a process requirement to get wide review...need to determine when we are ready to call for that 14:12:47 q? 14:12:51 AdrianHB: So let's aim for a publication date for a spec to get wide review 14:13:07 we can publish at any time 14:13:12 IJ: Editors, got a date when you'd like to have a draft and call for wide review 14:13:15 Ian: Editor's, what's the date for a draft for wide review? 14:13:31 zakim, agenda? 14:13:31 I see nothing on the agenda 14:14:29 Ian: Are you saying we shouldn't ask for wide review before we get Payment Apps in place? Or are you saying we need wide review independent of Payment Apps? 14:14:29 q+ 14:14:32 ack nick 14:14:33 ack me 14:14:58 nicktr: Surely we would not want to go to wide review if we think there are changes to come out of payment apps 14:15:01 ...so I think they are linked. 14:15:07 q? 14:15:11 q+ to note that wide review is fine, even if we think there might be normative changes. 14:15:17 ack manu 14:15:17 manu, you wanted to note that wide review is fine, even if we think there might be normative changes. 14:15:30 Manu: Wide review is fine, even if we think there might be normative changes 14:15:50 ...we can at a later date, if there are normative changes, ping people who did reviews to get updated review 14:16:10 q? 14:16:30 Ian: I think that the topic at hand is not the one that I imagine other groups reviewing the spec will focus on. For a11y and i18n, that coupling is not a substantive point. I'm hearing the Chair say let's move on and we can come back. 14:16:57 Nick: Any other comments on articulated priorities? 14:16:59 (No other comments) 14:17:06 topic: Reminder -CFC for Overview doc 14:17:10 https://lists.w3.org/Archives/Public/public-payments-wg/2016Sep/0132.html 14:17:21 Nick: CFC closes tomorrow; only seen +1's so far 14:17:30 Topic: Reviews of payment apps spec 14:17:44 There were actions from FTF on Max, Zach, Shane to review the spec. 14:17:59 present+ Shane 14:18:12 Shane: I looked over the spec and submitted PRs...mostly editorial 14:18:28 ..I think it's an interesting direction...I think the payment options component is confusing and possibly overengineered 14:18:32 (Ian has some actions to edit those bits) 14:18:42 q+ to note that options came up in payments apps yesterday 14:18:49 I can go 14:18:53 q- 14:19:03 zkoch: I reviewed the specification this morning! 14:19:16 zkoch: I can post individual issues 14:19:20 ...here are some high-level notes: 14:19:32 Ken_Mealey has joined #WPWG 14:19:35 ...I am still a bit confused about recommended payment apps, their value, their role, and how it will work in practice 14:20:03 ..the primary thing that concerns me is UX challenges - opening a new window 14:20:13 ...I think that will be one of our biggest issue 14:20:19 ...there's a mention of "extension points" in the spec 14:20:34 ...I also want to run Service Workers part of the proposal through Jake Archibald 14:20:43 ...it seems like it makes sense but I'd like to get Jake's view 14:20:58 ...from an implementation perspective, I am not excited by payment app options 14:21:29 ...in section 9.1 there are a number of MUST statements that are "no go" 14:21:45 q+ 14:22:03 ...I think the option ID in payment should be optional 14:22:24 q+ to respond to some of the feedback 14:22:31 ...it's my understanding that service workers are registered without the user knowing...I would not want service workers to be registered silently 14:22:42 ...overall it seems like a sane direction 14:22:51 ...I need to have someone review it internally..on the whole it doesn't seem "too bad" 14:22:58 ...but my overwhelming concern would be UX 14:23:13 ..I am intrigued enough to get wider review in the Chrome team 14:23:19 nicktr: Thank you for the review (coffee or not) 14:23:23 q? 14:23:26 ack Ian 14:23:40 Ian: One high level comment - good to get feedback now on Payment Options so we can take it to Github 14:23:54 Ian: I have to edit the spec so maybe we can chat offline about that 14:24:32 q+ to ask zkoch for more details about payment window, clarify registration and consent. 14:24:45 Ian: Regarding the "MUST" statements - we wanted to have functional requirements, not specific implementation guidance. For example - UA MUST display all matching options - the UA MUST NOT play a role of filtering things arbitrarily - it's a functional requirement, not a display requirement. 14:24:58 Zach: I still fundementally disagree with that. 14:25:28 Ian: I want to give confidence to people that the UA is not hiding things that the merchant or the user wants - we can find other language for that- not trying to tell UAs HOW to do things, just trying to keep the ecosystem fair. 14:25:31 q? 14:25:36 ack AdrianHB 14:25:36 AdrianHB, you wanted to respond to some of the feedback 14:25:36 ack AdrianHB 14:25:38 Ian: It would be helpful to raise issues and we'll take them into account. 14:25:43 AdrianHB: Quick feedback on two of the other points.... 14:25:56 ...on extension points...I think that's becoming a common pattern in algorithm where you are extending an interface 14:26:01 ...rather than people having to write monkey patches 14:26:08 ....you give people a place to "run your code here" 14:26:14 ...I've seen it in other specs like web app manifest 14:26:42 ...regarding "payment options"...Rouslan suggested we take it out in v1..but everyone in the call yesterday felt it had value...we need to have that discussion (with you and Rouslan) 14:26:51 ...it would probably be useful to join the payment apps call next week 14:27:22 ...arguments for - allow user agent to surface payment instruments up front to the user (for usability, and efficiency). This lets user select a thing in the mediator without having to click multiple times 14:27:44 ...the other reason is that merchants have been saying they want to put logos against those options (e.g., a card graphic) to show you are picking a visa card 14:27:52 q? 14:27:52 [Arguments against: complexity] 14:28:11 AdrianHB: I think it would be helpful for Rouslan, Zach, AdrianBa could join the payment apps call next weds 14:28:15 q? 14:28:19 ack adamR 14:28:19 adamR, you wanted to ask zkoch for more details about payment window, clarify registration and consent. 14:28:21 ack adam 14:28:49 adamR: Regarding UX...I'd like to hear a bit more about concerns around windows....is it the prospect that the apps will need any UX at all? Or the UX to invoke them? 14:28:54 q? 14:29:08 q+ adamR 14:29:09 zkoch: We definitely need to open up something for the user to interact with...I think authentication is one of those things that will have to take place 14:29:36 ...it's not clear to me how we would do this yet...we would not simply open a new window (e.g., closed accidentally, hidden behind other windows, etc.) 14:29:46 ...it's come up in other contexts like Web Intents 14:30:06 ...it's been difficult in the past...not insurmountable, but a known issue 14:30:09 q? 14:30:59 adamR: I was trying to confirm the objection is not about the proposal in the document...e.g., they can use the most recent event to discriminate "this is a payment window" 14:31:16 ...when I realized there is an affordance in service workers, 14:31:40 zkoch: I agree with you...seems fine to make use of that mechanism; I still want to get internal review 14:31:57 ack adamR 14:31:57 adamR: I think you agree we don't want to specify UX behavior in the spec...mostly an implementation challenge 14:32:01 zkoch: Yes 14:32:22 adamR: Regarding silent registration, we added something on top of service workers where I anticipated permission should be sought 14:32:32 ...+1 to mentioning this explicitly in the spec 14:32:38 zkoch: Yes, adding that language makes sense. 14:32:53 q? 14:33:02 q 14:33:04 q? 14:33:07 /me is a big fan of frolicking 14:33:10 IJ: I am hearing consensus between zkoch and adamR that consent is desirable 14:33:26 nicktr: The chairs will reach out to Max for his feedback. 14:33:47 I have made the request to generate http://www.w3.org/2016/10/06-wpwg-minutes.html Ian 14:34:10 nicktr: Regarding payment apps, I am hearing at a high level "directionally ok" and zkoch will reach out within google re: service workers 14:34:43 zkoch: I think there are big issues we need to talk about ... I will log issues for discussion ... want to discuss those before any thumbs-up 14:34:44 q+ 14:34:47 ? 14:34:50 ack me 14:34:53 q? 14:35:02 Ian: From an editorial perspective, I have some stuff in my todo list today regarding that. 14:35:21 Ian: Zach, question for you - do you want to log issues and have discussion/clarification around first review? 14:35:41 Zach: That's not a blocking dependency - I'm more concerned around Service Workers and stuff like that. 14:35:50 Ian: Ok, then log your issues at any point. Thanks for the review. 14:36:04 Topic: Issue 287 - transactionID 14:36:09 https://github.com/w3c/browser-payment-api/issues/287 14:36:14 https://github.com/w3c/browser-payment-api/issues/287#issuecomment-249231673 14:36:49 adamR: Topic is a shared ID between requestor and app (for tracking, e.g., help with network failures) 14:37:12 ...seems the cleanest solution is for mediator to generate it, put it in the object and hand to payment app 14:37:13 q? 14:37:18 q+ 14:37:45 ...if there are things that either side has that are unique to their usage, they can simply map them between themselves...and if payment methods have internal IDs, those are part of opaque data blobs 14:37:48 ack adrianba 14:37:50 ack adrianba 14:38:11 adrianba: Right now I don't support this proposal. Primarily it feels like guessing at something we might need but we don't have details yet. 14:38:30 ...e.g., coming up with an ID using a format that is controlled neither by merchant nor payment app. 14:38:37 ...also I think the ID could be created in the Web page 14:39:02 ...I would prefer to not add things until we have use case details 14:39:10 ...we know for certain some payment methods do not need this 14:39:25 q+ to agree with adrianba's comments but disagree with his conclusions :) 14:39:27 ...we are assuming that there are many payment methods that need this .... and payment method independent format 14:39:31 ack Ad 14:39:31 AdrianHB, you wanted to agree with adrianba's comments but disagree with his conclusions :) 14:39:35 q? 14:40:06 AdrianHB: I agree with AB's comments...but why I still think it's worth putting in there - it's low cost now and big cost to add this later. 14:40:20 q+ to mention push payments 14:40:21 ...if everyone has had to figure out ways to get around this problem, we add no value later by adding it. 14:40:45 if we add it in and nobody uses it because it's the wrong format or an unpredictable format then it is even worse 14:40:46 ...but if we add this from the start, if you can make an assumption that there will be an ID available, that changes a lot of assumptions for how you will work with the API 14:40:46 q+ to note that we should have a dependency on transactionId w/ another spec we're putting out there (like a push payments spec), otherwise I agree with adrianba. 14:40:52 ack nicktr 14:40:52 nicktr, you wanted to mention push payments 14:40:52 ack nicktr 14:41:08 nicktr: For me, I think this will be a requirement for anybody who is accepting a push payment. 14:41:51 q? 14:41:54 ack manu 14:41:54 manu, you wanted to note that we should have a dependency on transactionId w/ another spec we're putting out there (like a push payments spec), otherwise I agree with adrianba. 14:42:30 Manu: I think the argument we will need this is strong, but I also agree with AdrianB that if we haven't seen any implementation experience it's premature 14:42:42 q? 14:43:19 q+ 14:43:28 IJ: Is the primary use case here push payment management? 14:43:32 Ian: Trying to guage interest here - is the primary interest here push payment? 14:43:41 adamR: Yes, I think that was the primary use case 14:43:41 AdamR: Yes, that was the primary motivating use case. 14:43:45 q? 14:44:01 adamR: I think that there were other thoughts beyond push payments. 14:44:29 Ian: I'm bundling this with Roy, principly, perhaps we can put a hold on a concrete proposal here until we hear from Roy. 14:44:34 q- 14:44:46 Ian: Roy took an action, we should lean on him to provide that input. 14:44:47 q? 14:44:56 ShaneM: I'll get the use cases, I took an implicit action to do that. 14:45:12 To be clear, I'm very supportive of transactionId - we just need a concrete usage of it. 14:45:46 IJ: I am happy to have heard the proposal and suggest we bundle it with Roy's action 14:45:55 Topic: Review action items (from FTF meeting) 14:46:20 Manu to prepare Overview document for CFC (Done) 14:46:28 AdamR to propose text about why the API can reduce need for card data storage; without any recommendations 14:46:36 adamR: Ian suggested some editorial changes 14:47:07 IJ: Are editors ok with the proposal? 14:47:16 adamR: I can update the PR with some edits from Ian 14:47:55 https://github.com/w3c/webpayments-methods-card/pull/17 14:48:33 - Roy to revise the tokenization specification based on today's feedback 14:48:36 (No status update) 14:48:45 - Ben to organize review of tokenization spec from EMV perspective 14:49:17 (IJ: I will ping Ben/Ken) 14:49:55 - Ian to clarify the language around consent (to say more about WG thinking) for security and privacy considerations 14:49:55 I have to drop off early to make a meeting in another building, but my update: i will get to my actions next week (unless adrianba beats me to it ;)) 14:50:02 https://github.com/w3c/browser-payment-api/issues/229#issuecomment-249937391 14:50:07 - zkoch to remove the diagram from basic card 14:50:10 ShaneM has joined #wpwg 14:50:26 i removed the diagram 14:51:48 q? 14:51:50 - Ian to clarify the language around consent (to say more about WG thinking) for security and privacy considerations 14:51:50 - Ian to clarify the language around consent (to say more about WG thinking) for security and privacy considerations 14:52:06 adamR: Can we send a pointer to the PING? If they are happy with it I'll withdraw my objections 14:52:11 IJ: I will do that. 14:52:25 - Ian to work with AdamR on feedback (and question) to the TAG about ambiguity around what to do re: private browsing mode (IN PROGRESS) 14:52:29 IJ: No response from TAG yet 14:53:11 ...but not blocking for us 14:53:15 - MaheshK to work with Ben Smith on a proposal to handle merchant query for specific payment methods 14:53:17 https://github.com/maheshkk/webpayments/wiki/Detecting-if-payment-app-is-available 14:53:18 (Done and on the agenda) 14:53:35 - Shane to write a pull request on what might change around error handling re: addresses 14:53:40 Shane: Still working on that 14:53:53 - Zach to work with Max to revise the payment manifest proposal 14:53:54 (Pending) 14:54:00 nicktr: Thanks everyone 14:54:05 topic: FTF meeting schedule 2017 14:54:46 +1 thanks for all the work done since Lisbon 14:54:57 nicktr: How often do people want to meet? Any host volunteers 14:55:27 IJ: Next TPAC is 6-10 Nov 2017 in California 14:55:51 IJ: Feb/Jul/Nov 14:56:13 Q: Three meetings? 14:56:33 q+ 14:56:39 ack manu 14:56:47 manu: Do we have enough for 3 meetings? 14:56:51 q+ to say "yes" 14:57:02 ack me 14:57:02 Ian, you wanted to say "yes" 14:57:10 Manu: Three thinks like a bit too much 14:57:14 I would me open to trying a virtual F2F too! 14:57:21 s/me /be / 14:57:26 IJ: Our charter expires Dec 2017 14:57:51 q+ 14:57:54 nicktr_redux has joined #wpwg 14:58:08 Adrian-HB has joined #wpwg 14:58:22 q? 14:58:58 Ian: We may want to discuss rechartering mid-year. I'm confident that 3 meetings will provide good opportunities. 14:59:14 q? 14:59:16 ack dezell 14:59:32 dezell: I understand what Manu is saying, but it's practical to have a 3-meeting schedule 14:59:58 ...if you meet in Feb/Mar and get stuff done, you can cancel the July one 15:00:13 alyver has left #wpwg 15:00:26 nicktr: I hear a suggestion to start with one in Feb/Mar and then deciding whether we need a summer meeting 15:00:35 +1 to Feb/Mar next meeting 15:00:50 "earlier than February" is early indeed! 15:01:19 q+ 15:01:22 q? 15:01:25 Adrian-HB: I suggest we look in the range of "end feb" up to "april" and find dates that work 15:01:33 ack adamR 15:01:35 q+ to ask that we dont schedule the IG on a different conteinent this time 15:01:51 adamR: If we are struggling with dates to find, I suggest avoiding MARCH and JULY when the IETF meetings 15:01:58 q? 15:02:04 ...adamR: Feb and April sound good 15:02:08 ack shane 15:02:08 ShaneM, you wanted to ask that we dont schedule the IG on a different conteinent this time 15:02:34 https://www.ietf.org/meeting/upcoming.html 15:02:35 adrianba_ has joined #wpwg 15:02:40 q? 15:02:40 --- 15:02:40 March 2017 - IETF 98 15:02:40 March 26-31, 2017 15:02:40 Host: Please contact iad@ietf.org for hosting opportunities. 15:02:40 Location: Chicago, IL, USA 15:02:41 --- 15:03:21 nickTR: So I am hearing we should find a meeting in Q1 2017 15:03:36 ACTION: nicktr to work with chairs/team contacts on a Q1 2017 FTF meeting 15:03:36 Created ACTION-38 - Work with chairs/team contacts on a q1 2017 ftf meeting [on Nick Telford-Reed - due 2016-10-13]. 15:03:39 I like Chicago in March. 15:03:44 topic: Next meeting 15:03:51 13 October 15:03:54 (IJ at risk) 15:04:03 AdrianHB: Regrets from me 15:04:06 nicktr: Regrets from me 15:04:27 Next meeting is 20 October 15:04:33 rrsagent, make minutes 15:04:33 I have made the request to generate http://www.w3.org/2016/10/06-wpwg-minutes.html Ian 15:04:38 rrsagent, set logs public 15:08:46 shepazu has joined #wpwg 15:26:07 adrianba has joined #wpwg 15:26:22 zakim, bye 15:26:22 leaving. As of this point the attendees have been Ian, AdrianHB, Pascal, Manu, adamR, MaheshK, zkoch, nicktr, AndreL, dezell, AdrianBa, Ken, dlongley, ShaneM 15:26:22 Zakim has left #wpwg 15:26:29 rrsagent, bye 15:26:29 I see 1 open action item saved in http://www.w3.org/2016/10/06-wpwg-actions.rdf : 15:26:29 ACTION: nicktr to work with chairs/team contacts on a Q1 2017 FTF meeting [1] 15:26:29 recorded in http://www.w3.org/2016/10/06-wpwg-irc#T15-03-36