IRC log of wpwg on 2019-09-05

Timestamps are in UTC.

13:57:18 [RRSAgent]
RRSAgent has joined #wpwg
13:57:18 [RRSAgent]
logging to https://www.w3.org/2019/09/05-wpwg-irc
13:57:27 [Ian]
Meeting: Web Payments Working Group
13:57:39 [Ian]
Chair: NickTR
13:57:41 [Ian]
Scribe: Ian
13:57:43 [Ian]
present+
13:57:49 [Ian]
present+ Fawad_Nisar
13:58:13 [Ian]
agenda: https://github.com/w3c/webpayments/wiki/Agenda-20190905
13:58:15 [Ian]
agenda+ TPAC
13:58:32 [Ian]
agenda+ PR API 1.0
13:58:37 [Ian]
agenda+ PR API 1.1 new issues
13:59:17 [Ian]
present+ Florent_Lambert
14:00:22 [Ian]
present+ Nick_Telford-Reed
14:01:20 [florent]
florent has joined #wpwg
14:01:39 [rouslan]
rouslan has joined #wpwg
14:01:49 [Ian]
present+ David_Benoit
14:01:56 [nicktr]
present+ nicktr
14:02:09 [Ian]
present+ Rouslan_Solomakhin
14:02:10 [Ian]
present+ Dean_Ezra
14:02:34 [deanezra]
deanezra has joined #wpwg
14:02:49 [vkuntz]
vkuntz has joined #wpwg
14:02:59 [Ian]
present+ Vincent_Kuntz
14:04:01 [Ian]
-> https://github.com/w3c/webpayments/wiki/Agenda-20190905 Agenda
14:04:18 [Ian]
zakim, take up item 1
14:04:18 [Zakim]
agendum 1. "TPAC" taken up [from Ian]
14:04:39 [Ian]
NickTR: I look forward to seeing you all in Japan
14:04:55 [Ian]
...please note that registration has closed
14:05:20 [Ian]
present+ Danyao_Wang
14:05:33 [nicktr]
https://github.com/w3c/webpayments/wiki/FTF-Agenda-201909#preparation
14:05:33 [Ian]
NickTR: We have a list of things to read:
14:05:35 [Ian]
https://github.com/w3c/webpayments/wiki/FTF-Agenda-201909#preparation
14:07:14 [Ian]
present+ Alex_Liu
14:07:28 [nicktr]
ian: Group dinners
14:07:55 [nicktr]
... there are 41 members of the group registered plus observers
14:08:03 [nicktr]
...we may have 50-60 participants
14:08:26 [nicktr]
...we would like to have a dinner together on Monday evening
14:08:49 [nicktr]
ian: anyone have preferences?
14:09:37 [Ian]
IJ: I expect to seek a Japanese restaurant
14:10:12 [Ian]
zakim, close item 1
14:10:12 [Zakim]
agendum 1, TPAC, closed
14:10:13 [Zakim]
I see 2 items remaining on the agenda; the next one is
14:10:13 [Zakim]
2. PR API 1.0 [from Ian]
14:10:28 [Ian]
zakim, take up item 2
14:10:28 [Zakim]
agendum 2. "PR API 1.0" taken up [from Ian]
14:11:07 [Ian]
IJ: I think we are one Safari fix away from implementation report
14:11:49 [Ian]
IJ: There is a proposed privacy enhancement:
14:11:49 [Ian]
https://github.com/w3c/payment-request/pull/873
14:13:14 [Ian]
present+ Adrian_Hope-Bailie
14:14:48 [Ian]
IJ: What are the opportunities lost by not advancing to Recommendation for another 8 months?
14:14:56 [nicktr]
scribenick: nicktr
14:15:02 [rouslan]
q+
14:15:06 [Ian]
ack rouslan
14:15:08 [nicktr]
IJ: I expect we will discuss at the F2F
14:15:10 [Ian]
scribenick: Ian
14:15:27 [Ian]
Rouslan: For us, the Recommendation status is not critical to us; draft spec is good enough for us to implement.
14:15:48 [Ian]
...once the spec is modified to accommodate the needs of privacy reviewers, we will implement it in due time. But we will do so carefully.
14:15:54 [benoit]
benoit has joined #wpwg
14:15:56 [nicktr]
q+
14:15:58 [Ian]
ack nick
14:16:00 [Ian]
nicktr,
14:16:46 [Ian]
nicktr: From merchants I speak with, I think that not going to Rec can be a drag on adoption
14:17:57 [AdrianHB]
q+ to talk about complexity of parallel work
14:17:57 [Ian]
IJ: Group motivation is another topic
14:18:01 [Ian]
ack AdrianHB
14:18:01 [Zakim]
AdrianHB, you wanted to talk about complexity of parallel work
14:18:29 [Ian]
AdrianHB: Management of versions in parallel adds complexity and overhead.
14:18:30 [nicktr]
q+ to ask about whether it has a bearing on rechartering?
14:19:00 [Ian]
AdrianHB: I think if we can continue working and forging ahead on new features we should do so as simply as possible.
14:19:12 [Ian]
nicktr: What is the impact of delay on rechartering?
14:19:23 [Ian]
Ian: I doubt it
14:19:50 [danyao]
q+ to clarify parallel work comment
14:20:11 [nicktr]
ack me
14:20:11 [Zakim]
nicktr, you wanted to ask about whether it has a bearing on rechartering?
14:20:36 [nicktr]
ij: I don't think it's significant on rechartering
14:20:46 [Ian]
ack dan
14:20:46 [Zakim]
danyao, you wanted to clarify parallel work comment
14:20:49 [Ian]
scribenick: Ian
14:21:27 [Ian]
danyao: As we develop Chrome we focus on backward compatibility, so that should assuage merchant concern.
14:21:38 [Ian]
...I want to avoid feature creep
14:21:42 [AdrianHB]
+1 to avoid feature creep
14:22:38 [nicktr]
+1 to avoiding feature creep
14:22:47 [Ian]
Proposed: No other features than the privacy feature will be considered for PR API 1.0
14:22:51 [nicktr]
+1
14:22:56 [AdrianHB]
+1
14:22:59 [danyao]
+1
14:23:01 [rouslan]
+1
14:23:09 [AdrianHB]
clarifying comment: it is hard work for the group to manage parallel work on the specs if we have a v1.0 spec that is a trying to go to CR and another that is documenting new features
14:23:31 [nicktr]
I strongly support this - we need the privacy improving feature to get through the CR milestone but nothing else
14:23:37 [Ian]
Danyao: We are committed to finishing PR API 1.0 features before we start on 1.1 features
14:24:56 [Ian]
q?
14:25:10 [Ian]
zakim, close item 2
14:25:10 [Zakim]
agendum 2, PR API 1.0, closed
14:25:11 [Zakim]
I see 1 item remaining on the agenda:
14:25:11 [Zakim]
3. PR API 1.1 new issues [from Ian]
14:25:14 [benoit]
+1 for PR feature lock
14:25:16 [Ian]
zakim, take up item 3
14:25:16 [Zakim]
agendum 3. "PR API 1.1 new issues" taken up [from Ian]
14:25:49 [Ian]
Issue 879: SKUs instead of totals
14:25:55 [Ian]
https://github.com/w3c/payment-request/issues/879
14:26:10 [Ian]
Rouslan: This is a new feature (so 1.1). We want to have better integration of Web sites with Google Play.
14:26:21 [Ian]
...we want to expose the Google Play billing capabilities to Web sites
14:26:44 [Ian]
...merchants enter information in a Google Play database; they get back SKUs.
14:27:04 [Ian]
...when people want to buy things, merchants provide SKUs and the payment handler shows the price (that was stored in the database)
14:27:30 [Ian]
...so a proposal for PR API is to include an alternative where total/currency is replaced by an SKU.
14:27:39 [Ian]
...the SKUs would be origin-bound.
14:28:06 [AdrianHB]
q+ can we just pass in a Promise as total that must resolve to a valid total object?
14:28:13 [AdrianHB]
q+ to can we just pass in a Promise as total that must resolve to a valid total object?
14:28:26 [Ian]
...so we'd need to add a method to PR API (e.g., getDisplayedItems) and would require us to make the total more complex, like "currency/amount OR SKU"
14:28:29 [Ian]
ack AdrianHB
14:28:29 [Zakim]
AdrianHB, you wanted to can we just pass in a Promise as total that must resolve to a valid total object?
14:29:06 [Ian]
AdrianHB: If we wanted to make this slightly more generic...you are I believe getting a total asynchronously. Do you think we could decouple those further, e.g., pass in a promise for a total, and how the promise resolves is distinct from PR API.
14:29:57 [Ian]
Rouslan: We have considered that idea. There might be a server endpoint where the merchant could fetch the amount based on SKUs. However, we feel like it could make the world more complex since people would have to use a second API to translate SKUs.
14:30:05 [nicktr]
will take comments to the issue - I think this moves PR away from payment and into a commerce API. It's hard to imagine a payment request that doesn't specify an amount and currency
14:30:49 [Ian]
IJ: I am guessing "list of SKUs" as input
14:31:18 [Ian]
nicktr: I think we need to think carefully about this; currency/amount are fundamentals of a payment. It feels like we might be moving farther away from a "payment request"
14:31:24 [Ian]
q?
14:31:52 [Ian]
https://github.com/w3c/payment-request/wiki#payment-flows
14:32:37 [Ian]
Issue 407: More restrictive hasEnrolledInstrument() for autofill data
14:32:43 [Ian]
https://github.com/w3ctag/design-reviews/issues/407
14:33:00 [Ian]
Rouslan: Chrome is currently the browser that implements Basic Card using its own autofill data.
14:33:06 [Ian]
...in this data, Chrome is acting as a payment handler
14:33:46 [Ian]
...in general we don't standardize UX
14:33:59 [Ian]
..but there is one behavior we'd like to introduce that might alter the expectation about what Basic Card does
14:34:11 [Ian]
..we are not sure if this is a browser-specific optimization or whether it should be standardized.
14:35:20 [Ian]
..the behavior we'd like to change for Basic Card is, when you call hasEnrolledInstrument(), it will return false() unless the card is really ready to pay (e.g., all data is present, card has not expired, etc.)
14:35:41 [Ian]
...we really want true() to represent a happy path and high chance of conversion.
14:36:14 [Ian]
-> https://gist.github.com/rsolomakhin/d6d242cbb9306864ada5a29de7ab271e Rouslan's explainer
14:36:56 [Ian]
...so the request to the group is whether this behavior should be part of the Basic Card spec or whether it should be implementation-specific.
14:37:23 [Ian]
..might be good to be in the spec for consistent UX
14:37:24 [Ian]
q+
14:37:37 [Ian]
..but if we put this in the spec, this ties browser hands
14:38:56 [AdrianHB]
ian: first reaction, "What's the definition of hasEnrolledInstrument?". Is this payment method specific? I hadn't thought about it that way?
14:40:11 [AdrianHB]
ian: you raise questions about variability that is related to how payment handlers behave.
14:40:31 [AdrianHB]
... how explicit would we be in sepcifying this behaviour?
14:41:25 [nicktr]
q?
14:41:28 [nicktr]
ack Ian
14:41:46 [danyao]
q+ to comment on hasEnrolledInstrument for basic-card
14:42:11 [AdrianHB]
ian: If it's in Basic Card how would we define things like "valid billing address"? We have had issues in the past around determining things like card type from BIN
14:42:13 [Ian]
IJ: I would need to see definitions.
14:42:22 [Ian]
Rouslan: I am favor of NOT moving this into Basic Card. :)
14:42:25 [Ian]
ack Danyao
14:42:25 [Zakim]
danyao, you wanted to comment on hasEnrolledInstrument for basic-card
14:42:38 [AdrianHB]
q+ to ask if it makes any difference since basic card spec is a note
14:42:38 [Ian]
Danyao: My mental model is that Basic Card defines a schema.
14:43:06 [Ian]
Danyao: I think the minimum expectation is "true()" means the payment handler can return an instrument to the best of its ability
14:43:09 [AdrianHB]
+1
14:43:34 [Ian]
Danyao:..what we are fixing in Chrome is that an expired card would not work, so we should allow the payment handler to make the decision.
14:43:46 [benoit]
+1
14:43:47 [Ian]
...the spec should focus on data and allow the payment handler to do what it does best.
14:44:16 [Ian]
AdrianHB: I am agreeing with Danyao and Rouslan, although I would add to that that if we put any text in the Basic Card spec, we could do so as informative text.
14:44:39 [Ian]
...I would take it further to say that it's probably appropriate for the behavior of a payment handler to be defined in the payment method spec.
14:45:27 [Ian]
q+
14:45:32 [Ian]
ack AdrianHB
14:45:33 [Zakim]
AdrianHB, you wanted to ask if it makes any difference since basic card spec is a note
14:46:07 [Ian]
AdrianHB: I think we should make clear in the PR API spec that there's no guarantee you'll get something back even if you requested it.
14:46:59 [rouslan]
q+
14:47:46 [Ian]
AdrianHB: If it's possible for a payment handler to return shipping address or email addresses, then it's impossible for them to reply to hasEnrolledinstrument() with true unless they have the data.
14:47:51 [Ian]
ack rouslan
14:48:05 [Ian]
Rouslan: This is a behavior we want to provide for autofill data only
14:48:13 [Ian]
..it would not be relevant for third-party handlers
14:48:35 [Ian]
...so maybe that's the decision-maker: if it's autofill specific, then it's not part of the spec
14:48:38 [danyao]
q+
14:49:18 [Ian]
"The CanMakePaymentEvent is used to check whether the payment handler is able to respond to a payment request. "
14:50:16 [Ian]
IJ: I would add some verbiage to tell payment handlers that they should respond true when the user really is ready to pay.
14:50:26 [Ian]
....and that may be payment method specific and rely on other circumstances
14:50:29 [Ian]
ack Dan
14:50:31 [Ian]
ack me
14:51:19 [Ian]
Danyao: I think Adrian's point is that the mediator should not be overly restrictive. I agree. But payment handlers should have flexibility to be more restrictive.
14:52:15 [AdrianHB]
+1 to continue on GitHub. Can we log an issue or should we comment on Rouslan's Gist
14:53:05 [Ian]
Danyao: I am ok with with a non-normative note in PH API that says "ready to pay and may vary by payment method and context."
14:53:06 [nicktr]
to danyao's earlier point, the payment method specs should define the data model and behaviour specific to each payment method, so the "right thing" should be defined there
14:53:12 [Ian]
Topic: Next meeting
14:53:19 [Ian]
Face-to-face!
14:53:37 [Ian]
Topic: Web Monetization
14:53:44 [AdrianHB]
https://github.com/adrianhopebailie/web-monetization/blob/master/explainer.md
14:53:52 [Ian]
AdrianHB: We did a big update to the explainer.
14:53:53 [AdrianHB]
https://github.com/adrianhopebailie/web-monetization/blob/master/sending.md
14:54:00 [Ian]
...there's a nice synergy between the design and PR API
14:54:11 [Ian]
...we plan to send monetized payments via PH API as-is
14:54:31 [nicktr]
that's very exciting
14:54:32 [Ian]
-> https://www.w3.org/blog/2019/09/w3c-interview-coil-on-interledger-protocol-and-web-monetization/ Ian's interview with Stefan Thomas on Monetization
14:54:43 [benoit]
very cool
14:55:05 [Ian]
AdrianHB: See you in Japan
14:55:06 [benoit]
"coil hype machine" should absolutely be a thing ;)
14:55:08 [Ian]
RRSAGENT, make minutes
14:55:08 [RRSAgent]
I have made the request to generate https://www.w3.org/2019/09/05-wpwg-minutes.html Ian
14:55:28 [Ian]
RRSAGENT, set logs public
14:57:11 [Ian]
rrsagent, bye
14:57:11 [RRSAgent]
I see no action items