IRC log of apps on 2017-02-28

Timestamps are in UTC.

15:01:27 [RRSAgent]: RRSAgent has joined #apps
15:01:27 [RRSAgent]: logging to http://www.w3.org/2017/02/28-apps-irc
15:01:32 [Ian]: zakim, bye
15:01:33 [Zakim]: leaving. As of this point the attendees have been Ian, Andre, Frank, Jake, Adam, AdrianHB, michiel, rouslan, Conor
15:01:33 [Zakim]: Zakim has left #apps
15:01:34 [Zakim]: Zakim has joined #apps
15:01:41 [Ian]: present+ Rouslan
15:01:44 [Ian]: present+ Ian
15:01:46 [Ian]: present+ Frank
15:01:48 [Ian]: present+ Conor
15:01:48 [alyver]: alyver has joined #apps
15:01:59 [Ian]: Meeting: Payment Apps Task Force
15:02:01 [Ian]: Agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017Feb/0081.html
15:02:04 [Ian]: Chair: Ian
15:02:14 [alyver]: present+ alyver
15:02:38 [adamR]: present+
15:02:52 [Ian]: present+ Pascal
15:03:04 [Ian]: => https://lists.w3.org/Archives/Public/public-payments-wg/2017Feb/0081.html
15:03:11 [Ian]: Topic: Running summary
15:03:18 [Ian]: https://github.com/w3c/webpayments-payment-apps-api/wiki/Proposal-20170130
15:03:27 [pascal_bazin]: pascal_bazin has joined #apps
15:03:54 [Ian]: present+ Mathieu
15:04:24 [Ian]: IJ: Any comments?
15:04:57 [Ian]: IJ: Any volunteers to read it?
15:05:12 [pascal_bazin]: I volonter
15:05:25 [mathp]: mathp has joined #apps
15:05:40 [frank]: sure
15:05:54 [Ian]: Two volunteers for next week: Frank, Pascal
15:06:26 [conorhwp_]: conorhwp_ has joined #apps
15:06:27 [Ian]: Topic: AdamR's proposal
15:06:32 [Ian]: https://github.com/w3c/webpayments-payment-apps-api/commit/4430d10f1b0957196576b8018a095a4b5a26eb81
15:06:44 [Ian]: IJ: Next steps?
15:06:53 [Ian]: AdamR: I haven't seen support or opposition.
15:07:08 [rouslan]: statement of support
15:07:25 [Ian]: +1
15:08:11 [Ian]: s/americanexpress/amex
15:10:19 [Ian]: AdamR: My proposal does not touch the request/response object. It assumes filters are going to come in.
15:10:33 [Ian]: ...I do have an outstanding todo for aligning names
15:10:44 [Ian]: present+ AdrianHB
15:11:52 [Ian]: ACTION: AdamR to flesh out his proposal to put in place text around procedures for using these IDL constructs
15:12:29 [Ian]: AdamR: Another thing that I would like to do or see done and relocating explanatory tex to appendix.
15:12:36 [Ian]: ...so examples and IDL are nearer the top.
15:12:45 [Ian]: ACTION: Ian to move explanation to the bottom
15:13:53 [Ian]: Topic: Status of code writing
15:14:12 [Ian]: AdamR: I spoke with Marcos last week. I plan to take some of his examples (finer grain) and integrating into my proposal
15:14:14 [Ian]: +1
15:14:49 [Ian]: IJ: What is status of Marcos/Tommy/Pascal conversation?
15:14:55 [Ian]: Pascal: We have not made progress yet.
15:16:14 [Ian]: IJ: Please keep us posted; will be good to have code in the spec
15:16:26 [Ian]: Pascal: What kind of code do you want?
15:16:37 [Ian]: https://github.com/w3c/payment-request-info
15:17:03 [Ian]: ----
15:17:20 [Ian]: * Getting permission
15:17:20 [Ian]: * adding, removing, updating, payment methods
15:17:20 [Ian]: * handling .canMakePayment(),
15:17:20 [Ian]: * handling POSTing for payment (without a secure window).
15:17:22 [Ian]: * Getting the browser to open a secure window
15:17:24 [Ian]: * handling PaymentRequest .abort(), .updateWith(), and whatever else
15:17:26 [Ian]: PaymentRequest can throw at us.
15:17:28 [Ian]: * creating a PaymentResponse - and showing how it coordinates between
15:17:32 [Ian]: the secure window and merchant.
15:17:34 [Ian]: * Other critical things that I can't think of right now... Please add them!!!
15:17:36 [Ian]: ---
15:17:48 [Ian]: AdrianHB's list:
15:17:49 [Ian]: ====
15:17:49 [Ian]: - Handles multiple payment methods:
15:17:49 [Ian]: o Basic-card payment.
15:17:49 [Ian]: o Web App payment (mine and tommy’s)
15:17:50 [Ian]: - Rendering UI for payment confirmation or cancelation
15:17:51 [Ian]: - Use of the manifest to create explicit choice
15:17:53 [Ian]: - Management of Payment request options by the merchant
15:17:55 [Ian]: - Feedback of the shipping options to alter the amount
15:17:57 [Ian]: - Use of the payment response details by the payment app
15:18:01 [Ian]: - Use of the payment response details by the merchant (for display)
15:18:03 [Ian]: - Registration and more around the service worker control
15:18:05 [Ian]
15:18:07 [Ian]: ====
15:18:14 [Ian]: Pascal:I can gather what I have in small examples
15:18:29 [Ian]: ...can put that in once place and let editors put the code where it goes
15:18:47 [AdrianHB]: q+
15:18:54 [Ian]: ACTION: Pascal to gather example code; send link to WPWG
15:19:14 [Ian]: ack Ad
15:19:24 [Ian]: (IJ: How should we do this on github?)
15:19:53 [Ian]: AdrianHB: The original request from Marcos was not to write working code, but rather code that showed how we would use the API to see if it makes sense
15:19:58 [Ian]: agenda+ Rename the spec
15:20:59 [Ian]: ...I had understood we would write things the way we want them to work, and then design the API accordingly
15:22:06 [Ian]: AdamR: .canMakePayment() is no longer relevant
15:22:43 [Ian]: AdamR: I believe the example for POSTing for payment means take the current example and update it
15:23:05 [Ian]: https://github.com/w3c/webpayments-payment-apps-api/pull/101
15:23:20 [Ian]: IJ: May have been fixed
15:23:25 [Ian]: AdamR: If so, that addresses handling POSTing
15:23:53 [AdrianHB]: q+ to suggest we agree on use cases before diving into code
15:24:06 [Ian]: ack AdrianHB
15:24:06 [Zakim]: AdrianHB, you wanted to suggest we agree on use cases before diving into code
15:24:25 [Ian]: AdrianHB: I think it would be useful to agree first on the things we need examples for.
15:25:26 [Ian]: Adrian: I don't just mean functions. I mean different scenarios like "one service worker per payment method"
15:25:35 [Ian]: ..."I have 4 options that I want to separate into wallets"
15:25:58 [Ian]: IJ: Is the latter part of AdamR's proposal?
15:27:42 [AdrianHB]: The proposal from Tommy: https://github.com/tommythorsen/webpayments-demo/blob/gh-pages/proposals/Apps%20and%20Workers%202.md
15:27:52 [Ian]: AdamR: I think we probably do want to keep the WebIDL in concert with examples
15:28:07 [Ian]: ...otherwise it could be difficult, e.g., to write examples that are mutually consistent
15:29:10 [Ian]: AdamR: +1 to a place with lots of examples that we can cherry pick from for the spec
15:29:55 [Ian]: AdamR: examples.md
15:30:07 [AdrianHB]: https://github.com/w3c/webpayments-payment-apps-api/blob/gh-pages/proposals/examples.md
15:31:02 [Ian]: AdrianHB: This will also help with testing
15:31:34 [Ian]: IJ: Let's update Pascal's action to start to edit https://github.com/w3c/webpayments-payment-apps-api/blob/gh-pages/proposals/examples.md
15:32:07 [Ian]: Pascal: We may need to differentiate code example from app example
15:32:56 [pascal_bazin]: pjbazin on Github
15:33:41 [Ian]: IJ: AdamR, do you want to put some code in there too?
15:33:48 [Ian]: AdamR: Don't think it's necessary but not opposed
15:34:17 [Ian]: AdrianHB: Let's not waste time; just put in the spec if we are happy with code....this examples.md is a scratch pad
15:34:34 [Ian]: AdamR: I distinguish code to illustrate the design from code to drive the design
15:35:27 [Ian]: topic: Issue 91: Line items and privacy
15:35:40 [Ian]: https://github.com/w3c/webpayments-payment-apps-api/issues/91#issuecomment-279904374
15:38:35 [Ian]: IJ: Should browsers (good practice) offer a feature to let users share or not share line items with payment apps?
15:38:55 [alyver]: q+
15:39:25 [Ian]: AdamR: It's still my position that these strings should NOT be passed through, but I understand that's not the prevailing sentiment
15:39:48 [Ian]: alyver: There are cases where you do want to send it through, e.g., credit cards for level 2 and level 3 requirements
15:40:43 [Ian]: ...specific to credit card transactions (corporate cards)
15:40:48 [adamR]: q+
15:40:54 [Ian]: ..if there's a payment app that handles corporate purchasing
15:41:07 [Ian]: ...you would need additional data to get a lower interchange on that transaction
15:41:20 [Ian]: ack ada
15:41:36 [Ian]: adamR: Is this something that's possible to do based on text, or do you need structured data?
15:41:41 [Ian]: ack alyver
15:42:17 [Ian]: alyver: E.g., shopify would send this data to downstream processor
15:42:25 [Ian]: ..you'll have quantity, amount, tax amount, description
15:42:32 [Ian]: ...just treated as strings; no validation is done
15:43:07 [Ian]: AdamR: We probably want to collect information on this. if it's a requirement on the API, we want to make sure that what we have is adequate to satisfy those requirements
15:43:19 [Ian]: ..e.g., we don't have quantity indicator, etc.
15:43:27 [Ian]: ...these would be new requirements (on PR API, not payment apps)
15:43:33 [Ian]: alyver: It's really for corporate purchasing cadrs
15:44:07 [AdrianHB]: q+ to ask if there are other ways to get the data?
15:44:08 [Ian]: Frank: Ian summarized our use cases: credit based on risk assessment and what is purchased
15:44:27 [Ian]: ...we also send an invoice (similar to payPal) ... payment happens at a later stage and it's useful to know what you bought
15:44:30 [Ian]: ack AdrianHB
15:44:30 [Zakim]: AdrianHB, you wanted to ask if there are other ways to get the data?
15:44:37 [Ian]: AdrianHB: Are there other ways to get the data?
15:44:47 [Ian]: ..its sounds to me like this use case is potentially payment method specific.
15:45:08 [frank]: q+
15:45:11 [pascal_bazin]: q+
15:45:17 [Ian]: ..if you are using basic card but the line items are only appropriate for certain cases, you could provide data in payment method data
15:45:20 [Ian]: ack fr
15:45:36 [Ian]: Frank: Doesn't that complicate implementation? Easier if part of standard data set
15:45:43 [Ian]: AdrianHB: Yes, it would.
15:46:22 [frank]: q+
15:47:04 [Ian]: Adrian: One idea is for merchant to say "don't pass on"; so browser displays but does not pass on to the payment app
15:47:21 [Ian]: ...and this could be done on a payment method specific data
15:47:26 [Ian]: ...payment details only passed to selected payment apps
15:47:43 [Ian]: ...so merchants pass on only for payment methods where they think payment apps need the data.
15:47:58 [Ian]: IJ: That puts control in merchants' hands rather than users'
15:47:59 [Ian]: ack pas
15:48:12 [Ian]: pascal_bazin: We have to remember that at least shipping option is included
15:48:27 [Ian]: ..it's potentially always sent to the payment app
15:48:30 [Ian]: ack frank
15:48:48 [Ian]: frank: If the main concern is privacy, sharing this with the browser isn't that as bad as sharing with actual payment providers?
15:49:08 [frank]: Fair enough
15:49:23 [alyver]: q+
15:49:45 [Ian]: ack alylver
15:50:17 [Ian]: alyver: +1 to AdrianHB's idea of a merchant being able to control whether line items are passed on to the payment app
15:50:54 [adamR]: q+
15:51:04 [Ian]: ack ly
15:51:05 [Ian]: ack ad
15:51:08 [Ian]: ack aly
15:51:21 [Ian]: adamR: I would hesitate for this to be part of payment method specific data
15:51:28 [Ian]: ...if it's a flag that the merchant controls, I think this should be top-level
15:51:31 [AdrianHB]: +1
15:51:34 [frank]: +1
15:51:38 [pascal_bazin]: q+
15:51:40 [rouslan]: +0
15:51:42 [Ian]: ack pas
15:51:52 [alyver]: +1
15:52:40 [Ian]: IJ: Note that this is different from merchant not providing data at all, since browser does display line items in native chrome. This is just about not handing data to (1) all apps and (2) thus only selected app
15:52:42 [Ian]: q?
15:53:17 [Ian]: IJ: How is google currently managing this for native app integration?
15:53:42 [Ian]: rouslan: We are sending line items to native payment apps
15:54:06 [Ian]: ...haven't really heard any feedback. I'm open to changing this.
15:54:49 [Ian]: IJ: Should we address this with Pull request on PR API?
15:54:58 [AdrianHB]: +1 - maybe an issue first
15:55:09 [alyver]: Shopify officially providing feedback to Rouslan: As a default, we do not want to share line items to downstream payment apps.
15:55:37 [rouslan]: alyver: ack
15:55:53 [Ian]: ACTION: AdrianHB to raise PR API issue for discussion in the WG
15:56:09 [Ian]: https://github.com/w3c/webpayments-payment-apps-api/issues/91
15:57:28 [Ian]: Topic: Filters
15:57:34 [Ian]: IJ: Rouslan had some updates to do and talk to MS
15:57:40 [Ian]: Rouslan: We pinged MS; they have not yet replied.
15:58:03 [Ian]: ..in general there are mixed feelings about this particular change regarding addition of a filters field. We'd still prefer a data field
15:59:01 [Ian]: ...I understand that filters is a clean API...we trust Mozilla's idea. But the backwards compatibility is an issue. If MS does not implement "filters" as a key, there is less motivation
15:59:06 [Ian]: Topic: Next meeting
15:59:11 [Ian]: 7 Feb
15:59:36 [Ian]: IJ: Ideally we have an updated spec by 16 March
15:59:53 [Ian]: Topic: Spec title
15:59:57 [Ian]: Proposed: Payment Handler API
16:00:03 [adamR]: I support this change.
16:00:03 [rouslan]: +1
16:00:24 [Ian]: +1 from me
16:00:29 [Ian]: IJ: Any objections?
16:00:32 [AdrianHB]: +1
16:00:40 [Ian]: (Let's give people one week then we'll resolve this.)
16:00:46 [Ian]: RRSAGENT, make minutes
16:00:46 [RRSAgent]: I have made the request to generate http://www.w3.org/2017/02/28-apps-minutes.html Ian
16:00:52 [Ian]: RRSAgent, set logs public
17:26:22 [adamR]: adamR has joined #apps