14:58:31 <RRSAgent> RRSAgent has joined #wpwg
14:58:31 <RRSAgent> logging to http://www.w3.org/2017/03/09-wpwg-irc
14:58:33 <trackbot> RRSAgent, make logs public
14:58:33 <Zakim> Zakim has joined #wpwg
14:58:35 <trackbot> Zakim, this will be
14:58:35 <Zakim> I don't understand 'this will be', trackbot
14:58:36 <trackbot> Meeting: Web Payments Working Group Teleconference
14:58:36 <trackbot> Date: 09 March 2017
14:58:43 <Ian> agenda: https://github.com/w3c/webpayments/wiki/Agenda-20170309
14:58:45 <Ian> Chair: Nick
14:58:50 <Ian> Scribe: Ian
14:59:22 <pascal_bazin> pascal_bazin has joined #wpwg
15:01:32 <oyiptong> present+
15:01:43 <MattPi> MattPi has joined #wpwg
15:02:10 <Ian> present+
15:02:28 <rouslan> rouslan has joined #wpwg
15:02:31 <Ian> present+ stan
15:02:31 <rouslan> present+
15:02:32 <Guest91> Guest91 has joined #wpwg
15:02:41 <Ian> present+ AdrianHB
15:02:45 <MattS> MattS has joined #wpwg
15:02:46 <spolu> present+
15:02:51 <MattPi> present+
15:02:52 <MattS> present+ MattS
15:03:24 <zkoch> zkoch has joined #wpwg
15:03:28 <zkoch> present+
15:03:52 <vkuntz> vkuntz has joined #wpwg
15:03:58 <Ian> ->  https://github.com/w3c/webpayments/wiki/Agenda-20170309 Agenda
15:03:59 <vkuntz> present+
15:04:05 <adamR> present+
15:04:10 <Ian> present+ Christian
15:04:54 <Ian> topic:
15:04:54 <Ian> Topic: DST
15:04:58 <pascal_bazin> present+
15:05:46 <Ian> Next week's call one hour earlier for EU's
15:06:25 <Ian> topic: Payment Request API
15:07:05 <Ian> (On filtering)
15:07:40 <vkuntz> vkuntz has joined #wpwg
15:07:43 <Ian> AdrianHB: Other than "where the data is specified" we want to understand whether it's possible to have filters that are not a predefined set of enums.
15:07:48 <vkuntz> present+
15:07:57 <Ian> ...can the ecosystem start to use a filter, or are browsers required to roll out filters as they emerge?
15:08:03 <Ian> ...that has impact on the card network list
15:08:08 <Ian> q+
15:08:25 <Ian> present+ manash
15:08:44 <AdrianHB> ian: have had a few conversations on this
15:09:11 <AdrianHB> ... want to discuss the filtering in general and the networks list seperately
15:09:37 <AdrianHB> ... there is some value to the list beyond a hard coded list of filters
15:10:05 <AdrianHB> ... we want to allow apps to express capabilities and for browsers to consider these
15:10:30 <molly> molly has joined #wpwg
15:10:42 <AdrianHB> ... part 1: providing capabilities from the payment app is being handled by the TF
15:11:01 <zkoch> O.O
15:11:19 <AdrianHB> ... part 2: proposal is a generic string based filtering that browsers apply to the filters and capapbilities
15:11:49 <AdrianHB> ... in conversation with zkoch he has said he believes the number of methods that will use filtering to be small
15:12:14 <AdrianHB> ... also Google will have work to do to implement any W3C defined methods so adding filters will be part of that
15:12:40 <AdrianHB> ... so it occurred to me that this may be an implementation detail
15:12:56 <Ian> https://w3c.github.io/browser-payment-api/#show-method
15:13:00 <Ian> For each paymentMethod in request.[[serializedMethodData]]:
15:13:14 <AdrianHB> ... this means that browsers should indicate if they support filters
15:13:19 <Ian> "Consult the appropriate payment apps to see if they support any of the payment method identifiers given by the first element of the paymentMethod tuple, passing along the data string given by the second element of the tuple in order to help them determine their support. "
15:13:28 <AdrianHB> ... [reads from PR spec]
15:13:57 <AdrianHB> ... I believe this to be overly constraining. It should just say that filtering happens here.
15:14:08 <AdrianHB> ... AdrianHB suggested we should just make a decision
15:14:19 <adamR> +1 to describing filtering in PR API.
15:14:41 <AdrianHB> ... Concrete proposal is that we change PR spec to say "filters are taken into account"
15:15:00 <AdrianHB> ... This leaves browsers to decide how they interpret "taken into account"
15:15:04 <adamR> q+
15:15:09 <AdrianHB> ack ian
15:15:17 <Ian> ack adm
15:15:19 <Ian> ack ada
15:15:36 <Ian> adamR: Is the implication that we won't have a description anywhere of a reusable algorithm
15:15:44 <AdrianHB> ian: yes
15:16:31 <AdrianHB> ... we don't know yet how the apps will specify their capabilities. We could put guidance in the guidelines document.
15:16:34 <AdrianHB> q+
15:16:52 <Ian> IJ: Implication is no reusable string matching
15:17:12 <Ian> AdamR: concern that for infrequently released browsers, this will put a damper on payment method deployment
15:17:33 <zkoch> q+
15:17:39 <Ian> (IJ notes that we can add "suggested payment method filter syntax" to => https://w3c.github.io/webpayments/proposals/method-practice/)
15:17:59 <Ian> adamR: I understand we don't yet have filter use cases for custom payment methods, but I think that's short-sited.
15:18:04 <Ian> ..I expect they will arise in the future.
15:18:24 <Ian> ..cutting off at this time, especially something that is extremely likely to work, is short-sited
15:18:24 <MattS> +1
15:18:30 <Ian> ack ad
15:18:32 <AdrianHB> ack AdrianHb
15:18:40 <Ian> chair: AdrianHB
15:18:46 <Ian> regrets+ NickTR
15:19:05 <Ian> adrianHB: I want to add to AdamR's comment. We are effectively saying that we don't expect this aspect of the API to be interoperable
15:19:33 <AdrianHB> q?
15:19:33 <Ian> ..the only way I see this panning out if we say "browser implement this however they like"...then other browsers will need to implement generic string matching otherwise they will no longer interoperate
15:19:37 <Ian> ack zkoch
15:20:28 <Ian> zkoch: A few comments. The first thing is that we discussed this yesterday among the PR API editors/implementers. There was unanimity that given where we are (nearing CR) and with small number of use cases, it was not priority to implement generic filter matching today
15:20:38 <Ian> ...that did not mean "never" it just meant "not yet"
15:20:49 <Ian> ...this is one of a number of issues that we feel are not for V1
15:21:00 <adamR> q+
15:21:02 <Ian> ..we have 2 implementations in the wild, and the priority is interop between them.
15:21:13 <Ian> ...we can add this in the future.
15:21:41 <Ian> ...just because Chrome is making a choice to implement W3C spec short strings a particular way, does not imply everyone has to do so
15:22:04 <Ian> ...note also that an alternative to an abstract payment method spec is N payment method specs
15:22:09 <Ian> ...also, I don't see an interop risk here.
15:22:33 <Ian> ...suppose firefox implements something generic...that's not an interop problem; we will match on what we identify and effectively drop what we don't recognize
15:22:35 <Ian> q?
15:22:37 <Ian> ack ad
15:22:47 <Manash> Manash has joined #wpwg
15:22:53 <Ian> adamR: I want to agree with the third point...I don't see the interop issue (agree with Zach)
15:23:23 <AdrianHB> q+ to ask to clarify the browser will behave if it encounters filters it doesn't understand
15:23:24 <Ian> ..but I have concerns with the first point that we should go based on what is currently implemented
15:24:17 <AdrianHB> ian: my attempt to address was to write this in the payment apps spec. The re-usable matching algo was then a bonus
15:24:22 <AdrianHB> q?
15:24:32 <Ian> q?
15:24:34 <Ian> ack AdrianHB
15:24:34 <Zakim> AdrianHB, you wanted to ask to clarify the browser will behave if it encounters filters it doesn't understand
15:24:36 <AdrianHB> ack me
15:25:15 <Ian> AdrianHB: Zach can you clarify the last point you made about dropping filters...Suppose I introduce a payment method spec and want to filter based on system (e.g., values are bitcoin, ether, dashcoin)
15:25:29 <Ian> ....proprietary method, so I use payment method manifest....what would Chrome do?
15:25:58 <Ian> [Payment method identifier is a URL]
15:26:17 <Ian> zkoch: At the current time we would not do any filtering. If it's a URL, we just pass over the entire blob; no filtering
15:26:45 <Ian> ...I would say, don't make a generic one...make a specific one per system
15:27:01 <Ian> ... I don't see evidence of the real world use cases
15:27:02 <Ian> q+
15:27:56 <Ian> ack me
15:28:11 <Ian> IJ: I agree that if we bring an abstraction spec forward, we should be able to provide evidence that there is a common set of data fields
15:28:32 <adamR> +1 to AdrianHB’s point
15:28:44 <Ian> AdrianHB: I think the ability to filter or not is a material difference between w3c and non-w3c payment method specs
15:29:09 <AdrianHB> ian: there are other differences
15:29:29 <AdrianHB> ... we support features in the manifest for example
15:29:39 <MattPi> q+
15:29:41 <MattS> q+
15:29:45 <Ian> ack MattPi
15:30:39 <Ian> mattPi: To be quite frank, we are still indeterminate on the payment app spec. That spec is crisper than it has been, so we are absolutely looking at it and working with our partners
15:30:45 <Ian> ...we are 100% committed to payment request API
15:31:14 <Ian> ...our release cycle is such that we want to minimize change to the PR API spec
15:31:32 <Ian> ...+1 to zkoch's comment that we are not seeing a big demand at this time...we might see the demand grow once PR API takes off
15:31:40 <Ian> q+
15:32:10 <Ian> ack MattS
15:32:27 <Ian> MattS: Would Ian's proposal mean that payment apps cannot do filtering?
15:33:03 <AdrianHB> ian: the goal is an optimal user experience. Only apps that are most likely to work appear in the list
15:33:15 <AdrianHB> ... so some filtering is required before the list is show
15:34:17 <AdrianHB> matts: I had thought we still had canMakePayments() in the app
15:34:38 <AdrianHB> ian: no this is a replacement because of issues with making canMakePayment() work
15:35:17 <AdrianHB> ... keen to hear your opinion on this matts
15:36:30 <Ian> MattS: Regarding zkoch's point - SEPA needs a country filter...even though it's a specific payment method.
15:36:34 <Ian> ...you don't want one URL per country
15:36:44 <Ian> http://w3c.github.io/webpayments-methods-credit-transfer-direct-debit/
15:36:45 <AdrianHB> q?
15:36:48 <Ian> ack me
15:37:00 <adamR> q+
15:37:14 <MattS> q+
15:37:16 <Ian> adrianHB: Let's try to document the argument and take to the FTF meeting
15:37:23 <Ian> zakim, close the queue
15:37:23 <Zakim> ok, Ian, the speaker queue is closed
15:37:49 <Ian> adamR: Ian said something a few moments ago that works relatively well - having a specific step in PR API that says "this is where filters and capabilities are matched"
15:37:57 <Ian> ...and make clear that this is an extension point
15:38:05 <Ian> ...and we can talk about it at the payment app spec
15:38:22 <Ian> .....I think that's a reasonable compromise
15:38:29 <Ian> (Ian is hearing +1 to Ian's notino)
15:38:35 <Ian> MattS: Yes, seems like a reasonable compromise
15:38:42 <zkoch> def: notino (a tiny notion)
15:39:37 <AdrianHB> [RRSAgent can't find "def" on the attendees list]
15:39:46 <zkoch> sgtm, +1
15:39:51 <Ian> IJ: I'd be happy to work with Zkoch on a proposal
15:40:12 <Ian> AdrianHB: So the proposal is to clarify in PR API where payment app capabilities are evaluated
15:40:31 <Ian> ...I am hearing AdamR say that let's call it an extension point
15:40:38 <Ian> q?
15:40:41 <Ian> ack adam
15:40:42 <Ian> ack Matt
15:40:51 <adamR> Thanks, AdrianHB — that’s a very precise summary.
15:41:12 <Ian> ACTION: Ian to work with zkoch on a change to PR API to ensure payment app capabilities taken into account and details will be handled outside the spec
15:41:13 <trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., IFSF-EFT-WG-Lead, ijacobs, ijmad).
15:41:30 <Ian> topic:
15:41:40 <Ian> Topic: Addition of "cb" to list of approved networks
15:42:17 <Ian> https://www.w3.org/Payments/card-network-ids
15:42:32 <Ian> Proposed:
15:42:32 <Ian>     We adopt a procedure for validating requests to be added to the list (cf proposal to add cb). Validation will consist of avoiding duplication.
15:42:32 <Ian>     We update the explanation in the network id list to make clear that approval does not imply interoperable implementation in browsers.
15:42:33 <Ian>     We add a statement that merchants may use Payment Request API for a card network that is not yet in the list; the list is only used for further filtering.
15:43:28 <MattS> q+
15:43:33 <Ian> zakim, open the queue
15:43:33 <Zakim> ok, Ian, the speaker queue is open
15:43:36 <MattS> q+
15:43:38 <AdrianHB> ian: Nick raised concerns about anti-competitive issues if there are limits to joining
15:43:47 <AdrianHB> ... (missed 2nd point)
15:44:12 <betehess> betehess has joined #wpwg
15:44:30 <pascal_bazin> "cb" means "carte bancaire"
15:45:00 <AdrianHB> ... one way to mitigate the concern is that this doesn't prevent cards from unlisted networks being used it just gives some UI optimization
15:45:11 <pascal_bazin> "carte bleue" is a brand for specific bank
15:45:44 <Ian> MattS: It was my expectation that supported network list could be short strings or URLs...has this been debated?
15:45:57 <Ian> ..the problem with this list is that it was put therefore for bootstrapping purposes
15:46:20 <Ian> ..it seems to me that implementing your own supported network string would be same issue
15:47:07 <AdrianHB> ian: At least Google have said they won't implement matching based on arbitrary strings so a distributed filtering system is not feasible
15:47:11 <Ian> IJ: My understanding is that at least google will only implement known strings, so no need for distributed naming.
15:47:50 <AdrianHB> q?
15:47:52 <Ian> zkoch: That's correct, but I had not thought about network values being URLs...we had assumed that the list of card networks would be finite
15:47:55 <Ian> ack mat
15:47:56 <AdrianHB> ack MattS
15:48:21 <Ian> MattS: There is a similar list to this list...effectively the list of EMV card providers
15:48:26 <Ian> ...it's 100s and 100s long
15:48:44 <Ian> ..there are some issues with that list (e.g., duplication)
15:48:57 <Ian> ....same company appears multiple times
15:49:02 <Ian> ..but it shows me that the list is not small
15:49:11 <zkoch> It would be useful to see and/or review that list :)
15:49:14 <zkoch> If possible
15:49:43 <AdrianHB> ian: short string vs URL is immaterial if the issue is security
15:50:39 <Ian> IJ: Zach could you look into that?
15:50:53 <Ian> ...could help us avoid registry...but we hear that there are string issues...would URLs be any better?
15:51:11 <Ian> AdrianHB: I suggest we shelve this until we address filter issue
15:51:27 <MattS> Registered Provider Identifier list https://eftlab.co.uk/index.php/site-map/knowledge-base/212-emv-rid
15:51:38 <Ian> PROPOSED: Update network identifier list per IJ's proposal in the agenda (modulo editorial changes)
15:52:06 <adamR> +1
15:52:12 <zkoch> +1
15:52:25 <Ian> ACTION: Ian to update the network identifier policy and add CB
15:52:25 <trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., IFSF-EFT-WG-Lead, ijacobs, ijmad).
15:52:31 <Ian> RESOLVED: To adopt network id policy change and cb
15:52:47 <Ian> AdrianHB: It's worth noting that there was not resounding consensus there.
15:54:06 <rouslan> q+
15:54:23 <Ian> MattS: I am concerned about this list growing in size
15:54:34 <Ian> AdrianHB: I think many of us share this concern
15:54:47 <Ian> ...but I propose we put this aside until we do the filtering issue
15:55:22 <Ian> topic: Payment app demos
15:55:34 <rouslan> q+
15:55:40 <rouslan> q-
15:55:42 <Ian> AdrianHB: This is just a request to know which browser implementations we could use to do payment app demos; please share on the list
15:55:46 <Ian> Topic: Testing
15:56:26 <Ian> Stan: I sent an email last week at the end of the call with state of testing
15:56:34 <zkoch> Note that at first glance at this list, most of these are not CC networks @matts
15:56:54 <spolu> https://github.com/stan-stripe/js-payment-request
15:57:08 <spolu> https://github.com/w3c/web-platform-tests/pull/4768
15:57:27 <spolu> http://i.imgur.com/OeSdfxS.png
15:57:33 <Ian> stan: What's promising can be seen in that image
15:57:51 <Ian> ...I think we have a framework to test constructor and show() implementation
15:57:52 <zkoch> cool!
15:58:02 <Ian> ...how much do we want to test?
15:58:19 <Ian> ...during the test task force call we talked about creating a mock payment method service through the w3c testing framework
15:58:27 <Ian> ..I'm not sure how much we will test payment request v payment apps
15:58:35 <AdrianHB> q+
15:58:35 <Ian> ...that's my ask for the group - how far do we want to go?
15:58:37 <Ian> ack adr
15:58:51 <zkoch> Chrome has a desktop version in development behind a flag. We can see how it performs :)
15:58:57 <Ian> \o/
15:59:11 <zkoch> Edge also has an implementation on Insider Preview builds
15:59:18 <Ian> AdrianHB: I know there are sandboxes and simulators...can we try hooking one of those up as a payment method mock?
15:59:23 <Ian> Stan: I am open to anything....
15:59:54 <Ian> ..nice thing about a mock payment method is you can call show() and drive the behavior of the implementation
15:59:58 <Ian> ...test error handling, etc.
16:00:05 <Ian> ...it has proven pretty useful
16:00:19 <rouslan> q+
16:00:22 <Ian> AdrianHB: Any thoughts on making this easier?
16:00:38 <Ian> rouslan: we have a desktop implementation behind a flag; not quite functional yet
16:00:51 <Ian> ..but as soon as it more or less works we'll let you know and you can start to test
16:01:13 <Ian> https://github.com/w3c/payment-request-info/wiki/ImplementationStatus
16:01:22 <rouslan> chrome://flags/#enable-experimental-web-platform-features and chrome://flags/#web-payments
16:01:29 <zkoch> Download chrome dev, though
16:01:30 <zkoch> Or canary
16:01:36 <spolu> ack
16:01:38 <Ian> q?
16:01:40 <Ian> ack rous
16:03:11 <Ian> IJ: What do we need to know at the FTF meeting as far as test suites (for the "getting to CR" discussion)
16:03:19 <Ian> Topic: next meeting
16:03:32 <Ian> - 16 march call (time zone change!)
16:03:36 <Ian> - 23-24 March FTF meeting
16:04:12 <Ian> IJ: We are at capacity for the FTF meeting
16:04:17 <Ian> RRSAgent, make minutes
16:04:17 <RRSAgent> I have made the request to generate http://www.w3.org/2017/03/09-wpwg-minutes.html Ian
16:04:21 <zkoch> I suspect there will be mutliation
16:04:22 <Ian> RRSAgent, set logs public
16:04:25 <zkoch> and literal cutting off at knees
16:04:33 <Ian> we have a payment app effigy
16:04:37 <Ian> for that purpose
16:04:49 <zkoch> good, seems safer
16:04:52 <zkoch> see ya
16:05:12 <MattPi> MattPi has left #wpwg
16:05:45 <Ian> RRSAgent, make minutes
16:05:45 <RRSAgent> I have made the request to generate http://www.w3.org/2017/03/09-wpwg-minutes.html Ian
16:05:48 <Ian> RRSAgent, set logs public
16:07:17 <Guest91> Guest91 has joined #wpwg
16:08:44 <cweiss> cweiss has joined #wpwg
16:26:01 <Guest91> Guest91 has joined #wpwg
16:36:34 <Guest91> Guest91 has joined #wpwg
17:20:35 <Guest91> Guest91 has joined #wpwg
17:44:41 <Guest91> Guest91 has joined #wpwg
18:02:44 <Zakim> Zakim has left #wpwg
18:06:02 <betehess> betehess has joined #wpwg
19:54:17 <cweiss> cweiss has joined #wpwg
19:57:14 <betehess> betehess has joined #wpwg
19:59:27 <Guest91> Guest91 has joined #wpwg
20:01:51 <cweiss> cweiss has joined #wpwg
21:51:04 <cweiss> cweiss has joined #wpwg
22:32:17 <Guest91> Guest91 has joined #wpwg