IRC log of apps on 2017-04-04

Timestamps are in UTC.

13:55:47 [RRSAgent]

RRSAgent has joined #apps

13:55:47 [RRSAgent]

logging to http://www.w3.org/2017/04/04-apps-irc

13:55:50 [Zakim]

Zakim has joined #apps

13:55:55 [Ian]

Meeting: Payment Apps Task Force

13:55:57 [Ian]

Chair: Ian

13:55:59 [Ian]

Agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017Mar/0121.html

13:56:07 [Ian]

regrets+ Conor

13:56:08 [rouslan]

rouslan has joined #apps

13:56:19 [Ian]

yes!

13:56:22 [Ian]

https://lists.w3.org/Archives/Public/public-payments-wg/2017Mar/0121.html

13:56:31 [rouslan]

thx

13:58:16 [frank]

frank has joined #apps

14:00:27 [Ian]

present+

14:00:29 [Ian]

present+ Frank

14:00:34 [alyver]

alyver has joined #apps

14:00:35 [rouslan]

present+

14:01:17 [Ian]

present+ Christian

14:01:20 [Ian]

present+ Andre

14:02:01 [adamR]

adamR has joined #apps

14:02:33 [MattS]

MattS has joined #apps

14:02:56 [Ian]

present+ Ken

14:03:02 [Ian]

present+ MattS

14:03:05 [Ian]

zakim, who's here?

14:03:05 [Zakim]

Present: Ian, Frank, rouslan, Christian, Andre, Ken, MattS

14:03:07 [Zakim]

On IRC I see MattS, adamR, alyver, frank, rouslan, Zakim, RRSAgent, cweiss, Dongwoo, JakeA, Ian

14:03:29 [Ian]

present+ AdamR

14:03:30 [Ken]

Ken has joined #apps

14:03:39 [Ian]

agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017Mar/0121.html

14:04:13 [Ian]

triaged issues => https://lists.w3.org/Archives/Public/public-payments-wg/2017Apr/0010.html

14:05:41 [Ian]

Topic: Substantive maybe do before FPWD

14:05:42 [Ian]

https://github.com/w3c/webpayments-payment-apps-api/issues/120

14:05:57 [MattS]

q+

14:06:02 [Ian]

ack m

14:06:13 [rouslan]

q+

14:06:18 [Ian]

MattS: These two issues (120 and 111) they didn't sound substantive to me.

14:06:54 [Ian]

MattS: I suggest you reconsider the word "substantive"

14:07:04 [Ian]

IJ: I didn't mean "blocker"

14:07:39 [Ian]

ack rouslan

14:09:39 [Ian]

rouslan: We are close on 120, but not a lot of time

14:10:01 [Ian]

https://github.com/w3c/webpayments-payment-apps-api/issues/120#issuecomment-289769943

14:10:09 [AdrianHB]

AdrianHB has joined #apps

14:10:25 [Ian]

Rouslan: There was a proposal to put iframeOrigin into the payment app request data.

14:10:42 [Ian]

...I think that's a good idea and we do that in android payment apps (was a requirement from multiple vendors)

14:10:51 [adamR]

q+

14:11:04 [Ian]

...good to put in the handler spec as well...question was then about naming:

14:11:22 [Ian]

...some options are iframeOrigin, invokingOrigin, sourceOrigin

14:11:35 [Ian]

...I propose here that we go with source origin

14:11:38 [Ian]

ack adamR

14:12:02 [rouslan]

q+

14:12:04 [Ian]

adamR: It occurs to me that we have the potential for more than the root origin and the iframe origin

14:12:07 [Ian]

...these things can be nested

14:12:21 [Ian]

...one way to get around this is to pass an array

14:12:33 [Ian]

...and first element is root....second is iframe....then nested, etc

14:12:35 [alyver]

q+

14:12:35 [Ian]

ack rouslan

14:12:46 [Ian]

rouslan: Marcos also proposed an array

14:13:13 [Ian]

...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 [AdrianHB]

Present+

14:13:27 [Ian]

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 [Ian]

rouslan: ...so in practice we have 2 origins in practice

14:13:55 [alyver]

q-

14:14:24 [Ian]

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 [alyver]

removing myself from the queue. Rouslan addressed my same concern re: the usefulness of all the "intermediate" iframe origins

14:14:46 [Ian]

AdamR: If we are not seeing in the wild, then probably ok to go forward with proposal.

14:14:47 [rouslan]

q?

14:15:44 [Ian]

Summary of proposal: Pass origin of iframe that did payment request and call it sourceOrigin

14:16:08 [Ian]

...in addition to 'origin'

14:16:27 [Ian]

IJ: I think those are not sufficiently distinct

14:16:41 [Ian]

MattS: topLevelOrigin and sourceOrigin

14:16:46 [adamR]

SGTM

14:16:49 [alyver]

+1

14:16:51 [rouslan]

+1

14:17:14 [Ian]

Ian: Counter-proposal: topLevelOrigin and paymentRequestOrigin

14:17:26 [adamR]

+1

14:17:28 [rouslan]

+1

14:17:29 [AdrianHB]

+1

14:17:32 [alyver]

+1

14:17:33 [adamR]

+10 to rouslan

14:17:34 [frank]

+1

14:17:53 [Ian]

RESOLVED: To include topLevelOrigin and paymentRequestOrigin in payment app request data

14:18:12 [Ian]

ACTION: Ian to update issue 120 and edit the spec accordingly

14:18:21 [Ian]

topic: issue 111

14:18:46 [Ian]

`appRequest` attribute should not be a dictionary

14:19:14 [Ian]

rouslan: Original issue was syntactic...attribute was a dictionary...but IDL spec says dictionaries cannot be read-only attributes

14:19:46 [Ian]

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 [Ian]

...so they had to be changed to frozen arrays

14:20:25 [Ian]

...I think the spec is up to date

14:20:54 [Ian]

See Marcos' comment:

14:20:54 [Ian]

https://github.com/w3c/webpayments-payment-apps-api/issues/111#issuecomment-287944141

14:21:07 [rouslan]

q+

14:21:25 [Ian]

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 [Ian]

ack rouslan

14:21:46 [Ian]

rouslan: payment app request is no longer a dictionary, so the problem is solved from my perspective.

14:21:50 [Ian]

adamR: I think we can close this.

14:22:09 [Ian]

ACTION: Rouslan to close issue 111 with a summary

14:23:12 [Ian]

Topic: issue 109

14:23:39 [Ian]

https://github.com/w3c/webpayments-payment-apps-api/issues/109#issuecomment-287705543

14:24:02 [Ian]

WalletDetails to PaymentWallet

14:24:03 [Ian]

or

14:24:10 [Ian]

PaymentInstrument to InstrumentDetails

14:24:11 [rouslan]

q+

14:24:15 [Ian]

ack rouslan

14:24:27 [AdrianHB]

+1 - WalletDetails to PaymentWallet

14:24:32 [Ian]

rouslan: I think that the general pattern is to prefix datatypes with the word "Payment"

14:24:52 [Ian]

so the would be PaymentWallet and PaymentInstrument

14:25:22 [rouslan]

q+

14:25:31 [Ian]

===

14:25:31 [Ian]

5.2 PaymentManager interface

14:25:31 [Ian]

5.3 PaymentInstruments interface

14:25:31 [Ian]

5.4 PaymentInstrument dictionary

14:25:31 [Ian]

5.5 PaymentWallets interface

14:25:32 [Ian]

5.6 PaymentWallet dictionary

14:25:33 [Ian]

===

14:25:42 [Ian]

ack rouslan

14:26:24 [Ian]

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 [Ian]

...so you don't refer to it by name...you could define it in curly braces

14:26:44 [Ian]

...so low risk of name collections in code

14:27:31 [Ian]

Proposal: "PaymentWallet"

14:27:53 [AdrianHB]

+1

14:27:57 [rouslan]

+1

14:28:10 [Ian]

ACTION: Ian to update the spec with name harmonization of PaymentWallet

14:28:19 [Ian]

.and close 109

14:29:01 [Ian]

Topic: Issue 117

14:29:05 [Ian]

IJ: seems like it's mostly about PR API

14:29:06 [Ian]

https://github.com/w3c/webpayments-payment-apps-api/issues/117

14:30:03 [Ian]

IJ: where in payment handler do we talk about htis?

14:30:05 [rouslan]

q+

14:30:08 [Ian]

MattS: We don't; we need a handshake

14:30:32 [Ian]

..if the payment handler supports Abort, then PR API should say that it honors Abort

14:30:34 [Ian]

ack rouslan

14:30:53 [Ian]

rouslan: I think this is a good idea. Some payment apps will support abort, others will not

14:31:11 [Ian]

....abort is asynchronous....will succeed if abort succeeds and fails otherwise

14:32:02 [AdrianHB]

q+

14:32:08 [Ian]

..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 [AdrianHB]

q-

14:32:39 [Ian]

...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 [Ian]

..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 [AdrianHB]

q+

14:34:37 [Ian]

q+

14:34:37 [Ian]

ack Adrian

14:35:12 [Ian]

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 [rouslan]

q+

14:35:25 [Ian]

...we should not allow the handler to resolve the abort promise but also resolve the payment request promise

14:35:41 [Ian]

...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 [Ian]

ack rouslan

14:36:24 [Ian]

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 [Ian]

...let's have domenic or marcos take a look

14:36:33 [AdrianHB]

+1 to synchronous response to abort event

14:37:26 [Ian]

IJ: AHB would you mind adding some ideas on GitHub?

14:37:27 [MattS]

q+

14:37:28 [Ian]

Adrian:Sure

14:37:43 [Ian]

IJ: Where do we hook this issue into the spec?

14:37:44 [Ian]

ack me

14:38:01 [Ian]

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 [AdrianHB]

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 [MattS]

https://github.com/w3c/browser-payment-api/issues/473

14:39:34 [Ian]

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 [MattS]

q+

14:40:14 [Ian]

Topic: issue 105

14:40:14 [Ian]

https://github.com/w3c/webpayments-payment-apps-api/issues/105

14:40:28 [Ian]

IJ: I want to close this one due to evolution of the spec

14:40:48 [Ian]

MattS: Ok for handler; but there is some language harmonization to do in PR API around "payment app" or "payment handler"

14:40:56 [Ian]

...I raised an issue in PR API on that topic

14:41:34 [MattS]

See https://github.com/w3c/browser-payment-api/issues/497

14:43:12 [Ian]

MattS: How I would like to see it resolved...payment handler could use an architectural diagram

14:44:08 [Ian]

ACTION: MattS to create a diagram for Payment Handler showing the different components

14:44:24 [Ian]

PROPOSE: Close issue 105

14:44:28 [adamR]

+1

14:45:17 [MattS]

+0

14:45:25 [Ian]

IJ: I will go ask Tommy if he's ok with that, and mention MattS is working on a diagram

14:45:39 [Ian]

topic: Issue 84 - recommended payment apps

14:46:44 [MattS]

q+

14:47:14 [rouslan]

q+

14:47:17 [alyver]

Issue 74, not 84 - https://github.com/w3c/webpayments-payment-apps-api/issues/74

14:47:40 [adamR]

alyver: Thanks! I was lost.

14:48:18 [Ian]

[IJ does background on current state of apps, prefs]

14:48:21 [Ian]

ack MattS

14:49:17 [Ian]

MattS: I am wondering whether we should put this in as an issue marker

14:49:39 [Ian]

https://github.com/w3c/webpayments-payment-apps-api/issues/116

14:49:42 [Ian]

Relation between merchant order of payment methods and payment app order of instruments #116

14:50:36 [Ian]

IJ: I would like to focus on 116 rather than 84

14:50:50 [Ian]

...that is: how do we make use of payment method info, rather than expect new info from merchants

14:52:29 [Ian]

...I am not sure that 116 is resolved even if we remove merchant order of payment methods

14:52:59 [Ian]

MattS: Please update 116 if you think it includes other aspects like user order of payment methods in browser

14:53:21 [Ian]

(IJ: will go back to look at 116)

14:53:49 [rouslan]

q?

14:54:02 [Ian]

MattS: I would leave in 84 for discussion by merchants

14:54:05 [Ian]

ack rouslan

14:54:06 [Ken]

Q+

14:54:29 [Ian]

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 [Ian]

...this could also be worked on in parallel

14:55:43 [Ian]

...my recommendation is to close 74

14:55:50 [Ian]

...since the use case can be satisfied without changes to the API

14:55:54 [Ian]

ack Ken

14:56:11 [rouslan]

s/84/74/g

14:56:22 [Ian]

Ken: I support Matt's point and get more input from merchants...

14:56:29 [Ian]

...as well as card issuers and brands

14:57:24 [Ian]

IJ: If we leave it, it seems section 4 (Overview) might be appropriate

14:58:06 [Ian]

Ken: If one spec is providing prioritization and the other spec doesn't speak to it, there's a possible incongruency

14:58:17 [Ian]

...worth looking at how preferences are being asserted across all the spec

14:58:20 [Ian]

s/spec/specs

14:59:03 [adamR]

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 [alyver]

+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 [Ian]

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 [adamR]

Right. We should burn the term “recommended payment app” and come up with two very different terms for the different concepts.

15:01:50 [Ian]

(+1)

15:02:12 [alyver]

alyver has left #apps

15:02:15 [Ian]

Summary: Mention the 2 topics in question in the spec at FPWD (e.g., in 4)

15:02:26 [rouslan]

q+

15:02:34 [Ian]

topic: Issue 69

15:02:43 [Ian]

IJ: I propose we close this given the way the spec is written

15:02:48 [Ian]

ack rouslan

15:03:00 [Ian]

rouslan: There is no link to a definition of how image object works

15:03:16 [Ian]

adamR: We point to the definition in app manifest

15:04:32 [rouslan]

+1

15:04:41 [Ian]

PROPOSED: Close 69 and open new issue about definition of "image object"

15:04:43 [rouslan]

+1

15:04:46 [Ian]

AdamR: +1

15:05:03 [Ian]

ACTION: Ian to close 69 and create a new issue about definition of image object

15:05:29 [Ian]

AdrianHB, can you say what issue 5 means (on the mailing list or in github)?

15:05:42 [Ian]

ACTION: Ian will update the list and send to the WG for discussion on Thursday

15:05:44 [Ian]

Topic: next meeting

15:05:49 [Ian]

11 April!

15:05:59 [Ian]

RRSAgent, make minutes

15:05:59 [RRSAgent]

I have made the request to generate http://www.w3.org/2017/04/04-apps-minutes.html Ian

15:06:02 [Ian]

RRSAgent, set logs public

15:07:36 [rouslan]

rouslan has joined #apps

15:09:00 [cweiss]

cweiss has joined #apps

17:36:59 [cweiss]

cweiss has joined #apps

17:42:26 [cweiss]

cweiss has joined #apps

18:33:30 [Zakim]

Zakim has left #apps

18:45:32 [cweiss]

cweiss has joined #apps

20:21:39 [adamR]

adamR has joined #apps

21:00:42 [cweiss]

cweiss has joined #apps

22:59:11 [adamR]

adamR has joined #apps

23:12:30 [adamR]

adamR has joined #apps