See also: IRC log
https://w3c.github.io/webpayments/proposals/charter-2017
AdrianHB: A few weeks ago we asked people to bring their ideas for charter topics to the call.
IJ: Matt, do you want to write down recurring payments ideas for FTF meeting?
Matt: Yes, happy to do this.
Tricky topics like parameters, who uses the information, how it
is passed to the back end.
... so I think this goes beyond customer and merchant if it is
meant to be useful.
adrianhb: Some of these topics
are pertinent to some payment methods but not all
... so part of the discussion is whether a feature is for PR
API or for a payment method
... it's still worth having these topics in our charter (but
how they manifest themselves may vary...PR API or payment
method)
IJ: Is this of sufficient interest to you?
Matt: Yes
IJ: Andre, if we were to expand
data collection, what would be next?
... you spoke of discount codes before
alyver: Still discount
codes
... we can demo what we've done to work around lack of discount
codes
IJ: AdrianHB ILP?
adrianhb: Yes, I plan to write a proposal
https://github.com/w3c/webpayments/wiki/FTF-Nov2017
AdrianHB: How would we express things as in scope in new charter?
IJ: Can we do a demo of web-based payment apps?
Rouslan: Yes.
IJ: I will reach out to people to connect them.
Ian:Attendance note: 40 registered for WPWG FTF
... so far
Capability matching
https://github.com/w3c/payment-handler/issues/157
https://github.com/w3c/payment-handler/pull/170
[IJ reviews history of this]
Rouslan: We are experimenting
with canMakePayment...we've come up with a compromise in
discussions with Mozilla
... the compromise is this:
- if the merchant requests a W3C-standard payment method (basic card or others)
scribe: then the browser does the
capability matching
... this means that transaction information is not shared with
arbitrary service workers.
- for URL-based payment methods, we believe it will be best to do a canMakePayment() event unless the user's browser is in incognito mode
scribe: canMakePayment() responds
true in that case
... we think the concern goes down for proprietary payment
methods
... edge case => payment handler handles both open and
proprietary payment methods
... in this case we plan to adopt the browser-based matching
but only on the open standard
... final issue we need to address: some merchants will be
malicious and use this pipe to communicate to some other
malicious service worker.
... I think that private browsing mode is the right
solution.
Rouslan: We also have the safe
browsing database that is shared among browsers
... we provide guidance to users when they visit those
sites
... I believe the database should take into account abuse of
the API
IJ: Maybe at the end of CR we
document in our FAQ any security measures browsers are
using
... Next step?
Rouslan: Next step for me is to
write up a new pull request
... I could update the patch to do what I've described
Ian: Marcos has requested we adjust this time to accommodate Melbourne time zone
<scribe> ACTION: Chairs to discuss meeting time [recorded in http://www.w3.org/2017/09/28-wpwg-minutes.html#action01]
<trackbot> Error finding 'Chairs'. You can review and register nicknames at <http://www.w3.org/Payments/WG/track/users>.
IJ: hard problem
IJ: When do editors next meet?
Molly: Next weds
- Todo list from marcos => https://github.com/w3c/payment-method-basic-card/issues/43
- Basic Card to Note => https://github.com/w3c/payment-method-basic-card/issues/43
IJ: What can the WG do to help?
Molly: I will do by email or on the call next week
5 October
https://github.com/w3c/automotive-pay/wiki
IJ: Contact me if interested!