16:46:59 RRSAgent has joined #wpwg 16:46:59 logging to http://www.w3.org/2016/02/11-wpwg-irc 16:47:01 RRSAgent, make logs public 16:47:01 Zakim has joined #wpwg 16:47:03 Zakim, this will be 16:47:03 I don't understand 'this will be', trackbot 16:47:04 Meeting: Web Payments Working Group Teleconference 16:47:04 Date: 11 February 2016 16:47:20 agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2016Feb/0178.html 16:55:40 agenda? 16:55:42 agenda+ Flows 16:55:45 agenda+ CHeckout API 16:55:52 agenda+ Proposal regarding JSON-LD material 16:55:57 agenda+ FTF update 16:56:06 agenda: https://github.com/w3c/webpayments/wiki/Agenda-20160211 16:58:22 zkoch has joined #wpwg 16:58:22 present+ nicktr 16:58:25 present+ dlongley 16:59:25 present+ Manu 16:59:31 Present+ zkoch 17:01:13 I think that assumes a working phone number in the country… 17:01:34 https://mit.webex.com/mit/e.php?MTID=mf35a2209e62d9a74d2b813c3cabe6e99 17:02:22 present+ ShaneM 17:02:27 present+ Ian 17:02:53 present+ shepazu 17:03:07 dezell has joined #wpwg 17:03:11 present+ Fred 17:03:16 (as in, too much email - not that I've been emailing drunk... though, the latter may be indistinguishable to WG members from my regular emails). 17:03:18 present+ dezell 17:03:19 present+ AdrianHB 17:03:52 VincentK has joined #wpwg 17:04:01 present+ VincentK 17:04:56 scribe: Ian 17:04:59 topic: Intro 17:05:24 nicktr: Good we are having lots of conversations. Would like to see others participate as well. What are the obstacles to others contributing? 17:05:33 ...I would welcome the thoughts of the group now or in run-up to FTF 17:05:46 +1 to collaboration 17:05:55 q+ 17:05:59 ack ad 17:06:13 +1 - thinks it may have to do with bandwidth 17:06:19 adrianba: I think that one of the challenges I'm having is that we end up with a lot issues where a lot of topics are mixed in. 17:06:29 ...makes it hard to figure out what it is that is the core of what needs to be done 17:07:02 ...also, there are several conversation threads that sound to me like discussion of abstract ideas and I find it difficult to have an opinion on those ideas without a concrete instantiation. 17:07:13 ...for example, there are conversations about API patterns, shapes, conversations 17:07:43 ...many are related to different proposals for how we deal with shipping address. I would prefer we have conversations grounded in the user experience we want to provide, and see proposals to satisfy those experiences. 17:08:00 ...but a lot of discussions seem to be about how APIs should work, almost incidental to the capability in question 17:08:01 q? 17:08:15 q+ 17:08:18 DJackson has joined #wpwg 17:08:27 ..I would like the FTF (or a call) to be more productive and grounded in user experience 17:08:31 ack ad 17:08:34 ack AdrianHB 17:08:50 Yaso has joined #wpwg 17:08:54 Present+ DJackson 17:09:09 Present+ Yaso 17:09:21 adrianHB: I agree with AdrianBA that conversation has been abstract. But it seems to me we will cannot have another type of discussion until we have a unified proposal that people can poke at 17:09:26 +1 to adopting proposals ASAP - which we'll probably do after the face-to-face. 17:09:36 ..I think the conversations are staging the discussion for what will be important to the design decisions 17:09:42 (and putting the proposals into the group) 17:10:45 adrianHB: I think we will need design decisions to put into the process 17:10:54 q? 17:10:55 I also not that a lot of the early days of a WG is very high-bandwidth discussion to sync the group up. 17:11:08 and some of that discussion is abstract. 17:11:08 I personally appreciate that the discussions are having in front of me, even when I am not participating in them. 17:11:26 +1 to Shane's sentiment. 17:11:29 adrianHB: I think we need to consider the final user experience 17:12:00 nicktr: So drop the chairs a note if you have suggestions regarding management of the group discussion 17:12:39 zakim, take up item 1 17:12:39 agendum 1. "Flows" taken up [from Ian] 17:12:48 yes 17:12:49 https://github.com/w3c/webpayments/wiki/Agenda-20160211 17:13:06 -> https://github.com/w3c/webpayments/wiki/Flows 17:13:09 Seems to be a big delay 17:13:29 nicktr: The task force is currently struggling to make headway 17:13:35 ...I think it's a bandwidth issue. 17:14:02 q? 17:14:02 ...I think they will be important to 'exercise' our spec proposals against them 17:14:08 zakim, take up item 2 17:14:08 agendum 2. "CHeckout API" taken up [from Ian] 17:14:31 Spec -> https://wicg.github.io/web-payments-browser-api/checkout-api.html 17:14:38 Backgorund -> https://lists.w3.org/Archives/Public/public-payments-wg/2016Feb/0133.html 17:15:02 dlongley: the idea of the proposal is that the CG proposal and the browser proposal focus on different levels. 17:15:12 s/Backgorund/Background/ 17:15:41 dlongley: Since the APIs do different things, they could be layer. 17:15:46 s/layer/layered 17:16:14 ...the proposal is for a "high level" API (Checkout) that leverages the lower level API (paymentRequest) 17:16:31 ..the higher-level API includes activities to prepare for payment such as collecting information like shipping addresss. 17:16:49 ...once they have information they need, then they are in the same position as a merchant that has done the same thing through some custom method. 17:16:57 ..then the lower level API can be invoked. 17:17:15 ...I want to call out another design goal...there has been discussion about control being handed back to merchant site. 17:17:20 high-level API: http://wicg.github.io/web-payments-browser-api/checkout-api.html 17:17:24 low-level API: http://wicg.github.io/web-payments-browser-api/ 17:17:39 ...the original proposal from google/ms used Events 17:18:02 ...Events seem like an anti-pattern here since it does not behave like other API uses of Events 17:18:09 ...so the checkout API uses promises instead 17:18:37 ...there is a promise and the merchant takes action, then triggers another promise to hand back control to browser. then lower level API can be invoked. 17:18:52 q?J 17:18:54 q+ 17:18:59 q+ 17:19:01 ack zk 17:19:54 zkoch: Clarifying question for dave: in the case where you don't need to request a shipping address and all you want to do is make a payment request (e.g., for virtual goods)...is the expectation that merchants would use the checkout API or the payment API? 17:20:04 dlongley: Could use either 17:20:31 ...I want to decouple the low level API so it focuses only on payment app selection 17:21:11 ..if developer wants special checkout flow (other than just payment instrument selection) they would use the checkout API 17:21:25 ...but if only interested in low-level stuff, then payment API 17:21:46 zkoch: Even if you were only calling the lower level API, we would still display UI which is the end of the checkout flow 17:21:55 rouslan has joined #wpwg 17:21:58 ...it does not seem to me a good story for developers that there are two paths 17:22:11 ...I have some concerns about "when you use one or the other" 17:22:15 Present+ Rouslan 17:22:27 ..versus using a single API in the way you need to get things done. 17:22:33 Note that Extensible Web Manifesto was something written by W3C TAG members, and other folks deeply involved in API design at W3C. 17:22:44 dlongley: I think this pattern of low-level API + layer on top is consistent with extensible web API design approach 17:23:17 (dlongley describes app cache history and desire to create innovation on top of lower-level API) 17:23:38 dlongley: I don't think we should require people to use "checkout" when they only need to use "payment" 17:23:42 q? 17:23:50 ack adrianb 17:23:51 ack adrianba 17:24:00 adrianba: That conversation was helpful. 17:24:10 ...I think I want to hear more about this idea of high level v. low level 17:24:16 and the relationship of those primitives 17:24:26 I'm having a hard time understanding that from the current checkout API spec 17:24:55 ...one issue is that events are not the right approach and promises are 17:25:13 ...I spent a long time looking at example 4 in the checkout draft 17:25:24 ...thinking about promise resolving and I can't get there 17:25:35 ...not clear when the promise returns from request method actually resolves 17:25:41 ...there's an almost recursive set of calls 17:25:54 I do want to say that I don’t thiiink there are any plans in the web platform to build higher level APIs on top of service worker. There might be libraries that get published that abstract away some of the lower level/more complex stuff. But that’s a but different then the platform providing it 17:26:05 ...I think tit would be helpful to separate the issues of "layering" from "events v. promises" 17:26:12 s/tit/it 17:26:24 ...utlimately I don't agree that our usage of Events is improper. 17:26:44 ..there is a TAG finding that talks about using Events is fine for things that happen multiple times 17:26:49 q+ to ask talk about events 17:26:51 q+ 17:27:36 adrianba: Finally, the extensible web manifesto is not a prescription to always do something the same way. We subscribe to the general idea of the manifesto, but there are caveats 17:28:04 q+ to note high-level vs. low-level - that some merchants may not want to have a Checkout flow controlled by the browsers. 17:28:14 ..and one of the places where we have to be careful about low-level capabilities that we expose is where we have security and privacy issues...we definitely have those concerns for payments 17:28:37 zakim, close the queue 17:28:37 ok, Ian, the speaker queue is closed 17:28:40 q+ to note that we should talk about events separately 17:28:40 q? 17:29:02 nicktr: I am hearing agenda items for FTF (1) layering (2) events/promises 17:29:04 ack dlongley 17:29:04 dlongley, you wanted to ask talk about events 17:29:16 dlongley: I agree events are used for multiple things, but the issue is "control flow." 17:29:45 I think FetchEvent does that 17:29:50 ...the part that is strange to me is for the handler to have to tell a service worker "keep going" 17:29:52 -> https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#fetch-event-section FetchEvent 17:29:56 I disagree zkoch 17:30:04 this uses respondWith 17:30:12 ...in the FetchEvent case it may be that nothing else happens 17:30:20 but it doesn't fail if there is no event listener 17:30:24 ...I definitely agree that with low-level APIs privacy/.security is important 17:30:43 ...we want to ensure that the mechanism for selecting payment apps does not reveal information about the user to merchants 17:31:00 ..if we can encapsulate that behavior in the low-level API, then the high -level API does not have to deal with it. 17:31:03 ack adrianhb 17:31:28 https://github.com/w3c/webpayments/issues/55 17:31:35 adrianhb: dlongley said much of what I wanted to say. The conversation is happening on github 17:31:39 ...so have a look there. 17:31:57 ...I am going to disagree with AdrianBA and Zach that FetchEvent is the same as this. 17:31:59 i also disagree -- it's not the same pattern w/fetch 17:32:16 ...FetchEvent raises an event when Fetch is happening; events bubble up and then disappear 17:32:19 I also disagree - looking at the docs now to make sure - https://developer.mozilla.org/en-US/docs/Web/API/FetchEvent 17:32:31 ...in this case, a service worker can intercept and respond with cached information 17:32:42 ...but if there is no Event listener, the request still happens fine. 17:32:45 In general - developers don't use events to transfer control flow 17:32:49 ..and that's the difference 17:32:51 agree with adrian -- the control flow doesn't change, you modify what's passing through. 17:33:10 ..using events to solicit a response from a site, I don't think that's the right approach to doing it. Would want to hear from the TAG, for example 17:33:25 ack man 17:33:25 manu, you wanted to note high-level vs. low-level - that some merchants may not want to have a Checkout flow controlled by the browsers. 17:33:25 (I'm sympathetic to AdrianHB's point) 17:34:01 manu: Focusing on the Event bit is premature. I think the primary point of the checkout API is that there seems to be a natural high/low concept in this case. 17:34:20 ..the checkout API is primarily focused on getting information from customer before the payment initiation 17:34:55 ...there are also going to be merchants who do not want to hand control of gathering that information to the browser flow 17:35:06 ...they may have requirements for collecting information in a particular way 17:35:17 ..or big sites that have strong branded checkout expxeriences 17:35:18 +1 - payment API is a way to pass a payment request to a payment app and get a response, checkout API is a a way to let browser assist with checkout flow that builds on payment API 17:35:31 +1 to manu and AdrianHB 17:35:36 ...those orgs will want to gather information necessary to create a payment request, then use the low-level API 17:35:45 We always expected there to be sites that don’t want to take advantage of shipping address. That’s why shipping was an optional thing. Otherwise…paymentRequest is just a “low level” API for choosing a payment app 17:36:06 yes, we want it to be that simple 17:36:21 well, not just choosing a payment app, but getting a payment acknowledgement as well 17:36:21 (I'm less interested in the merchant's desires around payment UI flow, and more interested in the user's experience) 17:36:25 (from that app) 17:36:48 The same API for two purposes where a simple flag buried in the parameters differentiates them is a bad design 17:37:04 manu: checkout api is more for merchant/customer, and payment API is more for merchant/browser 17:37:06 (also, I think all the attention on custom payment UIs has been because the payment experience and UI options thus far have been terrible) 17:37:17 I am very interested in the merchant's desires, @shepazu. They pay my wages 17:37:19 +1 to improve checkout API as well, i think both APIs are important. 17:37:49 nicktr: Clear that further discussion required .. .let's take to FTF 17:37:57 ..if the interested parties can do work on this before FTF, that would be welcome 17:38:01 zakim, close this item 17:38:01 agendum 2 closed 17:38:02 I see 3 items remaining on the agenda; the next one is 17:38:02 1. Flows [from Ian] 17:38:02 nicktr, sure, but user > merchant 17:38:07 zakim, take up item 3 17:38:07 agendum 3. "Proposal regarding JSON-LD material" taken up [from Ian] 17:38:30 I think we need to understand what about the checkout API (not just symantics like events vs promises) doesn't cover their requirements 17:38:55 https://github.com/w3c/webpayments/issues/83 17:38:59 zakim, open the queue 17:38:59 ok, nicktr, the speaker queue is open 17:39:19 s/their/Google and Microsoft's/ 17:39:37 q+ to note JSON not the appropriate format - WebIDL is. 17:40:27 http://wicg.github.io/paymentrequest/specs/paymentrequest.html 17:42:27 https://wicg.github.io/web-payments-browser-api/ - also now using WebIDL to define API and parameters 17:42:33 q- 17:42:41 https://github.com/w3c/webpayments/issues/83 17:42:53 q? 17:42:57 q+ to note that all specs use WebIDL, so we don't have to say that. 17:43:26 ack manu 17:43:26 manu, you wanted to note that all specs use WebIDL, so we don't have to say that. 17:43:41 manu: There is now agreement on use of WebIDL to define interfaces 17:44:11 q+ 17:44:11 ...I think that that achieves the "all the specs use JSON" bits you want 17:44:31 ...the bit about the extensibility section...I'm happy with "WG seeks feedback from that spec" 17:44:45 ...I don't think we should name that spec yet 17:44:51 (IJ: I am fine to not name it yet) 17:45:31 Manu: So for me I think we agree now in principle and can do naming wordsmithing later. 17:45:39 IJ: +1 to writing the spec and then we'll comment on it 17:45:40 Proposed wording: A separate specification (linked to the document) explains how to extend the parameters used with this API using JSON-LD. 17:45:55 manu: I can work with Ian on wording 17:45:56 Ian: +1 17:46:09 q? 17:46:16 -> https://github.com/w3c/webpayments/issues/83 17:46:52 +1 to that 17:47:15 q+ 17:47:16 +1 to (simply add an issue about WIP) 17:47:39 q? 17:47:42 ack adrianba 17:48:02 adrianba: It sound like to me that there is rough consensus on what to do here and a bit of devil in the detail 17:48:04 nicktr_ has joined #wpwg 17:48:15 q? 17:48:15 ...currently the payment request API does define a new term "JSON OBJECT" 17:48:28 ...since WebIDL doesn't have the concept yet 17:48:33 ...the WebIDL community is working on that 17:48:41 This is why we had an issue w/ WebIDL in the first place :) 17:48:59 ...in the meantime, I essentially define a term that refers to an object that can be roundtripped to say "this is a JSON-compatible thing" 17:49:07 ..so we need to say something about JSON since WebIDL doesn't do it. 17:49:20 +1 to JsonObject that Ade is describing, it's a major shortcoming of WebIDL and the main reason we didn't use it to begin with! 17:49:21 Notes you can use interfaces for that now... 17:49:21 ..I think it's reasonable to say in the spec that we are working on what the extensibility mechanism should be 17:49:43 ...another question for the group is: Right now in the payment request API we have a number of different args (4) for the request 17:49:51 ...I wonder whether those might have different extensibility characteristics 17:49:57 ..they are defined as dictionaries 17:50:01 q+ to dictionaries for extensibility! 17:50:06 ...we do have one object (Data) 17:50:14 q+ to note that dictionaries don't copy unknown values. 17:50:15 ...I think a note on that seems reasonable. 17:50:18 q+ to note that we haven't actually defined our data model yet 17:51:24 +1 to Ian 17:52:03 q- 17:52:06 ack me 17:52:09 ack Ian 17:52:09 ack manu 17:52:10 manu, you wanted to dictionaries for extensibility! and to note that dictionaries don't copy unknown values. 17:52:11 ack manu 17:52:29 manu: I think that what AdrianBA said is important, but what Ian said this is not what this proposal is about 17:52:45 https://github.com/w3c/webpayments/issues/83 17:53:37 +1 for that proposal (with wording change as minuted) 17:53:48 A separate specification (linked to the document) explains how to extend the parameters used with this API using JSON-LD 17:53:57 Proposal: 17:54:02 * Adrian's text for the in-spec sentence 17:54:13 * The proposed issue marker: https://github.com/w3c/webpayments/issues/83 17:54:21 +1 17:54:22 Issue marker: "The Working Group seeks feedback from the community on that specification and how well it furthers interoperability needs in the payments ecosystem. To provide feedback, see the status section above (linked to status section of spec)" 17:54:33 +1 17:54:38 +1 17:54:42 +1 17:55:11 +1 17:55:14 +0.9, would have preferred something that tells people they *need* to follow that other spec to achieve interop, but that can go in that other spec i guess? 17:55:18 +1 17:55:20 +1 17:55:23 +1 17:55:27 nicktr: So resolved 17:55:31 zakim, close item 3 17:55:31 agendum 3, Proposal regarding JSON-LD material, closed 17:55:32 I see 2 items remaining on the agenda; the next one is 17:55:32 1. Flows [from Ian] 17:55:35 zakim, close item 1 17:55:35 agendum 1, Flows, closed 17:55:36 I see 1 item remaining on the agenda: 17:55:36 4. FTF update [from Ian] 17:55:41 agenda? 17:55:48 zakim, take up item 4 17:55:48 agendum 4. "FTF update" taken up [from Ian] 17:56:04 https://github.com/w3c/webpayments/wiki/WPWG-FTF-Feb-2016 17:56:18 https://www.w3.org/2002/09/wbs/83744/ftf-201602/results 17:56:30 DJackson has joined #wpwg 17:56:30 Ian: Currently there are 32 people registered from the group. 17:56:51 Ian: We have guests as well... 17:57:25 Ian: I have 4-5 remote participation requests - remote call in details. Samsung, Vantiv, Walmart, IBM, etc. 17:57:32 Yaso has joined #wpwg 17:57:51 Ian: Elevator usage - check proper usage on wiki - or you may be shot (not really). 17:58:21 Ian: Both Manu and AdrianB may be able to see how they see big issues - converge on identification of issues - put in agenda, prepare - hopefully we can do that before the F2F. 17:59:08 Ian: We should have a prioritized list - my guess is that editors and chairs, moreso than me, are better positioned to tease those out. Welcomed contribution, would help us organize. 17:59:49 nicktr_: Suggest that chairs and editors put together prioritized issues list. 18:00:04 ACTION: nicktr_ to consult with chair and editors on prioritized issues list 18:00:04 Error finding 'nicktr_'. You can review and register nicknames at . 18:01:32 rrasgent, make minutes 18:01:38 rrsagent, set logs public 18:40:35 scroogemcduck has joined #wpwg 18:40:35 [13web-payments-browser-api] 15msporny pushed 2 new commits to 06gh-pages: 02https://github.com/WICG/web-payments-browser-api/compare/73ed6c1a1c09...1228d3f2d7ee 18:40:35 13web-payments-browser-api/06gh-pages 14aacb460 15Manu Sporny: Add remote files to ensure ReSpec processing doesn't fail. 18:40:36 13web-payments-browser-api/06gh-pages 141228d3f 15Manu Sporny: Update Extensibility section to reflect WPWG decision.... 18:40:36 scroogemcduck has left #wpwg 19:05:25 scroogemcduck has joined #wpwg 19:05:25 [13web-payments-browser-api] 15msporny pushed 1 new commit to 06gh-pages: 02https://github.com/WICG/web-payments-browser-api/commit/6c1644759602a63b77df2186a9189041e18c729c 19:05:25 13web-payments-browser-api/06gh-pages 146c16447 15Manu Sporny: Add WPWG extensibility decision text to Checkout API.... 19:05:26 scroogemcduck has left #wpwg 19:30:46 scroogemcduck has joined #wpwg 19:30:46 [13web-payments-browser-api] 15msporny pushed 1 new commit to 06gh-pages: 02https://github.com/WICG/web-payments-browser-api/commit/04ba062928fda08423d27791d701032d11c3c07e 19:30:46 13web-payments-browser-api/06gh-pages 1404ba062 15Manu Sporny: Address @ianjacobs' concerns about MUST language. 19:30:47 scroogemcduck has left #wpwg 19:32:23 scroogemcduck has joined #wpwg 19:32:23 [13web-payments-browser-api] 15msporny 04force-pushed 06gh-pages from 1404ba062 to 14d72e379: 02https://github.com/WICG/web-payments-browser-api/commits/gh-pages 19:32:23 13web-payments-browser-api/06gh-pages 14d72e379 15Manu Sporny: Address @ianbjacobs' concerns about MUST language.... 19:32:24 scroogemcduck has left #wpwg 20:03:25 scroogemcduck has joined #wpwg 20:03:25 [13web-payments-browser-api] 15msporny pushed 1 new commit to 06gh-pages: 02https://github.com/WICG/web-payments-browser-api/commit/9c8f95b2e910f459006126ef343d67247dc7804d 20:03:25 13web-payments-browser-api/06gh-pages 149c8f95b 15Manu Sporny: Make example code easier to read. 20:03:26 scroogemcduck has left #wpwg 21:41:41 zkoch has joined #wpwg 22:36:00 zkoch has joined #wpwg