13:55:47 RRSAgent has joined #apps 13:55:47 logging to http://www.w3.org/2017/04/04-apps-irc 13:55:50 Zakim has joined #apps 13:55:55 Meeting: Payment Apps Task Force 13:55:57 Chair: Ian 13:55:59 Agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017Mar/0121.html 13:56:07 regrets+ Conor 13:56:08 rouslan has joined #apps 13:56:19 yes! 13:56:22 https://lists.w3.org/Archives/Public/public-payments-wg/2017Mar/0121.html 13:56:31 thx 13:58:16 frank has joined #apps 14:00:27 present+ 14:00:29 present+ Frank 14:00:34 alyver has joined #apps 14:00:35 present+ 14:01:17 present+ Christian 14:01:20 present+ Andre 14:02:01 adamR has joined #apps 14:02:33 MattS has joined #apps 14:02:56 present+ Ken 14:03:02 present+ MattS 14:03:05 zakim, who's here? 14:03:05 Present: Ian, Frank, rouslan, Christian, Andre, Ken, MattS 14:03:07 On IRC I see MattS, adamR, alyver, frank, rouslan, Zakim, RRSAgent, cweiss, Dongwoo, JakeA, Ian 14:03:29 present+ AdamR 14:03:30 Ken has joined #apps 14:03:39 agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017Mar/0121.html 14:04:13 triaged issues => https://lists.w3.org/Archives/Public/public-payments-wg/2017Apr/0010.html 14:05:41 Topic: Substantive maybe do before FPWD 14:05:42 https://github.com/w3c/webpayments-payment-apps-api/issues/120 14:05:57 q+ 14:06:02 ack m 14:06:13 q+ 14:06:18 MattS: These two issues (120 and 111) they didn't sound substantive to me. 14:06:54 MattS: I suggest you reconsider the word "substantive" 14:07:04 IJ: I didn't mean "blocker" 14:07:39 ack rouslan 14:09:39 rouslan: We are close on 120, but not a lot of time 14:10:01 https://github.com/w3c/webpayments-payment-apps-api/issues/120#issuecomment-289769943 14:10:09 AdrianHB has joined #apps 14:10:25 Rouslan: There was a proposal to put iframeOrigin into the payment app request data. 14:10:42 ...I think that's a good idea and we do that in android payment apps (was a requirement from multiple vendors) 14:10:51 q+ 14:11:04 ...good to put in the handler spec as well...question was then about naming: 14:11:22 ...some options are iframeOrigin, invokingOrigin, sourceOrigin 14:11:35 ...I propose here that we go with source origin 14:11:38 ack adamR 14:12:02 q+ 14:12:04 adamR: It occurs to me that we have the potential for more than the root origin and the iframe origin 14:12:07 ...these things can be nested 14:12:21 ...one way to get around this is to pass an array 14:12:33 ...and first element is root....second is iframe....then nested, etc 14:12:35 q+ 14:12:35 ack rouslan 14:12:46 rouslan: Marcos also proposed an array 14:13:13 ...I pushed back on that for 2 reasons..the full chain of iframes would be a pain to get in Chrome...there's also no use case to get the sequence of iframe 14:13:26 Present+ 14:13:27 Frank wrote on Github: "I checked wth the PSPs we are working with and it seems like nested iframe is an uncommon practice so I am fine with your suggestion." 14:13:55 rouslan: ...so in practice we have 2 origins in practice 14:13:55 q- 14:14:24 AdamR: What I have seen historically (but may no longer be done)....would be to frame a merchant site (e.g., for additional discounts)...which could then frame a payment 14:14:24 removing myself from the queue. Rouslan addressed my same concern re: the usefulness of all the "intermediate" iframe origins 14:14:46 AdamR: If we are not seeing in the wild, then probably ok to go forward with proposal. 14:14:47 q? 14:15:44 Summary of proposal: Pass origin of iframe that did payment request and call it sourceOrigin 14:16:08 ...in addition to 'origin' 14:16:27 IJ: I think those are not sufficiently distinct 14:16:41 MattS: topLevelOrigin and sourceOrigin 14:16:46 SGTM 14:16:49 +1 14:16:51 +1 14:17:14 Ian: Counter-proposal: topLevelOrigin and paymentRequestOrigin 14:17:26 +1 14:17:28 +1 14:17:29 +1 14:17:32 +1 14:17:33 +10 to rouslan 14:17:34 +1 14:17:53 RESOLVED: To include topLevelOrigin and paymentRequestOrigin in payment app request data 14:18:12 ACTION: Ian to update issue 120 and edit the spec accordingly 14:18:21 topic: issue 111 14:18:46 `appRequest` attribute should not be a dictionary 14:19:14 rouslan: Original issue was syntactic...attribute was a dictionary...but IDL spec says dictionaries cannot be read-only attributes 14:19:46 AdamR: In the set of edits that I did, I changed from a dictionary to an interface, but that raised an issue about not being able to have arrays 14:19:51 ...so they had to be changed to frozen arrays 14:20:25 ...I think the spec is up to date 14:20:54 See Marcos' comment: 14:20:54 https://github.com/w3c/webpayments-payment-apps-api/issues/111#issuecomment-287944141 14:21:07 q+ 14:21:25 AdamR: There are a bunch of fields missing that we would have to add...that would not be used on the PR API side...that will probably receive pushback from the broader group 14:21:27 ack rouslan 14:21:46 rouslan: payment app request is no longer a dictionary, so the problem is solved from my perspective. 14:21:50 adamR: I think we can close this. 14:22:09 ACTION: Rouslan to close issue 111 with a summary 14:23:12 Topic: issue 109 14:23:39 https://github.com/w3c/webpayments-payment-apps-api/issues/109#issuecomment-287705543 14:24:02 WalletDetails to PaymentWallet 14:24:03 or 14:24:10 PaymentInstrument to InstrumentDetails 14:24:11 q+ 14:24:15 ack rouslan 14:24:27 +1 - WalletDetails to PaymentWallet 14:24:32 rouslan: I think that the general pattern is to prefix datatypes with the word "Payment" 14:24:52 so the would be PaymentWallet and PaymentInstrument 14:25:22 q+ 14:25:31 === 14:25:31 5.2 PaymentManager interface 14:25:31 5.3 PaymentInstruments interface 14:25:31 5.4 PaymentInstrument dictionary 14:25:31 5.5 PaymentWallets interface 14:25:32 5.6 PaymentWallet dictionary 14:25:33 === 14:25:42 ack rouslan 14:26:24 rouslan: Don't be concerned about difference of "s"..the way that they are accessed in the API...Wallets is accessed through .wallets....and PaymentWallet is a dictionary 14:26:33 ...so you don't refer to it by name...you could define it in curly braces 14:26:44 ...so low risk of name collections in code 14:27:31 Proposal: "PaymentWallet" 14:27:53 +1 14:27:57 +1 14:28:10 ACTION: Ian to update the spec with name harmonization of PaymentWallet 14:28:19 .and close 109 14:29:01 Topic: Issue 117 14:29:05 IJ: seems like it's mostly about PR API 14:29:06 https://github.com/w3c/webpayments-payment-apps-api/issues/117 14:30:03 IJ: where in payment handler do we talk about htis? 14:30:05 q+ 14:30:08 MattS: We don't; we need a handshake 14:30:32 ..if the payment handler supports Abort, then PR API should say that it honors Abort 14:30:34 ack rouslan 14:30:53 rouslan: I think this is a good idea. Some payment apps will support abort, others will not 14:31:11 ....abort is asynchronous....will succeed if abort succeeds and fails otherwise 14:32:02 q+ 14:32:08 ..in PR API, the wording is "if the state of payment request is interactive" then abort should fail....we can change it to say that "if it's impossible to abort the third party payment app, then reject the abort promise" and then in the payment handler spec, we can define an event that would have to be responded to in the payment handler 14:32:19 q- 14:32:39 ...a payment abort event...and then the third party payment app would have the choice (e.g., based on logic or business requirements) to resolve or abort that promise 14:34:16 ..the promise exists on the payment request side. On the payment handler side it's a payment abort event that has a "respond with" function that takes a promise 14:34:33 q+ 14:34:37 q+ 14:34:37 ack Adrian 14:35:12 AdrianHB: If the abort event on the payment handler side lets you return a promise, we are getting into funny race conditions with the payment request promise. 14:35:24 q+ 14:35:25 ...we should not allow the handler to resolve the abort promise but also resolve the payment request promise 14:35:41 ...maybe you just raise an abort event and that's it; and the payment handler must resolve the request promise with a failure or something like that 14:35:49 ack rouslan 14:36:24 rouslan: That's an excellent proposal....another thing we could do is in a respond with function we could respond with a boolean....@@missed 14:36:31 ...let's have domenic or marcos take a look 14:36:33 +1 to synchronous response to abort event 14:37:26 IJ: AHB would you mind adding some ideas on GitHub? 14:37:27 q+ 14:37:28 Adrian:Sure 14:37:43 IJ: Where do we hook this issue into the spec? 14:37:44 ack me 14:38:01 MattS: Because this issue is related to handshake, we run the risk of not being able to take PR API to CR. 14:38:32 I note that we haven't entirely resolved Matt's issue (because we are saying we can't) but have proposed some additions to Payment Handler that would make it more complete 14:38:37 https://github.com/w3c/browser-payment-api/issues/473 14:39:34 IJ: I will (1) put on this week's WPWG agenda and (2) move 117 to the list of "open at FPWD" 14:40:07 q+ 14:40:14 Topic: issue 105 14:40:14 https://github.com/w3c/webpayments-payment-apps-api/issues/105 14:40:28 IJ: I want to close this one due to evolution of the spec 14:40:48 MattS: Ok for handler; but there is some language harmonization to do in PR API around "payment app" or "payment handler" 14:40:56 ...I raised an issue in PR API on that topic 14:41:34 See https://github.com/w3c/browser-payment-api/issues/497 14:43:12 MattS: How I would like to see it resolved...payment handler could use an architectural diagram 14:44:08 ACTION: MattS to create a diagram for Payment Handler showing the different components 14:44:24 PROPOSE: Close issue 105 14:44:28 +1 14:45:17 +0 14:45:25 IJ: I will go ask Tommy if he's ok with that, and mention MattS is working on a diagram 14:45:39 topic: Issue 84 - recommended payment apps 14:46:44 q+ 14:47:14 q+ 14:47:17 Issue 74, not 84 - https://github.com/w3c/webpayments-payment-apps-api/issues/74 14:47:40 alyver: Thanks! I was lost. 14:48:18 [IJ does background on current state of apps, prefs] 14:48:21 ack MattS 14:49:17 MattS: I am wondering whether we should put this in as an issue marker 14:49:39 https://github.com/w3c/webpayments-payment-apps-api/issues/116 14:49:42 Relation between merchant order of payment methods and payment app order of instruments #116 14:50:36 IJ: I would like to focus on 116 rather than 84 14:50:50 ...that is: how do we make use of payment method info, rather than expect new info from merchants 14:52:29 ...I am not sure that 116 is resolved even if we remove merchant order of payment methods 14:52:59 MattS: Please update 116 if you think it includes other aspects like user order of payment methods in browser 14:53:21 (IJ: will go back to look at 116) 14:53:49 q? 14:54:02 MattS: I would leave in 84 for discussion by merchants 14:54:05 ack rouslan 14:54:06 Q+ 14:54:29 rouslan: In terms of issue 84, I believe that we can close 84 since the spec works fine as-is and we don't need to define any additional fields 14:54:55 ...this could also be worked on in parallel 14:55:43 ...my recommendation is to close 74 14:55:50 ...since the use case can be satisfied without changes to the API 14:55:54 ack Ken 14:56:11 s/84/74/g 14:56:22 Ken: I support Matt's point and get more input from merchants... 14:56:29 ...as well as card issuers and brands 14:57:24 IJ: If we leave it, it seems section 4 (Overview) might be appropriate 14:58:06 Ken: If one spec is providing prioritization and the other spec doesn't speak to it, there's a possible incongruency 14:58:17 ...worth looking at how preferences are being asserted across all the spec 14:58:20 s/spec/specs 14:59:03 As an aside, I’ll repeat that we’re making this harder than it needs to be by using the term “recommended payment app” to mean both “if you don’t have an app installed for a supported payment method, here is where to find one” and the very different “if you have more than one app installed that matches this payment method, please render them to the user in a way that highlights or orders them according to some scheme.” 15:00:39 +1 to Adam's comment above. We discussed that same point previously, and I thought we had agreed to seperate those concerns. 15:01:02 IJ: I don't mind including a hook in section 4 asking for feedback on importance of a feature to (1)facilitate installation of a particular app or (2) highlight an already registered app. 15:01:43 Right. We should burn the term “recommended payment app” and come up with two very different terms for the different concepts. 15:01:50 (+1) 15:02:12 alyver has left #apps 15:02:15 Summary: Mention the 2 topics in question in the spec at FPWD (e.g., in 4) 15:02:26 q+ 15:02:34 topic: Issue 69 15:02:43 IJ: I propose we close this given the way the spec is written 15:02:48 ack rouslan 15:03:00 rouslan: There is no link to a definition of how image object works 15:03:16 adamR: We point to the definition in app manifest 15:04:32 +1 15:04:41 PROPOSED: Close 69 and open new issue about definition of "image object" 15:04:43 +1 15:04:46 AdamR: +1 15:05:03 ACTION: Ian to close 69 and create a new issue about definition of image object 15:05:29 AdrianHB, can you say what issue 5 means (on the mailing list or in github)? 15:05:42 ACTION: Ian will update the list and send to the WG for discussion on Thursday 15:05:44 Topic: next meeting 15:05:49 11 April! 15:05:59 RRSAgent, make minutes 15:05:59 I have made the request to generate http://www.w3.org/2017/04/04-apps-minutes.html Ian 15:06:02 RRSAgent, set logs public 15:07:36 rouslan has joined #apps 15:09:00 cweiss has joined #apps 17:36:59 cweiss has joined #apps 17:42:26 cweiss has joined #apps 18:33:30 Zakim has left #apps 18:45:32 cweiss has joined #apps 20:21:39 adamR has joined #apps 21:00:42 cweiss has joined #apps 22:59:11 adamR has joined #apps 23:12:30 adamR has joined #apps