13:56:01 RRSAgent has joined #wpwg 13:56:01 logging to http://www.w3.org/2016/08/18-wpwg-irc 13:56:03 RRSAgent, make logs public 13:56:03 Zakim has joined #wpwg 13:56:05 Zakim, this will be 13:56:05 I don't understand 'this will be', trackbot 13:56:06 Meeting: Web Payments Working Group Teleconference 13:56:06 Date: 18 August 2016 13:56:31 agenda: https://github.com/w3c/webpayments/wiki/Agenda-20160818 13:59:56 present+ dlongley 14:00:06 regrets ShaneM 14:00:12 present+ Manu 14:00:27 Regrets: ShaneM 14:00:35 present+ Ian 14:00:41 Max has joined #wpwg 14:00:44 scribe: Ian 14:01:46 Present+ Dongwoo 14:03:51 present+ AdrianHB 14:04:03 agenda? 14:04:09 jnormore has joined #wpwg 14:04:26 present+ nicktr 14:04:31 Present+ adamR 14:04:44 rouslan has joined #wpwg 14:04:45 present+ jnormore 14:04:58 present+ rouslan 14:05:12 zkoch has joined #wpwg 14:05:15 agenda: https://github.com/w3c/webpayments/wiki/Agenda-20160818 14:05:35 Roy has joined #wpwg 14:05:38 present+ zkoch 14:05:43 Sorry, I just got here 14:05:44 1 min 14:06:00 looking for headphones 14:06:15 proposal-> https://github.com/w3c/webpayments/issues/170 14:06:48 hmm, I updated ... will try again 14:07:30 MikeSmith has joined #wpwg 14:07:45 zkoch: The proposal addresses some key filtering scenarios. 14:08:04 ...by putting in data field we are doing it the way other apps are doing it today (e.g., Android Pay and Apple Pay do this) 14:08:22 ...proposal addresses credit/debit 14:09:00 zkoch: I have been going back and forth on this. I am not a fan of filtering attribute to the top-level 14:09:07 ...this seems to be only for basic cards at this time. 14:09:24 (cf 170 https://github.com/w3c/webpayments/wiki/Agenda-20160818 ) 14:09:40 RRSAgent, make minutes 14:09:40 I have made the request to generate http://www.w3.org/2016/08/18-wpwg-minutes.html MikeSmith 14:09:48 ..so I do not support the proposal of 170. Prefer that this be in the "data" blob for now and we can revisit this as new use cases arise. 14:09:49 RRSAgent, make logs public 14:09:57 q+ to say this forces the browser to process the data blob 14:10:00 ...I also am not inclined to address AND and OR more explicitly 14:10:10 q? 14:10:11 q? 14:10:14 ack AdrianHB 14:10:14 AdrianHB, you wanted to say this forces the browser to process the data blob 14:10:20 ack AdrianHB 14:10:37 AdrianHB: My only comment is that we want the data blob to be something that the browser doesn't have to parse and understand; this requires them to do so 14:10:45 ...this feels short-sighted to me 14:10:52 q+ to note not a strong position, request more use cases, ask if we can start by generalizing and back off if implementers don't like it? 14:11:22 q? 14:11:24 AdrianHB: this proposal to leave in the data blob seems in contradiction to previous comments about security (not having unlimited lists, e.g.) 14:11:54 zkoch: This seems today like only a basic card thing. We make lots of weird exceptions for cards today which is appropriate and pragmatic. 14:11:57 For what it's worth, while exploring tokenized cards, we need a similar feature most likely 14:11:59 ack manu 14:11:59 manu, you wanted to note not a strong position, request more use cases, ask if we can start by generalizing and back off if implementers don't like it? 14:12:00 there's potentially an argument for new payment methods to add other mechanisms like this that payment mediators *MAY* use to make the experience better for the user, but it isn't required for them to filter? 14:12:10 q+ to ask if we should allow 3rd party apps to process basic card (i.e. make it a VERY special case) 14:12:24 Manu: I don't think we have a strong position on this; good points on either side. Regarding "use cases before we move out of data blog" resonates for me. 14:12:31 Present+ dezell 14:12:31 q+ to wonder aloud about per method encryption 14:12:32 so mediators MAY look at the payment method data to provide a better experience, but it wouldn't be a requirement 14:12:43 ...but I also find compelling the "not having to parse" point 14:12:53 Agreed dlongley 14:13:04 ..I think we could easily go either way ... start general or start payment method specific 14:13:21 dlongley makes a good point, keen to explore more 14:13:23 ...I don't want to start in the data blob and then move outside 14:13:27 (IJ; But that is possible) 14:13:39 q? 14:14:00 Manu: When we get to CR we should have a clear story...we should make a decision one way or the other 14:14:06 ...we should be consistent (over time) 14:14:12 ack AdrianHB 14:14:12 AdrianHB, you wanted to ask if we should allow 3rd party apps to process basic card (i.e. make it a VERY special case) 14:14:14 I think it’s Nick 14:14:22 neverminndd misread :) 14:15:09 q+ 14:15:19 AdrianHB: dlongley makes a good point - if we leave it in the data blob, browsers special case...I do worry about the relationship between browser vendors and people who are pushing different payment methods 14:15:25 q+ to ask if you'd want to filter SEPA methods? 14:15:31 q? 14:15:54 AdrianHB: It feels like every time we talk about basic card to everything else we give ourselves headaches. 14:16:19 ...part of the conversation around issue 11 is: doesn't it make sense for every payment app out their to say they support basic card to get in front of users? 14:16:33 ...here's a controversial proposal - should we allow third party apps to return raw card details? 14:16:34 I want to punt this question for now and make it its own 14:16:37 q+ 14:16:43 Because it’s a great question, but it’s a big, complicated one 14:16:50 ...so basic card is basically a replacement for form filling 14:17:22 -1000 to making it so payment apps can't play in the space 14:17:26 ...if we said only browsers could return basic card, maybe it solves this problem...I realize that's controversial 14:17:28 ack nicktr 14:17:29 nicktr, you wanted to wonder aloud about per method encryption 14:17:37 -1 to restricting basic card to only browsers. Limits flexibility for merchants. 14:17:52 nicktr: I want to wonder aloud about several things...we have spoken previously about signing blobs 14:18:22 ...if we put the extra information in the blob, then the browser has to also implement that capability...I wanted to see whether that is relevant to this discussion. 14:18:24 q? 14:18:24 ack zkoch 14:18:44 q- 14:19:08 If we limit basic card to only browsers we can define a better scheme for apps to return card details (like one where the card numbers are not returned via the API but rather POSTed to a URL defined by the merchant)... thinking out loud 14:19:17 zkoch: Regarding encryption .... the data blob that is passed in right now is minimal and may not need encryption...there are other payment methods where encryption could be more useful, and I think that in many cases those would be proprietary 14:19:31 nicktr: The reason that it's front of mind for me today is that I've been reading the EBA draft standards on strong authentication 14:19:42 ...they are making noise about keeping identifying information confidential 14:19:57 ..and that raises the question about whether we need to encrypt on outbound 14:20:08 zkoch: filtering would not be personally identifying 14:20:19 nicktr: You can't encrypt the blob though ..... 14:20:27 zkoch: There's nothing IMO to encrypt in the blob 14:20:41 nicktr: Regs came out this week...I am reading them...and they are still draft 14:20:52 zkoch: I have a request - please send email to the WG pointing us to the draft 14:21:04 ACTION: nicktr to send link to new EBA regs to the WG 14:21:09 Created ACTION-27 - Send link to new eba regs to the wg [on Nick Telford-Reed - due 2016-08-25]. 14:21:14 RTS from EBA -> https://www.eba.europa.eu/documents/10180/1548183/Consultation+Paper+on+draft+RTS+on+SCA+and+CSC+%28EBA-CP-2016-11%29.pdf 14:21:16 q? 14:21:18 q? 14:21:23 ack manu 14:21:23 manu, you wanted to ask if you'd want to filter SEPA methods? 14:21:41 manu: What would make this decision easy would be if we could come up with another use case. 14:21:48 ..is SEPA another use case? 14:22:03 q? 14:22:52 Manu: I think that if we don't have other use cases, it probably means we are doing something prematurely (even if I'd love to generalize) 14:22:58 +1 14:22:59 SGTM 14:23:01 +1 14:23:01 AdrianHB: I am ok to close issue as postponed until we have more use cases 14:23:02 +1 14:23:03 +1 14:23:12 Issue 11 14:23:13 https://github.com/w3c/webpayments-method-identifiers/issues/11 14:23:46 zkoch: What I wanted to discuss earlier is that in the proposal we made 2 concrete proposals to change payment request API 14:24:04 https://github.com/zkoch/zkoch.github.io/blob/master/pmi.md 14:24:17 zkoch: I want to be sure people are ok with the changes 14:24:37 ...we would now allow N > 1 instances of a payment method identifier 14:24:39 (IJ: +1) 14:24:54 ...the second change is to modify payment details modifiers to enable per payment-method pricing 14:25:36 ...matching algorithm is "first match" 14:25:43 ..so most specific filters go first 14:25:47 IJ: +1 14:25:49 q? 14:25:51 +1 14:26:01 +1 - but would like to see the spec text obviously 14:26:12 +1 14:26:20 if it works, sounds fine to me. 14:26:33 q? 14:26:35 +1 - if it works, sounds like a good approach. 14:26:36 nicktr: I hear consensus; please push forward, Zach 14:26:51 topic: payment method identifiers 14:27:06 https://github.com/w3c/webpayments/wiki/Agenda-20160818#pmi-notes 14:27:23 adrianhb: We don't have consensus yet on the proposal. 14:27:31 ..the proposal distinguishes open v. proprietary 14:27:33 q+ 14:27:38 ...question was "why use URLs" 14:27:58 ...we are back to the question of "what the requirements are" (for PMIs) 14:28:13 ...the proposal says that the requirements are different for open v. proprietary 14:28:36 ...concerns of some respected voices on the github repo is URL-as-identifier is an anti-pattern 14:29:15 ...zkoch has said he wants to point to resources, but we don't know what they are yet. 14:29:16 q? 14:29:18 ack me 14:29:36 q = zkoch 14:29:41 IJ: also w3c v. other 14:29:43 Ian: The open vs. proprietary is potentially a useful distinction. W3C controlled vs. other is a useful distinction. 14:29:44 q? 14:30:32 q+ zkoch 14:30:33 Ian: Sometimes those axes overlap, but sometimes they don't, specifically there are some choices we may make because W3C is in a privileged position and can publish short strings. We may want to place other requirements to make sure other parties do something extra, whether the other parties are open or closed. 14:30:41 q+ to make another (controversial) proposal - related to #11 14:31:02 Ian: URLs for everyone but W3C - where are we optimizing, and are we doing so with the constituencies that we're identifying in mind, is W3C in a privileged position or not? 14:31:03 q? 14:31:07 ack zkoch 14:31:30 zkoch: Have been having discussions with lots of stakeholders. 14:31:45 ...one useful thing to do is look at top 100 ecommerce sites and how they accept payments 14:32:19 ...credit cards get us somewhere but there are other methods that other companies would like to see supported by payment request...so my comments are informed by those discussions. 14:32:43 ...I agree with Tab Atkins that URLs as identifiers are problematic...but there are a number of things in payments that make URLs valuable despite the limitations. 14:32:52 this report is in the public domain and might be a helpful view on the distribution and usage of different payment methods -< http://www.worldpay.com/global/insight/articles/2016-07/global-payment-report 14:32:53 ...in particular given the use cases of the people we are talking to. 14:32:57 ...the benefits include: 14:33:24 q+ to ask if we're saying that payment method information (name, description, how to install, partners, etc.) are at the end of those URLs? Isn't this the key question? 14:33:28 (1) brands are very protective and also very busy....the web affords them what they need ... they have URLs, JS, IFrames...so they may ask "why is this new thing more useful"? 14:33:52 ...one thing I want to remove from the obstacle list is "no process is required"...people can use existing origin-based security model 14:34:03 ...and we can, in addition, put things at the ends of URLs to improve the user experience 14:34:18 ...right now the spec says that if you don't match throw a false. 14:34:21 +1 to use the identifier mechanism that the Web uses... which is the URL. 14:34:37 ..but you could imagine that the browser does something useful like getting data about a payment method 14:34:42 ...that can improve the use experience. 14:35:04 +1 to what zkoch is saying about making it easier for people to do more decentralized innovation 14:35:10 ...we have postponing the discussion of "what they point to" but I am hearing people may not wish to decouple them 14:35:28 q? 14:35:33 ack AdrianHB 14:35:33 AdrianHB, you wanted to make another (controversial) proposal - related to #11 14:35:37 ...we would have to make a decision knowing the anti-pattern exists, but I think the benefits outweigh the costs 14:35:41 reminds me of the decision to allow URLs to fail (return 404) instead of forcing every link/document to be up to date in a centralized database 14:36:00 adrianhb: One thing based on what you said that I want to highlight....what the URLs point to depends largely on what payment apps look like. 14:36:28 ...so I think this PMI discussion relates to payment apps and we can't make a decision about PMIs and what they point at until we have a better idea of what payment apps will look like. 14:36:50 ...we can't decide on pointing at app or manifest or other until we have greater clarity about payment apps (and esp. how they are registered) 14:37:04 ...I support using URLs but I think we need to prioritize what they point to. 14:37:22 +1 to figure this out by furthering the payment apps spec and direction 14:37:35 AdrianHB: My controversial proposal is that instead of differentiating proprietary v open...we could have URLs for ALL payment methods EXCEPT cards. 14:37:51 ...we have a bootstrapping problem and perhaps we should make basic card a string 14:37:54 q+ to ask about parsing cost 14:38:05 ...and treat it as an exception... 14:38:50 ...also regarding apps announcing support for card payments....and collecting card data... 14:39:07 +1 to URL pointing to a manifest to improve user experience, agree that it needs to be informed by payment app registration though. 14:39:29 +1 no, it's a bad idea 14:39:33 ...the controversial piece of my proposal is that browsers determine who can do payments 14:39:44 Same thing as before, I think this is a good question that we should discuss, but it’s a bit orthogonal to how we identify them 14:39:49 ...browsers are well-positioned to evaluate whether apps are doing bad things 14:39:51 I expect many formal objections if we say "only browsers can handle card payments" 14:40:02 So would vote to bring this up as topic next call or a github issue :) 14:40:15 if this group wants to specify good practices to help identify bad payment apps, that's another thing 14:40:19 q+ 14:40:20 q? 14:40:24 ...summary - payment methods identified by URLs...basic card an exception...browsers curate card-supporting payment apps 14:40:24 ack manu 14:40:24 manu, you wanted to ask if we're saying that payment method information (name, description, how to install, partners, etc.) are at the end of those URLs? Isn't this the key 14:40:28 ... question? 14:40:38 q+ 14:41:26 manu: I think it makes sense to identify payment apps...but if we make a decision that there is no metadata associated with a PMI, then it makes sense to have strings in a registry 14:41:49 q? 14:41:49 Yes, +1 14:42:04 ...is the main question whether we want machine-readable data? 14:43:02 the idea that we want something located at the URL was the most significant reason for me switching my preference to URL 14:43:11 q? 14:43:27 +1 to adrianba 14:44:10 +1 - I believe the group is in consensus we should use URLs and define a machine-readable resource that is at the end 14:44:20 We must evaluate the cost of this though 14:44:20 IJ: What ;is the cost of parsing "small set of strings or URLs" 14:44:30 zkoch: Not a problem. 14:44:44 ...ok to say simple strings for w3c-published identifiers 14:44:47 +1 to zkoch and AdrianHB 14:44:47 ..and URLs for other things 14:44:48 q? 14:44:50 ack me 14:44:50 Ian, you wanted to ask about parsing cost 14:44:51 q? 14:44:52 I can live with that but it isn't my preference 14:45:21 s/that/using strings instead of URNs/ 14:45:25 adamR: The choice of URNs isn't just so that we can say "All URIs"...other orgs may want to use URN space 14:45:31 That’s a fair points 14:45:36 s/points/point 14:45:40 +1 to adamR 14:45:41 ...if they want an identifier they don't want dereferenced, they too could use URNs 14:46:06 AdamR: Regarding browser curation of card-enabled payment apps gives me heartache. Whitelisting by browsers is antithetical to the open web 14:46:10 q? 14:46:11 Note that we have browsers curating lists of malware providers, I'd expect this to be the same. 14:46:12 ack ad 14:46:31 nicktr: I am also pretty uncomfortable making browsers more privileged than they need to be 14:46:31 ack zkoch 14:46:51 zkoch: I largely agree with Manu's characterization of the problem...whether something machine readable will live at the end of the URL 14:47:03 ...one thing that I propose is that there is not a dependency on the payment app spec 14:47:11 +1 to manu, but i don't want to see a situation where open payment methods are somehow a fundamentally worse experience for users than proprietary ones 14:47:19 ...I think we can write a proposal that both payment request and payment apps depend on 14:47:23 ...we define what lives at the end of this URL 14:47:28 which could arise depending on how app policing occurs. 14:47:31 ...could be used by registration spec and by browsers as well 14:47:32 +1 to define the manifest 14:47:51 q? 14:47:52 q+ 14:47:54 +1 14:48:46 q+ to note that he's hearing consensus - use URLs, define a manifest... then we can come back and see if we've made a horrible mistake... we're not in CR, we can try this out. 14:49:15 what's in the manifest? 14:49:26 q? 14:49:52 IJ: Payment app spec talks about identifying payment apps.... 14:49:57 NickTR, name, description, image - we'll have to decide that. 14:50:07 identify by URL and fetch URL to get machine readable data is a well known pattern, may work in a variety of places. 14:50:10 q+ to propose we resolve what the payment method identifier will not be to make progress 14:50:12 ack me 14:50:18 manu, metadate for the payment method or the app? 14:50:29 s/metadate/metadata/ 14:50:38 Several related/unrelated points (not taking airtime): 14:50:38 1) most in-app applications merchants create that I've seen use ACH, not cards. 14:50:38 2) I have heard criticism of the Payment Method Identifiers not reusing the codes used in ISO20022. So if URI are always followable, an easy (provable) translation to/from ISO would be a big help is assuaging concerns, and if that method doesn't require following (i.e. "machine readable") that might have lower overhead. 14:50:38 3) We (NACS) are not in favor of trading contractor lock-in (for merchants) for browser lock-in. 14:50:41 nicktr - why can't it be both? 14:50:42 q? 14:50:44 +1 on not blocking - if the payment apps proposal has requirements of PMIs then they should be explicitly stated, which was the feedback I gave at the F2F 14:50:57 zkoch: I think we can separate this out 14:51:43 zkoch: I still stand by the proposal to distinguish proprietary from open...and app and payment method. 14:52:49 q? 14:53:02 Not always a 1:1 mapping, just most of the time 14:53:03 IJ: I believe that blurring payment method and payment app will be a source of problem 14:53:24 AdrianHB: I agree that is a point of contention 14:54:19 ...and may have pragmatic consequences like using origin for security / etc. 14:54:26 present+ ShaneM 14:54:26 zkoch: Happy to have the conversation separately 14:54:39 ..and understand the exceptions (in the real world) 14:55:06 q? 14:55:23 adrianhb:I suggest we have the discussion in the payment app task force 14:55:34 zkoch: Meanwhile, let's see if we can independently define "what's at the end of the URL" 14:55:35 q+ 14:55:59 ack manu 14:55:59 manu, you wanted to note that he's hearing consensus - use URLs, define a manifest... then we can come back and see if we've made a horrible mistake... we're not in CR, we can try 14:56:00 zakim, close the queue 14:56:02 ... this out. 14:56:02 ok, Ian, the speaker queue is closed 14:56:08 manu: I am hearing consensus to use URLs 14:56:23 ...the only thing we need to see is the proposal for what is at the end 14:56:35 +1 manu 14:56:37 ack AdrianHB 14:56:37 AdrianHB, you wanted to propose we resolve what the payment method identifier will not be to make progress 14:56:40 +1 to developing a spec for what is at the end of a payment URL 14:56:50 adrianhb: +1 .... we need to resolve what will be at the end. 14:57:00 ...I think that's impacted by the payment apps work 14:57:39 PROPOSAL: W3C can mind short strings for some payment methods, otherwise URLs (which includes URNs) 14:57:47 -1 vague 14:57:48 -1 14:57:51 a URN isn't a URL :) 14:57:57 AdrianHB: URNs provide context outside of the browser 14:58:56 Note that my -1 was that I don't have a strong opinion of URN vs. short string UNLESS we take AdamR's comments into account (other organizations may want to use URNs) 14:59:27 IJ: We could also do short strings now and then mint URNs separately if we want 14:59:37 dlongley: wow - them's fightin' words 14:59:42 I also note that this whole debate is only because serving up HTTP URLs don't scale for smaller organizations. This whole issue would be taken care of if we were using something like IPFS :P 14:59:56 and we wouldn't be having this discussion... we'd be using URLs for everything. 15:00:04 (IPFS URLs) 15:00:12 Topic: TPAC Agenda 15:00:20 nicktr: Send us in your items 15:00:25 Topic: CFC extension 15:00:38 nicktr: Now 25 August based on Manu input 15:00:41 I have made the request to generate http://www.w3.org/2016/08/18-wpwg-minutes.html Ian 15:00:51 Manu's blog -> https://lists.w3.org/Archives/Public/public-payments-wg/2016Aug/0077.html 15:00:55 And please vote (editor's hat) 15:06:06 Max has joined #wpwg 15:07:26 rrsagent, make minutes 15:07:26 I have made the request to generate http://www.w3.org/2016/08/18-wpwg-minutes.html ShaneM 17:26:05 Zakim has left #wpwg 18:33:58 zkoch has joined #wpwg 19:17:05 sam has joined #wpwg 19:30:13 zkoch has joined #wpwg 20:06:50 adamlake has joined #wpwg 21:02:40 zkoch has joined #wpwg 21:37:46 adamlake has joined #wpwg 22:36:29 sam has joined #wpwg 23:03:51 zkoch has joined #wpwg 23:23:04 MikeSmith has left #wpwg