13:49:36 RRSAgent has joined #wpwg 13:49:36 logging to http://www.w3.org/2016/09/01-wpwg-irc 13:49:38 RRSAgent, make logs public 13:49:38 Zakim has joined #wpwg 13:49:40 Zakim, this will be 13:49:40 I don't understand 'this will be', trackbot 13:49:41 Meeting: Web Payments Working Group Teleconference 13:49:41 Date: 01 September 2016 13:49:44 agenda: https://github.com/w3c/webpayments/wiki/Agenda-20160901 13:49:52 regrets+ NickTR 13:49:56 regrets+ AdrianHB 14:01:12 Present+ zkoch 14:01:51 alyver has joined #wpwg 14:02:09 present+ Max 14:02:11 present+ Ian 14:02:15 present+ Rouslan 14:02:20 present+ AdamR 14:03:05 present+ alyver 14:04:38 present+ Mahesh 14:04:56 present+ Andre 14:05:30 agenda? 14:05:38 topic: TPAC 2016 14:05:45 rouslan has joined #wpwg 14:05:48 https://www.w3.org/2002/09/wbs/35125/TPAC2016/?login 14:06:00 IJ: Registration goes up tomorrow 14:06:13 draft agenda -> https://github.com/w3c/webpayments/wiki/FTF-Sep2016 14:06:18 Max has joined #wpwg 14:06:29 MaheshK has joined #wpwg 14:08:31 q+ regarding Samsung demo 14:08:41 ack M 14:08:46 [We walk through agenda] 14:09:41 q+ 14:10:00 MaheshK: Please add Samsung demo to the implementation session 14:13:08 ACTION: Ian to work with Rouslan to organize the implementation session 14:13:08 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., ijacobs, ijmad). 14:16:07 present+ Ken 14:16:56 Ken has joined #wpwg 14:18:20 present+ ShaneM 14:18:24 pascal has joined #wpwg 14:21:36 topic: Payment method identifier proposals 14:21:41 https://lists.w3.org/Archives/Public/public-payments-wg/2016Sep/0000.html 14:22:30 present+ Pascal 14:22:52 zkoch: Would like to get agreement on four points: 14:22:56 Absolute URLs will be used to identify proprietary payment methods 14:22:56 Strings will be used to identify open payment methods and will be maintained by the WG 14:22:56 Every payment method must have an associated payment-manifest file (or similar) 14:22:56 There must be some standard way to access that payment-manifest file (or similar) 14:23:55 zkoch: Some discussion of URNs on the thread. Mostly cost is "burden for developers". Mostly benefit is "all things are URLs" except that's not a big benefit. 14:24:04 ...so the current proposal is just short strings minted by w3c and defined in a w3c spec 14:24:10 q+ to talk about the MUST 14:24:15 q+ 14:24:18 ack max 14:25:14 zkoch: My focus today is not on exactly what needs to be in the manifest file. Initial proposal is to start conversation. And I don't know that we need to nail down the right way to get the data 14:25:27 zkoch: I think we need to resolve these issues to make progress. 14:25:54 q+ to say that the division is not open/proprietary but w3c/non-w3c 14:26:11 zkoch: The manifest file can be flexible enough to accommodate a number of use cases. 14:26:34 ...we don't need (yet) to know what the vocabulary is exactly; we can work on that at TPAC 14:26:53 +1 14:27:05 PMI: https://github.com/zkoch/zkoch.github.io/blob/master/pmi.md 14:27:12 Manifest: https://github.com/zkoch/zkoch.github.io/blob/master/payment-manifest.md 14:27:28 zkoch: The idea of the manifest is data for a payment method. 14:27:41 ....there's a proposal for how to identify the manifest (based on the "root" payment method URL) 14:27:57 ...and within the manifest file you can put information about the method - default payment apps, for example 14:28:23 ..this way, as implementers we can verify securely that the "true" payment app has been installed. (cf the Alipay use case) 14:28:41 ..that's the summary 14:28:46 ack me 14:28:46 Ian, you wanted to talk about the MUST and to say that the division is not open/proprietary but w3c/non-w3c 14:28:48 q+ 14:30:15 IJ: can we express what these PMIs identify by definition rather than "MUST" 14:31:39 q+ to say that web apps indicate that there MUST be a manifest file... same thing 14:31:55 +1 to specifying what a PROCESSOR does when it finds or does not find a resource 14:31:57 +1 to Ian’s point — I agree that the spec should spell out what happens rather than mandating things and not being clear about what happens if those aren’t met. 14:32:27 +1 to specifying all behavior 14:33:54 IJ: I suggest the split be: W3C - short string; other -> URL 14:34:06 ..it's not about open v. proprietary 14:34:31 zkoch: I don't want to see proprietary methods done at W3C for short names. 14:35:42 seems fine to invent short strings anywhere 14:35:44 IJ: We could also establish a principle that w3c will not mint proprietary short strings 14:35:51 doesn't have to be at W3C 14:35:55 collisions are unlikely 14:36:24 adrianba: That doesn’t end well. 14:36:49 q? 14:37:22 zkoch: What you said is an implementation detail within manifest files....where we need consensus is that there are things minted by w3c (minimal set) and other things identified by URLs 14:37:29 ack ad 14:37:48 adamR: I also have tweaks and also support the general idea. I want to reinforce something from AdrianHB. The headline is "defaults matter" 14:38:04 ..the way that things are spelled out now, by default things specified by URL are constrained to the domain in that ULR. 14:38:17 ...as long as we give people the means to constrain, then the default should be "open" 14:38:24 ..I think it will make a big difference in ecosystem. 14:39:06 q+ to ask if it makes sense to define a mechanism to permit broader use rather than a mechanism to restrict use 14:39:07 zkoch: I think we'll probably need a longer discussion at TPAC. I agree that defaults matter. I would rather map to what is common in the marketplace today. 14:39:15 ...I have not seen may examples today. 14:39:30 ...I agree it's possible (or should be possible) to accommodate both cases via the manifest file, whatever default we choose. 14:39:47 adamR: I think that there are arguments for being explicit rather than implicit (about origins) 14:40:05 ...and you'll need some extraordinary syntax for "everyone" 14:40:06 dezell has joined #wpwg 14:40:12 Present+ dezell 14:40:24 zkoch: I welcome direct proposals to the manifest; please use github. I think these are valid points. 14:40:25 q? 14:40:27 ack Max 14:40:52 Max: We had a similar proposal (in payment app task force) with some slight differences. The general direction is similar. 14:40:55 ...perhaps we can discuss the details offline 14:41:27 ...in general, we agree on the four points of Zach's points (in particular the manifest idea) 14:41:42 present+ AdrianBa 14:41:58 Max: Correction: we agree with 1/3/4...not sure on point 2 yet 14:42:26 Max: Second point - the definitions of "open" and "proprietary" methods 14:42:36 I like 1/3/4... 2 feels weird. And I don't understand how 2 and 3 relate. 14:42:52 IJ: Can you propose revisions to the specs for definitions? 14:44:03 W3 maintaining le payment identifier would help to verify/certify the security level of the method 14:44:07 IJ: how would you characterize the distinction? 14:44:15 zkoch: I will work on refining the definitions. 14:44:31 there should be no business relationship needed to implement open methods - they are defined as *open* standards 14:44:32 ACTION: zkoch to work on the distinction between open and proprietary 14:44:33 Created ACTION-30 - Work on the distinction between open and proprietary [on Zach Koch - due 2016-09-08]. 14:45:16 and can be independently implemented 14:45:34 +1 to independent implementation without prior business agreement 14:45:37 ack ShaneM 14:45:37 ShaneM, you wanted to say that web apps indicate that there MUST be a manifest file... same thing and to ask if it makes sense to define a mechanism to permit broader use rather 14:45:40 ... than a mechanism to restrict use 14:46:07 shane: At its core, I feel like it is fine to say "there must be a manifest file" as long as we spell out behavior when there is and isn't. 14:46:20 (IJ recaps his distinction - I prefer to write specs for software than for people) 14:46:57 shane: Regarding "default" - my preference is that the default be "restricted" 14:46:57 I don't think we should be trying to enumerate every possible use case for the manifest file 14:47:07 ..but I don't have a strong reason right now 14:47:08 q? 14:47:12 of course specs will say how they specifically use the manifest file 14:47:54 ::cue elevator music:: 14:48:44 IJ: Is the expectation that multiple specs / groups could define what goes in the manifest? 14:49:00 adrianba: Not saying that exactly; just that more discussion is necessary (including about scope) 14:49:22 ...I am just trying to push back slightly on the idea that a PMI URL has associated with it an algo on how to get to the manifest file. 14:49:36 ...of course there will be implications to that manifest file existing or not in the system 14:50:08 ...one example is that if you come across the file one type of behavior is to ignore...there will be an implication for that particular scenario 14:50:18 ...we will not define every possible way it will be used and preclude others 14:50:20 q+ 14:50:52 ...there may be a number of different ways in which the manifest file is used in some scenario (e.g,. native apps) but are not defined by this group 14:51:05 ack me 14:52:10 hopefully we'll have an extensible format 14:52:32 because inevitable this group will want extensions even if we didn't consider proprietary extensions 14:52:43 IJ: yes, we should be explicit about the extension points 14:53:03 zkoch: I mostly was thinking about payment methods here...but I hope payment apps will also make use of the manifest 14:53:20 +1 to a few principles for how the manifest file can/should be used up front (e.g., on extensibility) 14:53:34 q? 14:53:53 IJ: AHB's points here or by email? 14:53:55 zkoch: Email 14:53:57 [Straw poll] 14:54:11 +1 14:54:14 +1 14:54:21 zkoch: I am hearing ok to use absolute URLs for proprietary and non-w3c payment methods 14:54:22 +1 14:54:25 +1 14:54:35 [on manifests] 14:54:45 +1 14:54:45 +1 14:54:48 +1 - and +1 on working out the details 14:54:49 zkoch: I also hear consensus on a manifest file and we should move forward even though more details to work out 14:54:52 +1 14:55:14 [on short strings] 14:55:15 +1 for short strings 14:55:16 +1 for short strings 14:55:21 zkoch: I propose we adopt short strings (not URNs) 14:55:26 +1 14:55:27 we might constrain the characters allowed 14:55:57 +1 to not URNs... I feel weird about short strings still but I will get over it 14:55:59 +1 14:56:10 q+ to ask something abotu short strings 14:56:14 ack Sh 14:56:14 ShaneM, you wanted to ask something abotu short strings 14:56:14 +1 on short strings 14:56:32 shane: One thing I don't quite understanding...what about manifest for short strings? 14:57:12 zkoch: Don't have the same needs for open (e.g., default) and payment method specs are there for other behavior 14:57:27 this needs to be clarified in the proposal because it is ambiguous 14:57:34 IJ: Zach do you have what you need? 14:57:41 zkoch: Yes, I think we are unblocked 14:57:44 I reserve the right to lobby hard for JSON-LD 14:57:52 ...we should go away and look ahead to use cases. 14:58:27 agenda+ Important announcement about ReSpec 14:58:29 RESOLVED: (1) manifest files (2) short strings for w3c payment methods (3) URLs for non-w3c and proprietary 14:58:49 Topic: I18N issues 14:58:57 IJ: Quick FYI on I18N issues that were raised 14:59:02 https://lists.w3.org/Archives/Public/public-payments-wg/2016Sep/0002.html 14:59:05 https://lists.w3.org/Archives/Public/public-payments-wg/2016Sep/0003.html 14:59:52 topic: 8 September 15:00:01 IJ: we will discuss CFC decision and also a payment apps topic 15:00:14 rrsagent, make minutes 15:00:14 I have made the request to generate http://www.w3.org/2016/09/01-wpwg-minutes.html Ian 15:00:17 rrsagent, set logs public 15:00:37 bye 15:14:34 alyver has joined #wpwg 15:16:10 alyver has left #wpwg 15:59:53 rouslan has joined #wpwg 16:15:29 rouslan has left #wpwg