IRC log of apps on 2017-03-07

Timestamps are in UTC.

13:52:57 [RRSAgent]
RRSAgent has joined #apps
13:52:57 [RRSAgent]
logging to
14:41:13 [Max]
Max has joined #apps
14:58:22 [jnormore]
jnormore has joined #apps
15:01:41 [Ian]
Meeting: Payment Apps Task Force
15:01:43 [Ian]
Chair: Ian
15:01:56 [Ian]
15:02:01 [Ian]
15:02:04 [Ian]
present+ Jason
15:02:06 [adamR]
15:02:08 [ConorhWP]
ConorhWP has joined #apps
15:02:30 [AdrianHB]
present+ AdrianHB
15:02:45 [rouslan]
rouslan has joined #apps
15:03:16 [Ian]
present+ Mathieu
15:03:29 [rouslan]
15:03:34 [ConorhWP]
15:03:46 [mathp]
mathp has joined #apps
15:03:51 [Ian]
regrets+ Pascal
15:04:11 [Ian]
topic: Updating the spec
15:04:25 [Ian]
15:04:33 [Ian]
agenda+ Pascal's code
15:05:21 [Ian]
* Change the title (Payment Handler API)
15:05:21 [Ian]
* Update the model description per the Proposal
15:05:21 [Ian]
* Move explanatory information to an appendix
15:05:21 [Ian]
* Add code samples
15:05:22 [Ian]
15:05:23 [Ian]
* AdamR to flesh out his proposal per 28 Feb discussion
15:05:24 [Ian]
15:07:45 [Ian]
adamR: I wasn't able to update the proposal last week due to IETF deadlines; that's likely to continue to next week.
15:07:52 [Ian] that's ok if you move a lot of things around during that period.
15:08:00 [Ian]
..part of what I wanted to do with my edits is add in examples.
15:08:04 [Ian]
...from pascal's document
15:08:15 [Ian]
...I already borrowed IDL...will include exmaples
15:08:38 [Ian]
15:09:32 [Ian]
...I thank we will have incorporated most of what Marcos has provided...I also think that Marcos created that document to demonstrate some code and my understanding is that once I've taken the info into account, he won't develop that document further
15:09:43 [Ian]
present+ Max
15:09:56 [Ian]
present+ Ken
15:10:12 [Ian]
adamR: When you are done with the big structural moves, if you can tag me let me know.
15:10:21 [Ken]
Ken has joined #apps
15:10:58 [Ian]
agenda+ filtering update
15:11:51 [Ian]
topic: issue 91
15:11:58 [Ian]
Discussion of AHB's proposal:
15:11:58 [Ian]
15:11:58 [Ian]
is on the WG agenda this week:
15:11:58 [Ian]
15:12:54 [AdrianHB]
15:13:10 [Ian]
IJ: Anyone want to add to the GitHub issue in favor of sharing line items?
15:13:12 [Ian]
ack AdrianHB
15:14:25 [adamR]
q+ to ask Adrian a clarifying question
15:14:26 [Ian]
AdrianHB: Line items in payment request are not the things that you buy
15:14:34 [Ian]
..they are typically things like subtotal, tax, total
15:14:43 [Ian] if a payment app wants full details about what is being purchased,
15:14:50 [Ian]
..that can be a payment method specific piece of data.
15:14:56 [Ian]
...I think that that's where we are headed on that issue.
15:15:54 [Ian]
ack ad
15:15:54 [Zakim]
adamR, you wanted to ask Adrian a clarifying question
15:16:23 [Ian]
adamR: Adrian, regarding the method you described passing through does that that imply redundancy of information passed through the top level?
15:16:43 [Ian]
AdrianHB: My proposal is that there's a flag in PR API...and if you want to pass line items to payment apps you would set the flag.
15:16:55 [Ian]
...zach's point is that we don't expect merchants to use line items to list products
15:17:52 [Ian]
...if there are no use cases for getting "total", "tax" etc. then we can drop the proposal, otherwise if there are use cases (which Klarna's is not an example of), then the proposal can stand
15:18:34 [Ian]
IJ: Privacy issue goes away if the line items are just used for tax and total information
15:19:15 [adamR]
15:19:30 [Ian]
AdrianHB: The breakdown was to show a change in total based on user actoins
15:19:33 [Ian]
ack Ada
15:19:58 [Ian]
AdamR: I understand the use case and the google use case, but I suspect that developers will use the line items for other purposes.
15:20:48 [AdrianHB]
15:21:13 [Ian]
AdamR: The number of web developers who read specs for good practice is close to zero
15:21:20 [Ian]
ack AdrianHB
15:21:58 [Ian]
AdrianHB: I think the only way we will address the concern from AdamR is to change the API to be less flexible.
15:22:07 [Ian]
...I also think that Google limits the number of things you can send through the API
15:22:10 [Ian]
..due to UI consideratinos
15:22:27 [rouslan]
15:22:30 [Ian]
..the spec should not hard-code a limit, but I believe there is one
15:22:33 [Ian]
ack rous
15:22:46 [Ian]
rouslan: We don't currently enforce a limit (we use scroll bars)
15:23:02 [Ian]
..we'll probably send a PR on the spec soon that says you can provide something like 50 shipping options and 50 line items
15:23:05 [Ian]
...for security reasons
15:23:46 [Ian]
15:23:55 [Ian]
zakim, take up item 1
15:23:55 [Zakim]
agendum 1. "Rename the spec" taken up [from Ian]
15:23:59 [AdrianHB]
If the intent is explicitly to not show shopping cart items then we should limit to 5
15:24:08 [Ian]
Proposal: Payment Handler API for the title
15:24:17 [AdrianHB]
15:24:21 [adamR]
15:24:22 [rouslan]
15:24:24 [jnormore]
15:24:28 [Ian]
zakim, close this item
15:24:28 [Zakim]
agendum 1 closed
15:24:29 [Zakim]
I see 2 items remaining on the agenda; the next one is
15:24:29 [Zakim]
2. Pascal's code [from Ian]
15:24:33 [Ian]
zakim, take up item 2
15:24:33 [Zakim]
agendum 2. "Pascal's code" taken up [from Ian]
15:24:41 [Ian]
15:25:21 [Ian]
IJ: Has anybody had a look? What is relationship to Marcos' code?
15:25:51 [Ian]
AdamR: This is input to drive the API; the examples in the spec are meant to explain the API.
15:26:30 [AdrianHB]
15:26:32 [Ian]
ack AdrianHB
15:26:49 [Ian]
AdrianHB: One thing immediately useful from the code samples is that if you don't have time to read the whole spec,
15:27:34 [Ian]
...I see the first example and say "Is our intent to get permission by calling options.set?" Is it implicit? Or do we want an explicit function to get permissions?
15:27:42 [Ian]
adamR: I think we had an open issue on this.
15:28:09 [Ian]
15:28:32 [Ian]
15:28:37 [Ian]
15:28:50 [Ian]
AdrianHB: that example shows an explicit permissions call
15:28:58 [Ian]
...asking for 'payments' permission
15:29:09 [Ian]
AdamR: yes, this can be incorporated.
15:30:07 [Ian]
AdrianHB: I suggest we respond on the issue and try to get a general approach
15:30:19 [Ian]
AdamR: I am confident in Marcos and Jake here
15:30:35 [Ian]
...if we want further validation, let's find another person who is familiar with how web apps ask for permissions.
15:32:35 [Ian]
IJ: Is PaymentManager more clearly captured in the new text (from Adam)?
15:33:59 [Ian]
AdamR: there is a page on the payment app's web site that installs the payment app...that's not the service worker
15:34:59 [Ian]
AdamR: there is a thing on the service worker registration that is where we are setting things like supported payment methods
15:35:17 [Ian]
...but I think this is something else (on window)
15:35:55 [Ian]
zakim, close item 2
15:35:55 [Zakim]
agendum 2, Pascal's code, closed
15:35:56 [Zakim]
I see 1 item remaining on the agenda:
15:35:56 [Zakim]
3. filtering update [from Ian]
15:35:58 [Ian]
zakim, take up item 3
15:35:58 [Zakim]
agendum 3. "filtering update" taken up [from Ian]
15:37:41 [AdrianHB]
15:37:42 [Ian]
- Filtering mostly for w3c (abstraction) specs
15:37:50 [Ian]
ack AdrianHB
15:37:54 [Ian]
AdrianHB: I disagree with that.
15:38:12 [Ian]
..the whole point of the filtering is that new payment methods can be introduced that have their own unique filters
15:40:04 [adamR]
I said it last Thursday, but for the record, I disagree with Zach’s characterizatin here. If Chrome wants to do things that way, it’s fine, but I don’t think it should be required of all browsers.
15:40:33 [adamR]
And this is particularly distressing when you consider, e.g., Safari, which comes out every 18 to 24 months.
15:41:23 [AdrianHB]
ian: we want to be able to support filters for 3rd party payment apps
15:41:32 [Ian]
- payment handler api needs a stnadard way to provide capability information
15:42:29 [Ian]
15:42:37 [Ian]
For each paymentMethod in request.[[serializedMethodData]]:
15:42:37 [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:43:38 [AdrianHB]
15:43:52 [Ian]
IJ: I proposed a more neutral framing to make it possible that browsers do the matching
15:45:29 [Ian]
ack adr
15:46:30 [Ian]
AdrianHB: Let's get a resolution rather than a neutral stance
15:47:39 [Ian]
IJ: We got again into the security issues
15:47:50 [Ian]
I distinguished two things:
15:48:12 [Ian]
* Unconstrained string syntax
15:48:23 [Ian]
* Unlimited list length
15:48:44 [AdrianHB]
IJ: Nick-TR pointed out that generic string matching would also resolve an issue around the ability of networks to get included on the hard-coded network list
15:49:41 [Ian]
15:49:59 [Ian]
1) We need to clarify the process for accepting new identifiers. (e.g.,a simple anti-spam verificatino)
15:50:08 [Ian]
2) A disclaimer that appearance in the list is not a guarantee of interoperability across browsers.
15:50:41 [AdrianHB]
Sounds like this boils down to: Is there a strong enough case for a hard coded list (enumeration) or can we have a more flexible (but still constrained) list?
15:50:53 [adamR]
15:51:15 [AdrianHB]
For the record I would be a big +1 to doing away with the networks list if we can
15:52:25 [Ian]
IJ: Can we basically say (1) here's how you provide capabilities from a payment app and (2) here's in PR Api where that's taken into account, and leave it at that?
15:52:28 [Ian]
ack Ada
15:52:56 [Ian]
adamR: I'm not sure I followed that...we need to think about these things from the POV of browsers that are released less frequently, such as every 18 months.
15:53:18 [Ian] a network list that is only infrequently updated in a browser is a problem.
15:53:45 [Ian]
...I also would like there to be an authoritative list of network strings (to avoid e.g., amex v. americanexpress confusion).
15:54:21 [AdrianHB]
To be clear, having a list that helps avoid confusion and conflicts is fine but that's different to a list that has a gatekeeper to be added
15:54:50 [Ian]
AdamR: We also don't want duplicates
15:55:17 [Ian] ok with WG having lightweight approval process and indicating browser support is independent
15:55:18 [Ian]
15:55:40 [AdrianHB]
-1 to "lightweight approval process"
15:56:06 [Ian]
AdrianHB: I don't think there needs to be "approval". I think you can avoid duplicates without an approval process.
15:56:33 [Ian] approval process is dangerous
16:00:33 [ConorhWP]
I won't interrupt - I need to drop off now. Thanks all, goodbye.
16:03:46 [Ian]
Topic: next meeting
16:03:49 [Ian]
14 March
16:05:28 [Ian]
RRSAGent, bye
16:05:31 [Ian]
RRSAgent, make minutes
16:05:31 [RRSAgent]
I have made the request to generate Ian
16:05:36 [Ian]
RRSAgent, set logs public