IRC log of wpwg on 2017-09-21

Timestamps are in UTC.

13:59:53 [RRSAgent]
RRSAgent has joined #wpwg
13:59:53 [RRSAgent]
logging to http://www.w3.org/2017/09/21-wpwg-irc
14:00:06 [Ian]
Meeting: Web Payments Working Group
14:00:18 [AdrianHB]
AdrianHB has joined #wpwg
14:00:30 [Ian]
Chair: AdrianHB
14:00:32 [Ian]
Agenda: https://github.com/w3c/webpayments/wiki/Agenda-20170921
14:00:35 [Ian]
Scribe: Ian
14:01:08 [Ian]
present+
14:01:10 [Ian]
present+ NickTR
14:01:14 [manu]
present+ Manu
14:01:14 [Ian]
present+ Manu
14:03:01 [Ian]
present+ DaveLongley
14:03:31 [Ian]
present+ Ken
14:03:34 [Ian]
present+ ChrisMarconi
14:04:00 [AdrianHB]
present+ AdrianHB
14:04:02 [Ian]
present+ alyver
14:04:03 [alyver]
present+
14:06:41 [Ian]
Topic: Digital Bazaar Polyfill
14:07:21 [Ken]
Ken has joined #wpwg
14:07:51 [Ian]
Manu email: https://lists.w3.org/Archives/Public/public-payments-wg/2017Sep/0042.html
14:08:31 [Ian]
present+ DavidLehn
14:08:38 [Ken]
Ken has joined #wpwg
14:08:46 [Ian]
Manu: We are trying to hit as many browsers as we can, with different form factors
14:08:52 [Ian]
...UNTIL there is native support for PR API
14:09:02 [lte]
lte has joined #wpwg
14:09:03 [Ian]
...addresses both PR API and Payment Handler
14:09:06 [Ian]
...three scenarios:
14:09:12 [Ian]
1) Neither PR API nor PH implemented
14:09:17 [dlehn]
present+ David_Lehn
14:09:18 [Ian]
2) PR API implemented but not PH
14:09:48 [Ian]
3) Third party payment handlers supported
14:10:00 [Ian]
...polyfill does its best to maximize functionality
14:10:29 [Ian]
...in today's demo we run the polyfill in Safari. Safari does not have service workers
14:10:46 [Ian]
...what this demonstrates is that even with some core functionality missing, this is still possible
14:10:55 [Ian]
present+ Roy
14:11:02 [nicktr]
q?
14:11:16 [Ian]
present+ LauraTownsend
14:12:36 [Ian]
[Manu adds cards]
14:12:52 [dezell]
present+ dezell
14:13:05 [nicktr]
q?
14:13:20 [Ian]
[Part II of demo - click on the buy button]
14:13:58 [Ian]
Manu: We do some pre-caching to speed up user experience
14:15:40 [nicktr]
Manu: deployable now
14:15:56 [nicktr]
...target audience is 2.8B people
14:16:20 [nicktr]
...polyfill almost entirely JavaScript
14:16:30 [nicktr]
...nothing server side
14:16:53 [nicktr]
... v fast to iterate and release within a week
14:17:04 [dezell]
q+
14:17:24 [Ken]
q+
14:17:34 [nicktr]
ack de
14:18:01 [Ian]
Manu: There is no backing database
14:18:08 [nicktr]
dezell: what's not js?
14:18:12 [Ian]
...we chose not to do that; information is stored in indexdd or or lock storage
14:18:17 [Ian]
s/lock/local
14:18:27 [nicktr]
Manu: only the web server
14:18:30 [AdrianHB]
ack ken
14:18:35 [Ian]
Ken: This is very interesting; thank you
14:18:55 [Ian]
Ken: How does this affect top of wallet selection by the user?
14:19:09 [Ian]
Ken: How would this affect the value proposition for merchants, payment instruments?
14:19:27 [Ian]
Manu: Regarding top-of-wallet...that's a topic of ongoing discussion in the group.
14:19:34 [Ian]
...whatever consensus there is, we can impelment.
14:19:41 [Ian]
...we are preferring what the user wants
14:20:05 [Ian]
...some options:
14:20:09 [Ian]
1) Show the entire list, randomized
14:20:38 [Ian]
2) Sort the cards based on what the user has selected most frequently
14:20:53 [Ian]
...we could store user information client side
14:21:10 [Ian]
3) Merchants can signal preferences which are reflected on the user side
14:21:24 [Ian]
...we would only do that if there is WG consensus
14:21:32 [Ian]
...so at a high level, we will defer to the WG
14:21:56 [Ian]
Manu: regarding value proposition
14:22:01 [Ian]
...I don't think much changes for merchants here
14:22:49 [Ian]
...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
14:23:06 [Ian]
...there are security and performance advantages of native implementation
14:23:16 [Ian]
...but I think the value proposition for DEVELOPERS goes up
14:23:30 [Ian]
...they can start to experiment
14:24:32 [Ian]
present+ AnaGrace
14:24:59 [AdrianHB]
q+ to ask about hosting and origin security
14:25:00 [Ian]
Ken: My understanding is that this is intended as an interim solution. But I see this as potentially being used on a permanent basis.
14:25:27 [Ian]
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
14:26:07 [Ian]
...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.
14:26:24 [Ian]
...it could also support experimentation
14:26:46 [Ian]
...if there are enough people wanting to experiment with something behind a flag, the polyfill could still support it
14:27:15 [Ian]
...we could also extend the polyfill to support other features not discussed in the WPWG
14:27:24 [Ian]
..one example could be around credential handling
14:28:00 [Ian]
..there is a lot of similarity between handing payment information to the merchant and handing assertions to the merchant
14:28:47 [Ian]
...we could use this polyfill framework to exchange social data.
14:29:09 [Ian]
(Ian thinks that where the polyfill departs from WG activity; that should be signaled somehow)
14:29:25 [Ian]
AdrianHB: It would make sense for this to be hosted at the same origin irrespective of where used
14:29:36 [Ian]
...does this need to be hosted in one place, or could merchants host it themselves and still expect it to work?
14:29:54 [Ian]
Manu: Our biggest concern about the polyfill, there needs to be a payment mediator website.
14:29:57 [Ian]
..there should only be one of those
14:30:04 [Ian]
...we are suggesting that we use one payment mediator site
14:30:09 [Ian]
..there's a security concern
14:30:35 [Ian]
...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
14:30:45 [Ian]
...through a man-in-the-middle attack.
14:30:56 [Ian]
..if we had end-to-end encryption, details would not be available
14:31:16 [Ian]
...this is no different from someone injecting a script on other sites
14:31:25 [dezell]
q+ to ask about E2E
14:31:43 [Ian]
...we use mitigations like code signing, continuous monitoring (of hashes of scripts)
14:32:10 [Ian]
...we can do things like use service workers for browsers that have them to only download the polyfill code once unless manually reloaded
14:32:24 [Ian]
..we'd like to share the burden of running the polyfill site with other companies
14:32:24 [Ian]
q+
14:32:30 [Ian]
ack AdrianHB
14:32:30 [Zakim]
AdrianHB, you wanted to ask about hosting and origin security
14:32:30 [AdrianHB]
ack me
14:32:51 [Ian]
Manu: There are parts of the polyfill hosted on the merchant site, and parts hosted on the payment handler side.
14:33:04 [Ian]
..the only part we can't do that with is the mediator code, which is small but centralized
14:33:16 [Ian]
AdrianHB: The mediator code is client-side JS, right?
14:33:35 [Ian]
...it seems like you could resist tampering with hash-based protections
14:33:43 [Ian]
..sub resource integrity
14:33:44 [Ian]
ack de
14:33:44 [Zakim]
dezell, you wanted to ask about E2E
14:34:00 [Ian]
dezell: What is in your mind regarding end-to-end encryption?
14:34:12 [Ian]
...do you think some of the tokenization discussions in the WG would help?
14:34:26 [Ian]
Manu: There are two levels of the concern. One is doing the bare minimum in protecting the card data....
14:34:32 [Ian]
...tokenization would help
14:34:45 [Ian]
..what we'd really like to see is complete end-to-end encryption
14:35:03 [Ian]
(See the nascent encrypted card spec => https://github.com/w3c/webpayments-methods-tokenization/wiki/encrypted_card )
14:35:26 [Ian]
Manu: this is probably a new payment method
14:35:36 [Ian]
ack me
14:35:45 [manu]
Ian: Just wanted to get a clarification...
14:36:15 [Ian]
Manu: Data passes through a third party, which is the mediator web site
14:36:32 [Ian]
IJ: Is that a source of concern?
14:36:43 [Ian]
Manu: It acts in the same role as the browser
14:36:54 [Ian]
....the benefit for the payment mediator is that all the code can be verified
14:37:11 [Ian]
...so it's a bit more open that proprietary browser code
14:37:16 [Ian]
...but I do expect this to be a topic of debate
14:37:45 [Ian]
..orgs that aren't comfortable with this don't have to use the polyfill.
14:38:10 [manu]
Ian: Similarly, concerns raised as things going in the clear is the same as web forms are submitted today.
14:38:25 [Ian]
AdrianHB: Thanks Manu!
14:38:49 [Ian]
topic: TPAC 2017
14:39:05 [Ian]
Please register
14:39:06 [Ian]
https://www.w3.org/2002/09/wbs/35125/TPAC2017/
14:39:51 [Ian]
https://www.w3.org/2017/11/TPAC/
14:39:53 [manu]
Ian: We are going up against DreamForce ... please reserve... room blocks are precious.
14:39:55 [Ian]
6 October break point
14:40:07 [manu]
Ian: After that date, registration fee goes up, it gets harder and harder to attend.
14:40:20 [Ian]
https://github.com/w3c/webpayments/wiki/FTF-Nov2017
14:40:56 [manu]
Ian: Rechartering the WG is something we'll discuss at TPAC.
14:40:57 [Ian]
topic: Draft Charter
14:40:57 [Ian]
https://w3c.github.io/webpayments/proposals/charter-2017
14:41:45 [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.
14:42:23 [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.
14:42:52 [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.
14:43:11 [Ian]
Manu: When is the charter going to be finalized?
14:43:43 [manu]
Ian: The Agenda will be finalized a week before the meeting...
14:44:25 [Ian]
IJ: I would like to start review in Dec and extend group; expect rechartered by Feb
14:44:26 [Ian]
q?
14:44:29 [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.
14:45:00 [Ian]
topic: Marcos' todo list before TPAC for PR API
14:45:00 [Ian]
https://github.com/w3c/payment-request/issues?q=is%3Aissue+is%3Aopen+label%3ACR-Exit
14:45:03 [marconi]
marconi has joined #wpwg
14:45:04 [nicktr]
Would encourage everyone to review the the proposed revised charter
14:45:48 [Ian]
AdrianHB: We asked for comments on these before end of TPAC
14:45:58 [Ian]
IJ: Let's start walking through in calls up to TPAC
14:46:24 [Ian]
Roy: Not up to speed
14:46:43 [Ian]
ACTION: AdrianHB and chairs to check with Editors on how to manage this list
14:46:46 [trackbot]
Created ACTION-67 - And chairs to check with editors on how to manage this list [on Adrian Hope-Bailie - due 2017-09-28].
14:47: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.
14:47:37 [manu]
Ian: I don't believe it means people can't comment after that date.
14:47:48 [manu]
q+ to note that we don't want to cut comments off...
14:48:07 [manu]
Ian: We set that date w/ TPAC in mind... to prompt comments.
14:48:25 [Ian]
Manu: Let's not use that date to say "we cannot further accept comments"
14:49:18 [manu]
Ian: That's not the date that says we're going to leave CR... it's just a minimal date.
14:49:41 [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.
14:50:09 [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.
14:50:51 [Ian]
AdrianHB: I think that interpreting it as a "minimum" time is the right way to do it
14:51:01 [Ian]
AdrianHB: I've done a blog post on the feature at risk
14:51:15 [Ian]
https://medium.com/@ahopebailie/currencysystem-is-at-risk-d29aebafdd38
14:51:47 [Ian]
Topic: Payment Apps Task Force next steps
14:51:53 [Ian]
AdrianHB: the task force has disbanded
14:51:59 [Ian]
...henceforth those topics will move to this agenda
14:52:07 [Ian]
Topic: next meeting
14:52:24 [Ian]
AdrianHB: I suggest we meet next week and focus on TPAC agenda and charter
14:52:39 [Ian]
IJ: Let's also consider https://github.com/w3c/payment-request/issues?q=is%3Aissue+is%3Aopen+label%3ACR-Exit
14:52:52 [Ian]
Next meeting: 28 September
14:52:55 [AdrianHB]
https://medium.com/@ahopebailie/currencysystem-is-at-risk-d29aebafdd38
14:53:02 [Ian]
[No regrets signaled]
14:53:05 [Ian]
RRSAGENT, make minutes
14:53:05 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/09/21-wpwg-minutes.html Ian
14:53:09 [Ian]
RRSAGENT, set logs publicd
14:53:11 [Ian]
RRSAGENT, set logs public
14:53:27 [Ian]
AdrianHB: Thanks Manu and Dave
14:53:33 [Ian]
RRSAGENT, make minutes
14:53:33 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/09/21-wpwg-minutes.html Ian
14:53:36 [nicktr]
Thanks everyone, esp manu and dlongley
16:02:00 [AdrianHB]
AdrianHB has joined #wpwg
16:48:15 [Zakim]
Zakim has left #wpwg