15:00:04 RRSAgent has joined #wpwg 15:00:04 logging to http://www.w3.org/2016/11/17-wpwg-irc 15:00:06 RRSAgent, make logs public 15:00:06 Zakim has joined #wpwg 15:00:08 Zakim, this will be 15:00:08 I don't understand 'this will be', trackbot 15:00:09 Meeting: Web Payments Working Group Teleconference 15:00:09 Date: 17 November 2016 15:00:16 MikeSmith has joined #wpwg 15:00:31 agenda: https://github.com/w3c/webpayments/wiki/Agenda-20161117 15:00:54 present+ alyver 15:00:57 Chair: Nick 15:00:59 Scribe: Ian 15:01:07 present+ Rouslan 15:01:13 present+ nicktr 15:01:17 MaheshK has joined #wpwg 15:01:33 present+ stan 15:01:34 present+ Ian 15:01:41 present+ 15:01:44 zakim, who's here? 15:01:44 Present: alyver, Rouslan, nicktr, stan, Ian, MikeSmith 15:01:46 On IRC I see MaheshK, MikeSmith, Zakim, RRSAgent, alyver, rouslan, mbu, stan, jenan, Adam_, Max, collier-matthew, hyojin, ShaneM, trackbot, Ian, schuki, dlehn, JakeA, emschwartz, 15:01:46 ... nicktr, AdrianHB, mkwst, adrianba, Dongwoo, davidillsley_, slightlyoff, dlongley, manu 15:01:48 present+ 15:01:55 present+ Mahesh 15:01:57 present+ Max 15:02:05 present+ BenSmith 15:02:20 regrets+ AdrianHB 15:02:32 nicktr has changed the topic to: Conference Call 17th November 2016 -> https://github.com/w3c/webpayments/wiki/Agenda-20161117 15:03:09 present+ dlongley 15:04:26 Present+ AdrianHb (IRC only) 15:04:36 present+ Manu 15:04:39 zkoch has joined #wpwg 15:04:46 betehess has joined #wpwg 15:04:53 agenda -> https://github.com/w3c/webpayments/wiki/Agenda-20161117 15:04:58 Agenda: https://github.com/w3c/webpayments/wiki/Agenda-20161117 15:05:02 topic: Status of pull request about Detecting Payment Method Availability 15:05:10 https://github.com/zkoch/zkoch.github.io/blob/master/pr-detect-avail.md 15:05:15 see pull request https://github.com/w3c/browser-payment-api/pull/316 15:05:31 present+ Zach 15:06:04 zkoch: I think that Mahesh put in a pull request for review 15:06:13 q+ 15:06:26 ack rou 15:06:27 q+ to comment 15:06:50 rouslan: I looked at the pull request which looks great. We already have a patch that does what the pull request describes. 15:06:53 q+ 15:07:02 ...the discussion on the patch so far seems to involve some naming choices 15:07:05 q+ 15:07:13 ...should we call it canMakePayment or canMakeActivePayment? 15:07:28 ...also some questions about formatting HTML (but I don't think hat's critical path for the issue) 15:07:43 ...there's also been some questions about throttling, but i think I've resolved those without requiring changes to the PR 15:07:48 ben_ has joined #wpwg 15:07:50 ack Mike 15:07:50 MikeSmith, you wanted to comment 15:07:52 ack MikeSmith 15:08:41 MikeSmith: MarcosC has been doing a careful review of the PR API spec; today he spent a lot of time looking at the PR in question 15:08:50 ..it looks like good progress on this. 15:09:07 q+ 15:09:13 ...the one thing i'd say is that, given the maturity of the rest of the spec, what we probably want to do here is get as much browser implementer feedback as we can so we can move this forward. 15:09:26 ...I have not been on the last few WG calls where this has been discussed 15:09:30 ...where does Microsoft stand on this PR? 15:09:50 ...and it would be good to get Nick Shearer's view on this. 15:10:09 ...along with the PR, the Chrome team wants to get this implemented and shipped in Chrome 15:10:30 ...so I hope that more folks will do a detailed review to give feedback to the editors 15:10:57 ...by the way, this call time is suboptimal for Marcos but he's been active in GitHub 15:11:24 nickTR: Previously we have not gotten traction for a second call in a more favorable time zone 15:11:34 q? 15:11:39 ack mahesh 15:12:02 ack Mah 15:12:18 MaheshK: I just went through the PR and the good comments from Rouslan and Marcos 15:12:26 ...I agree with most of the comments from Rouslan 15:12:34 ...I will also look at the patch 15:13:03 ...thanks to Marcos 15:13:03 ;; 15:13:08 q? 15:13:09 ...I will update the pull request 15:13:12 ack jenan 15:13:14 ack jenan 15:13:50 jenan: The square space example was from me...I think that the issue is that shared origin pages would run into trouble if they want to share different payment methods potentially from different merchants 15:14:00 ...squarespace is an example where all merchants share the same domain 15:14:10 ..the proposal was to query ahead of time from the merchant pass and pass that along 15:14:22 ..I think that's viable but klunky for a case like squarespace 15:14:30 q+ 15:14:40 ..but it doesn't work if you can't make a decision about what you want to present before the hosted page, or if you can't run code at all 15:14:51 mbu has joined #wpwg 15:14:51 ..imagine a hosted page where merchants aren't running code from the host payment page ahead of time 15:14:58 ...how do people think about addressing this case. 15:15:13 ...and I also have a question - how are we thinking about what 'active" means? 15:15:25 ..with apple pay and the web, if they have a card in the wallet ... 15:15:41 ..but with a number of payment methods for PR API you will have both "just in time" registration and non just-in time 15:15:48 q? 15:15:49 i left some comments on the use of "active" here: https://github.com/w3c/browser-payment-api/issues/310#issuecomment-261130645 15:15:50 ..is that a component of this PR or has this been considered already? 15:15:58 nicktr: Good questions! 15:16:15 q? 15:16:18 ..the point you make about shared top-level domain had not occurred to me previously, but it will affect a number of hosted page offerings 15:16:20 ack rouslan 15:16:36 rouslan: I think that the word "active" is the best we've got in the function name 15:16:53 ...it means that "even if the payment app has just in time registration, the user already has done the registration of their profile information into the app" 15:17:01 ...so the user would not be taken through that flow 15:17:07 `pr.requiresRegistration()` 15:17:23 ...merchants want to know for sure whether they will be taken through the flow (of browser or payment app) or whether they will be able to click and pay quickly. 15:17:36 ...regarding shared origin - I think it's not as scary as people think 15:17:42 ..note that the throttling is done on the user side 15:18:07 ...so for example, two users using two user agents will not impact one another 15:18:16 ...we are trying to prevent polling on the same user 15:18:24 ..we are thinking of resetting the quota in 30 minutes 15:18:43 ...and only for users that are making purchases on your site 15:18:56 ...regardless, my opinion is that we should put this in the hands of merchants to play with and see what feedback they give 15:19:07 ..our stance at Chrome is that this PR looks good as-is and we are good to ship it. 15:19:28 ...we'd love to hear from Microsoft and Mozilla implementers hear about this 15:19:43 q+ to say that if this API is about checking to see if a payment request requires some kind of registration to complete, the name should reflect that 15:19:53 ack zkoch 15:19:55 q+ to mention that this approach doesn't prevent crawling payment instruments, which was its intent. A privacy review would show a privacy violation for a concerted attacker. 15:20:27 zkoch: I think for shared merchants / retailers there are limitations. 15:20:40 ...some people want to do specific buttons; others want show/throw 15:20:44 ...we are looking for balance 15:20:55 ..this request has come up numerous times 15:21:20 ...I think the square space scenarios is overblown ... user hopping from square space site to square space site with different payment methods 15:21:29 ....I think feedback will be useful from merchants 15:21:32 ack dlongley 15:21:32 dlongley, you wanted to say that if this API is about checking to see if a payment request requires some kind of registration to complete, the name should reflect that 15:22:01 dlongley: What is the reason again for this call? 15:22:28 present+ ShaneM 15:22:38 q? 15:22:43 ...I don't think the name is clear; I wouldn't know as a merchant why to call this. I think we need to be clearer on that. 15:22:56 ..since the method is attached to a payment request since payment requests don't make payments 15:22:59 q+ 15:23:26 dlongley: isPaymentMethodConfigured? isUserReady? see other github comments 15:23:35 https://github.com/w3c/browser-payment-api/issues/310#issuecomment-261130645 15:23:39 requiresRegistration 15:23:45 ack manu 15:23:45 manu, you wanted to mention that this approach doesn't prevent crawling payment instruments, which was its intent. A privacy review would show a privacy violation for a concerted 15:23:48 ... attacker. 15:23:49 ack manu 15:24:03 Manu: I am fine with the way things are proceeding; want to keep an eye on privacy concerns 15:24:39 q+ 15:24:40 ...we are not really protecting privacy 15:25:02 ...for a concerted party that wants to profile you, if you spend a lot of time on their site, over several days they can find out whether you are using common payment methods 15:25:14 ..while i appreciate the length people are going to to protect privacy, but I think we are failing to do that 15:25:17 q? 15:25:31 ack zkoch 15:25:51 zkoch: I don't think you are missing anything. I think that over long-term sustained use, someone who was motivated to find out something could do so. 15:26:13 ...some merchants are happy to use payment apps and PR API if they can guarantee that a payment method is immediately available. 15:26:23 ..they are not interested in using payment apps for backup flows 15:26:36 ..in the absence of metrics we need to find a balance 15:26:47 ...I don't see a good way to prevent attacks over a duration 15:27:11 ...my original proposal is to limit access "within reason" 15:27:16 q? 15:27:22 ..I think merchants also figure things out through transactions over time 15:27:39 rouslan: I agree that if a user spends hours on a site the site can learn a lot about the user (but that is true outside of payment request) 15:27:44 +1 to dlongley 15:27:51 ...utlimately it's up to the user agent to act in the user's interest 15:28:14 ...that's why we are clear in the proposal about how throttling works exactly. We don't know for sure if 30 minutes is the right amount 15:28:27 ..we might vary it if we think that there is abuse 15:28:39 ...we can also notify the user if we detect abuse 15:28:54 ..whatever we apply, I think it requires investigation...but the blocking action is needed for the function to exist 15:29:00 q? 15:29:04 ack rouslan 15:29:14 I'm happy to stay vague in the spec and have the browser vendors making sure this is safe for the user by experimenting. 15:29:37 +1 ... and it seems the current approach likely doesn't offer sufficient protection. 15:29:55 +1 to being okay with leaving the details outside of the spec. 15:30:11 q? 15:30:12 nicktr: Any mozilla or microsoft comments here? 15:30:19 we're still reviewing - we have some architectural challenges with the proposal 15:30:33 nicktr: So let's bring this topic back next week, after changes to pull request 15:30:47 q+ 15:30:49 maybe the call always returns false if the user isn't active on the tab ... much like video won't play if you're not looking at a tab in chrome these days. 15:30:54 ack zkoch 15:30:57 IJ: I am hearing the action is on mahesh to take comments into account 15:31:03 +1 on the action 15:31:06 zkoch: Yes, and I'll work with Mahesh. I would like to time-box this. 15:31:28 +1 on time boxing 15:31:41 ...I think that everyone (especially Mozilla, Microsoft) be prepared with all comments by 1 December call 15:31:55 dlongley: I'd prefer to resolve/reject the promise only when user is active instead. Then, if the user looks at the tab, the website can receive the response to their query at that time. 15:31:55 zakim, close this item 15:31:55 I do not know what agendum had been taken up, Ian 15:32:02 brb 15:32:04 topic: Pull request on Push Payments 15:32:19 rouslan: that could work 15:32:30 (Roy not hear so skipping) 15:32:39 topic: Basic Card 15:32:50 https://w3c.github.io/webpayments-methods-card/ 15:32:59 https://w3c.github.io/webpayments-methods-card/#request 15:34:01 q? 15:34:04 q+ 15:34:06 IJ: I hear there's an idea to reference a list of networks from the spec 15:34:10 ack rouslan 15:34:11 ...what's the status of that proposal 15:34:26 rouslan: I've not spoken with Zach yet....I think the best place for this list is in github 15:35:06 q+ 15:35:06 zkoch: I think it may be easiest in the spec rather than outside, but I don't feel strongly 15:35:12 ack rouslan 15:35:30 rouslan: I am in agreement with zkoch...I think the list should be in github so people can make pull requests and what should be added 15:35:41 ...so there's a new card network ("mir") that chrome plans to support. 15:35:44 mir == peace? 15:36:01 ..it would be great for devs at mir to make a pull request into a list 15:36:09 q+ 15:36:28 ..this list is not intended to be machine readable, so it might as well be hard coded in the spec. 15:36:52 q+ to mention alternatives that have worked at W3C... hand spec over to CG w/ W3C oversight for management. 15:36:59 (IJ clarifies that we can't update the spec easily) 15:37:06 rouslan: So let's have a separate list 15:37:06 ack me 15:37:07 ack nicktr 15:37:20 nicktr: I was going to say that there are often rules around who can have a bin 15:37:53 q+ 15:38:02 q? 15:38:48 ...I think we will get consumers and ourselves in a difficult place if we are not specific 15:38:55 IJ: We will be specific; question is "in" or "out" 15:39:00 q? 15:39:04 nicktr: My instinct is to keep inside the basic card spec 15:39:05 ack manu 15:39:05 manu, you wanted to mention alternatives that have worked at W3C... hand spec over to CG w/ W3C oversight for management. 15:39:16 -1 to maintenance outside of the PWWG 15:39:26 s/PWWG/WPWG 15:39:34 manu: we can have a CG that maintains the list 15:39:50 (IJ: Not sure why the WG would hand over the list to a CG while the WG exists) 15:40:08 manu: We can have someone at W3C (staff) update a spec in TR space based on CG consensus 15:41:01 q? 15:41:18 q+ 15:41:25 ack rous 15:41:46 betehess has joined #wpwg 15:41:53 rouslan: I have a question - I know that in some specs there are extension points...can we specify a base list in the spec and then some means to extend the list 15:42:21 Ian: I propose that we take this question offline, wanted to raise it given some initial feedback. 15:42:25 for information - this is useful -> https://www.bincodes.com/bin-list/ 15:43:07 Ian: I like that extension point proposal. At present, I don't like the idea of handing that list off to a CG while this WG is operating. 15:43:09 in particular note that only cards starting 4,5,6 are "financial" 15:43:21 To be clear, this WG would be in charge of the list until this group ceases to exist. 15:43:42 q? 15:43:44 (I intended that to be a part of my proposal) 15:43:47 ack Ian 15:44:17 Ian: I've been trying to get in touch with Kris Ketels wrt. naming and relevant card specs for ISO and alignment with those specs. 15:44:18 ACTION: Ian to work on a proposal around network list 15:44:18 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., ijacobs, ijmad). 15:44:44 topic: PMI 15:44:57 https://github.com/w3c/webpayments-method-identifiers/pull/16 15:45:17 https://github.com/w3c/webpayments-method-identifiers/pull/16 15:45:48 Ken has joined #wpwg 15:46:05 IJ: My gut says a bit more time on github for discussion 15:46:18 NickTR: What if AHB calls in to state them here then take to github? 15:46:45 QUESTION: Should PMIs that are URLs be limited to HTTPS? 15:47:07 AdrianHB: I think we need to say that manifests need to be retrieved securely, but I'm not excited to hard-code HTTPS 15:47:31 ..also fetching static resources with HTTPS would not be optimal from a performance perspective. 15:47:55 +1 to make it secure and note that HTTPs is ONE possible mechanism. 15:48:38 IJ: HTTPs requirement came up at the Lisbon discussion 15:48:57 QUESTION: What about sub resource integrity support? 15:49:26 ...that's difficult to do when all you have is a URL..but "ni" URL scheme could be used 15:49:36 q+ 15:49:42 +1, good point AdrianHB 15:50:03 ..so you could have a payment method identifier with "ni" that would map with an HTTPS URL, but that would be associated with a (numerical) hash 15:50:09 ...I suggest we continue on github 15:50:11 q? 15:50:29 https://tools.ietf.org/html/rfc6920 15:50:30 ack rouslan 15:50:37 ni:// spec - https://tools.ietf.org/html/rfc6920 15:51:12 AdrianHB's issue: https://github.com/w3c/webpayments-method-identifiers/issues/18 15:51:19 rouslan: concerns about slowing down due to dependencies 15:51:24 ...on specs that are not yet implemented 15:51:45 q? 15:52:27 adrianhb: The proposal is not to go off to implement another spec, it just is about the constraint on URLs as PMIs 15:52:42 https://github.com/w3c/webpayments-method-identifiers/issues/18 15:54:02 IJ: Can I update the spec with a link to the issue 17? 15:54:05 https://github.com/w3c/webpayments-method-identifiers/issues/17 15:54:10 +1 15:54:12 AdrianHB: Yes, and then I will merge the PR 15:54:34 topic: Payment Method Manifest Specification 15:54:52 +1! 15:55:05 q+ to propose that manifest is defined in the PMI spec 15:55:08 Ian: I did edits to the PMI spec, tried to see if Max would help w/ Zach's proposal. 15:55:23 Ian: A couple of questions have come up wrt. where the spec should go. 15:55:40 Ian: How do we find these manifests? HTTP headers, content negotiation, etc. We don't have a lot of time, but we have to get through this issue. 15:55:44 ack AdrianHB 15:55:45 AdrianHB, you wanted to propose that manifest is defined in the PMI spec 15:56:28 Q1: Should manifest spec be in PMI spec? 15:56:39 Q2: How do we get the manifest: Payment method URL or derived URL? 15:56:50 Agreed with AdrianHB - why does it need to be in a separate spec? 15:57:21 +1 to push changes in current PR to TR space 15:57:29 Ian: I'd like to update the PMI spec in TR space first, then get these other changes in, then update TR space again w/ manifest stuff. 15:57:39 Why aren't we using Echidna yet? 15:57:40 +1 to rev the PMI spec 15:57:42 IJ: I don't mind having manifest info the PMI spec 15:57:45 propose we branch pmi spec and work on manifest 15:58:07 q+ to request that we move to Echidna for all TR specs. 15:58:21 PROPOSED: Push PMI spec without manifest bits in it, and begin work in parallel on the Manifest bits to be included in the PMI spec for a future release. 15:58:26 +1 15:58:28 +1 15:58:34 q- 15:58:43 q? 15:58:44 doesn't the group have to make a decision on it? 15:58:44 +1 15:58:49 https://github.com/w3c/echidna/wiki/How-to-use-Echidna 15:58:55 +0 15:59:00 +1 15:59:10 +1 15:59:11 +1 15:59:17 SO RESOLVED 15:59:18 +1 15:59:27 Topic: Check in priorities 15:59:31 PR API issues 15:59:31 Payment app spec reviews 15:59:31 Push payment proposal 15:59:31 Test suite 15:59:36 Updates: 15:59:52 * Payment app spec reviews: (Zach reviewed but owes comments on github) 16:00:01 * PR API issue (making progress on key issues is my understanding) 16:00:07 * Push payment proposal (in progress) 16:00:40 test suite we have set up a mailing list and now that there are two implementors actively working I am planning a push 16:00:47 - push payment is a PR against payment req spec, needs to be merged or changed 16:01:00 canMakeActivePayment? 16:01:02 +1 on priorities 16:01:16 canMakeActivePayment is a PR API issue 16:01:22 Topic: Next meeting 16:01:25 1 December 16:01:31 alyver has left #wpwg 16:01:31 ..happy Thanksgiving to those who celebrate it 16:01:34 rrsagent, make minutes 16:01:34 I have made the request to generate http://www.w3.org/2016/11/17-wpwg-minutes.html Ian 16:01:38 rrsagent, set logs public 16:01:49 present+ Ken 16:02:01 MikeSmith has left #wpwg 16:02:43 rrsagent, make minutes 16:02:43 I have made the request to generate http://www.w3.org/2016/11/17-wpwg-minutes.html Ian 16:02:48 rrsagent, set logs public 16:18:55 zkoch has joined #wpwg 16:34:02 adamlake has joined #wpwg 17:08:38 zkoch has joined #wpwg 17:19:02 zkoch has joined #wpwg 17:29:54 zkoch has joined #wpwg 17:46:23 stan has joined #wpwg 17:48:45 zkoch has joined #wpwg 17:55:41 zkoch has joined #wpwg 18:02:32 Zakim has left #wpwg 18:03:19 zkoch has joined #wpwg 18:09:53 zkoch has joined #wpwg 18:16:53 zkoch has joined #wpwg 18:22:25 zkoch has joined #wpwg 18:23:36 betehess has joined #wpwg 18:32:51 Adam_ has joined #wpwg 19:10:54 zkoch has joined #wpwg 19:52:19 stan has joined #wpwg 20:20:50 stan has joined #wpwg 21:09:10 betehess has joined #wpwg 21:21:10 Adam_ has joined #wpwg 21:56:31 betehess has joined #wpwg 22:17:35 Adam_ has joined #wpwg 22:40:52 stan has joined #wpwg 23:26:26 betehess has joined #wpwg