15:00:16 RRSAgent has joined #wpwg 15:00:16 logging to http://www.w3.org/2017/02/02-wpwg-irc 15:00:18 RRSAgent, make logs public 15:00:18 Zakim has joined #wpwg 15:00:20 Zakim, this will be 15:00:20 I don't understand 'this will be', trackbot 15:00:21 Meeting: Web Payments Working Group Teleconference 15:00:21 Date: 02 February 2017 15:00:29 alyver has joined #wpwg 15:00:36 present+ AdrianHB 15:00:38 betehess has joined #wpwg 15:01:26 mathp has joined #wpwg 15:02:44 Meeting: WPWG Teleconf 15:02:59 Agenda: https://github.com/w3c/webpayments/wiki/Agenda-20170202 15:03:01 present+ alyver 15:03:04 Ian has changed the topic to: 2 Feb agenda => https://github.com/w3c/webpayments/wiki/Agenda-20170202 15:03:11 Chair: AdrianHB 15:03:13 Scribe: Ian 15:03:36 zkoch has joined #wpwg 15:03:39 present+ zkoch 15:03:41 present+ oyiptong 15:04:03 present+ 15:04:07 zakim, agenda? 15:04:07 I see nothing on the agenda 15:04:08 present+ 15:04:12 zakim, who's on the call? 15:04:12 Present: AdrianHB, alyver, zkoch, oyiptong, Ian, adamR 15:04:24 present+ Alan 15:04:26 present+ Mathieu 15:04:32 rouslan has joined #wpwg 15:04:34 AlanMarshallSamsung has joined #wpwg 15:04:47 present+ 15:05:14 regrets+ DavidE 15:05:24 I think an update would be nice 15:06:04 Topic: PMIs 15:06:25 AdrianHB: Please move discussion to next week 15:06:41 topic: Payment method manifest 15:06:58 IJ: Max took an action to work with Zach to put together a plan for advancing this specification. 15:07:02 ...any progress? 15:07:11 zkoch: Max and I will speak this week 15:07:39 ...let's return to this in a week 15:09:36 Topic: Back to PMI 15:09:43 === 15:09:46 In section on Syntax: 15:09:46

When URLs are used for payment method identifiers they MUST be absolute URLs including only the schema, authority, and path parts.

15:09:46 In section on manifest fetching: 15:09:46

Publishers of payment method manifests must make them available in a secure manner. This may involve, for example, identifying them with 15:09:47 HTTPS URLs and user agents fetching them using secure protocols.

15:09:50 In section on matching: 15:09:52

When matching, user agents must ignore any URLs that include query string parameters or fragment identifiers.

15:09:55 === 15:10:37 vkuntz has joined #wpwg 15:10:42 present+ 15:10:51 right, these seem fine to me 15:10:52 Relevant to this conversation: https://www.w3.org/TR/secure-contexts/#is-origin-trustworthy 15:11:14 topic: HTTP Link Headers 15:11:38 Ian: Samsung to let us know today if they are ok closing issue 19 with support for HTTP Link headers. 15:11:43 Ian: You may want to look at that (and section 3.3 of that same document) before completeing text to satisfy AdrianHB’s request 15:11:53 (AdrianHB ^^^^^^) 15:11:57 Ian: And I would recommend citing it as well 15:12:01 (AdrianHB ^^^^^^) 15:12:24 Alan: Regarding payment method manifest file, we support the structure of the file 15:13:36 present+ ShaneM 15:13:58 Alan: Ok to use HTTP Link headers to get from payment method identifier to payment method manifest file 15:14:12 PROPOSE: Close issue 19 with solution of HTTP Link headers 15:14:13 +1 15:14:21 \o/ 15:14:23 +1 15:14:36 ACTION: Ian to close issue 19 with solution of HTTP Link Header 15:14:36 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., ijacobs, ijmad). 15:15:23 https://w3c.github.io/webpayments-method-identifiers/ 15:16:24 MaheshK has joined #wpwg 15:16:44 IJ: What is the right home for mention of HTTP Link headers? 15:16:47 a) PMI spec 15:16:52 b) Payment method manifest spec 15:16:58 probably b 15:17:02 +1 to b 15:17:03 Me too: b 15:17:08 +1 to b 15:17:13 such consensus. amaze. 15:17:39 q+ to clarify final resolution 15:18:07 ACTION: Zkoch to include mention of HTTP Linkers for addressing payment manifest files (in that spec) 15:18:07 Created ACTION-49 - Include mention of http linkers for addressing payment manifest files (in that spec) [on Zach Koch - due 2017-02-09]. 15:18:13 ack AdrianHB 15:18:13 AdrianHB, you wanted to clarify final resolution 15:18:32 adrianhb: We are saying that in the payment method manifest spec, we will define a mechanism for discovering the manifest file. 15:18:45 that is my understanding 15:18:53 ...the algorithm will involve doing a HEAD given the PMI, and there will be a rel value pointing to the manifest. 15:19:15 IJ: I assume that once we define the rel value we will register it with IANA 15:19:39 +1 to not defining 15:19:59 IJ: We also need to change this in PMI spec: 15:20:07 "When the party responsible for a payment method wishes to publish machine-readable information associated with the payment method, it does so with a URL. " 15:20:15 Yes. I think we should just reference the other spe 15:20:16 c 15:20:44 IJ: I think PMI sets an expectation about how the method lives in the ecosystem, and we'll define the mechanism separately 15:21:01 Sounds like Adrian is volunteering to submit a PR with that phrase 15:21:04 :) 15:21:09 AdrianHB: So PMI says "The PMI can be used to discover machine readable information, which is defined elsewhere." 15:21:43 Action: AdrianHB to do a pull request to tweak intro to section 3 of PMI spec to clarify how PMI is used 15:21:43 Created ACTION-50 - Do a pull request to tweak intro to section 3 of pmi spec to clarify how pmi is used [on Adrian Hope-Bailie - due 2017-02-09]. 15:22:23 topic: Test suite check-in 15:23:02 Shane: No update to report 15:23:48 topic: Payment App update 15:24:15 q+ to mention address collection and filtering 15:24:17 adrianhb: There's been a lot discussion in the payment app task force (including via GitHub) 15:24:31 I’ve been watching the threads -> http://i.imgur.com/5s4kkZ1.gif 15:24:45 ...some of the topics relate to long ago decisions 15:25:03 ...one includes where filtering happens: in the browser or payment app 15:26:05 [Adrian summarizes filtering discussion] 15:26:09 q+ 15:26:27 Context on this topic: https://github.com/w3c/webpayments-payment-apps-api/issues/96 15:26:32 AdrianHB: Some discussion of "configuration-based approach" where the payment app declares to the browser what it can do, and then the browser does the filtering 15:27:35 https://github.com/w3c/webpayments-payment-apps-api/issues/96#issuecomment-276416457 15:27:44 AdamR: Regarding filtering, see my proposal ^^^^^ 15:28:14 q+ 15:28:25 (See also Rouslan's follow-up: https://github.com/w3c/webpayments-payment-apps-api/issues/96#issuecomment-276423629) 15:28:45 ack ad 15:28:45 adamR, you wanted to mention address collection and filtering 15:29:07 betehess has joined #wpwg 15:29:15 AdamR: I want to highlight one piece related to PR API - if we go down the configuration-based approach, we need to determine which fields in the payment request are intended to be used for filters 15:29:26 ...my proposal was to move filters into a new "filters" structure 15:29:36 ...Rouslan has an alternative proposal (that IMO is more fragile) 15:29:48 ...Rouslan's proposal preserves backwards compatibility 15:29:55 ack rous 15:30:16 rouslan: I think the API is not functionally frozen. But I feel that adding more parameters to the API is cumbersome 15:30:41 q+ 15:30:44 ...the point of my proposal was to consider "data items that are lists of strings" are considered filters 15:30:48 q+ to reply to rouslan 15:31:27 rouslan: I did not intend to say "if a payment app does not match all the filters then show it"....I agree instead with Adam's approach 15:31:32 ack Ad 15:31:32 adamR, you wanted to reply to rouslan 15:31:56 adamR: The major concern I have with deducing that arrays of strings are filters....that prevents other payment methods from using arrays of strings 15:32:10 ...so I prefer to mark filters clearly in some way 15:32:12 ack zk 15:32:53 zkoch: the idea of a separate filter type came up previous....my recollection was that filters were limited to basic cards 15:32:56 IJ: That is no longer true 15:33:05 zkoch: each payment method spec defines filters 15:33:06 IJ: Yes 15:33:49 q+ to talk about not having to wait for browsers to implement something new for each new payment method 15:33:57 IJ: There are now 2 more PM specs that would use filters 15:34:52 ... we have some simple cases where the computation of the intersection of sets of strings would solve the use case 15:35:33 ... we had been taking an approach of the apps doing the work but we couldn't find a solution without privacy implications or network delays 15:36:14 ... we proposed the app would provide a lambda to the browser but this proved to have implementation challenges 15:36:26 ... we should continue discussion in the TF 15:36:30 q? 15:36:46 ... TF is not in consensus yet 15:37:33 zkoch: are filters only from those defined in known specs? 15:37:46 I can see a payment method of “cryptocurrency” and a filter of “network: [‘bitcoin’,’dogecoin’]” 15:37:50 ij: we could define a generic mechanism 15:38:07 https://github.com/w3c/webpayments-payment-apps-api/issues/96#issuecomment-276416457 15:38:13 zkoch: the goal is not requiring UA changes for new PMs that have filtering reqs 15:38:18 ij: yes 15:38:39 zkoch: q for me is how valuable this feature is 15:38:56 or “targetcreditcard” and “type: [‘red’,’gold’]” 15:39:00 ij: we increase likelihood of rich ecosystem if apps do less 15:39:05 q? 15:39:08 ack adamR 15:39:08 adamR, you wanted to talk about not having to wait for browsers to implement something new for each new payment method 15:39:29 adamR: We don't want to have to update browsers for each new payment method 15:39:48 ...i think that we are likely to have closed payment methods where they may want some filtering 15:39:51 ..but not published by W3C 15:40:26 zkoch: I do think that there's a solid argument to be made that we might not support payment methods without client changes 15:40:39 q+ 15:41:06 Got it! 15:41:13 ij: we're moving the canMakePayment logic from app to browser 15:41:19 ack ada 15:41:38 adamR: If you want to have a more curated experience in the browser, this does not preclude that. Browsers can still whitelist payment methods 15:41:43 ack me 15:41:47 https://github.com/w3c/webpayments-payment-apps-api/wiki/Proposal-20170130 15:42:52 IJ: proposal not yet updated based on TF discussion on tues. 15:43:08 ... this is a synthesis of some extensive discussion last few weeks 15:43:27 ... process is to work through this within TF and come up with proposals to address 15:43:46 Topic: Meetings 15:43:55 Next call: 9 Feb 15:44:05 FTF: 15:44:11 - Confirmed IG meeting on 22 March 15:44:29 https://www.w3.org/Payments/IG/wiki/Main_Page/FTF_Mar2017 15:44:38 - 22 March improv show 15:44:56 - Thank Zach for enabling us to meet!! 15:45:14 - Dinner on 23 March at local french 15:45:32 https://github.com/w3c/webpayments/wiki/FTF-March2017 15:46:25 Currently about 25; I expect to hit 35...please register 15:46:30 AdrianHB: On the agenda: 15:46:39 https://github.com/w3c/webpayments/wiki/FTF-March2017#agenda-notes 15:46:49 AdrianHB: What are our goals for the call? 15:47:06 ...it's easiest perhaps to speak in terms of deliverables and milestones 15:47:25 ...so I would like to get to a place where we are confident that PR API is ready for CR, and payment app api is ready for FPWD 15:47:42 IJ: Similarly credit transfer and tokenization to FPWD (headed to Notes) 15:47:52 AdrianHB: What about PMI? (to CR?) 15:48:25 AdrianHB: Regarding payment method manifest, PR API depends on it, so we want that to move forward soon 15:48:45 ....I'd like to see payment request API and PMI + Manifest to advance together. 15:49:04 seems reasonable 15:50:10 zkoch: +1 to trying to achieve the above 15:50:21 Really just...achieve 15:50:56 AdrianHB: So editors should come back to us with issues that we need to resolve (either before or during FTF) 15:51:33 adamR: The only thing I would throw in there....we should not freeze payment request API until we are comfortable with the basic shape of the payment app API 15:52:49 IJ: CR means "please implement to learn more....and possibly change the spec" 15:53:03 No more learn. Just achieve. 15:53:11 let's get T-shirts 15:53:20 Chicago 2017: No more learn. Just Achieve 15:53:38 RRSAgent, make minutes 15:53:38 I have made the request to generate http://www.w3.org/2017/02/02-wpwg-minutes.html Ian 15:53:44 RRSagent, set logs public 15:53:52 bye 15:56:13 alyver has joined #wpwg 16:03:24 alyver has joined #wpwg 16:27:36 alyver has joined #wpwg 16:29:14 alyver has joined #wpwg 16:35:05 alyver has joined #wpwg 16:46:32 alyver has joined #wpwg 17:00:41 alyver has joined #wpwg 17:33:07 alyver has joined #wpwg 17:52:07 sam has joined #wpwg 17:55:07 alyver has joined #wpwg 18:02:31 Zakim has left #wpwg 18:05:19 RRSAgent, bye 18:05:19 I see 3 open action items saved in http://www.w3.org/2017/02/02-wpwg-actions.rdf : 18:05:19 ACTION: Ian to close issue 19 with solution of HTTP Link Header [1] 18:05:19 recorded in http://www.w3.org/2017/02/02-wpwg-irc#T15-14-36 18:05:19 ACTION: Zkoch to include mention of HTTP Linkers for addressing payment manifest files (in that spec) [2] 18:05:19 recorded in http://www.w3.org/2017/02/02-wpwg-irc#T15-18-07 18:05:19 ACTION: AdrianHB to do a pull request to tweak intro to section 3 of PMI spec to clarify how PMI is used [3] 18:05:19 recorded in http://www.w3.org/2017/02/02-wpwg-irc#T15-21-43