IRC log of wpwg on 2016-09-08

Timestamps are in UTC.

13:58:04 [RRSAgent]
RRSAgent has joined #wpwg
13:58:04 [RRSAgent]
logging to http://www.w3.org/2016/09/08-wpwg-irc
13:58:06 [trackbot]
RRSAgent, make logs public
13:58:08 [trackbot]
Zakim, this will be
13:58:08 [Zakim]
I don't understand 'this will be', trackbot
13:58:09 [trackbot]
Meeting: Web Payments Working Group Teleconference
13:58:09 [trackbot]
Date: 08 September 2016
13:58:23 [Ian]
agenda: https://github.com/w3c/webpayments/wiki/Agenda-20160908
13:58:37 [Ian]
Ian has changed the topic to: http://www.w3.org/Payments/WG/
13:59:00 [Ian]
Regrets+ AdrianHB
13:59:17 [Ian]
present+ Ian
13:59:19 [Ian]
present+ Pascal
14:00:25 [nicktr]
present+ nicktr
14:00:39 [Ian]
present+ Roy
14:00:49 [Ian]
present AdamR
14:00:53 [Ian]
present+ AdamR
14:01:32 [nicktr]
q?
14:02:11 [ShaneM]
present+ ShaneM
14:02:50 [Max]
Max has joined #wpwg
14:03:03 [zkoch]
zkoch has joined #wpwg
14:03:13 [zkoch]
present+ zkoch
14:03:20 [Ian]
present+ Jean-Yves
14:03:25 [dlongley]
present+ dlongley
14:03:27 [manu]
Present+ Manu
14:04:35 [jyr]
Present+ jyr
14:04:42 [Ian]
regrets+ AdrianB
14:04:54 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/09/08-wpwg-minutes.html Ian
14:05:06 [Ian]
agenda => https://github.com/w3c/webpayments/wiki/Agenda-20160908
14:05:21 [Ian]
Topic: Decision to publish HTTP API and core message specifications
14:05:27 [Ian]
Decision email => https://lists.w3.org/Archives/Public/public-payments-wg/2016Sep/0035.html
14:05:54 [Ian]
nicktr: Thanks to all who prepared the documents and those who reviewed them.
14:06:05 [Ian]
...chairs and team contacts have been discussing the feedback and concerns as well
14:06:22 [rouslan]
rouslan has joined #wpwg
14:06:26 [Ian]
...there was broad support in the group to publish
14:06:29 [rouslan]
present+
14:06:38 [Ian]
...but also statements regarding implementation ("not planning to")
14:06:44 [manu]
q+ to offer next steps / plan
14:06:46 [Ian]
...we will want to ensure we have implementers in the group
14:06:49 [Ian]
ack manu
14:06:49 [Zakim]
manu, you wanted to offer next steps / plan
14:06:56 [nicktr]
ack manu
14:07:07 [ShaneM]
Thanks for getting this moving!
14:07:20 [Ian]
Manu: The Editors chatted briefly before this call. Our plan is to change the title of Core Messages, update the prose to match that, and we are wondering if there are other changes people want us to make to finalize the specs for publication
14:07:27 [Ian]
nicktr: I don't recall seeing seeing others
14:07:44 [Ian]
IJ: Any interest in combining the specs?
14:07:50 [Ian]
Manu: I think we would like to keep them separate for now.
14:08:03 [Ian]
...distinguish protocol from messaging
14:08:23 [Ian]
...at TPAC we will put forward a plan to address some of the concerns that were raised, such as getting implementers in the group.
14:08:37 [Ian]
...having the FPWD out there will help us in discussions with other PSPs and sites that want to expose the API
14:08:42 [nicktr]
q?
14:09:40 [Ian]
IJ: I am happy to draft the transition request. Anybody other than chairs want to see it?
14:09:42 [Ian]
[No answers]
14:09:49 [Ian]
IJ: I will draft that today for the Chairs.
14:10:42 [manu]
The editors will have FPWD-ready specs by next Monday.
14:10:48 [Ian]
...Hope to have approval by Monday
14:11:44 [Ian]
topic: Payment apps discussion on merchant control of display order
14:11:51 [Ian]
present+ Max
14:12:08 [Ian]
present+ Ken
14:12:44 [manu]
present+ Rouslan
14:13:08 [Ian]
Max: We had a brief discussion in the payment apps task force about merchant control of app ordering
14:13:15 [Ian]
...decided to bring the discussion here
14:13:41 [Max]
https://github.com/w3c/webpayments/blob/gh-pages/proposals/payment_app_user_experience.markdown
14:13:51 [Ian]
[Max wrote a proposal for discussion
14:14:15 [pascal]
pascal has joined #wpwg
14:14:29 [Ian]
Max: The use case is that a merchant may want to highlight a particular payment method (e.g., because there is some period of time when that payment method is subject to a promotion)
14:14:35 [Ian]
===
14:14:35 [Ian]
The merchant website supports aPay and bPay.
14:14:35 [Ian]
The user browser has only registered bPay.
14:14:35 [Ian]
There is a commercial promotion campaign cooperation between merchant website and aPay.
14:14:36 [Ian]
The merchant want the user browser to display both aPay and bPay during the promotion cooperation period. It is preferred to display aPay in a higher priority.
14:14:37 [Ian]
===
14:15:27 [Roy]
Roy has joined #wpwg
14:15:27 [manu]
q+ to wonder if this is the thing that drove the card brands out of the room at our F2F meeting?
14:15:28 [rouslan]
q+
14:15:31 [Ian]
Max: Merchant needs an API to influence the payment app display order
14:15:35 [Roy]
q+
14:15:41 [Ian]
q?
14:15:45 [nicktr]
q?
14:15:46 [Ian]
ack Manu
14:15:47 [Zakim]
manu, you wanted to wonder if this is the thing that drove the card brands out of the room at our F2F meeting?
14:16:07 [nicktr]
ack manu
14:16:36 [Ian]
Manu: Right now we have payment method order from merchant.
14:17:01 [Ian]
...are you suggesting an API instead?
14:17:24 [Ian]
Max: I am not sure what the mechanism should be...API is just an example. Other mechanisms to achieve the same goal of merchant-specified order are ok
14:17:56 [Ian]
q+
14:18:02 [Ian]
q+ to give some framing
14:18:14 [nicktr]
q?
14:18:20 [Ian]
ack rouslan
14:18:23 [nicktr]
ack rouslan
14:18:32 [Ian]
rouslan: I would like to hear perspectives from Amex.
14:18:38 [Ian]
...it would be good to get back to us on that
14:18:51 [nicktr]
ack Roy
14:19:03 [manu]
+1 rouslan - this should be /one/ of the signals that a browser takes.
14:19:06 [Ian]
...I think that we should enable the merchant to send preferences, but leave to the browser (using other data as well such as user prefs) to choose the final order
14:19:18 [Ian]
ack roy
14:19:28 [manu]
also, fwiw - +1 to declarative approach (in JSON) vs. imperative approach (API)
14:19:45 [Ian]
Roy: I definitely see the use case for this and why it is valuable. I get concerned about "going down the rabbit hole" of allowing the merchant to have final control over display
14:20:40 [rouslan]
q+ to perhaps clarify Roy's point?
14:20:40 [dlongley]
+1 merchants can implement this on their own by communicating with the payment app in some way
14:21:02 [Ian]
...what is the value proposition of a merchant to use the API instead of implementing their own checkout flow, especially if they have a limited number of payment methods, and they have a desire to strongly control the ordering.
14:21:05 [Ian]
ack rouslan
14:21:05 [Zakim]
rouslan, you wanted to perhaps clarify Roy's point?
14:21:05 [nicktr]
q?
14:21:41 [Ian]
rouslan: to clarify Roy's point further - the browser provides value to the merchant by bringing in more signals like "which payment methods were used on other sites" which the merchant would not know. This is a value-add for the merchant.
14:21:50 [Ian]
...if the merchant controls everything there are no signals from the browser.
14:21:53 [Ian]
ack me
14:21:53 [Zakim]
Ian, you wanted to give some framing
14:22:11 [Ian]
IJ: Signals we have
14:22:12 [manu]
Ian: Sounds like we're going to talk about signals, some of these signals include:
14:22:28 [manu]
Ian: The first one is payment method order through the Payment Request API.
14:22:32 [pirouz]
pirouz has joined #wpwg
14:22:35 [manu]
Ian: The second one is recommended payment apps
14:23:20 [Max]
q+
14:23:26 [manu]
Ian: Some of the scenarios we can imagine are - if you are on a website, and merchant recommends their own app, they can decide if one of them is same origin and display that at the top. Browser may have other configs that are helpful to the user, though. The question is a choice between the merchant having enough channels to express their preferences where browser takes those signals into account.
14:24:03 [manu]
Ian: or, browser has a definitive list - Roy/Rouslan said that if you want to take over the flow totally, then using the API doesn't help that much.
14:24:06 [nicktr]
q?
14:24:15 [nicktr]
ack Max
14:25:09 [Ian]
Max: Responding to Roy/Rouslan...merchant doesn't want full control...just some options to influence the ordering of the payment app. The benefit is that some merchants are more likely to adopt the payment request API if there is more flexibility to meet their needs.
14:25:24 [Ian]
...we would rather have them using the API then falling back to "the current way" of implementing their own checkout flow.
14:25:40 [zkoch]
q+
14:26:08 [Ian]
...my opinion (to clarify) is not to give the merchant total control of display order, just a mechanism to give the merchant some flexibility to influence the display order
14:26:09 [nicktr]
ack zkoch
14:26:35 [Ian]
zkoch: Two quick thoughts - ...(Chromium 53 rolled out yesterday)....we have talked with a lot of merchants
14:26:57 [Ian]
....as you know we are only supporting cards + android pay..it's not been a blocker for merchants to accept the API..it's limiting yes, but not a big blocker.
14:27:12 [Ian]
...in the end the merchants want to know whether the API has a positive effect on convergence
14:27:29 [Ian]
...I don't think we need all uses covered for merchants to adopt the API
14:27:46 [Ian]
....I will say that we have heard that there are use cases where the merchant would like to guarantee definitively that a payment app is available
14:27:50 [Ian]
...e.g., PayPal
14:28:10 [Ian]
...merchants would like, for example, not only to influence ordering, but to guarantee that a particular app is available
14:28:19 [Ian]
...so that's another "I need to guarantee" requirement
14:28:27 [Ian]
q+
14:28:57 [Ian]
nicktr: Max, are you looking for there to be a new mechanism beyond payment method order and recommended apps?
14:29:16 [Ian]
Max: For me, I haven't spent a lot of time thinking about solutions yet.
14:29:26 [nicktr]
q?
14:29:31 [Ian]
...I think we need more discussion to see whether the current mechanism is sufficient to cover the use case
14:29:35 [nicktr]
ack Ian
14:29:46 [manu]
Ian: On the topic that Zach raised about guaranteeing a particular payment method...
14:30:44 [manu]
Ian: I think we discussed this at some point, Zach, don't know if you put this idea of splitting accepted payment methods into two bundles - "must have support for these payment methods" and "I also accept these other ones". The merchant could get a signal back from "none of the required payment methods are registered".
14:31:03 [manu]
Ian: Can you clarify, Zach?
14:31:06 [Ian]
zkoch: I made two contradictory points - you don't have to solve all problems and "sometimes there are must-haves"
14:31:28 [Ian]
...if we want to solve the nascar problem and have a single "buy" button, then we need to solve this "must show" problem.
14:32:03 [Ian]
...meanwhile, back to the question about required v. also-supported payment methods, we've chatted a bit about it...AdrianB is looking into how we could potentially address this requirement.
14:33:35 [manu]
Ian: Then the merchant can set preferred order if required instruments are there? I don't know what browsers are going to provide - going out on a limb, Max, do you think knowing that required thing is there and being able to specify order is sufficient?
14:33:45 [manu]
Ian: Max, does having those two things meet your use case?
14:33:45 [Ian]
Max: Maybe...but need more time to work on it
14:34:01 [Ian]
NickTR: Sounds like it would be useful to have an issue to track against
14:34:37 [Ian]
IJ: I think we have an issue on this ...maybe we need to reopen if already closed to include this use case
14:34:37 [manu]
Ian: I think we have an issue on this, will look into it later.
14:34:43 [nicktr]
q?
14:35:18 [Ian]
Topic: Any updates to PMI proposal
14:35:33 [Ian]
zkoch: No updates yet
14:36:03 [Ian]
topic: Issue 244 - remove careOf?
14:36:08 [Ian]
https://github.com/w3c/browser-payment-api/issues/244
14:36:19 [Ian]
zkoch: Google's I18N team raised this issue
14:36:35 [adamR]
q+
14:36:43 [Ian]
ack Ad
14:37:19 [Ian]
adamR: The rationale for putting it there in the first place (and why I would like to keep it)...is that it has semantic importance at least in the US.
14:37:34 [Ian]
...I cite some references to legal postal code where these things have legal force
14:37:45 [Ian]
...and it's semantically appropriate to include these in addresses
14:38:15 [dlongley]
+1 priority of constituencies (easier for users)
14:38:24 [nicktr]
q?
14:38:25 [Ian]
...by not having this, we either force users to put information in a place where it's not convenient or obvious, or we make libraries more complicated to deal with this
14:38:26 [zkoch]
q+
14:38:41 [Ian]
...priority of constituencies suggests we make the user's experience easier
14:38:49 [Ian]
nicktr: I've not seen careOf in other APIs, FWIW
14:38:54 [nicktr]
ack zkoch
14:39:35 [Ian]
zkoch: There is a cost to support this. While I agree with AdamR's point about preferring the user experience, there are ways to address this.
14:39:50 [Ian]
...the browser could have a careOf field and put into the recipient of the response...we do that already
14:40:23 [Ian]
...if you want to put a CareOf field, you need to figure out as an implementer where to put it
14:40:37 [Ian]
....I do agree with Andy who raised the issue that there's not a lot of evidence of this in use out there.
14:40:59 [ShaneM]
q+ to mention that there are interop requriments with other standards like ISO 20022
14:41:24 [Ian]
ack ShaneM
14:41:24 [Zakim]
ShaneM, you wanted to mention that there are interop requriments with other standards like ISO 20022
14:41:26 [nicktr]
ack ShaneM
14:41:46 [Ian]
ShaneM: We may also want to consider interop with ISO20022
14:41:52 [adamR]
q+
14:41:57 [Ian]
ack ad
14:42:02 [dlongley]
is "care of" just a "special delivery instructions" field?
14:42:16 [adamR]
dlongley: See the references I put on the issue
14:42:23 [Ian]
nicktr: I don't think I've seen careOf in a card protocol; I also don't recall (but it may exist) careOf in a payment protocol
14:42:38 [Ian]
adamR: We are still going to have to have these fields, it's just a question of whether the user is doing it or software.
14:43:01 [nicktr]
q?
14:43:56 [manu]
Ian: We have an upcoming face-to-face meeting where we've been talking about whether browser vendors want to see if their code bases could use better harmonization. Wonder if Zach and AdrianB might discuss how this could be managed/addressed.
14:44:13 [manu]
Ian: So, punting to face-time so we can look at user experiences.
14:44:14 [Ian]
IJ: Can we punt to face time at TPAC to look at user experiences?
14:44:19 [ShaneM]
Might be useful to query the interest group
14:44:35 [Ian]
zkoch: I'm ok to punt to pac...also allows additional time for responses on github
14:44:46 [nicktr]
https://www.iso20022.org/standardsrepository/public/wqt/Content/mx/dico/bc/_FN9rs8TGEeChad0JzLk7QA_-1512507243
14:44:47 [Ian]
zkoch: Is there more evidence than USPS..if so, would be good to highlight that?
14:45:15 [Ian]
(Nick observes ISO 20022 doesn't have careOf)
14:45:27 [Ian]
Nick: I will take an action to work with Kris/Vincent to look at careOf in ISO20022
14:45:51 [Ian]
ACTION: Nick to check with Kris/Vincent on support for careOf in ISO20022
14:45:51 [trackbot]
'Nick' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., nshearer, ntelford).
14:46:00 [Ian]
topic: TPAC agenda check
14:46:09 [manu]
https://github.com/w3c/webpayments/wiki/FTF-Sep2016
14:46:16 [Ian]
https://github.com/w3c/webpayments/wiki/FTF-Sep2016
14:46:41 [manu]
Ian: In the last call, we asked for some people to sign up for some sessions. Just an update. Rouslan and I talked about implementation experience and demos.
14:47:10 [manu]
Ian: The goals of that session are now going to be to have implementers ask us questions based on their implementation experience, showing us demos, address issues, etc.
14:47:53 [manu]
Ian: For folks doing testing, share some of their observations on the specs. I distinguish that on the test suite. What we've learned through testing that might affect the APIs, I know Mike found some ambiguities / inadequate level of details when writing tests. This is an opportunity to discuss that.
14:48:26 [manu]
Ian: The decision on HTTP API, Manu will present something there.
14:48:49 [nicktr]
-> https://w3c.github.io/webpayments/proposals/method-practice/
14:49:05 [manu]
Ian: For Payment methods, we could have breakout sessions on day 2 to make progress on payment method specs. Max started a draft, I made some edits to it. Part of the payment methods agenda item. We don't have updates to SEPA, don't yet know if someone wants to sign up to lead a discussion on that.
14:49:30 [jyr]
q+
14:49:35 [manu]
Ian: That requires preparation - what question do editor's want feedback from group on. We'll have to meet on day 2 and make progress, unless someone wants to do a SEPA update for the group.
14:49:38 [Ian]
ack jyr
14:49:40 [nicktr]
ack jyr
14:51:18 [manu]
Ian: We have a draft SEPA Credit Transfer specification that Cyril started to work on.
14:51:22 [Ian]
http://w3c.github.io/webpayments-methods-credit-transfer-direct-debit/
14:51:32 [manu]
Ian: Unfortunately, Cyril won't be at TPAC.
14:52:14 [manu]
Ian: I started discussion w/ editors and Matt trying to figure out what we need to do to get it updated so we have a fresh draft for the group/get it updated. I haven't heard how we're going to do that. No updates to specification in time for TPAC. For those that are interested in spec, like in London, we can meet and make progress.
14:52:31 [manu]
Ian: Capturing inputs/outputs for credit transfer - don't know what we need to do to get that into a FPWD.
14:54:26 [manu]
Ian: Credit Transfer is close to push payments, so we have a first step to go through which is to establish some common vocabulary and understanding of what we're talking about, which is Direct Debit and Credit Transfer. Cyril created a UML diagram on credit transfer and some bits on direct debit, just a first draft. Various use cases inside Direct Debit. The point I'm making is that I do think that we need to not be so specific as SEPA. There is a recurring
14:54:26 [manu]
impression wrt. what are push payments. I think it would be very useful to define, during TPAC, the common understanding of what we're talking about. Payments for push payments / pull payments should not be specifically European question.
14:54:28 [Ian]
jyr: Maybe we need to group this under "push payment" discussion
14:54:46 [manu]
Ian: Maybe we do a break-out session where we talk about push-payments
14:54:48 [Roy]
+100
14:54:55 [manu]
q+ to say we should dump the Bitcoin folks into that discussion.
14:54:58 [ShaneM]
+1
14:55:08 [ShaneM]
(super interested in push payments!)
14:55:19 [jyr]
+1
14:55:21 [pirouz]
+1
14:55:44 [jyr]
+1
14:56:08 [Roy]
q+
14:56:46 [manu]
q-
14:56:50 [manu]
ack Roy
14:56:50 [nicktr]
ack Roy
14:57:33 [ShaneM]
How do we know when we are done?
14:57:43 [Roy]
q-
14:57:45 [Ian]
IJ: Roy will lead the push payment session and start by documenting his idea of goals for the session
14:58:35 [manu]
Ian: We may have discussion on recurring payments, etc. led by Andrew Betts in IG
14:58:58 [manu]
Ian: Points that we need to get through to get specs to CR, Zach, you're going to do stuff in that slot?
14:59:00 [manu]
Zach: Yes
14:59:33 [manu]
Ian: You mentioned two other specs that might appear by TPAC - cash on delivery and invoice specs.
14:59:56 [manu]
Zach: Yes, I'll see if we can bring some of that stuff up at TPAC. Those are payment method specs.
15:00:35 [manu]
NickTR: If there are other things you want to see on the Agenda, put them on there.
15:00:43 [Ian]
Topic: Next meeting
15:00:49 [Ian]
15 September
15:00:55 [Ian]
rrsagent, make minutes
15:00:55 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/09/08-wpwg-minutes.html Ian
15:01:02 [Ian]
rrsagent, set logs public
16:03:35 [zkoch]
zkoch has joined #wpwg
16:12:02 [adamR_]
adamR_ has joined #wpwg
16:15:41 [adamR__]
adamR__ has joined #wpwg
16:37:50 [adamR_]
adamR_ has joined #wpwg
16:40:29 [adamR__]
adamR__ has joined #wpwg
16:44:06 [adamR__]
adamR__ has joined #wpwg
16:48:04 [Ian]
Manu?
16:48:28 [Ian]
Shane?
16:54:46 [Adam__]
Adam__ has joined #wpwg
17:26:33 [ShaneM]
I am here
17:26:40 [ShaneM]
(sorry - in ARIA meeting)
17:35:14 [zkoch]
zkoch has joined #wpwg
18:54:30 [Adam__]
Adam__ has joined #wpwg
19:10:45 [shepazu_]
shepazu_ has joined #wpwg
19:35:20 [manu]
Ian, hey - what's up?
19:35:31 [Ian]
hi there!
19:35:35 [Ian]
see email re naming and shortnames
19:35:58 [Ian]
that's all...I'll look for email reply
19:37:09 [Ian]
tx!
19:53:52 [zkoch]
zkoch has joined #wpwg
20:00:01 [zkoch]
zkoch has joined #wpwg
20:09:57 [zkoch]
zkoch has joined #wpwg
20:30:04 [zkoch]
zkoch has joined #wpwg
20:35:48 [zkoch]
zkoch has joined #wpwg
21:17:10 [zkoch]
zkoch has joined #wpwg
21:22:10 [zkoch]
zkoch has joined #wpwg
21:48:28 [adamR]
adamR has joined #wpwg
21:48:34 [davidillsley_]
davidillsley_ has joined #wpwg
21:48:43 [shepazu]
shepazu has joined #wpwg
21:48:44 [mkwst]
mkwst has joined #wpwg
21:48:53 [adrianba]
adrianba has joined #wpwg
21:48:57 [emschwartz]
emschwartz has joined #wpwg
21:50:07 [zkoch]
zkoch has joined #wpwg
21:52:06 [nicktr]
nicktr has joined #wpwg
21:52:07 [AdrianHB]
AdrianHB has joined #wpwg
21:52:43 [Dongwoo]
Dongwoo has joined #wpwg
21:52:58 [slightlyoff]
slightlyoff has joined #wpwg
22:52:44 [zkoch]
zkoch has joined #wpwg
23:02:58 [zkoch]
zkoch has joined #wpwg
23:05:29 [zkoch]
zkoch has joined #wpwg
23:22:04 [zkoch]
zkoch has joined #wpwg