14:58:35 RRSAgent has joined #wpwg 14:58:35 logging to http://www.w3.org/2016/12/15-wpwg-irc 14:58:37 RRSAgent, make logs public 14:58:37 Zakim has joined #wpwg 14:58:39 Zakim, this will be 14:58:39 I don't understand 'this will be', trackbot 14:58:40 Meeting: Web Payments Working Group Teleconference 14:58:40 Date: 15 December 2016 14:58:52 stan has joined #wpwg 14:59:03 agenda: https://github.com/w3c/webpayments/wiki/Agenda-20161215 14:59:05 scribe: ian 14:59:12 Max has joined #wpwg 14:59:17 Ian has changed the topic to: WPWG Conf Call - 15 Dec https://github.com/w3c/webpayments/wiki/Agenda-20161215 15:00:08 present+ Manu 15:00:18 present+ Ian 15:00:21 present+ Max 15:00:44 oyiptong_ has joined #wpwg 15:01:04 rouslan has joined #wpwg 15:01:04 present+ Stan 15:01:19 present+ Rouslan 15:01:32 chair: NickTR 15:01:58 dezell has joined #wpwg 15:02:04 present+ dezell 15:02:16 present+ Olivier 15:02:35 present+ Alan 15:02:54 present+ AdrianHB 15:03:04 rrsagent, make minutes 15:03:04 I have made the request to generate http://www.w3.org/2016/12/15-wpwg-minutes.html Ian 15:03:12 present+ Adam 15:03:18 regrets+ zkoch 15:03:28 present+ nicktr 15:03:39 agenda => https://github.com/w3c/webpayments/wiki/Agenda-20161215 15:04:08 topic: end of year blog post 15:04:27 Ian: I've started to work on an end of year Blog post at the end of the year, talking about progress, topics we've been looking at. 15:04:38 Ian: Some payment method spec advancements, keep an eye out for that. 15:04:55 topic: Pre CR outreach 15:04:57 Ian: The purpose is to give a high-level mention of topics for folks not closely following this work. 15:05:35 alyver has joined #wpwg 15:05:41 +1 on Payment Apps progress 15:05:55 Ian: In Lisbon, we discussed advancement to CR - take away was that folks wanted to see third party payment apps further along. Test suites, a couple of other things, I feel like we've made substantial progress on 3rd party payment app API. The Task Force resolved to go to FPWD for that spec. Trying to get what we can get done between now and then. 15:06:07 Ian: So late January, early Feb, we'd have FPWD of Payment Apps API 15:06:25 MaheshK has joined #wpwg 15:06:48 Ian: We're getting lots of edits/refinements of Payment Request... it's solidifying, we're getting deployments, if we look ahead, going to CR in February timeframe, one of the CR entry criteria is wide review. Can we start wide review process in early January? 15:06:54 betehess has joined #wpwg 15:07:19 q? 15:07:28 Ian: Since we have auto-publishing, all changes are in TR page, now I can point people at those specs comfortably. For example, have discussions with Privacy IG. Can we begin outreach, wider review of specs, make decision to go to CR -we've fulfilled that portion of that criteria. 15:07:34 q+ to be concerned 15:07:40 ack manu 15:07:40 manu, you wanted to be concerned 15:07:59 manu: My read for payment apps further along is we want to see implementation 15:08:01 q+ 15:08:34 manu: I have no problem with getting review of PR API (the wide review part) 15:08:49 manu: We still haven't answered the digital signature question around payment requests 15:09:36 Ian: I think that we can get wide review and that is independent of the need to close additional issues. I can't guarantee that there won't be new issues raised. We can continue to get wide review, so people can get a broader sense of review of these specs. 15:10:02 Ian: Regarding payment app implementation - we're getting implementations. We know of native implementations, we are also doing experimentation with web-based payment apps. 15:10:32 Ian: That is not a criteria for getting to FPWD, but there is a request to understand if web-based payment apps work with the Payment Request API. 15:11:03 Ian: Regarding digital signatures, that's something that as a group, we'd want to address known issues before requesting to go to CR. I'm not suggesting that we rush that, only that we start the process of getting wide review, because that takes a while. 15:11:03 q? 15:11:05 ack me 15:11:13 All that sounds good, Ian. 15:11:18 Ian: Thanks Manu 15:12:18 Ian: The sense I have from watching the Github discussions, implementers increasingly want stability, we've tried to move faster with PaymentApp API, we may get pushback from implementers of significant changes. 15:12:26 q? 15:12:38 Ian: It's thrilling to have implementations, people are excited about that. 15:12:52 Ian: When we get wider review, we may face some challenges. That's the reality of doing this work. 15:12:57 q+ to ask manu what he'd expect as a goal re signatures 15:13:04 ack AdrianHB 15:13:04 AdrianHB, you wanted to ask manu what he'd expect as a goal re signatures 15:13:04 q+ to ask about "yes, but have you had the extra changes reviewed?" 15:13:27 AdrianHB: You've listed digital signatures as an issue you think we need to resolve before we go to CR 15:13:57 ..are you satisfied if we say "The group has decided digital signatures are a payment methods specific topic" 15:14:33 Manu: the issue is "what is our strategy around digital signatures" and if our response is "it's per payment method" then I think it's not good enough; I want to ensure the group realizes it's painting itself into a corner 15:14:58 ..it's not that I'm preposing a particular signature approach, I would like to have clarity around strategy 15:15:13 This is the digital signature issue: https://github.com/w3c/browser-payment-api/issues/291 15:15:41 ack manu 15:15:41 manu, you wanted to ask about "yes, but have you had the extra changes reviewed?" 15:15:52 Manu: No objection from me to putting out a call for pre-CR review; that's good and healthy 15:15:59 ack manu 15:16:23 ...we'll get reviews and then we'll have to show more review over changes 15:16:44 pascal_bazin has joined #wpwg 15:17:00 NickTR: I hear no objections to starting the process of soliciting wide review 15:17:01 Correct, no objections (from me) 15:17:10 ACTION: Ian will begin soliciting wide review of PR API in January 2017 15:17:10 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., ijacobs, ijmad). 15:17:14 I have made the request to generate http://www.w3.org/2016/12/15-wpwg-minutes.html Ian 15:17:15 +1 let's start wide review process 15:17:18 q? 15:17:31 topic: Detecting payment method availability 15:17:39 q+ 15:17:45 ack ad 15:17:46 ack adamR 15:18:05 q+ to talk about active 15:18:06 adamR: I can't speak to the issue itself, but what I want to verify is whether we are doing this for "payment methods" or "active payment methods" 15:18:06 q+ 15:18:15 ack rouslan 15:18:15 rouslan, you wanted to talk about active 15:18:15 ack rouslan 15:18:30 rouslan: The current text is silent on whether it's active or not. The Edge plan is to always return "true" for basic card 15:18:46 ..the Chrome plan is to check whether the autofill store has info and return "true" accordingt6ly 15:18:48 q+ 15:18:52 ...but this is left to the implementer 15:19:05 q? 15:19:07 AdamR: And both are considered explicitly valid? 15:19:08 Rouslan: Yes 15:19:21 mahesh: Here's an update on the pull request 15:19:23 Sorry I'm late 15:19:43 ...I spoke with Zach and he proposed to make some editorial changes to the PR 15:19:51 ...Domenic Denicola is also reviewing it 15:20:03 ...so it will be modifications to the current pull request 15:20:17 https://github.com/zkoch/zkoch.github.io/blob/master/pr-detect-avail.md 15:20:25 q? 15:20:26 ..the new PR is not yet there 15:20:27 ack M 15:20:34 ack adrianba 15:20:38 https://github.com/w3c/browser-payment-api/pull/380 15:20:45 adrianba: Zach and I met yesterday and we merged the new pull request in. 15:20:53 ...we anticipate making some further changes 15:21:01 ...this pull request doesn't distinguish active v. not active 15:21:28 ...that's kind of by design, but the conversation Zach and I had was, based on WPWG discussions and the fact that we use the word "support" to mean different things, we need to elaborate on the text that's there for clarity 15:21:29 q+ 15:21:39 ..so that's now in the current spec and available for review 15:21:59 ...we intend to add a note indicating that it's valid to limit "support' to mean "active" and also valid to not make that check 15:22:12 q+ to mention issue 367 15:22:24 q? 15:22:27 ack Ian 15:22:27 Ian, you wanted to mention issue 367 15:22:31 https://w3c.github.io/browser-payment-api/#canmakepayment-method 15:22:40 ack me 15:22:46 Added issue 367 https://github.com/w3c/browser-payment-api/issues/367 15:22:58 q+ 15:23:28 Ian: Matt Saxxon has been concerned about issue 367, was closed prematurely 15:23:35 ack ad 15:23:42 ack adrianba 15:23:53 adrianba: Right now the language in the spec leaves it to implementations to make a determination about "the right way of limiting" 15:24:16 ...nobody is happy with timeout even though timing is mentioned 15:24:19 ...as a consideration 15:24:27 ...we will probably change how we do this over time 15:24:53 Ian: So, I'm hearing that the issue should stay open. 15:24:56 ...so I don't think we need to say anything else 15:25:06 ...changes and experimentation will continue after the spec is frozen 15:25:32 q+ to be worldpay for a moment 15:25:38 Ian: I don't think Matt Saxxon is on the call, we could ask him to close the issue if he is... but I suggest we leave it open until the person that wanted it raised is okay with the result. 15:25:40 ack nic 15:25:40 nicktr, you wanted to be worldpay for a moment 15:26:03 nicktr: Thanks IJ for raising the issue that Matt is tracking; I'd like the issue to stay open for now....the question is whether we signpost that in the spec or not. 15:26:13 q? 15:27:01 IJ: I will put tokenization and credit transfer on a January agenda 15:27:05 ....progress on both! 15:27:28 topic: PMI Specification 15:27:47 https://w3c.github.io/webpayments-method-identifiers/ 15:28:16 Ian: Based on filtering, use of URLs, etc. we've updated this spec. 15:28:39 https://github.com/w3c/webpayments-method-identifiers/issues/17 15:28:39 Ian: There are still a number of issues, notably around Manifest spec, but AdrianHB raised some issues, before we get to those, there is one particular one... Issue #17 - 15:29:10 Ian: We said that we constrained the shape of URls for PMIs, which include HTTPS every time. AdrianHB raised if that was overly constraining because of things he cited in the issue. Let's discuss 15:29:22 Text from AdrianHB's issue: 15:29:29 ----- 15:29:29 There is a concern that having browsers all over the world fetching a manifest all the time will put significant strain on the hosts of the manifest. 15:29:29 There are protocols that are better at serving static content than HTTP such as IPFS. While they're not supported in most browsers yet, they may be soon. 15:29:30 So, should we be limiting the PMI URLs to https as the scheme or rather wording this as something that requires fetching the manifest through a SecureContext or similar? 15:29:31 ---- 15:30:07 Ian: There is a link from the spec to that issue 15:30:08 q+ to provide input, if that would be helpful. 15:30:29 AdrianHB: HTTPS is restrictive in terms of how a manifest is hosting 15:30:42 ...hosting a manifest is potentially a resource-intensive thing (for popular payment methods) 15:31:10 ...while there are CDNs and cachgin, and there are better protocols e.g., for distribution 15:31:24 ...so I would prefer we not have this limitation to HTTPs 15:31:38 q+ 15:31:43 ack manu 15:31:43 manu, you wanted to provide input, if that would be helpful. 15:31:47 ack manu 15:31:53 manu: +1 to AdrianHB's comment; I would not restrict to HTTPs 15:32:12 q? 15:32:14 ...the spec can say something about expectations for secure transport (e.g., HTTPs) 15:32:22 AdrianHB: +1 to HTTPs as an example 15:32:39 q? 15:32:54 ack rouslan 15:33:07 rouslan: +1 to not saying HTTPs and talking about secure hosting 15:33:27 q? 15:33:48 Ian: We have a draft manifest spec 15:33:59 Ian: That seems to be the appropriate place for discussion of secure hosting of manifest files. 15:34:02 present+ ShaneM 15:34:19 Delete "The URL scheme MUST be https. " from PMI spec 15:34:20 Ian: So, this would mean that it's no longer a syntax of the payment method identifier, we could remove the constraint on the URLs from the PMI spec. 15:34:32 Ian: There is another conversation that's happening, whether to put manifest spec in PMI spec 15:34:47 Ian: I would say there are two modifications to make. Delete from syntax spec, add to manifest spec. 15:34:59 q? 15:35:03 Ian: I don't think there will be substantive impact to merge specs, but we could discuss more. 15:35:27 ACTION: AdrianHB to propose changes to PMI spec and Payment Manifest spec regarding loosening of the HTTPs syntax requirement and secure payment method manifest hosting 15:35:28 Created ACTION-40 - Propose changes to pmi spec and payment manifest spec regarding loosening of the https syntax requirement and secure payment method manifest hosting [on Adrian Hope-Bailie - due 2016-12-22]. 15:35:54 Topic: Addressing payment method manifest files 15:36:19 https://github.com/w3c/webpayments-method-identifiers/issues/19 15:37:06 (Adrian going into detail) 15:37:33 AdrianHB: Useful to be able to go in both directions; we need to take into account service workers 15:38:30 Ian: Zachs proposal is outlined here - https://github.com/w3c/webpayments-method-identifiers/issues/19 15:39:03 Ian: There are proposals for: Hard-coded URL, HTTP Link Header, Content Negotiation, Serve JSON for PMI, then link to human readable content from there. 15:39:25 q? 15:39:26 Ian: Those are four proposals on the table, some pros and cons based on what folks suggest. We need to figure out which of those we want to do. 15:40:24 AdrianHB: The second bullet refers to what I was discussing 15:41:00 Ian: In any case, we should post pone payment app discussion after payment method identifiers. 15:41:13 Ian: So, this issue - https://github.com/w3c/webpayments-method-identifiers/issues/19 15:41:24 Ian: These are the four options, is anyone else aware of other options that they think may get traction. 15:41:45 Ian: Then folks can go off and study these, and then come back so we can discuss. 15:41:54 https://w3c.github.io/webpayments/proposals//Payment-Manifest-Proposal.html 15:41:57 Ian: In the Payment Manifest spec... 15:41:59 q+ to ask some questions about the issue? 15:42:36 Ian: There is a section called "Manifest File Addressing" and cheated and said there is an algorithm. For example, you can use HTTP Link headers, and if that doesn't give you an answer, you can use a hard coded URL. Maybe not restrict and provide multiple methods via an algorithm. 15:42:48 q+ 15:43:01 Ian: I hesitate to go too far down that path, but we could use two of these. Header takes precedence over hard coded URL. 15:43:04 ack AdrianHB 15:43:04 AdrianHB, you wanted to ask some questions about the issue? 15:43:06 ack AdrianHB 15:43:14 AdrianHB: I have a few questions about the options in that issue. 15:43:36 ...first high-level question - for a link header what would be the URL I would be visiting? 15:43:36 Ian: The payment method identifier URL 15:43:40 IJ: You do a Head request on the PMI 15:43:58 ..and we would register the header type with IANA 15:44:25 q+ to ask about content negotiation? 15:44:27 q? 15:44:34 AdrianHB: So I am hearing that the PMI points to (a potential) machine readable page, and HEAD on the PMI gives you a link for a registered header type. 15:44:43 ...so options 2 and 4 seem relatively interchangeable 15:44:44 ack adamR 15:44:44 q- 15:45:07 adamR: We can add new link relations in the HTTP Link approach, but option 4 does not allow that 15:45:07 q+ 15:45:32 adamR: Regarding an algorithm...we accrue the list of "cons"...I would steer us away from that approach 15:45:54 Ian: One of the limitations of option #1 - you can only have a single manifest file. 15:46:13 q+ to consider the ability of servers to do HEAD properly for option 2 15:46:18 Ian: In different jurisdictions, you may want to serve different manifest files, therefore, having the ability to only get one takes you closer to content negotiation. 15:46:21 ack ian 15:46:26 Ian: You may be able to address multiple manifest files. 15:46:39 Ian: Are there real world use cases for having different manifest files is useful? 15:46:51 ack AdrianHB 15:46:51 AdrianHB, you wanted to consider the ability of servers to do HEAD properly for option 2 15:46:53 Ian: Or, would you serve different files and you don't need to address them differently. 15:47:10 AdrianHB: One of the cons listed for conneg is the challenge of setting up servers; I appreciate that can be difficult to do 15:47:19 ...but I am wondering how easy it is to set up Link headers 15:47:39 q+ to wonder if conneg is a problem for payment method creators? How many of these folks are out there? Aren't they technically capable? 15:47:40 ...is it possible to do HTTP Link stuff via ? 15:47:49 q+ 15:47:58 ack manu 15:47:58 manu, you wanted to wonder if conneg is a problem for payment method creators? How many of these folks are out there? Aren't they technically capable? 15:48:17 manu: I don't think there will be a lot of payment method manifest files; maybe several hundred 15:48:43 ...I think that it's not that hard to do 15:48:46 +1 15:49:01 q? 15:49:04 Ian: There are concerns to caching as well 15:49:14 ack Adam 15:49:21 (proxy support is a concern with conneg I think) 15:49:43 adamR: I was also going to say that, in terms of entities that will create these identifiers, those entities will have no difficulty with conneg config 15:50:06 adamR:... or headers (option2) 15:50:21 s/conneg/link headers/ 15:50:41 IJ: Remind me whether servers look at META for Link headers? 15:50:45 Shane: Not in general 15:51:07 Ian: There are four options listed, suggestions about other options and support for existing four are welcome. 15:51:09 IJ: Welcome both other options and indications of support or concerns about the existing 4 15:51:16 ...will return to this in January 15:51:32 --- 15:51:33 Any optimization desirable for the case where someone wants to say "I have a URL for my payment method and want to allow any payment app to implement it; but don't want to host a manifest file." 15:51:34 --- 15:52:16 Ian: Matt was concerned around the ability for W3C to mint new URLs w/o paying the cost for serving manifest files where everyone else does. 15:52:44 Ian: We don't want to prevent people from minting short names, but they need explicit support in browsers for shortnames. 15:53:20 Ian: There are modern techniques for managing server load wrt. multiple trips to get manifest file and server load in HTTP/2 and proper config, these are much less significant performance issues. We should go in the direction of good practice to help them do the right thing. 15:53:56 Ian: There may or may not be a connection to the approach that we're going to take for the addressing. We should hang on to this, don't recall if we have an issue for this explicitly. We should not lose sight of this wrt. payment method good practice note. 15:54:16 ACTION: Ian to add a note to the payment method good practice spec to not lose track of the performance topic 15:54:16 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., ijacobs, ijmad). 15:54:40 topic: Basic Card 15:54:58 nicktr: I am seeing traction within EMVCo to engage with W3C on basic and tokenization topics 15:55:22 https://github.com/w3c/webpayments/blob/gh-pages/proposals/supported-networks-list.md 15:55:33 q? 15:56:42 Ian: Asking for input on https://github.com/w3c/webpayments/blob/gh-pages/proposals/supported-networks-list.md 15:56:44 q+ to note all those short names are EMVco members 15:57:08 IJ: Please provide feedback on the proposal 15:57:09 Ian: That issue will affect tokenizatin spec, SEPA CT spec, feedback is welcome. 15:57:09 ack nicktr 15:57:09 nicktr, you wanted to note all those short names are EMVco members 15:57:26 ACTION: NickTR to ask EMVCo if they would be ok with our use of short strings this way 15:57:26 Created ACTION-41 - Ask emvco if they would be ok with our use of short strings this way [on Nick Telford-Reed - due 2016-12-22]. 15:57:35 Tentative +1 to put network names in their own spec (or registry, but W3C doesn’t have a registry story….) 15:57:56 Topic: meetings 15:58:01 Next teleconf is 5 January 15:58:25 FTF: proposed 23-24 March in Chicago week before IETF 15:59:27 PROPOSED: 23-24 March in Chicago 15:59:37 +1 for date and city 16:00:43 q+ 16:01:13 ack dezell 16:01:14 ack dezell 16:01:44 +1 with dates and venue 16:01:46 IJ: Perfectly happy to have the IG meet alongside that 16:01:56 +1 for dates nad venue 16:01:56 ..it's not precluded 16:02:40 RESOLVED: Next WPWG FTF meeting is 23-24 March in Chicago 16:02:45 Happy Holidays everyone! 16:02:48 alyver has left #wpwg 16:02:53 I have made the request to generate http://www.w3.org/2016/12/15-wpwg-minutes.html Ian 16:04:11 tx 16:04:52 rrsagent, make minutes 16:04:52 I have made the request to generate http://www.w3.org/2016/12/15-wpwg-minutes.html Ian 16:04:55 rrsagent, set logs public 16:34:49 stan has joined #wpwg 16:38:14 zkoch_ has joined #wpwg 17:55:52 betehess has joined #wpwg 18:31:50 Zakim has left #wpwg 18:55:05 adamlake has joined #wpwg 19:23:16 stan has joined #wpwg 19:38:45 betehess has joined #wpwg 19:46:41 olivexu1 has joined #wpwg 20:18:04 adamlake has joined #wpwg 20:18:52 stan has joined #wpwg 21:12:20 betehess has joined #wpwg 21:30:01 betehess has joined #wpwg 22:09:56 stan has joined #wpwg 22:44:50 zkoch_ has joined #wpwg 22:46:32 stan has joined #wpwg 22:52:29 zkoch_ has joined #wpwg 23:11:36 zkoch_ has joined #wpwg 23:24:48 betehess has joined #wpwg