13:52:57 RRSAgent has joined #apps 13:52:57 logging to http://www.w3.org/2017/03/07-apps-irc 14:41:13 Max has joined #apps 14:58:22 jnormore has joined #apps 15:01:41 Meeting: Payment Apps Task Force 15:01:43 Chair: Ian 15:01:56 agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017Mar/0020.html 15:02:01 present+ 15:02:04 present+ Jason 15:02:06 present+ 15:02:08 ConorhWP has joined #apps 15:02:30 present+ AdrianHB 15:02:45 rouslan has joined #apps 15:03:16 present+ Mathieu 15:03:29 present+ 15:03:34 Present+ 15:03:46 mathp has joined #apps 15:03:51 regrets+ Pascal 15:04:11 topic: Updating the spec 15:04:25 https://github.com/w3c/webpayments-payment-apps-api/wiki/Proposal-20170130 15:04:33 agenda+ Pascal's code 15:05:21 * Change the title (Payment Handler API) 15:05:21 * Update the model description per the Proposal 15:05:21 * Move explanatory information to an appendix 15:05:21 * Add code samples 15:05:22 https://github.com/w3c/webpayments-payment-apps-api/blob/gh-pages/proposals/examples.md 15:05:23 * AdamR to flesh out his proposal per 28 Feb discussion 15:05:24 https://www.w3.org/2017/02/28-apps-minutes#item02 15:07:45 adamR: I wasn't able to update the proposal last week due to IETF deadlines; that's likely to continue to next week. 15:07:52 ...so that's ok if you move a lot of things around during that period. 15:08:00 ..part of what I wanted to do with my edits is add in examples. 15:08:04 ...from pascal's document 15:08:15 ...I already borrowed IDL...will include exmaples 15:08:38 s/pascal's/marcos'/ 15:09:32 ...I thank we will have incorporated most of what Marcos has provided...I also think that Marcos created that document to demonstrate some code and my understanding is that once I've taken the info into account, he won't develop that document further 15:09:43 present+ Max 15:09:56 present+ Ken 15:10:12 adamR: When you are done with the big structural moves, if you can tag me let me know. 15:10:21 Ken has joined #apps 15:10:58 agenda+ filtering update 15:11:51 topic: issue 91 15:11:58 Discussion of AHB's proposal: 15:11:58 https://github.com/w3c/webpayments-payment-apps-api/issues/91#issuecomment-283111711 15:11:58 is on the WG agenda this week: 15:11:58 https://github.com/w3c/webpayments/wiki/Agenda-20170309 15:12:54 q+ 15:13:10 IJ: Anyone want to add to the GitHub issue in favor of sharing line items? 15:13:12 ack AdrianHB 15:14:25 q+ to ask Adrian a clarifying question 15:14:26 AdrianHB: Line items in payment request are not the things that you buy 15:14:34 ..they are typically things like subtotal, tax, total 15:14:43 ...so if a payment app wants full details about what is being purchased, 15:14:50 ..that can be a payment method specific piece of data. 15:14:56 ...I think that that's where we are headed on that issue. 15:15:54 ack ad 15:15:54 adamR, you wanted to ask Adrian a clarifying question 15:16:23 adamR: Adrian, regarding the method you described passing through does that that imply redundancy of information passed through the top level? 15:16:43 AdrianHB: My proposal is that there's a flag in PR API...and if you want to pass line items to payment apps you would set the flag. 15:16:55 ...zach's point is that we don't expect merchants to use line items to list products 15:17:52 ...if there are no use cases for getting "total", "tax" etc. then we can drop the proposal, otherwise if there are use cases (which Klarna's is not an example of), then the proposal can stand 15:18:34 IJ: Privacy issue goes away if the line items are just used for tax and total information 15:19:15 q+ 15:19:30 AdrianHB: The breakdown was to show a change in total based on user actoins 15:19:33 ack Ada 15:19:58 AdamR: I understand the use case and the google use case, but I suspect that developers will use the line items for other purposes. 15:20:48 q+ 15:21:13 AdamR: The number of web developers who read specs for good practice is close to zero 15:21:20 ack AdrianHB 15:21:58 AdrianHB: I think the only way we will address the concern from AdamR is to change the API to be less flexible. 15:22:07 ...I also think that Google limits the number of things you can send through the API 15:22:10 ..due to UI consideratinos 15:22:27 q+ 15:22:30 ..the spec should not hard-code a limit, but I believe there is one 15:22:33 ack rous 15:22:46 rouslan: We don't currently enforce a limit (we use scroll bars) 15:23:02 ..we'll probably send a PR on the spec soon that says you can provide something like 50 shipping options and 50 line items 15:23:05 ...for security reasons 15:23:46 agenda? 15:23:55 zakim, take up item 1 15:23:55 agendum 1. "Rename the spec" taken up [from Ian] 15:23:59 If the intent is explicitly to not show shopping cart items then we should limit to 5 15:24:08 Proposal: Payment Handler API for the title 15:24:17 +1 15:24:21 +1 15:24:22 +1 15:24:24 +1 15:24:28 zakim, close this item 15:24:28 agendum 1 closed 15:24:29 I see 2 items remaining on the agenda; the next one is 15:24:29 2. Pascal's code [from Ian] 15:24:33 zakim, take up item 2 15:24:33 agendum 2. "Pascal's code" taken up [from Ian] 15:24:41 https://github.com/w3c/webpayments-payment-apps-api/blob/gh-pages/proposals/examples.md 15:25:21 IJ: Has anybody had a look? What is relationship to Marcos' code? 15:25:51 AdamR: This is input to drive the API; the examples in the spec are meant to explain the API. 15:26:30 q+ 15:26:32 ack AdrianHB 15:26:49 AdrianHB: One thing immediately useful from the code samples is that if you don't have time to read the whole spec, 15:27:34 ...I see the first example and say "Is our intent to get permission by calling options.set?" Is it implicit? Or do we want an explicit function to get permissions? 15:27:42 adamR: I think we had an open issue on this. 15:28:09 https://github.com/w3c/webpayments-payment-apps-api/issues/94 15:28:32 https://github.com/w3c/webpayments-payment-apps-api/issues/94#issuecomment-275600989 15:28:37 https://github.com/w3c/webpayments-payment-apps-api/issues/94#issuecomment-275618212 15:28:50 AdrianHB: that example shows an explicit permissions call 15:28:58 ...asking for 'payments' permission 15:29:09 AdamR: yes, this can be incorporated. 15:30:07 AdrianHB: I suggest we respond on the issue and try to get a general approach 15:30:19 AdamR: I am confident in Marcos and Jake here 15:30:35 ...if we want further validation, let's find another person who is familiar with how web apps ask for permissions. 15:32:35 IJ: Is PaymentManager more clearly captured in the new text (from Adam)? 15:33:59 AdamR: there is a page on the payment app's web site that installs the payment app...that's not the service worker 15:34:59 AdamR: there is a thing on the service worker registration that is where we are setting things like supported payment methods 15:35:17 ...but I think this is something else (on window) 15:35:55 zakim, close item 2 15:35:55 agendum 2, Pascal's code, closed 15:35:56 I see 1 item remaining on the agenda: 15:35:56 3. filtering update [from Ian] 15:35:58 zakim, take up item 3 15:35:58 agendum 3. "filtering update" taken up [from Ian] 15:37:41 q+ 15:37:42 - Filtering mostly for w3c (abstraction) specs 15:37:50 ack AdrianHB 15:37:54 AdrianHB: I disagree with that. 15:38:12 ..the whole point of the filtering is that new payment methods can be introduced that have their own unique filters 15:40:04 I said it last Thursday, but for the record, I disagree with Zach’s characterizatin here. If Chrome wants to do things that way, it’s fine, but I don’t think it should be required of all browsers. 15:40:33 And this is particularly distressing when you consider, e.g., Safari, which comes out every 18 to 24 months. 15:41:23 ian: we want to be able to support filters for 3rd party payment apps 15:41:32 - payment handler api needs a stnadard way to provide capability information 15:42:29 https://w3c.github.io/browser-payment-api/#show-method 15:42:37 For each paymentMethod in request.[[serializedMethodData]]: 15:42:37 Consult the appropriate payment apps to see if they support any of the payment method identifiers given by the first element of the paymentMethod tuple, passing along the data string given by the second element of the tuple in order to help them determine their support. 15:43:38 q+ 15:43:52 IJ: I proposed a more neutral framing to make it possible that browsers do the matching 15:45:29 ack adr 15:46:30 AdrianHB: Let's get a resolution rather than a neutral stance 15:47:39 IJ: We got again into the security issues 15:47:50 I distinguished two things: 15:48:12 * Unconstrained string syntax 15:48:23 * Unlimited list length 15:48:44 IJ: Nick-TR pointed out that generic string matching would also resolve an issue around the ability of networks to get included on the hard-coded network list 15:49:41 https://www.w3.org/Payments/card-network-ids 15:49:59 1) We need to clarify the process for accepting new identifiers. (e.g.,a simple anti-spam verificatino) 15:50:08 2) A disclaimer that appearance in the list is not a guarantee of interoperability across browsers. 15:50:41 Sounds like this boils down to: Is there a strong enough case for a hard coded list (enumeration) or can we have a more flexible (but still constrained) list? 15:50:53 q+ 15:51:15 For the record I would be a big +1 to doing away with the networks list if we can 15:52:25 IJ: Can we basically say (1) here's how you provide capabilities from a payment app and (2) here's in PR Api where that's taken into account, and leave it at that? 15:52:28 ack Ada 15:52:56 adamR: I'm not sure I followed that...we need to think about these things from the POV of browsers that are released less frequently, such as every 18 months. 15:53:18 ...so a network list that is only infrequently updated in a browser is a problem. 15:53:45 ...I also would like there to be an authoritative list of network strings (to avoid e.g., amex v. americanexpress confusion). 15:54:21 To be clear, having a list that helps avoid confusion and conflicts is fine but that's different to a list that has a gatekeeper to be added 15:54:50 AdamR: We also don't want duplicates 15:55:17 ...so ok with WG having lightweight approval process and indicating browser support is independent 15:55:18 q? 15:55:40 -1 to "lightweight approval process" 15:56:06 AdrianHB: I don't think there needs to be "approval". I think you can avoid duplicates without an approval process. 15:56:33 ....an approval process is dangerous 16:00:33 I won't interrupt - I need to drop off now. Thanks all, goodbye. 16:03:46 Topic: next meeting 16:03:49 14 March 16:05:28 RRSAGent, bye 16:05:31 RRSAgent, make minutes 16:05:31 I have made the request to generate http://www.w3.org/2017/03/07-apps-minutes.html Ian 16:05:36 RRSAgent, set logs public