IRC log of wpwg on 2016-05-26
Timestamps are in UTC.
- 15:55:09 [RRSAgent]
- RRSAgent has joined #wpwg
- 15:55:09 [RRSAgent]
- logging to http://www.w3.org/2016/05/26-wpwg-irc
- 15:55:11 [trackbot]
- RRSAgent, make logs public
- 15:55:11 [Zakim]
- Zakim has joined #wpwg
- 15:55:13 [trackbot]
- Zakim, this will be
- 15:55:13 [Zakim]
- I don't understand 'this will be', trackbot
- 15:55:14 [trackbot]
- Meeting: Web Payments Working Group Teleconference
- 15:55:14 [trackbot]
- Date: 26 May 2016
- 15:55:17 [Ian]
- agenda: https://github.com/w3c/webpayments/wiki/Agenda-20160526
- 15:55:21 [Ian]
- Chair: AdrianHB
- 15:55:24 [Ian]
- Regrets: NickTR
- 15:57:15 [maheshk]
- maheshk has joined #wpwg
- 15:57:59 [Ian]
- scribe: Ian
- 15:58:55 [alyver]
- alyver has joined #wpwg
- 15:58:57 [AdrianHB]
- Present+ AdrianHB
- 15:59:04 [alyver]
- present+ alyver
- 15:59:11 [adamR]
- present+ adamR
- 15:59:57 [Ian]
- present+ Ian
- 15:59:59 [Ian]
- present+ Kevin
- 16:00:03 [Ian]
- present+ Mahesh
- 16:01:02 [manu]
- present+ Manu
- 16:01:03 [brian_s]
- brian_s has joined #WPWG
- 16:01:11 [Ian]
- present+ Brian
- 16:01:17 [dlongley]
- present+ dlongley
- 16:01:18 [MattS]
- MattS has joined #wpwg
- 16:03:11 [ShaneM]
- present+ ShaneM
- 16:04:40 [AdrianHB]
- https://github.com/w3c/webpayments/wiki/Agenda-20160526
- 16:04:56 [MikeSmith]
- MikeSmith has joined #wpwg
- 16:05:42 [Ian]
- scribe: Ian
- 16:05:50 [RRSAgent]
- I have made the request to generate http://www.w3.org/2016/05/26-wpwg-minutes.html Ian
- 16:05:55 [Ian]
- rrsagent, set logs public
- 16:06:26 [Ian]
- Topic: Payment Method Identifiers
- 16:06:36 [Ian]
- Topic: FTF meeting
- 16:06:44 [Ian]
- Registration -> https://www.w3.org/2002/09/wbs/83744/wpwgftf-201607/
- 16:06:44 [manu]
- s/Topic: Payment Method Identifiers//
- 16:07:32 [Ian]
- adrianHB: register and get your hotel quickly
- 16:07:49 [Ian]
- candiate topics -> https://github.com/w3c/webpayments/wiki/Web-Payments-Working-Group-FTF-Meeting-%28July-2016%29#candidate-topics
- 16:07:54 [Ian]
- q+
- 16:08:01 [Ian]
- q-
- 16:08:13 [Ian]
- zakim, who's here?
- 16:08:13 [Zakim]
- Present: AdrianHB, alyver, adamR, Ian, Kevin, Mahesh, Manu, Brian, dlongley, ShaneM
- 16:08:15 [Zakim]
- 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 [Zakim]
- ... wseltzer, trackbot, dlehn, AdrianHB, adrianba, davidillsley, dwim_
- 16:08:19 [Ian]
- regrets: Zach
- 16:08:39 [Ian]
- Topic: On issue triage
- 16:08:47 [Ian]
- adrianhb: We are using "milestones" in issues list
- 16:09:03 [Ian]
- ...if you want to know "what's coming up" then milestones is a good place to start
- 16:09:29 [Ian]
- ...furthermore, "help wanted" label is a standard github label...that means "we need a proposal"
- 16:09:41 [Ian]
- ...proposal can range from text in the thread to a pull request
- 16:10:10 [Roy]
- Roy has joined #wpwg
- 16:10:14 [Ian]
- ...."High priority" issues also helpful to look at. I am managing that prioritization
- 16:11:04 [AdrianHB]
- q?
- 16:11:15 [Ian]
- topic: Do we need short names?
- 16:11:35 [Ian]
- rrsagent, make minutes
- 16:11:35 [RRSAgent]
- I have made the request to generate http://www.w3.org/2016/05/26-wpwg-minutes.html Ian
- 16:11:48 [Ian]
- AdrianHB: Motivation is reduced verbosity in payment request input data
- 16:12:28 [Ian]
- ..the urgency for these goes up (perhaps) if we do grouping semantics
- 16:12:37 [manu]
- q+ to provide concrete PROPOSAL: Do not support aliases or grouping semantics in Web Payments v1.
- 16:12:42 [adamR]
- q+
- 16:12:58 [apaliga]
- apaliga has joined #wpwg
- 16:13:27 [Ian]
- manu: Aliases seem like they make it easier for developer. I suggest no aliases in v1.
- 16:13:45 [dlongley]
- q+ to say libraries can do the conversion
- 16:13:48 [dlongley]
- q-
- 16:14:01 [Ian]
- manu: People could create aliases in libraries that use the payment request API
- 16:14:23 [dlongley]
- helper.paymentMethods('visa', 'mastercard', ...) => ["https://visa.com/basic-card/..., ...]
- 16:14:31 [adamR]
- dlongley: +1
- 16:15:06 [adrianba]
- q+
- 16:15:11 [manu]
- q-
- 16:15:22 [Ian]
- adrianhb: Does anybody think there is a need for short names/aliases other than for reducing verbosity?
- 16:15:33 [Ian]
- ack ad
- 16:15:49 [dlongley]
- +1 to adamR
- 16:15:49 [adamR]
- q-
- 16:15:49 [Ian]
- adamR: I don't see a need for them. People are copy and pasting
- 16:15:53 [manu]
- +1 to adamR
- 16:16:05 [MattS]
- MattS has joined #wpwg
- 16:16:32 [Ian]
- adrianba: Our original motivation was not strictly about verbosity, it was more about short names for common things
- 16:17:04 [Ian]
- adrianba: And that having a short name (without a domain) would allow us to bootstrap the mechanism
- 16:17:05 [Ian]
- q+
- 16:17:39 [Ian]
- adrianba: I agree with Manu's proposal to not support short names in v1
- 16:18:28 [manu]
- We can always re-open an issue if there is new information.
- 16:19:01 [manu]
- ahh, the good old "vote on it while the proposer is getting married" spec attack.
- 16:19:04 [MattS]
- q+
- 16:19:22 [Ian]
- PROPOSED: No short names/aliases for PMIs in v1
- 16:19:37 [Ian]
- MattS: What does that mean in practice for ubiquitous payment method identifiers?
- 16:20:08 [manu]
- 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 [Ian]
- IJ: MattS has a proposal about generic card spec.
- 16:20:36 [manu]
- MattS: How do these new URLs get minted?
- 16:20:45 [manu]
- We could mint them as URNs *ducks*
- 16:20:47 [Ian]
- MattS: But there has been pushback about using w3.org for URLs that we mint.
- 16:21:13 [Ian]
- 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 [Ian]
- MattS: Yes, that will push the concern to another issue.
- 16:21:41 [dlongley]
- +1
- 16:21:42 [Ian]
- +1
- 16:21:43 [manu]
- +1
- 16:21:44 [AdrianHB]
- +1
- 16:21:44 [MattS]
- +1
- 16:21:49 [adamR]
- +1
- 16:21:49 [dlehn]
- +1
- 16:21:50 [Roy]
- +1
- 16:21:50 [brian_s]
- +1
- 16:21:52 [adrianba]
- +1
- 16:21:55 [ShaneM]
- +1
- 16:21:58 [Ian]
- RESOLVED: No short names/aliases for PMIs in v1
- 16:22:15 [apaliga]
- +1
- 16:22:45 [Ian]
- Topic: Grouping/subclassing semantics (and matching algorithm)
- 16:23:01 [Ian]
- https://github.com/w3c/webpayments/wiki/PMI_Notes
- 16:23:16 [manu]
- q+ to put forward a concrete proposal: Do not support grouping semantics in v1.
- 16:23:30 [alyver]
- also having difficulty.
- 16:24:15 [manu]
- 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 [manu]
- Ian: Allow people to say "I accept any kind of debit card" - more abstract use cases.
- 16:25:03 [manu]
- 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]
- Marta has joined #wpwg
- 16:25:50 [adamR]
- q+
- 16:25:52 [manu]
- 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 [manu]
- ack Ian
- 16:26:30 [manu]
- 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 [manu]
- Ian: In the very early implementations of payment request API, people will demand this.
- 16:27:07 [Ian]
- ack m
- 16:27:07 [Zakim]
- manu, you wanted to put forward a concrete proposal: Do not support grouping semantics in v1.
- 16:27:35 [Ian]
- 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 [AdrianHB]
- q+ to say we already kind of support grouping, just we do it badly
- 16:28:08 [Ian]
- Manu: Some ideas:
- 16:28:15 [Ian]
- 1) Have a URL reference a list of URLs
- 16:28:43 [Ian]
- 2) Have a js library that can expand a single URL into N URLs. This library can be expanded automatically.
- 16:28:53 [Ian]
- -1 to requiring a library to use the system
- 16:29:04 [dlongley]
- helperLibrary.accept('X').exclude(['Y', 'Z']) => [...]
- 16:29:22 [dlongley]
- not *required*, just makes it easier.
- 16:29:23 [brian_s]
- brian_s has joined #WPWG
- 16:29:28 [Marta_]
- Marta_ has joined #wpwg
- 16:29:31 [Ian]
- Manu: You don't _have_ to use a library...you can specify all the PMIs if you want to
- 16:29:41 [Ian]
- ...my concern is that we are trying to solve a problem we don't aver a firm grasp on.
- 16:29:52 [adrianba]
- +1 - this doesn't seem like minimum viable functionality
- 16:30:04 [brian_s]
- q+
- 16:30:19 [MattS]
- q+
- 16:30:22 [MattS]
- q-
- 16:30:23 [MattS]
- q+
- 16:30:36 [Ian]
- adamR: I think Matt has made a good case for going down this path.
- 16:31:03 [Ian]
- ...what about using regexps as input?
- 16:31:17 [manu]
- -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 [MattS]
- -1 to regexs
- 16:31:31 [Ian]
- I also think regexps may be overkill
- 16:31:34 [manu]
- ack adamR
- 16:31:36 [manu]
- ack AdrianHB
- 16:31:36 [Zakim]
- AdrianHB, you wanted to say we already kind of support grouping, just we do it badly
- 16:32:15 [Ian]
- adrianhb: The way we are doing PMIs already today ... we kind of support grouping.
- 16:32:27 [ShaneM]
- https://xkcd.com/208/
- 16:33:39 [Ian]
- 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 [Ian]
- ...as filters
- 16:34:10 [AdrianHB]
- q?
- 16:34:17 [Ian]
- 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 [Ian]
- brian_s: In Europe this is a hot topic of conversation.
- 16:34:45 [Ian]
- ...regulation allows merchants to say "I except all these card types EXCEPT these types"
- 16:34:53 [manu]
- ack brian_s
- 16:34:59 [Ian]
- ...one question .. .if we say this capability may not be in v1, what's the time scale for the next version?
- 16:35:24 [Ian]
- adrianhb: Good points...there ARE use cases here (e.g., from Europe)
- 16:35:33 [Ian]
- q?
- 16:35:44 [Ian]
- ....the second point is when is v2?
- 16:36:23 [Ian]
- 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 [Ian]
- will meet our use cases.
- 16:36:34 [AdrianHB]
- ?
- 16:36:37 [ShaneM]
- I don't think we "mint" any URLs
- 16:36:39 [AdrianHB]
- q?
- 16:36:42 [Ian]
- ack mattS
- 16:36:43 [AdrianHB]
- ack matts
- 16:36:43 [Ian]
- q+
- 16:37:04 [manu]
- q+ to say that the problem can be addressed in v1 w/ helper libraries.
- 16:37:05 [Ian]
- 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 [Ian]
- MattS: There's a clear use case in my region for distinguishing debit and credit
- 16:38:04 [manu]
- ack Ian
- 16:38:04 [Ian]
- AdrianHB:I am hearing mix of "push it down the road" and "there are clear use cases"
- 16:38:24 [adrianba]
- 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 [manu]
- Ian: At a high-level, I think there is enough mixed views that I prefer that we not close this today.
- 16:38:46 [adamR]
- q+
- 16:38:59 [MattS]
- q+
- 16:39:04 [MattS]
- q-
- 16:39:13 [manu]
- 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 [MattS]
- 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 [manu]
- 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 [manu]
- g.
- 16:40:47 [AdrianHB]
- q+
- 16:41:11 [manu]
- 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 [Ian]
- adrianhb: I think we need pretty rigorous standardization here. The mediator behavior needs to be well-specified.
- 16:41:48 [MattS]
- +1 to Adrians point on needing this to be rigourous
- 16:41:55 [Ian]
- ack manu
- 16:41:55 [Zakim]
- manu, you wanted to say that the problem can be addressed in v1 w/ helper libraries.
- 16:42:08 [Ian]
- manu: I'd like to push the group to make a preliminary decision today.
- 16:42:23 [Ian]
- ...maybe we can hear from people on IRC.
- 16:42:35 [adamR]
- I think we’re not operating from the same set of information, though.
- 16:42:55 [Ian]
- PROPOSED: Do not support grouping/subclassing in v1.
- 16:43:30 [Ian]
- q?
- 16:43:36 [Ian]
- ack Adam
- 16:43:54 [AdrianHB]
- q-
- 16:44:18 [Ian]
- 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 [MattS]
- there is no entire list, that is the problem, it is volatile
- 16:44:41 [manu]
- ... which is why I don't think we should create grouping semantics over a list that's volatile.
- 16:44:50 [Ian]
- See also Zach's list -> https://lists.w3.org/Archives/Public/public-payments-wg/2016May/0018.html
- 16:45:02 [Ian]
- AdrianHB: Granularity is changing (in EU)
- 16:45:03 [MattS]
- I am happy to put together a good set of example use cases though
- 16:45:16 [Ian]
- ...card payment landscape has changed in past few years
- 16:45:27 [MattS]
- I can also put together some non cards examples
- 16:45:40 [Ian]
- ...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 [Ian]
- q?
- 16:46:04 [Ian]
- PROPOSED: Do not support grouping/subclassing in v1.
- 16:46:05 [Ian]
- -1
- 16:46:06 [alyver]
- MattS, I would be happy to help you with the use cases.
- 16:46:06 [AdrianHB]
- -1
- 16:46:07 [manu]
- +1
- 16:46:08 [dlongley]
- +1
- 16:46:11 [adamR]
- 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 [brian_s]
- Matt: I can help from the Visa side (not next week though as i'm on holiday)
- 16:46:17 [adrianba]
- +1
- 16:46:26 [ShaneM_]
- ShaneM_ has joined #wpwg
- 16:46:32 [ShaneM_]
- +1
- 16:46:36 [MattS]
- +0, look after the use cases
- 16:46:36 [adamR]
- So I’m not + or - : I think it’s not the right time to call the question
- 16:46:42 [alyver]
- +1
- 16:46:44 [brian_s]
- -1
- 16:47:08 [manu]
- Thanks - that helps me see that we don't have consensus in the group yet.
- 16:47:09 [Ian]
- total: -3, +5, 2x0
- 16:47:16 [Roy]
- -1
- 16:47:30 [Ian]
- adrianhb: I suggest people make further proposals.
- 16:48:30 [MattS]
- q+
- 16:48:34 [Ian]
- ack mat
- 16:48:58 [Ian]
- MattS: I can put together some example use cases and bring back to the WG.
- 16:49:13 [Ian]
- ...that should help get us on the same page.
- 16:49:19 [Ian]
- ...I appreciate this is a complex problem domain
- 16:49:31 [Ian]
- ...I hear people saying "too complex" rather than "not useful"
- 16:49:54 [Ian]
- AdrianHB: See my proposal https://github.com/w3c/browser-payment-api/issues/205
- 16:50:19 [Ian]
- ..there are some bits in there about matching (e.g., ignore domain name)
- 16:51:01 [Ian]
- ...payment method may not be defined by the payment method URL owner.
- 16:51:08 [Ian]
- ...I heard a lot of push-back on .well-known.
- 16:51:19 [Ian]
- ...but perhaps the most important part of the proposal is to use query params
- 16:51:41 [Ian]
- q+
- 16:52:03 [Ian]
- ..proposal does not include a "not" operator
- 16:52:08 [Ian]
- ..could be added
- 16:52:21 [Ian]
- ...I will revise my proposal
- 16:52:34 [manu]
- ack Ian
- 16:53:56 [manu]
- 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 [manu]
- Ian: As an editor, does that give you things you can do on the spec.
- 16:55:22 [AdrianHB]
- q+
- 16:55:47 [manu]
- 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 [manu]
- 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 [manu]
- adrianba: We may end up dereferencing.
- 16:56:59 [manu]
- ack AdrianHB
- 16:57:32 [manu]
- AdrianHB: We have consensus on not using aliases for now.
- 16:57:57 [Ian]
- Topic: Payment Apps Task Force
- 16:58:13 [Ian]
- adrianhb: Payment Apps task force (ad-hoc) has formed in the past 2 weeks.
- 16:58:25 [Ian]
- ...we met last week and Ian will coordinate moving forward (among editors)
- 16:58:35 [Ian]
- ..we are preparing to bring a proposal to the group
- 16:58:43 [Ian]
- ...it's happening in the proposals folder on github
- 16:58:58 [Ian]
- ...Tommy has posted a few things to the list and is working on a polyfill
- 16:59:18 [Ian]
- ..if you'd like to join the discussion, let Ian know
- 16:59:32 [Ian]
- Topic: Reminder to register!
- 16:59:36 [Ian]
- Topic: Next meeting
- 16:59:44 [Ian]
- 2 June
- 16:59:53 [Ian]
- rrsagent, make minutes
- 16:59:53 [RRSAgent]
- I have made the request to generate http://www.w3.org/2016/05/26-wpwg-minutes.html Ian
- 16:59:58 [Ian]
- rrsagent, set logs public
- 17:03:15 [alyver]
- alyver has joined #wpwg
- 17:07:32 [alyver]
- alyver has joined #wpwg
- 17:09:41 [Ian]
- zakim, who's here?
- 17:09:41 [Zakim]
- Present: AdrianHB, alyver, adamR, Ian, Kevin, Mahesh, Manu, Brian, dlongley, ShaneM
- 17:09:43 [Zakim]
- 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 [Zakim]
- ... schuki_, wseltzer, trackbot, dlehn, AdrianHB, adrianba, davidillsley, dwim_
- 17:10:23 [alyver]
- alyver has left #wpwg
- 17:16:42 [MattS]
- MattS has left #wpwg
- 19:15:14 [Zakim]
- Zakim has left #wpwg