15:55:09 RRSAgent has joined #wpwg 15:55:09 logging to http://www.w3.org/2016/05/26-wpwg-irc 15:55:11 RRSAgent, make logs public 15:55:11 Zakim has joined #wpwg 15:55:13 Zakim, this will be 15:55:13 I don't understand 'this will be', trackbot 15:55:14 Meeting: Web Payments Working Group Teleconference 15:55:14 Date: 26 May 2016 15:55:17 agenda: https://github.com/w3c/webpayments/wiki/Agenda-20160526 15:55:21 Chair: AdrianHB 15:55:24 Regrets: NickTR 15:57:15 maheshk has joined #wpwg 15:57:59 scribe: Ian 15:58:55 alyver has joined #wpwg 15:58:57 Present+ AdrianHB 15:59:04 present+ alyver 15:59:11 present+ adamR 15:59:57 present+ Ian 15:59:59 present+ Kevin 16:00:03 present+ Mahesh 16:01:02 present+ Manu 16:01:03 brian_s has joined #WPWG 16:01:11 present+ Brian 16:01:17 present+ dlongley 16:01:18 MattS has joined #wpwg 16:03:11 present+ ShaneM 16:04:40 https://github.com/w3c/webpayments/wiki/Agenda-20160526 16:04:56 MikeSmith has joined #wpwg 16:05:42 scribe: Ian 16:05:50 I have made the request to generate http://www.w3.org/2016/05/26-wpwg-minutes.html Ian 16:05:55 rrsagent, set logs public 16:06:26 Topic: Payment Method Identifiers 16:06:36 Topic: FTF meeting 16:06:44 Registration -> https://www.w3.org/2002/09/wbs/83744/wpwgftf-201607/ 16:06:44 s/Topic: Payment Method Identifiers// 16:07:32 adrianHB: register and get your hotel quickly 16:07:49 candiate topics -> https://github.com/w3c/webpayments/wiki/Web-Payments-Working-Group-FTF-Meeting-%28July-2016%29#candidate-topics 16:07:54 q+ 16:08:01 q- 16:08:13 zakim, who's here? 16:08:13 Present: AdrianHB, alyver, adamR, Ian, Kevin, Mahesh, Manu, Brian, dlongley, ShaneM 16:08:15 On IRC I see MikeSmith, MattS, brian_s, alyver, maheshk, Zakim, RRSAgent, Adam_, shepazu, ShaneM, manu, adamR, collier-matthew, dlongley, slightlyoff, mkwst, Ian, hober, schuki_, 16:08:15 ... wseltzer, trackbot, dlehn, AdrianHB, adrianba, davidillsley, dwim_ 16:08:19 regrets: Zach 16:08:39 Topic: On issue triage 16:08:47 adrianhb: We are using "milestones" in issues list 16:09:03 ...if you want to know "what's coming up" then milestones is a good place to start 16:09:29 ...furthermore, "help wanted" label is a standard github label...that means "we need a proposal" 16:09:41 ...proposal can range from text in the thread to a pull request 16:10:10 Roy has joined #wpwg 16:10:14 ...."High priority" issues also helpful to look at. I am managing that prioritization 16:11:04 q? 16:11:15 topic: Do we need short names? 16:11:35 rrsagent, make minutes 16:11:35 I have made the request to generate http://www.w3.org/2016/05/26-wpwg-minutes.html Ian 16:11:48 AdrianHB: Motivation is reduced verbosity in payment request input data 16:12:28 ..the urgency for these goes up (perhaps) if we do grouping semantics 16:12:37 q+ to provide concrete PROPOSAL: Do not support aliases or grouping semantics in Web Payments v1. 16:12:42 q+ 16:12:58 apaliga has joined #wpwg 16:13:27 manu: Aliases seem like they make it easier for developer. I suggest no aliases in v1. 16:13:45 q+ to say libraries can do the conversion 16:13:48 q- 16:14:01 manu: People could create aliases in libraries that use the payment request API 16:14:23 helper.paymentMethods('visa', 'mastercard', ...) => ["https://visa.com/basic-card/..., ...] 16:14:31 dlongley: +1 16:15:06 q+ 16:15:11 q- 16:15:22 adrianhb: Does anybody think there is a need for short names/aliases other than for reducing verbosity? 16:15:33 ack ad 16:15:49 +1 to adamR 16:15:49 q- 16:15:49 adamR: I don't see a need for them. People are copy and pasting 16:15:53 +1 to adamR 16:16:05 MattS has joined #wpwg 16:16:32 adrianba: Our original motivation was not strictly about verbosity, it was more about short names for common things 16:17:04 adrianba: And that having a short name (without a domain) would allow us to bootstrap the mechanism 16:17:05 q+ 16:17:39 adrianba: I agree with Manu's proposal to not support short names in v1 16:18:28 We can always re-open an issue if there is new information. 16:19:01 ahh, the good old "vote on it while the proposer is getting married" spec attack. 16:19:04 q+ 16:19:22 PROPOSED: No short names/aliases for PMIs in v1 16:19:37 MattS: What does that mean in practice for ubiquitous payment method identifiers? 16:20:08 Ian: Meanwhile, Matt Saxxon has a proposal - more generic URL for card payments in most payments even if we don't get card brands to publish those specs. 16:20:31 IJ: MattS has a proposal about generic card spec. 16:20:36 MattS: How do these new URLs get minted? 16:20:45 We could mint them as URNs *ducks* 16:20:47 MattS: But there has been pushback about using w3.org for URLs that we mint. 16:21:13 AdrianHB: I think this proposal is independent of those questions. We won't have "visa" as a short name, but we still need to address the question of well-understood identifiers. 16:21:21 MattS: Yes, that will push the concern to another issue. 16:21:41 +1 16:21:42 +1 16:21:43 +1 16:21:44 +1 16:21:44 +1 16:21:49 +1 16:21:49 +1 16:21:50 +1 16:21:50 +1 16:21:52 +1 16:21:55 +1 16:21:58 RESOLVED: No short names/aliases for PMIs in v1 16:22:15 +1 16:22:45 Topic: Grouping/subclassing semantics (and matching algorithm) 16:23:01 https://github.com/w3c/webpayments/wiki/PMI_Notes 16:23:16 q+ to put forward a concrete proposal: Do not support grouping semantics in v1. 16:23:30 also having difficulty. 16:24:15 Ian: We want people to be able to specify a high-levle matching mechanism - not URL matching - we want a subbrand to match a higher level brand. 16:24:28 Ian: Allow people to say "I accept any kind of debit card" - more abstract use cases. 16:25:03 Ian: I was at card not present expo talking this week - talking to merchants - they're quite keen on this functionality. It's a bit complex to implement, makes matching harder, URI equivalence testing becomes more difficult. 16:25:45 Marta has joined #wpwg 16:25:50 q+ 16:25:52 Ian: Matt came up with a first version of an idea - let's do it as URL paths - /brand/subbrand/ - but that turns out to be a bit brittle. It doesn't allow you to express the full graph semantics, but may be able to address a couple of use cases. You could do graph matching semantics by using query parameters. 16:25:56 ack Ian 16:26:30 Ian: We can catch the use case by saying "visa but not electron" via another way instead of URL semantics - where you say "I do not support this". If you have grouping, being able to exclude items from the group becomes important. 16:27:00 Ian: In the very early implementations of payment request API, people will demand this. 16:27:07 ack m 16:27:07 manu, you wanted to put forward a concrete proposal: Do not support grouping semantics in v1. 16:27:35 Manu: Concrete proposal is to not support grouping semantics in v1. I think there is a better solution to the problem via helper libraries. I'm not sure we have a handle on what we want to do. 16:28:03 q+ to say we already kind of support grouping, just we do it badly 16:28:08 Manu: Some ideas: 16:28:15 1) Have a URL reference a list of URLs 16:28:43 2) Have a js library that can expand a single URL into N URLs. This library can be expanded automatically. 16:28:53 -1 to requiring a library to use the system 16:29:04 helperLibrary.accept('X').exclude(['Y', 'Z']) => [...] 16:29:22 not *required*, just makes it easier. 16:29:23 brian_s has joined #WPWG 16:29:28 Marta_ has joined #wpwg 16:29:31 Manu: You don't _have_ to use a library...you can specify all the PMIs if you want to 16:29:41 ...my concern is that we are trying to solve a problem we don't aver a firm grasp on. 16:29:52 +1 - this doesn't seem like minimum viable functionality 16:30:04 q+ 16:30:19 q+ 16:30:22 q- 16:30:23 q+ 16:30:36 adamR: I think Matt has made a good case for going down this path. 16:31:03 ...what about using regexps as input? 16:31:17 -1 to regexes - developers have a hard time w/ them, especially when they don't know the universe of text that's being searched. 16:31:27 -1 to regexs 16:31:31 I also think regexps may be overkill 16:31:34 ack adamR 16:31:36 ack AdrianHB 16:31:36 AdrianHB, you wanted to say we already kind of support grouping, just we do it badly 16:32:15 adrianhb: The way we are doing PMIs already today ... we kind of support grouping. 16:32:27 https://xkcd.com/208/ 16:33:39 adrianhb: The idea of my proposal is to use a PMI as a "top level brand" and use query params for subclasses 16:33:41 ...as filters 16:34:10 q? 16:34:17 adrianhb: We want multiple URLs to be able to point to the same PM spec, which is a kind of implicit groupings 16:34:27 brian_s: In Europe this is a hot topic of conversation. 16:34:45 ...regulation allows merchants to say "I except all these card types EXCEPT these types" 16:34:53 ack brian_s 16:34:59 ...one question .. .if we say this capability may not be in v1, what's the time scale for the next version? 16:35:24 adrianhb: Good points...there ARE use cases here (e.g., from Europe) 16:35:33 q? 16:35:44 ....the second point is when is v2? 16:36:23 MattS: We are removing functionality and saying "it can be in v2" but we've not minted any URLs yet in our specs, so we don't know whether they 16:36:27 will meet our use cases. 16:36:34 ? 16:36:37 I don't think we "mint" any URLs 16:36:39 q? 16:36:42 ack mattS 16:36:43 ack matts 16:36:43 q+ 16:37:04 q+ to say that the problem can be addressed in v1 w/ helper libraries. 16:37:05 MattS: I am +1 to the proposal but I think we need to mint actual URLs to see if they meet our needs. 16:37:16 MattS: There's a clear use case in my region for distinguishing debit and credit 16:38:04 ack Ian 16:38:04 AdrianHB:I am hearing mix of "push it down the road" and "there are clear use cases" 16:38:24 I think we should say we not support it in v1 (motivation is keep it simpler) but new information as MattS describes could re-open this 16:38:31 Ian: At a high-level, I think there is enough mixed views that I prefer that we not close this today. 16:38:46 q+ 16:38:59 q+ 16:39:04 q- 16:39:13 Ian: More concretely, I'm wondering if there is a happy medium - first hypothesis is that this is only relevant for cards, not sure it's relevant, but will assume it is for this call. 16:40:07 I don't think this is only relevant for cards. I am using that example because 1) it is our only spec today 2) the non cards ecosystem has not expanded sufficient to make it clear this is needed. I can give some clear examples of how we might see this expand in the future which needs the grouping 16:40:29 Ian: If you want to refer to a top-level brand, you always use the top URL plus something else - we don't specify what the other thing is, we let the payment apps figure it out. People could experiment w/ query parameters, recognize there is an issue, provide guidance. What this would mean in practice - use case #2 - merchant announces A, user announces B which is a subclass of A. It still doesn't catch the NOT case. I'm inclined to push for that for the time bein 16:40:29 g. 16:40:47 q+ 16:41:11 Ian: It may be an optional parameter in the API - much of the time people may not use it. But that would help you continue to do simple URL matching. More modest matching - want us to think more about it. Maybe there is a path forward that helps a modicum of standardization that lets us experiment. 16:41:34 adrianhb: I think we need pretty rigorous standardization here. The mediator behavior needs to be well-specified. 16:41:48 +1 to Adrians point on needing this to be rigourous 16:41:55 ack manu 16:41:55 manu, you wanted to say that the problem can be addressed in v1 w/ helper libraries. 16:42:08 manu: I'd like to push the group to make a preliminary decision today. 16:42:23 ...maybe we can hear from people on IRC. 16:42:35 I think we’re not operating from the same set of information, though. 16:42:55 PROPOSED: Do not support grouping/subclassing in v1. 16:43:30 q? 16:43:36 ack Adam 16:43:54 q- 16:44:18 adamR: People have different ideas of what the set of identifiers for cards will look like. I propose that if we can find someone who is sufficiently familiar with payment types to put together what the entire list of PMIs might look like at this time, that might inform the decision 16:44:19 there is no entire list, that is the problem, it is volatile 16:44:41 ... which is why I don't think we should create grouping semantics over a list that's volatile. 16:44:50 See also Zach's list -> https://lists.w3.org/Archives/Public/public-payments-wg/2016May/0018.html 16:45:02 AdrianHB: Granularity is changing (in EU) 16:45:03 I am happy to put together a good set of example use cases though 16:45:16 ...card payment landscape has changed in past few years 16:45:27 I can also put together some non cards examples 16:45:40 ...there are laws being introduced that are forcing the system to become more open and our API needs to be accepting of the granularity required. 16:45:41 q? 16:46:04 PROPOSED: Do not support grouping/subclassing in v1. 16:46:05 -1 16:46:06 MattS, I would be happy to help you with the use cases. 16:46:06 -1 16:46:07 +1 16:46:08 +1 16:46:11 Ian: If the list we’re operating on is O(12) entries long, then I think enumerating is fine. If it’s O(100), then I think there’s a very different answer. 16:46:13 Matt: I can help from the Visa side (not next week though as i'm on holiday) 16:46:17 +1 16:46:26 ShaneM_ has joined #wpwg 16:46:32 +1 16:46:36 +0, look after the use cases 16:46:36 So I’m not + or - : I think it’s not the right time to call the question 16:46:42 +1 16:46:44 -1 16:47:08 Thanks - that helps me see that we don't have consensus in the group yet. 16:47:09 total: -3, +5, 2x0 16:47:16 -1 16:47:30 adrianhb: I suggest people make further proposals. 16:48:30 q+ 16:48:34 ack mat 16:48:58 MattS: I can put together some example use cases and bring back to the WG. 16:49:13 ...that should help get us on the same page. 16:49:19 ...I appreciate this is a complex problem domain 16:49:31 ...I hear people saying "too complex" rather than "not useful" 16:49:54 AdrianHB: See my proposal https://github.com/w3c/browser-payment-api/issues/205 16:50:19 ..there are some bits in there about matching (e.g., ignore domain name) 16:51:01 ...payment method may not be defined by the payment method URL owner. 16:51:08 ...I heard a lot of push-back on .well-known. 16:51:19 ...but perhaps the most important part of the proposal is to use query params 16:51:41 q+ 16:52:03 ..proposal does not include a "not" operator 16:52:08 ..could be added 16:52:21 ...I will revise my proposal 16:52:34 ack Ian 16:53:56 Ian: I'd like to propose a set of edits on the PMI spec based on consensus views - I think we have pretty much agreed - we're not going to do aliases or dereference the URL that is used as a PMI. The spec can be clear that the primary purpose for using URLs are for identification. The spec doesn't define what happens when you derefernce the URLs. We're close on syntax. 16:54:05 Ian: As an editor, does that give you things you can do on the spec. 16:55:22 q+ 16:55:47 adrianba: I can change a few small things - like around aliases. Zack and I were talking about the structure of the URLs. So, we may not have consensus on that. 16:56:26 Ian: Maybe practices are their own thing, but I'm hearing you say that there isn't consensus yet - you think there is possibility of conformance that we dereference the URL and get something from there? 16:56:33 adrianba: We may end up dereferencing. 16:56:59 ack AdrianHB 16:57:32 AdrianHB: We have consensus on not using aliases for now. 16:57:57 Topic: Payment Apps Task Force 16:58:13 adrianhb: Payment Apps task force (ad-hoc) has formed in the past 2 weeks. 16:58:25 ...we met last week and Ian will coordinate moving forward (among editors) 16:58:35 ..we are preparing to bring a proposal to the group 16:58:43 ...it's happening in the proposals folder on github 16:58:58 ...Tommy has posted a few things to the list and is working on a polyfill 16:59:18 ..if you'd like to join the discussion, let Ian know 16:59:32 Topic: Reminder to register! 16:59:36 Topic: Next meeting 16:59:44 2 June 16:59:53 rrsagent, make minutes 16:59:53 I have made the request to generate http://www.w3.org/2016/05/26-wpwg-minutes.html Ian 16:59:58 rrsagent, set logs public 17:03:15 alyver has joined #wpwg 17:07:32 alyver has joined #wpwg 17:09:41 zakim, who's here? 17:09:41 Present: AdrianHB, alyver, adamR, Ian, Kevin, Mahesh, Manu, Brian, dlongley, ShaneM 17:09:43 On IRC I see alyver, ShaneM_, MattS, Roy, MikeSmith, maheshk, Zakim, RRSAgent, Adam_, shepazu, ShaneM, manu, adamR, collier-matthew, dlongley, slightlyoff, mkwst, Ian, hober, 17:09:43 ... schuki_, wseltzer, trackbot, dlehn, AdrianHB, adrianba, davidillsley, dwim_ 17:10:23 alyver has left #wpwg 17:16:42 MattS has left #wpwg 19:15:14 Zakim has left #wpwg