See also: IRC log
<scribe> Scribe: Ian
Manu email: https://lists.w3.org/Archives/Public/public-payments-wg/2017Sep/0042.html
Manu: We are trying to hit as
many browsers as we can, with different form factors
... UNTIL there is native support for PR API
... addresses both PR API and Payment Handler
... three scenarios:
1) Neither PR API nor PH implemented
2) PR API implemented but not PH
3) Third party payment handlers supported
scribe: polyfill does its best to
maximize functionality
... in today's demo we run the polyfill in Safari. Safari does
not have service workers
... what this demonstrates is that even with some core
functionality missing, this is still possible
[Manu adds cards]
[Part II of demo - click on the buy button]
Manu: We do some pre-caching to speed up user experience
<nicktr> Manu: deployable now
<nicktr> ...target audience is 2.8B people
<nicktr> ...polyfill almost entirely JavaScript
<nicktr> ...nothing server side
<nicktr> ... v fast to iterate and release within a week
Manu: There is no backing database
<nicktr> dezell: what's not js?
Manu: we chose not to do that; information is stored in indexdd or or local storage
<nicktr> Manu: only the web server
Ken: This is very interesting;
thank you
... How does this affect top of wallet selection by the
user?
... How would this affect the value proposition for merchants,
payment instruments?
Manu: Regarding
top-of-wallet...that's a topic of ongoing discussion in the
group.
... whatever consensus there is, we can impelment.
... we are preferring what the user wants
... some options:
1) Show the entire list, randomized
2) Sort the cards based on what the user has selected most frequently
scribe: we could store user information client side
3) Merchants can signal preferences which are reflected on the user side
scribe: we would only do that if
there is WG consensus
... so at a high level, we will defer to the WG
Manu: regarding value
proposition
... I don't think much changes for merchants here
... the polyfill is not quite ready, but in a few months after
testing, etc. the WG can promote the API with the polyfill as a
transition path
... there are security and performance advantages of native
implementation
... but I think the value proposition for DEVELOPERS goes
up
... they can start to experiment
Ken: My understanding is that this is intended as an interim solution. But I see this as potentially being used on a permanent basis.
Manu: The plan is that if the
WG's features are implemented, then native implementations will
take over, and the polypill will defer to native
... there is a possibility that, if some of the browser vendors
decide they don't want to implement something like payment
handlers, the polyfill could support third party payment apps
in those browsers.
... it could also support experimentation
... if there are enough people wanting to experiment with
something behind a flag, the polyfill could still support
it
... we could also extend the polyfill to support other features
not discussed in the WPWG
... one example could be around credential handling
... there is a lot of similarity between handing payment
information to the merchant and handing assertions to the
merchant
... we could use this polyfill framework to exchange social
data.
(Ian thinks that where the polyfill departs from WG activity; that should be signaled somehow)
AdrianHB: It would make sense for
this to be hosted at the same origin irrespective of where
used
... does this need to be hosted in one place, or could
merchants host it themselves and still expect it to work?
Manu: Our biggest concern about
the polyfill, there needs to be a payment mediator
website.
... there should only be one of those
... we are suggesting that we use one payment mediator
site
... there's a security concern
... if someone were to get access to that site, because we do
things like basic card and don't do end-to-end encryption,
people could read data
... through a man-in-the-middle attack.
... if we had end-to-end encryption, details would not be
available
... this is no different from someone injecting a script on
other sites
... we use mitigations like code signing, continuous monitoring
(of hashes of scripts)
... we can do things like use service workers for browsers that
have them to only download the polyfill code once unless
manually reloaded
... we'd like to share the burden of running the polyfill site
with other companies
<Zakim> AdrianHB, you wanted to ask about hosting and origin security
Manu: There are parts of the
polyfill hosted on the merchant site, and parts hosted on the
payment handler side.
... the only part we can't do that with is the mediator code,
which is small but centralized
AdrianHB: The mediator code is
client-side JS, right?
... it seems like you could resist tampering with hash-based
protections
... sub resource integrity
<Zakim> dezell, you wanted to ask about E2E
dezell: What is in your mind
regarding end-to-end encryption?
... do you think some of the tokenization discussions in the WG
would help?
Manu: There are two levels of the
concern. One is doing the bare minimum in protecting the card
data....
... tokenization would help
... what we'd really like to see is complete end-to-end
encryption
(See the nascent encrypted card spec => https://github.com/w3c/webpayments-methods-tokenization/wiki/encrypted_card)
Manu: this is probably a new payment method
<manu> Ian: Just wanted to get a clarification...
Manu: Data passes through a third party, which is the mediator web site
IJ: Is that a source of concern?
Manu: It acts in the same role as
the browser
... the benefit for the payment mediator is that all the code
can be verified
... so it's a bit more open that proprietary browser code
... but I do expect this to be a topic of debate
... orgs that aren't comfortable with this don't have to use
the polyfill.
<manu> Ian: Similarly, concerns raised as things going in the clear is the same as web forms are submitted today.
AdrianHB: Thanks Manu!
Please register
https://www.w3.org/2002/09/wbs/35125/TPAC2017/
https://www.w3.org/2017/11/TPAC/
<manu> Ian: We are going up against DreamForce ... please reserve... room blocks are precious.
6 October break point
<manu> Ian: After that date, registration fee goes up, it gets harder and harder to attend.
https://github.com/w3c/webpayments/wiki/FTF-Nov2017
<manu> Ian: Rechartering the WG is something we'll discuss at TPAC.
https://w3c.github.io/webpayments/proposals/charter-2017
<manu> Ian: One of the gaps in the charter is new topics that the group should pick up... I'd like to work up introductory proposals so the group can go through them at the F2F meeting.
<manu> Ian: Let's get a sense from people about what they'd specifically like to be covered in the charter. W3C Members like specific deliverables... open ended charters create concerns around patents.
<manu> Ian: People that are interested in us covering certain topics should reach out to Chairs and me - we should make sure they're on the Agenda. You can type things in on the Agenda that you'd like to discuss.
Manu: When is the charter going to be finalized?
<manu> Ian: The Agenda will be finalized a week before the meeting...
IJ: I would like to start review in Dec and extend group; expect rechartered by Feb
<manu> Ian: Charter expires on Dec 31st... I'd like to take a charter to management by 3rd week of November... start the review, which would go into January. When review starts, group extension is probably provided.
https://github.com/w3c/payment-request/issues?q=is%3Aissue+is%3Aopen+label%3ACR-Exit
<nicktr> Would encourage everyone to review the the proposed revised charter
AdrianHB: We asked for comments on these before end of TPAC
IJ: Let's start walking through in calls up to TPAC
Roy: Not up to speed
<scribe> ACTION: AdrianHB and chairs to check with Editors on how to manage this list [recorded in http://www.w3.org/2017/09/21-wpwg-minutes.html#action01]
<trackbot> Created ACTION-67 - And chairs to check with editors on how to manage this list [on Adrian Hope-Bailie - due 2017-09-28].
<manu> Ian: My interpretation of that date ... a couple of functions. We want substantive comments in as early as possible. It sets an expectation that we won't advance to PR until after that date.
<manu> Ian: I don't believe it means people can't comment after that date.
<manu> Ian: We set that date w/ TPAC in mind... to prompt comments.
Manu: Let's not use that date to say "we cannot further accept comments"
<manu> Ian: That's not the date that says we're going to leave CR... it's just a minimal date.
<manu> Ian: I don't think the process authorizes the group to stop listening to input, but the group... over time... is increasingly licensed to postpone things because the spec is maturing.
<manu> Ian: People can raise issues at PR, they can be taken into account, but it becomes more socially expected that things raised late in the process may not lead to changes.
AdrianHB: I think that
interpreting it as a "minimum" time is the right way to do
it
... I've done a blog post on the feature at risk
https://medium.com/@ahopebailie/currencysystem-is-at-risk-d29aebafdd38
AdrianHB: the task force has
disbanded
... henceforth those topics will move to this agenda
AdrianHB: I suggest we meet next week and focus on TPAC agenda and charter
IJ: Let's also consider https://github.com/w3c/payment-request/issues?q=is%3Aissue+is%3Aopen+label%3ACR-Exit
Next meeting: 28 September
<AdrianHB> https://medium.com/@ahopebailie/currencysystem-is-at-risk-d29aebafdd38
[No regrets signaled]
AdrianHB: Thanks Manu and Dave