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