14:51:09 RRSAgent has joined #wpwg 14:51:09 logging to http://www.w3.org/2017/02/09-wpwg-irc 14:51:11 RRSAgent, make logs public 14:51:11 Zakim has joined #wpwg 14:51:13 Zakim, this will be 14:51:13 I don't understand 'this will be', trackbot 14:51:14 Meeting: Web Payments Working Group Teleconference 14:51:14 Date: 09 February 2017 14:51:25 Agenda: https://github.com/w3c/webpayments/wiki/Agenda-20170209 14:51:28 Scribe: Ian 15:00:28 alyver has joined #wpwg 15:01:22 present+ oyiptong 15:01:26 present+ 15:01:29 zakim, who's here? 15:01:29 Present: oyiptong, Ian 15:01:31 On IRC I see alyver, Zakim, RRSAgent, davidillsley_, adamR, AdrianHB, emschwartz, oyiptong, nicktr, adrianba, JakeA, Dongwoo, slightlyoff, mkwst, manu, dlongley, dlehn, pea13, 15:01:31 ... canton, Ian, ShaneM, hober, schuki, trackbot 15:02:20 present+ 15:02:53 present+ adrianhb 15:03:06 present+ 15:03:26 Chair: AdrianHB 15:03:58 Max has joined #wpwg 15:04:22 i'll be there! 15:04:38 zkoch has joined #wpwg 15:04:51 dezell has joined #wpwg 15:05:01 present+ zkoch 15:05:23 topic: PMIs 15:05:29 https://github.com/w3c/webpayments-method-identifiers/pull/21/ 15:05:41 present+ dezell 15:05:45 AdrianHB: Have some draft text. But Ian and I were not in agreement on one point and want to ask the group 15:05:52 Question: When a PMI URL is malformed (i.e., has a query string or fragment id), should the user agent throw it out and not match at all, or simply throw out the query string and fragment id but consider the URL for matching? 15:06:22 q+ 15:06:30 ack zkoch 15:07:04 (The pull request basically says "Keep the URL but throw out the offending parts") 15:07:15 (Ian had thought we had decided "Throw out the URL") 15:07:46 andrelyver_ has joined #wpwg 15:07:46 zkoch: Unrealistic to expect implementations to strip out bits. Prefer "throw out the URL" 15:07:55 AdrianHB: That is what Rouslan said at the last call 15:08:03 Note: Rouslan sends regrets, is caught in snowstorm 15:08:07 regrets+ Rouslan 15:08:11 present+ Molly 15:08:14 present+ nicktr 15:08:15 in favor of zkoch's suggestion 15:08:15 +1 15:08:16 present+ Ken 15:08:21 present+ max 15:08:31 present+ alyver 15:08:42 PROPOSED: Throw out malformed URLs for matc hing 15:08:42 Sounds okay to me. 15:08:47 so RESOLVED 15:09:02 makes sense to me +1 15:09:02 AdrianHB: I will update the PR 15:09:09 ::leaves:: 15:09:13 topic: Payment Method Manifest Specification 15:09:40 zkoch: Max and I met last week. Max is working on defining the link header parts. 15:09:46 ...I am working on the structure of the manifest file 15:09:59 ...we've decided we're going to use the current web app manifest spec for inspiration 15:10:17 ..I also reached out to Marcos re: reuse of web app manifest 15:10:31 ...and sent to Molly as well 15:11:02 ...I have asked Marcos for feedback before end of week 15:11:07 q? 15:12:00 adrianhb: I think that we may not be able to reuse web app manifest for some of the tasks we have in mind for a payment method manifest file 15:12:10 ...I think it will be a simple file 15:12:23 zkoch: I tend to agree; but hope we get this resolved quickly 15:12:40 q+ 15:13:31 ian: the apss TF is having debates about the granularity of choices to present a user 15:13:34 a) One container and that's it 15:13:43 b) One container with different walls 15:13:50 c) N containers with N instruments 15:13:52 o.O 15:14:31 ian: we had envisioned that the user would see options with something they recognise (like the last 4 digits of their card) to save some clicks 15:14:39 zkoch: Option c) looks like https://dl.dropboxusercontent.com/u/53717247/amex.png 15:14:53 ... what granularity is being provided in native? 15:15:04 zkoch: there are two questions (1) what is our objection and (2) what are we doing 15:16:18 zkoch: I suppose that if other implementers want to do this, I wouldn't oppose. But we think that there are sufficient problems with instrument-level information..it can be overwhelming to the user, you need to figure out how to identify strings in a consistent manner across apps, you have a deduplication problems (same card in multiple apps) 15:16:27 ...and are unhappy in general with instrumental level UX 15:16:32 q+ 15:16:33 deduplication is a valid concern! 15:16:43 ..there are a few other things as well...we found these to be hard challenges 15:16:56 ...today you just see "Android Pay" as an option 15:17:06 ...when you click you open Android Pay and choose an instrument, do authentication, etc. 15:17:11 ...so we don't do any line-time support 15:17:22 ...the same flow should work for 3rd party payment apps 15:17:24 ack me 15:17:31 ack adamR 15:17:43 q+ to ask MS and Opera and Mozilla 15:17:46 adam? 15:18:04 adamR: I am sensitive to the point that Zach is talking about re; user experience. 15:18:24 ...but I want to put forth the countervailing force - the amount of friction to go through a flow increases dramatically with each click the user must perform. 15:18:37 ...the prospect that they are choosing an app and then an instrument in the app doesn't do the user or merchant any favors 15:18:54 q+ 15:18:56 ...we had previously discussed registering these things and then leaving to the browser whether to render them to the user, or render the app-level 15:19:00 q+ to present a counter-point to the argument for options as a reduction of fricition 15:19:11 ...so we wanted to enable a single click flow if user agent wants to 15:19:14 zakim, who is here? 15:19:14 Present: oyiptong, Ian, adamR, adrianhb, nicktr, zkoch, dezell, Molly, Ken, max, alyver 15:19:17 On IRC I see andrelyver_, dezell, zkoch, Max, Zakim, RRSAgent, davidillsley_, adamR, AdrianHB, emschwartz, oyiptong, nicktr, adrianba, JakeA, Dongwoo, slightlyoff, mkwst, manu, 15:19:17 ... dlongley, dlehn, pea13, canton, Ian, ShaneM, hober, schuki, trackbot 15:19:44 adrianHB: I heard zach not objecting to having the info available, and simply google choosing not to implement. 15:19:55 adamr: Note that the desktop experience may be different 15:20:00 q- 15:20:16 q- 15:20:18 IJ: The spec currently says "UA must render options" 15:20:41 ian: spec currently says UA must render options. I hear us saying this is not a normative req on UAs 15:20:59 +1 to no “must” language on this :) 15:21:20 ... any thoughts from other implementors? 15:21:48 q+ to point out spec complexity that we could avoid by putting this off to a v2 15:21:52 Molly: I need to think about it 15:22:14 q? 15:22:16 ack me 15:22:16 Ian, you wanted to ask MS and Opera and Mozilla 15:22:28 ack AdrianHB 15:22:28 AdrianHB, you wanted to point out spec complexity that we could avoid by putting this off to a v2 15:22:36 https://dl.dropboxusercontent.com/u/53717247/amex.png 15:22:59 q+ 15:23:23 AdrianHB: There is still the question of "app container walls' (esp for 2 apps from same origin) 15:23:59 AdrianHB: Another thing I wanted to raise...there's a lot of complexity and debate in the apps task force about how to support this 15:24:14 ...and how this set of data that needs to be loaded into the browser needs to be tied back to composable parts of a web app 15:24:22 ...we have security and app boundaries to worry about 15:24:43 To be clear, this is showing a single origin, and therefore a single “web app” the way that term is used. 15:24:57 Not two apps 15:25:05 AdrianHB: ^^^ 15:25:29 q+ to make a point of order 15:25:39 ack zkoch 15:25:55 zkoch: Two quick thoughts - as I look at the image...I think there are two points of subtlety 15:26:04 ...there are three total instruments 15:26:21 ..there is a difference between instrument selection and "Giving users more insight as to what they will find in the app" 15:26:27 ...so seeing not the same as clicking 15:26:38 ...perhaps that would improve experience without complexity. 15:27:02 ..+1 to going with "payment app level" for now and then revisiting if deemed insufficient 15:27:22 ian: helpful feedback 15:27:29 q+ 15:27:46 q- 15:27:49 ... TF should put proposal to WG 15:28:01 q+ 15:28:10 ... but if there is enough info now then a strawpoll may be useful to give the Tf input 15:28:25 No :) 15:28:31 IJ: Do you expose instruments in native? 15:28:33 ... useful input from zkich 15:28:34 zkoch: No 15:28:39 thinks that the schemes would probably have a strong view particularly given the link up between Masterpass and Visa Checkout 15:28:42 s/zkich/zkoch/ 15:28:55 ack me 15:28:55 Ian, you wanted to make a point of order 15:29:02 molly has joined #wpwg 15:29:05 nicktr: can you expound? 15:29:50 adamR: Important to think about mobile v desktop. I think that on mobile, app-level presentation makes a lot of sense. 15:30:01 ...I would be concerned to be glossing over the other experiences 15:30:04 q? 15:30:07 ack adamr 15:30:22 We also have a desktop implementation designed in almost implemented, so I think our thoughts come from that experience as well. But I agree there’s a risk of oversimplification 15:30:30 @zach - Mastercard and Visa have agree that they can put each other's tokens in each other's wallets 15:30:35 -> http://uk.businessinsider.com/unpacking-visa-and-mastercards-tokenization-deal-2016-12?r=US&IR=T 15:30:45 Or to re-use a commonly employed IETF phrase: “Let’s make it as simple as possible, but no simpler.” 15:31:15 AdrianHB: I am hearing a feeling a concept the the specs should support options but not require impelmentation of them 15:32:38 AdamR: I think the spec should support this but agree it should not be required to be implemented by UAs (notably for mobile) 15:32:46 I have made the request to generate http://www.w3.org/2017/02/09-wpwg-minutes.html Ian 15:32:51 +1 to adamR's position - allow/support but don't mandate the display 15:33:26 q? 15:33:49 topic: Test suite check in 15:34:00 ian: meeting this week 15:34:03 http://www.w3.org/2017/02/09-wpwg-minutes.html 15:34:23 ... stan and roy joined and have stepped up and volunteered to help 15:34:37 To be clear, I think the best way to think about this is as a “graceful degradation” scenario. Put another way: let’s say v1 didn’t support this functionatliy, but v2 didn’t. We would still have to support v1 apps that didn’t register this, and they would have to deal with v1 browsers that didn’t display sub-options. If that’s a tenable state of affiars, I’d like to just go ahead and jump to that state right out of the gate. 15:34:39 ... resource constraints have held us back to daye 15:34:54 s/v2 didn’t/v2 did/ 15:35:17 ... roy investigating if Facebook impl could be used for testing 15:35:28 ... and also if Fb has tests that it can contribute 15:35:39 ... currently tests are only run against Chrome on Android 15:35:45 Questions: 15:35:51 1) Anyone have PR API implementations available for testing? 15:35:58 2) Anyone have tests for those implementations 15:36:05 3) Anyone else want to participate in the testing effort? 15:36:43 ian: important to have tests at the end of CR 15:37:06 ... WG said in Lisbon that we wanted a good test suite pre CR 15:37:26 roy: we have an impl and were able to run the test suite against it 15:37:36 ... how do we "provide the impl back" 15:37:40 ...? 15:38:23 ian: part of that q is "how do we run tests". Normally we just point a browser at some code (tests) and see what happens. 15:38:37 ... some can be automated but some require manual intervention 15:39:22 roy: do we need to have a publicly accessible release or can we run tests internally and share results 15:39:47 ian: for the purposes of building out the suite there doesn't need to be a publicly available impl 15:40:04 ... historically the director has evaluated private impl as part of the process 15:40:27 ... there is also precedent of test suite results only being shown to W3C staff 15:40:57 IJ: I think you can get the test suite, run tests, check back new tests to the repo 15:40:57 ... so there is a process req and but that doesn't impact what we do to build the suite 15:40:59 q? 15:41:38 Ian: Let me know if you have tests or want to help! 15:41:45 adrianhb: end-to-end integration testing could be complex, so help welcome 15:42:09 topic: Meetings 15:42:14 next FTF meeting 15:42:20 https://github.com/w3c/webpayments/wiki/FTF-March2017 15:42:50 (Currently about 30 people) 15:43:41 I would like to give an update on the EMVco work if I can a) get that update and b) get permission to communicate it. I am working on getting both 15:43:51 https://github.com/w3c/webpayments/wiki/FTF-March2017 15:45:07 I would love to see demos 15:45:10 AdrianHB: People ok looking at demos? 15:45:13 [No objections] 15:45:54 Topic: PAG update 15:46:19 IJ: We have a draft report 15:47:17 ...expect the PAG to review the report, then take to the Director 15:47:22 Topic: next meeting 15:47:23 18 Feb 15:47:31 I have made the request to generate http://www.w3.org/2017/02/09-wpwg-minutes.html Ian 15:47:33 thank you everyone 15:47:37 RRSAgent, set logs public 15:48:59 andrelyver_ has left #wpwg 16:55:22 zkoch has joined #wpwg 16:57:12 pea13 has joined #wpwg 16:57:13 canton_ has joined #wpwg 17:45:28 Zakim has left #wpwg 19:15:29 davidillsley_ has joined #wpwg 19:30:21 adamlake has joined #wpwg 21:11:58 sam has joined #wpwg 21:31:12 dlehn has joined #wpwg