07:58:39 <RRSAgent> RRSAgent has joined #wpwg
07:58:39 <RRSAgent> logging to http://www.w3.org/2016/09/20-wpwg-irc
07:58:41 <trackbot> RRSAgent, make logs public
07:58:41 <Zakim> Zakim has joined #wpwg
07:58:43 <trackbot> Zakim, this will be
07:58:43 <Zakim> I don't understand 'this will be', trackbot
07:58:44 <trackbot> Meeting: Web Payments Working Group Teleconference
07:58:44 <trackbot> Date: 20 September 2016
07:58:55 <Ian> rrsagent, this meeting spans midnight
08:00:29 <Ian> Chair: NickTR
08:00:57 <mountie> mountie has joined #wpwg
08:03:43 <adamR> adamR has joined #wpwg
08:05:12 <MaheshK> MaheshK has joined #wpwg
08:05:29 <lilin> lilin has joined #wpwg
08:07:48 <nicktr> Day 2 proposed agenda -> https://github.com/w3c/webpayments/wiki/FTF-Sep2016
08:08:43 <Jaewan> Jaewan has joined #wpwg
08:08:50 <MattS> MattS has joined #wpwg
08:10:08 <bensmith> bensmith has joined #wpwg
08:10:19 <manu> rrsagent, this meeting spans midnight
08:10:28 <Ian> zakim, who's here?
08:10:28 <Zakim> Present: (no one)
08:10:30 <Zakim> On IRC I see bensmith, MattS, Jaewan, lilin, MaheshK, adamR, mountie, Zakim, RRSAgent, sam_, lbolstad_, zkoch, chunming, pascal_bazin, jungkees, shepazu, weinig, rouslan, pirouz,
08:10:30 <Zakim> ... hyojin, Mike5, JakeA, collier-matthew, mkwst, adrianba, emschwartz, davidillsley_, slightlyoff, Dongwoo, AdrianHB, nicktr, hober, ShaneM, schuki, dlongley, manu, dlehn, Ian,
08:10:30 <Zakim> ... wseltzer, trackbot
08:10:36 <Ian> present+ AdamR
08:10:38 <zkoch> present+ zkoch
08:10:38 <Ian> present+ MattS
08:10:42 <Ian> present+ BenSmith
08:10:44 <Ian> present+ Manu
08:10:44 <nicktr> present+ nicktr
08:10:50 <Dongwoo> present
08:10:51 <Dongwoo> =
08:10:52 <Ian> present+ MaheshK
08:10:54 <Ian> present+ Dongwoo
08:10:55 <manu> rrsagent, make minutes
08:10:55 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/20-wpwg-minutes.html manu
08:10:56 <Ian> present+ dezell
08:10:58 <Ian> present+ Roy
08:11:00 <Ian> present+ Shane
08:11:02 <Ian> present+ Rouslan
08:11:04 <Dongwoo> present+ Dongwoo
08:11:04 <ShaneM> present+ ShaneM
08:11:08 <Ian> present+ Max
08:11:12 <Ian> present+ JiaJia
08:11:14 <Ian> present+ Mountie
08:11:18 <Ian> present+ evgeny
08:11:22 <Ian> scribe: Ian
08:11:24 <Ian> present+ Ian
08:11:30 <Max> Max has joined #wpwg
08:11:32 <Ian> present+ AdrianHB
08:11:36 <Ian> present+ NickTR
08:11:42 <Ian> present+ LarsErik
08:11:44 <Ian> present+ William
08:11:52 <Ian> Topic: WG teleconf
08:12:14 <manu> AdrianHB: Are folks okay with the call times
08:12:23 <Ian> AdrianHB: Any challenges to current call? Weekly too often?
08:13:06 <Ian> present+ Laurent
08:13:08 <Ian> present+ MattP
08:13:09 <angel> angel has joined #wpwg
08:13:14 <olivexu> olivexu has joined #wpwg
08:13:25 <Ian> AdrianHB: Would like to make it easier for people to provide input to the agenda
08:13:45 <Ian> topic:  Web Payments HTTP API Next Steps
08:13:53 <manu> https://docs.google.com/presentation/d/1MobW3X6vH0MP9SpTE37tDlOnM5hgx3-DgQT1xDWs40U/edit#slide=id.p
08:13:54 <Ian>  Web Payments HTTP API Next Steps
08:14:22 <dezell> dezell has joined #wpwg
08:14:29 <betehess> betehess has joined #wpwg
08:14:40 <Ian> Manu: We recently published the two specs. They are designed to mirror payment request API
08:14:55 <nick> nick has joined #wpwg
08:15:01 <Ian> ...the HTTP API is about how you execute the current browser flow using purely HTTP
08:15:11 <Ian> ...Digital Bazaar and Worldpay have done basic implementations
08:15:33 <Laurent_> Laurent_ has joined #wpwg
08:15:35 <Ian> ...the orgs didn't chat about their implementations but we are off to a good start
08:15:54 <Ian> ...three categories of questions arose around the specs:
08:15:59 <Ian> 1) Do they reflect existing practice?
08:16:04 <Ian> 2) What are the use cases?
08:16:11 <Ian> 3) Who do we get relevant parties involved?
08:16:20 <MattPi> MattPi has joined #wpwg
08:16:35 <Ian> present+ NickS
08:17:17 <Ian> ...the HTTP API works like this:
08:17:24 <Ian>  * You try to get something and are told you have to pay
08:17:33 <Ian>  * You are told where to send a payment request, which is shipped via HTTP
08:17:46 <Ian>  * You get a payment response and you get access to a resource
08:18:12 <AdrianHB> present+ AdrianHB
08:18:21 <Ian> ...on the question of whether the API reflects current practice - the flow we are trying to enable is the SAME flow that we are talking about in the browser API, just out of a browser.
08:18:28 <AdrianHB> q+ to suggest we discuss use cases first
08:18:34 <nicktr> q+
08:18:55 <Ian> ..the question arose - isn't this about communication between the payee and the payment service provider? That's not what the API is about, but we could do that if the group thinks that's a priority
08:18:56 <Ian> q?
08:19:05 <Ian> adrianhb: Let's talk about use cases first
08:19:14 <nicktr> ack AdrianHB
08:19:14 <Zakim> AdrianHB, you wanted to suggest we discuss use cases first
08:19:19 <nicktr> q-
08:19:20 <Ian> ..if the use cases are things that don't exist, then the other questions would be moot
08:19:23 <Ian> ...so let's start with the use cases
08:19:36 <Evgeny> Evgeny has joined #wpwg
08:19:49 <Ian> Manu: I think there was a misconception that the HTTP API is for internet of things use cases
08:20:05 <Ian> ...while in theory that could work, that's not our focus.
08:20:12 <Ian> ...the primary focus is automatic payments.
08:20:26 <Ian> ...e.g., your bank software makes monthly payments
08:20:39 <Ian> ...or you want to use an app (not in the browser) to make a payment
08:20:57 <Ian> ...software running in kiosks...so it's non-interactive but it's not IOT
08:21:21 <Ian> ...think of paying a utility bill...today you give your payment instrument information to the utility company....if your card changes you have to set it up again
08:21:27 <zkoch> q+
08:21:41 <Ian> ...the other thing with utility payments is that they occur regularly, but you don't know what you have to pay until the end of the month
08:21:45 <AdrianHB> q+ to note some similarities with PSD2
08:22:35 <Ian> ...what you could do is having wallet or banking software where you set up a payment endpoint with your electricity provider, and your banking software will ping the provider to get a total. That results in a payment request. The utility company says "you owe this much this month". Your wallet software responds to the payment request (using some payment method) and the utility processes the payment.
08:23:02 <Ian> ...there are various benefits (e.g., your wallet can pay with your updated card)
08:23:07 <Ian> ack zk
08:23:21 <Ian> zkoch: Is the idea that once it's set up it's automated?
08:23:23 <Ian> Manu: Yes.
08:24:00 <Ian> zkoch: It's hard for me to imagine automatically switching underlying form of payment without user consent. I'm having a hard time understanding the line between HTTP/Browser because of the user connect that's likely
08:24:05 <Ian> s/connect/consent
08:24:10 <rouslan> rouslan has joined #wpwg
08:24:28 <Ian> Manu: The scenario goes like this: there is prior consent to use different payment methods.
08:24:35 <nicktr> q?
08:25:05 <Ian> zkoch: So is a key use case that you are delegating to the wallet authority to make decisions on how to pay.
08:25:12 <Ian> Manu: That is a use case, not the primary use case.
08:25:16 <pascal_bazin> pascal_bazin has joined #wpwg
08:25:22 <nicktr> q?
08:25:23 <pascal_bazin> q+
08:25:27 <Ian> ...the primary use case is "some piece of software other than the browser" that you have configured to make payments on your behalf.
08:25:39 <Ian> Manu: Another use case is a large corporation that wants to pay vendors automatically
08:26:04 <Ian> ...e.g., a gov agency could ping different suppliers each month where automatically they ping the vendor for the amount owed,
08:26:21 <Ian> ...and the system determines whether the value is within an acceptable range, and if so payment happens automatically
08:26:30 <dezell> q+
08:26:32 <nicktr> ack AdrianHB
08:26:32 <Zakim> AdrianHB, you wanted to note some similarities with PSD2
08:26:33 <Ian> ...so the primary focus is "smart payment agents making payments on your behalf"
08:26:51 <Ian> AdrianHB: Understanding the actors has made it clearer to me parallels to the PSD2 architecture
08:27:11 <Ian> ...you are describing an actor that is authorized to initiate payments...PISP in PSD2
08:27:14 <nicktr> q?
08:27:44 <Ian> manu: Yes, the PISP could be using HTTP API
08:27:49 <nicktr> ack pascal_bazin
08:27:49 <Ian> ack pas
08:27:50 <pascal_bazin_> pascal_bazin_ has joined #wpwg
08:28:15 <Ian> pascal_bazin: Could the HTTP API be used to introduce third party payment methods not managed by the browser?
08:28:37 <Ian> Manu: The goal is to use any payment method that the browser supports....
08:28:48 <Ian> pascal_bazin: Could you use the HTTP API implement a new payment method?
08:28:55 <Ian> Manu: Maybe; that's a general answer
08:29:05 <nicktr> ack dezell
08:29:07 <Ian> ack dezell
08:29:36 <Ian> dezell: NACS is interested in not forcing merchants to use apps.
08:29:50 <Ian> ...I like the HTTP API and the separation of concerns it represents.
08:30:12 <Ian> ...it enables us to decompose problems
08:30:23 <jyrossi> jyrossi has joined #wpwg
08:30:35 <Ian> ...in my day job at Verifone we push some L2 processing into an outside web server
08:30:39 <Ian> present+ Jean-Yves
08:31:18 <Ian> ...that's the sort of thing that the HTTP API would enable us to do
08:31:31 <Ian> present+ AlexandreB
08:32:04 <Laurent_> Laurent_ has joined #wpwg
08:32:06 <nicktr> q?
08:32:13 <Ian> dezell: I also think that conexxus could make use of this
08:32:14 <Nicolas_A_> Nicolas_A_ has joined #wpwg
08:32:48 <Ian> manu: Some addition use cases (but not an area of focus): in-vehicle, electronic receipts
08:33:08 <MattS> MattS has joined #wpwg
08:33:13 <MattPi> MattPi has joined #wpwg
08:33:21 <Ian> Manu: On the question of "do we have the right people in the group to work on this?"
08:34:04 <Ian> ...we have a healthy list of payment app providers (10), merchants or merchant reps (6)
08:34:12 <betehess> betehess has joined #wpwg
08:34:43 <Ian> ...if we wanted to do the new connection between payment app / PSP we only have about 3 PSPs in the group and we'd need to do more outreach
08:35:40 <Ian> q+
08:36:11 <Ian> Manu: So the question if we have limited resources, should we focus on "enabling the same browser flow in other software" or "PSP communication"?
08:36:15 <nicktr> ack
08:36:19 <nicktr> ack Ian
08:36:27 <AdrianHB> ian: thinking about who is in the group
08:36:48 <AdrianHB> ... if I understand the use cases it's focusing on automated payments
08:37:22 <AdrianHB> ... the value of interop for the browser api is small number of implementations and wide user base
08:37:45 <AdrianHB> ... what is the interop gain for http api and therefor who do we need involved in the work?
08:37:51 <nicktr> q?
08:38:01 <lilin> lilin has joined #wpwg
08:38:43 <Laurent__> Laurent__ has joined #wpwg
08:38:56 <Mike5> RRSAgent, make minutes
08:38:56 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/20-wpwg-minutes.html Mike5
08:39:03 <Ian> Manu: Interop is that app providers have common format.
08:39:59 <AdrianHB> ian: whow are the companies that would be payment app providers?
08:40:01 <Ian> IJ: I have not figured out the economic / interop incentives yet.
08:40:15 <Ian> manu: Anyone who is doing a wallet app wants to do automatic payments...
08:40:39 <Ian> ...so the incentive for wallet providers is that users stay in their wallet for all payments
08:40:58 <Ian> q?
08:41:47 <Ian> Manu: There is no way today for a wallet provider to hit a service and get a payment request in a universal format
08:42:13 <ShaneM> q?
08:42:55 <Ian> Shane: Manu mentioned not being able to hit an endpoint. One thing you can't do today as an automated service provider...
08:43:07 <Ian> ...there are proprietary ways to do things...but there's no standard way to do thing
08:43:14 <Ian> ..I can pay mortgage monthly today
08:43:41 <nicktr> q?
08:43:42 <Ian> ...if my wallet had a way to talk to the electric company, get the amount, and pay them, it would improve user experience and improve interop for all wallet providers
08:44:33 <sangchul> sangchul has joined #wpwg
08:44:55 <Ian> IJ: Who are the service providers who want to come together to do this?
08:45:04 <Ian> ...I apologize I am not understanding the incentives yet
08:45:31 <Ian> Manu: We want to work on a primer and clarify the benefits, then reach out to parties to determine whether this is a compelling use case for them
08:45:37 <AjaySR> AjaySR has joined #WPWG
08:45:44 <Ian> IJ: +1 to talking to key parties to determine what the interop needs are
08:46:17 <Ian> Manu: Are org is very interest in this level of interop...we don't hear enough orgs in the WG today so we want to go out there and talk with them. If we go out and find out that this is not something that is broadly desired, we'll need to change direction.
08:46:38 <Ian> ...so we need more data to find out whether this is a compelling thing for merchants and payment service providers
08:46:47 <Ian> q+
08:46:49 <MattS_> MattS_ has joined #wpwg
08:46:54 <Roy> Roy has joined #wpwg
08:46:54 <Ian> q-
08:47:20 <Ian> AdrianHB: My feeling is that it's too early to say what direction to pursue. I think people are still thinking about the use cases.
08:47:36 <Nicolas_A__> Nicolas_A__ has joined #wpwg
08:47:46 <Ian> ...I can understand the question Ian is asking...it's not about technical benefits of interop...what are the incentives for the players in the ecosystem to implement the standard?
08:47:51 <Laurent_> Laurent_ has joined #wpwg
08:48:25 <Ian> Ben: I think you need to show what this displaces in the current processing chain. More work on that would be useful
08:48:27 <nicktr> q+
08:48:52 <Ian> AdrianHB: I think we need to figure out the commercial incentives...
08:50:43 <nicktr> ack nicktr
08:51:19 <nicktr> q?
08:52:12 <Nicolas_A_> Nicolas_A_ has joined #wpwg
08:52:13 <adamR> adamR has joined #wpwg
08:52:24 <adamR> …And we seem to be back.
08:52:33 <AdrianHB> ian: I like the idea of doing outreach
08:52:46 <mountie> mountie has joined #wpwg
08:52:47 <AdrianHB> ... support that as a next step
08:53:11 <dezell> q+
08:53:14 <ShaneM> Intuit (Quicken), LastPass, Fitpay
08:53:40 <ShaneM> micropayments / paywall access
08:54:54 <Laurent__> Laurent__ has joined #wpwg
08:55:11 <nicktr> q?
08:56:34 <nicktr> q?
08:56:41 <nicktr> ack dezell
08:57:26 <AdrianHB> q?
08:57:33 <AdrianHB> zakim, close the queue
08:57:33 <Zakim> ok, AdrianHB, the speaker queue is closed
08:57:38 <hwlee> hwlee has joined #wpwg
08:58:06 <AdrianHB> zakim, open the queue
08:58:06 <Zakim> ok, AdrianHB, the speaker queue is open
08:58:39 <betehess> betehess has joined #wpwg
09:00:17 <nicktr> q?
09:00:53 <Ian> IJ: +1 to getting feedback from potential implementers on value of the spec and interop.
09:00:55 <Ian> Ben: I think that users would like the additional automation, what I don't
09:00:56 <adamR_> adamR_ has joined #wpwg
09:00:57 <Ian> understand is the relationship to current processing and stakeholder roles.
09:00:59 <Ian> AdrianHB: So Manu, you are driving the work and can continue. I would plan
09:01:01 <Ian> to get more involved once we've addressed other priorities in the WG.
09:01:03 <Ian> ...also the Interledger CG is setting up a micropayments breakout tomorrow.
09:01:05 <Ian> Evgeny: From a PSP perspective. I had not understood previously that
09:01:07 <Ian> HTTP API is for automated payments; I agree that is useful. It would
09:01:09 <Ian> be useful to simplify the API as a starting point. E.g., 2 calls to make
09:01:11 <Ian> a payment.
09:01:13 <Ian> DavidE: On your point of people who would like this: zipline and @@
09:01:15 <Ian> are two companies that come to mind. They are the kinds of NACS members
09:01:19 <Ian> who want to innovate in the wallet space.
09:01:21 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/20-wpwg-minutes.html Ian
09:01:45 <Ian> topic: Push payments
09:01:47 <Ian> Roy: See my write-up of the problem statement. Failures in card
09:01:51 <Ian> payment scenario are not that harmful. But for Alipay, SEPA pay, etc.
09:01:53 <Ian> where funds are changing hands before you get the response, there
09:01:55 <Ian> are many failure points in the flow where failure is more harmfil
09:02:13 <Ian> ...one previous idea to address this would be (1) mediator generated identifier (e.g., UUID) in combination with (2) discovery service
09:04:43 <MattS> MattS has joined #wpwg
09:04:48 <mountie> mountie has joined #wpwg
09:06:43 <nicktr> q?
09:07:19 <lbolstad> lbolstad has joined #wpwg
09:07:23 <lbolstad> present+ lbolstad
09:09:31 <zkoch> zkoch has joined #wpwg
09:10:12 <Jaewan> Jaewan has joined #wpwg
09:12:35 <nicktr> q?
09:12:38 <chunming> chunming has joined #wpwg
09:13:51 <mountie> mountie has joined #wpwg
09:15:57 <Evgeny> Evgeny has joined #wpwg
09:18:13 <lbolstad_> lbolstad_ has joined #wpwg
09:19:36 <nicktr> q?
09:28:13 <mountie> mountie has joined #wpwg
09:28:31 <weinig> weinig has joined #wpwg
09:28:54 <Laurent_> Laurent_ has joined #wpwg
09:32:33 <zkoch> zkoch has joined #wpwg
09:33:31 <mountie> mountie has joined #wpwg
09:33:41 <MattPi> MattPi has joined #wpwg
09:34:10 <zkoch> zkoch has joined #wpwg
09:34:19 <sam> sam has joined #wpwg
09:34:28 <shepazu> shepazu has joined #wpwg
09:34:35 <mountie> mountie has joined #wpwg
09:34:55 <chunming> chunming has joined #wpwg
09:36:07 <adamR_> adamR_ has joined #wpwg
09:36:08 <weinig> weinig has joined #wpwg
09:36:21 <MattS> MattS has joined #wpwg
09:57:54 <nick> nick has joined #wpwg
10:00:27 <betehess> betehess has joined #wpwg
10:05:23 <Jaewan> Jaewan has joined #wpwg
10:05:33 <nicktr> q?
10:14:40 <adamR> adamR has joined #wpwg
10:14:50 <nick> nick has joined #wpwg
10:16:48 <rouslan> rouslan has joined #wpwg
10:19:11 <MaheshK> MaheshK has joined #wpwg
10:19:59 <olivexu> olivexu has joined #wpwg
10:21:28 <Ian> <IAN WILL ADD OFFLINE MINUTES HERE>
10:21:36 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/20-wpwg-minutes.html Ian
10:21:48 <Ian> topic: Payment Method Identifiers
10:22:03 <olivexu> olivexu has joined #wpwg
10:22:10 <adamR_> adamR_ has joined #wpwg
10:22:13 <Ian> AdrianHB: I think we have agreement that PMIs are URLs that refer to web payment manifests
10:22:27 <Ian> ...data about how an origin plays in the ecosystem
10:23:11 <Ian> zkoch: I want to be able to finish the PMI spec.
10:23:18 <Roy> Roy has joined #wpwg
10:23:30 <Ian> zkoch: There are a few high level use cases we want to support
10:23:48 <Ian> 1) For a given payment method ,we want to make security assertions about apps
10:23:52 <lilin> lilin has joined #wpwg
10:24:44 <Max> Max has joined #wpwg
10:24:58 <Ian> 2) Browser wants reliable information about where to get an app
10:25:28 <Ian> zkoch: I want to get agreement that there will be a manifest file, and secondarily (later) we can discuss what goes in it.
10:26:03 <Ian> PROPOSED: An identifier is an absolute URL composed of the schema, origin, path. No query string params and no fragments.
10:26:27 <Ian> ...these URLs could be used by users to get web pages
10:26:49 <Ian> PROPOSED #2: At that URL you can append payment-manifest.json which has data describing that payment method.
10:27:06 <Ian> zkoch: There is precedence for this in Android
10:27:34 <Laurent_> Laurent_ has joined #wpwg
10:27:45 <ShaneM> q+ to propose something alternate to that
10:27:46 <nicktr> q?
10:28:22 <jeff> jeff has joined #wpwg
10:28:22 <nicktr> q+
10:28:32 <Ian> ack Shane
10:28:32 <Zakim> ShaneM, you wanted to propose something alternate to that
10:28:44 <lbolstad> lbolstad has joined #wpwg
10:28:51 <lbolstad> present+ lbolstad
10:28:52 <Ian> ShaneM: I don't object to the hard-coded path, but there are other ways to do this like HTTP headers
10:29:06 <Ian> ...that gives us the ability to more easily extend in the future.
10:29:17 <Ian> ..that does imply two round trips.
10:29:19 <rouslan> rouslan has joined #wpwg
10:29:21 <Ian> AdamR: That's not the case for HTTP 2
10:29:43 <Ian> AdrianHB: So if I visit the site of the PMI I get back an HTTP header?
10:29:55 <Ian> Shane: Probably multiple headers (e.g., here's information about the payment app, etc.)
10:30:03 <nicktr> ack ShaneM
10:30:09 <rouslan> q+ to ask what other technologies use link header in similar wat
10:30:21 <Ian> AdamR: I get a little heartburn from a hard-coded path
10:30:24 <jyrossi> jyrossi has joined #wpwg
10:30:48 <Ian> zkoch: There are a couple of reasons I like the hard-coded URL but I am open to other approaches.
10:31:04 <Ian> ...one advantage is it's very easy for merchants to implement....it's harder for merchants to manage headers
10:31:35 <AdrianHB> q+ to emphasize when this happens
10:31:51 <Ian> ...this proposal also lets me do things in a single request
10:32:21 <Ian> ..it's costly to download a page and parse it to get more information. This is particularly costly on low-end devices
10:32:34 <pascal_bazin> pascal_bazin has joined #wpwg
10:32:38 <Ian> AdamR: If it were a common operation that would be compelling, but IMO this will happen rarely for a given payment method
10:32:48 <ShaneM> ack AdrianHB
10:32:48 <Zakim> AdrianHB, you wanted to emphasize when this happens
10:32:53 <Ian> AdrianHB: This will happen every time a browser encounters a payment method they haven't seen before
10:32:59 <Ian> zkoch: Or if they want to refresh.
10:33:13 <Ian> AdrianHB: This may be happening int he background and therefore needs to happen quickly.
10:33:17 <Ian> q?
10:33:20 <Ian> ack nickt
10:33:52 <Ian> nicktr; I have two practical points. I am really worried about this....what do we think the likelihood that orgs will put a manifest at a URL?
10:34:14 <Nicolas_A_> Nicolas_A_ has joined #wpwg
10:34:26 <Ian> zkoch: We are going to use short strings for the open payment methods; this proposal about URLs is for proprietary systems
10:35:06 <Ian> nicktr: My second practical question is  - are you introducing a single point of failure for those payment methods?
10:35:13 <Ian> ...suppose a bad actor takes over the site.
10:36:06 <Ian> AdamR: You already have that problem with bobpay.com....
10:36:06 <betehess> note that it could at least be /.well-known/payment-manifest.json   (that's https://tools.ietf.org/html/rfc5785 )
10:36:47 <adamR> betehess: That only works if you require that each origin has at most one payment method. I don’t think that’s a reasonable restriction.
10:36:58 <Ian> zkoch: I am open to discussing headers; need to understand more how they work
10:37:05 <betehess> adamR: I see
10:38:24 <nicktr> q?
10:38:45 <Ian> IJ: Have you talked with Anne/Tab about URL matching?
10:39:06 <Ian> zkoch: I think there's some discomfort but this proposal is preferable - string match on well-defined components
10:39:18 <Ian> ...we'll loop back with Tab and Anne on this
10:39:42 <Ian> AdamR: I believe that the constraints that zkoch is talking about addresses the points that have been raised
10:39:53 <Ian> w?
10:39:54 <Ian> q?
10:40:07 <Ian> ben: I would like to check with our security team how they would feel about this.
10:40:16 <ShaneM> q+ to point out that this means the URI is BOTH an identifier and a resource
10:40:19 <Ian> ...from a regulatory perspective, I am pretty sure that the payment method needs to be identified
10:40:24 <nicktr> q?
10:40:43 <Ian> zkoch: The URL has to be HTTPS
10:40:56 <Ian> ..origins will control the shape of the URL
10:40:58 <Ian> q?
10:41:00 <Ian> ack rous
10:41:00 <Zakim> rouslan, you wanted to ask what other technologies use link header in similar wat
10:41:12 <Ian> rouslan: I'm happy we seemed to be agreeing on constrained URLs
10:41:36 <Ian> ...on the second proposal Shane mentioned headers
10:41:52 <Ian> ...I'd like to hear some examples of technologies that are using header links.
10:42:10 <adamR> LInk headers: https://www.w3.org/wiki/LinkHeader
10:42:12 <Ian> Shane: Web annotation protocol spec specifies that link headers with certain values allow you to discover resources of various types within that ecosystem
10:42:35 <betehess> lots of uses of Link in https://www.w3.org/TR/ldp/
10:42:52 <adamR> HTTP/2.0 server push: https://tools.ietf.org/html/rfc7540#section-8.2
10:42:52 <Evgeny> Evgeny has joined #wpwg
10:44:10 <betehess> Twitter API uses it too https://developer.github.com/v3/#link-header
10:44:43 <Ian> AdamR: HTTP 2.0 server push...if set up correctly, will let you get a single response rather than two trips
10:45:00 <ShaneM> ack shepazu
10:45:03 <Ian> AdrianHB: So I am hearing "one less request" is not a key benefit using HTTP 2
10:45:05 <nicktr> ack ShaneM
10:45:05 <Zakim> ShaneM, you wanted to point out that this means the URI is BOTH an identifier and a resource
10:45:05 <Ian> ack Sh
10:45:12 <nicktr> q?
10:45:33 <Ian> q+
10:46:42 <Ian> RESOLVED: PMIs are constrained URLs as describe here.
10:47:06 <MattS> MattS has joined #wpwg
10:47:35 <Ian> zkoch: For open systems we decided short strings. I suggest that we limit those to [a-z0-9_]+
10:47:49 <adamR> [a-z0-9-]
10:48:23 <Ian> SO RESOLVED (AdamR's rexexp)
10:48:31 <AjaySR> AjaySR has joined #WPWG
10:49:06 <Ian> AdamR: I suggest you talk to TAG about use of headers v. pre-defined URLs
10:49:08 <nicktr> q?
10:49:21 <Ian> zkoch: I am ok to talk to TAG...but there is a question about ease of implementation by merchants
10:49:23 <Ian> ack me
10:50:05 <Ian> [We will take Proposed #2 to lunch and possibly the TAG]
10:50:10 <nicktr> q+
10:50:41 <Ian> AdrianHB: Are we agreeing that the PMI -- through some mechanism to be defined -- will enable someone to find a manifest
10:51:01 <rouslan> +1
10:51:07 <Ian> +1
10:51:12 <AdrianHB> +!
10:51:16 <AdrianHB> +1
10:52:11 <wseltzer> q+
10:52:20 <adamR> +1
10:52:26 <Ian> AdrianHB: Primary use of the manifest doc is security (which apps are authorized to fulfill the payment method)
10:52:37 <MaheshK> q+ on open method without manifest
10:52:45 <wseltzer> q+ re findable vs must be found (and when)
10:53:21 <Ian> ack nick
10:54:45 <Ian> zkoch: I think we should aggressively limit the number of short strings that circulate
10:55:06 <Ian> q?
10:55:10 <Ian> ack wseltzer
10:55:10 <Zakim> wseltzer, you wanted to discuss findable vs must be found (and when)
10:55:58 <Ian> wseltzer: One piece of commentary from a staff conversation is that just because you have a URL doesn't mean you have to look it up all the time...they can be used where an automatic process dereferences them.
10:56:07 <Ian> ..but they don't have to do the lookup most of the time
10:56:28 <Laurent_> q+
10:56:41 <Ian> AdrianHB: Our expectation is browsers will cache info they get
10:56:50 <nicktr> nicktr: Notwithstanding the desire to bootstrap the ecosystem,  I am worried about W3C claiming a mandate to control and define payment methods that we do not have - the minting of short-strings troubles me
10:56:56 <Ian> (Interesting question - relationship between PMI and caching if done through headers...)
10:57:24 <Ian> MaheshK: Suppose I only trust certain apps as a merchant
10:58:35 <nicktr> ack MaheshK
10:58:35 <Zakim> MaheshK, you wanted to comment on open method without manifest
10:58:59 <wseltzer> s/can be used where an automatic process dereferences them/can be useful because their references are findable by automated processes/
11:00:31 <rouslan> q+ to comment that URLs are not only for security, but also to define your own payment methods.
11:01:13 <Ian> q?
11:01:33 <Ian> [Discussion about URLs and short strings some more]
11:01:43 <Ian> ack L
11:02:05 <MattS_> MattS_ has joined #wpwg
11:02:12 <Ian> Laurent_: Is it bad to use a URL?
11:02:22 <Ian> IJ: We heard objection to server risk.
11:04:29 <Ian> IJ: It's not clear to me that we need a manifest for open payment methods
11:05:00 <Ian> Laurent: An empty manifest file might be useful to tell browser something about the payment method (that it's open)
11:05:13 <Ian> AdrianHB: We still need to define what goes in the manifest
11:05:22 <Ian> q?
11:05:26 <Ian> ack rouslan
11:05:26 <Zakim> rouslan, you wanted to comment that URLs are not only for security, but also to define your own payment methods.
11:05:37 <nick> nick has joined #wpwg
11:05:55 <Ian> rouslan: I heard a comment that the best use of the URL is to ensure the security of the payment method and interaction via payment apps. I think an even better use case is to define your own payment method.
11:06:19 <Ian> ...I would like to respond to Lauren's comments
11:06:35 <MaheshK_> MaheshK_ has joined #wpwg
11:06:36 <Ian> ...I think it's cool from an engineering perspective to have a URL like w3.org/visa .. the problem is of course the server risk.
11:06:57 <Ian> ..we could hard code information into browsers so that there is no dereferencing.
11:07:30 <Ian> IJ: Hard-coding in the browser is equivalent to them implementing a short string but it's harder on developers
11:07:32 <Ian> q?
11:07:32 <nicktr> q?
11:08:50 <Ian> IJ: We've had problems with software downloading DTDs too often
11:08:53 <Ian> Nick: Worldpay, too
11:09:16 <Ian> [Recap]
11:09:21 <Ian>  - PMIs are constrained absolute URLs
11:09:25 <MattS> MattS has joined #wpwg
11:09:29 <Ian>  - They can be used to get manifests (through mechanism TBD)
11:09:53 <Ian> IJ: Do you have preliminary ideas on what goes in the manifest?
11:10:06 <Ian> zkoch: I have a straw man...
11:10:16 <nicktr> Zach's strawman is here: -> https://github.com/zkoch/zkoch.github.io/blob/master/pmi.md
11:10:36 <Ian> Topic: What goes in payment manifest
11:10:39 <Ian> AdamR:
11:10:41 <MaheshK> MaheshK has joined #wpwg
11:10:46 <Ian>  - Restricting origins
11:10:50 <Ian>  - Where to get apps
11:11:13 <Ian> zkoch: I think the two broad categories are:
11:11:20 <Ian>  - platform dependent things (e.g., what you need on Android)
11:11:28 <Ian> ...including something like "where to get in the app store)
11:11:35 <bensmith> bensmith has joined #wpwg
11:11:38 <Ian>  - web assertion model (I delegate to other origins)
11:11:58 <Ian> AdrianHB: Are we happy to restrict by origin? Or specific apps?
11:12:00 <rouslan> q+ to talk abut restricting by origin
11:12:34 <nicktr> manifest strawman from Zach is here -> https://github.com/zkoch/zkoch.github.io/blob/master/payment-manifest.md
11:13:08 <nicktr> q?
11:13:32 <Ian> AdamR: Are we relying on origins for native apps?
11:14:05 <Ian> AdrianHB: I am suggesting we say things in two parts (1) identify origins (2) identify where to get apps associated with those origins
11:14:13 <kazho> kazho has joined #wpwg
11:15:04 <adrianba> rrsagent, make minutes
11:15:04 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/20-wpwg-minutes.html adrianba
11:16:08 <Ian> IJ: The other piece I've thought about for payment method manifest is "Here is the payment method spec."
11:16:32 <Ian> [Discussion about payment app data]
11:16:54 <Ian> AdrianHB: Some data about apps can be part of the service worker code (rather than external file)
11:17:27 <Ian> ...but there's a use case where the browser can go get data about an app before executing a service worker
11:17:32 <Ian> IJ: E.g., recommended payment apps
11:18:25 <nicktr> q?
11:18:33 <Ian> ack rous
11:18:33 <Zakim> rouslan, you wanted to talk abut restricting by origin
11:18:57 <Ian> rouslan: I agree that those three pieces of information in a  manifest (trust, apps, payment method spec) would be useful
11:19:44 <Ian> ...regarding trust representation..I am ok to drop path part
11:20:02 <adamR> basically, something like this: https://pastebin.mozilla.org/8911575
11:20:20 <Ian> ..in terms of service worker and manifest file relationship...I think you are right that we will need some info about the App BEFORE the service worker is invoked.
11:20:37 <Ian> ...I think that service workers can update the manifest files.
11:20:43 <Ian> ...this allows payment apps to push updates to the browser
11:21:06 <MaheshK> q+ have few questions on manifest
11:21:22 <MaheshK> q+ questions on manifest
11:21:30 <Ian> AdrianHB: As a payment app publisher I want to avoid saying the same thing twice
11:21:51 <nicktr> q?
11:22:14 <nicktr> ack questions
11:22:14 <Zakim> questions, you wanted to comment on manifest
11:22:58 <Ian> AdrianHB: We have more work to do on what data is specific to browser-based payment apps.
11:23:06 <Ian> MaheshK: What about native apps?
11:23:21 <Ian> AdrianHB: That's platform specific...and we have more work to do on the payment app spec to put hooks in place
11:23:49 <Ian> MaheshK: Samsung had different apps (for different regions)
11:24:14 <rouslan> q+ to talk about regions
11:25:08 <Ian> IJ: Interesting....it's one thing to say the apps are allowed and another to say "You can't use this app in this region" I don't know where that's implemented
11:25:27 <rouslan> q-
11:25:45 <Ian> IJ: Actually, use server-side filtering
11:26:15 <nicktr> q?
11:26:19 <Ian> AdamR: What I want is to know all the apps that are allowed. And a second concern is "For your region, here's where to get an app"
11:26:42 <Ian> AdrianHB: Is origin-based constraint sufficient?
11:27:11 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/20-wpwg-minutes.html Ian
11:27:23 <Ian> q?
11:28:50 <zkoch> zkoch has joined #wpwg
11:29:11 <adamR> https://pastebin.mozilla.org/8911575
11:29:26 <adamR> zkoch: https://www.w3.org/wiki/LinkHeader
11:30:52 <zkoch> here was my original straw man: https://github.com/zkoch/zkoch.github.io/blob/master/payment-manifest.md
11:34:35 <Max> q+
11:35:23 <Ian> zkoch: Web app manifest has a way to go from web app to a native app
11:35:33 <Ian> ...my straw man speaks to this
11:35:54 <rouslan> rouslan has joined #wpwg
11:35:59 <Ian> ..we can probably define a platform that is "web"
11:36:56 <nicktr> ack Max
11:36:56 <Ian> zkoch: I agree we can strip the path (as Rouslan pointed out) when delegating authority to other origins
11:37:08 <Ian> Max: In yesterday's demo we used this mechanism!
11:37:21 <Ian> ...so it works
11:37:50 <zkoch> +1
11:38:12 <Ian> AdrianHB: I am hearing manifest has these sections:
11:38:19 <Ian>  - allowed origins (for app distribution)
11:38:22 <Ian>  - getting apps
11:38:32 <Ian>  - payment method documentation
11:39:59 <Ian> IJ: So do we partner about the payment app data bits (that might be in a manifest or in a payment app manifest)?
11:40:03 <Ian> zkoch: Partner
11:40:46 <Ian> Q1: Should payment app data be both available inline or by ref?
11:40:54 <Ian> Q2: Should the manifest spec define both types of data
11:41:02 <nicktr> q+
11:41:32 <Ian> zkoch: What I will probably propose first is to put everything in the PMI spec...we can then see if payment apps also want it and we can pull it out as needed
11:41:36 <adamR> zkoch: Re icons — https://www.w3.org/TR/html5/links.html#link-type-icon
11:41:47 <Ian> zkoch: Propose everything be in PMI spec to start
11:41:48 <Ian> +1
11:41:57 <Ian> ack nicktr
11:42:29 <K_> K_ has joined #wpwg
11:44:08 <Ian> IJ: +1 to including the payment method and payment app data in the PMI spec to start...and pulling out as needed as payment apps proceeds
11:44:12 <Ian> zkoch: +1
11:44:22 <Ian> adamr: If we take what adam proposed, it's mostly about icons
11:45:51 <rouslan> rouslan has joined #wpwg
11:46:09 <nicktr> q?
11:46:23 <Ian> ACTION: Zach to work with Max to revise the payment manifest proposal
11:46:24 <trackbot> Created ACTION-37 - Work with max to revise the payment manifest proposal [on Zach Koch - due 2016-09-27].
11:47:55 <zkoch> zkoch has joined #wpwg
11:49:46 <nick> nick has joined #wpwg
11:50:56 <adamlake> adamlake has joined #wpwg
11:51:45 <adrianba> rrsagent, make minutes
11:51:45 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/20-wpwg-minutes.html adrianba
12:31:18 <mountie> mountie has joined #wpwg
12:33:17 <rouslan> rouslan has joined #wpwg
12:57:31 <olivexu> olivexu has joined #wpwg
13:01:34 <chu> chu has joined #wpwg
13:03:24 <shepazu> shepazu has joined #wpwg
13:04:15 <weinig> weinig has joined #wpwg
13:05:21 <adamlake> adamlake has joined #wpwg
13:06:19 <adamR> adamR has joined #wpwg
13:08:16 <kazho> kazho has joined #wpwg
13:09:54 <bensmith> bensmith has joined #wpwg
13:13:28 <chunming> chunming has left #wpwg
13:23:06 <betehess> betehess has joined #wpwg
13:23:12 <Ian> topic: Overview doc
13:24:02 <nick> nick has joined #wpwg
13:24:02 <Ian> https://w3c.github.io/webpayments-overview/
13:24:07 <Ian> Manu: Not much has changed since June
13:24:10 <Ian> (at a high level)
13:24:18 <Ian> ...I did update some links to TR specs
13:25:14 <zkoch> zkoch has joined #wpwg
13:26:37 <jyrossi> jyrossi has joined #wpwg
13:26:45 <nicktr> q?
13:27:00 <jyrossi> present+ jyrossi
13:27:31 <Ian> PROPOSED: Publish this as a NOTE in TR space, and update it as other specs are updated
13:27:46 <Ian> MattS: I have some minor edits to suggest.
13:27:58 <Ian> Manu: You can suggest those changes during the CFC
13:28:15 <Ian> q?
13:28:17 <Ian> agenda?
13:29:26 <MattS> MattS has joined #wpwg
13:29:46 <pascal_bazin> pascal_bazin has joined #wpwg
13:30:13 <AdrianHB> +1
13:30:17 <lbolstad> lbolstad has joined #wpwg
13:30:17 <Roy> Roy has joined #wpwg
13:30:24 <lbolstad> present+ lbolstad
13:30:27 <MattS> +1
13:30:28 <ShaneM> +1
13:30:29 <Roy> +1
13:30:29 <Max> +1
13:30:29 <lbolstad> +1
13:30:31 <rouslan> +1
13:30:33 <nicktr> +1
13:30:34 <Ian> +0 (no objection; but think it does not need to be a TR doc)
13:30:35 <bensmith> +1
13:30:41 <Ian> RESOLVED: Issue a CFC for overview specification
13:30:57 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/20-wpwg-minutes.html Ian
13:34:43 <Nicolas_A_> Nicolas_A_ has joined #wpwg
13:34:54 <Mike5> q+ to comment
13:35:03 <nick> q+
13:35:07 <Ian> topic: WPWG timing on payment request API
13:35:31 <Ian> IJ: Proposed CFC in 5 weeks. Also PR API would not leave CR until payment apps enters CR
13:35:41 <Ian> AdamR: Would rather have all specs leave CR at the same tine
13:35:43 <jyrossi_> jyrossi_ has joined #wpwg
13:35:48 <nicktr> q+ manu
13:36:06 <nicktr> ack mike
13:36:06 <Zakim> Mike, you wanted to comment
13:36:31 <Ian> Mike5: The way I think PLH would articulate it is that you should not start CR until you know when you are going to leave CR.
13:36:36 <MattPi> MattPi has joined #wpwg
13:37:01 <Ian> ...I think that you should have a test suite before leaving CR
13:37:31 <Ian> ...we don't have two implementations yet that we know about that we can test; we only have one that we know of.
13:37:48 <AdrianHB> q?
13:38:17 <adrianba> I think you need to know _how_ you are going to leave CR - i.e. what are the exit criteria but not when
13:38:18 <Ian> ...in short - I think the focus should be on getting the test suite to advance in order to have a concrete discussion about when to leave CR
13:38:21 <nicktr> ack nick
13:38:24 <adrianba> you also need a minimum CR time period
13:38:45 <Ian> nickS: I would have some concerns about gating payment request (which is implemented) against something that is not implemented (payment apps)
13:38:57 <adrianba> exit criteria should outline how you're going to determine that you meet the PR entry criteria, which is likely to include a test suite
13:39:02 <Ian> NickS:...I would be concerned about introducing that dependency
13:39:06 <Ian> ack Manu
13:39:07 <nicktr> ack manu
13:39:15 <pea> pea has joined #wpwg
13:39:38 <Ian> Manu: I don't understand what going to CR buys us. It's usually used to demonstrate that the group is done with the work and we are fairly sure what we have. Why do we want to move to CR? What does it buy us?
13:39:38 <nicktr> q?
13:39:51 <Ian> zkoch: I think what CR buys us is some stability.
13:39:58 <AdrianHB> q+
13:40:07 <Ian> ...people are confident that we won't introduce breaking changes unless really necessary...and those are based on implementation issues.
13:40:20 <ShaneM> q+
13:40:24 <pea13> pea13 has joined #wpwg
13:40:32 <Ian> q+
13:40:47 <Ian> zkoch: Today we have one implementation. I think others would like more confidence in the stability of the API
13:40:54 <Mike5> q?
13:41:11 <Ian> MaheshK: We are concerned about going public with our implementation unless it is a CR
13:41:43 <Ian> AdrianHB: Who do you think is looking for the stability? Merchants or browsers?
13:41:48 <Ian> zkoch: Both
13:41:55 <nicktr> ack AdrianHB
13:42:04 <adrianba> we definitely are looking for stability - want to avoid rework
13:42:35 <Mike5> q?
13:42:37 <adrianba> when we talk to partners they want to avoid rework too
13:43:00 <Ian> zkoch: I believe from Editor perspective we are ready from a pec perspective
13:43:22 <nicktr> q+ manu
13:43:25 <ShaneM> ack ShaneM
13:43:25 <nicktr> ack ShaneM
13:43:27 <Ian> IJ: Note that having a test suite is not  prerequisite for entering CR
13:44:00 <nicktr> q?
13:44:11 <Ian> ShaneM: I think it's fine to set goals (e.g., go to CFC in 5 weeks)
13:44:32 <Ian> ...wrt testing, I think having a test suite will be easier with two implementations available
13:44:54 <nicktr> q?
13:44:55 <Ian> ...I am happy to having a test suite available in 5 weeks if we have two implementations available
13:45:14 <nicktr> ack ian
13:45:14 <Ian> ...finally, I'm ambivalent about whether to push to CR because of payment apps
13:45:15 <Ian> ack me
13:45:24 <Ian> https://www.w3.org/Payments/WG/charter-201510.html
13:45:53 <Ian> IJ: Charter milestone is CR in Nov 2016
13:47:52 <MattPi> q+ +1 to CR / de-dupe dependency with Payment App
13:48:01 <MattPi> q+
13:48:16 <nicktr> q- +1
13:48:37 <nicktr> q+
13:48:40 <adamR> q+
13:49:05 <Ian> IJ: I believe stars are aligned to go to CR (1) charter (2) implementations (3) stable spec trajectory
13:49:31 <adamR> q-
13:49:36 <Ian> Manu: I hear people saying that some other things may destabilize payment request API...payment apps could destabilize payment request API
13:49:38 <nicktr> ack manu
13:49:39 <Ian> ...that's what I'm hearing.
13:49:50 <Ian> ack Matt
13:50:12 <Ian> MattPi: +1 to IJ and ZK points about CR and stability...I think it will send an important signal to our partners
13:50:40 <zkoch> q+
13:50:53 <Ian> IJ: I think that payment apps and payment request API do relate closely hence proposal that PR API not leave CR before other in CR
13:51:05 <Ian> MattPi: I'm not sure of the dependency.
13:51:49 <nicktr> ack me
13:51:51 <Ian> [Summary of CR]
13:52:36 <Ian> nicktr: I am hearing two different accounts: some want to go to CR (implementers in particular who are talking to customers) and those who do not (notably around payment apps)
13:52:44 <Ian> ..so one question is "when will payment apps be ready"?
13:53:00 <Ian> ..I think personally that there may be some things in payment apps that affect payment request API
13:53:11 <nicktr> q?
13:53:12 <Ian> ack zkoch
13:53:15 <nicktr> ack zkoch
13:53:34 <Ian> zkoch: We've tried to design payment request API with all this in mind - how things work in the real world.
13:53:45 <Ian> ...it's based on that confident and we are confident about moving forward
13:54:03 <Ian> ...this is an opportunity to say "we are not going to add new features"
13:54:14 <Ian> ...my other point is that these are independent specifications.
13:54:24 <Ian> ...we believe in the open ecosystem, but the specs are independent.
13:54:41 <adamR> q?
13:54:51 <Ian> ...we can make a best effort to go to CFC in 5 weeks to motivate ourselves
13:54:53 <AdrianHB> q+
13:54:55 <Ian> ...and see where we are in 5 weeks
13:55:04 <Mike5> q?
13:55:06 <Ian> ..it doesn't seem negative to me to aim for a target date.
13:55:07 <adamR> q+
13:55:17 <Ian> ack Adri
13:55:31 <Ian> AdrianHB: Something Zach said - what is the expectation at the end of the 5 weeks?
13:55:57 <Ian> ...I want to be clear what the expectation will be in 5 weeks.
13:56:35 <nicktr> q?
13:56:47 <Ian> AdrianHB: I don't think we are in a position to say "We will issue a CFC in 5 weeks." I think we are in a position to get things done and then check then
13:56:53 <Ian> ...whether we are ready to go to CFC.
13:57:11 <MattS> q+
13:57:17 <Ian> AdamR: I am concerned that when we get further into payment app spec, we may find we will make breaking changes to payment request API
13:57:26 <Ian> zkoch: I'm aware of that.
13:57:30 <nicktr> ack adamR
13:57:31 <adrianba> I think the proposal for the timeline encourages people to file their issues rather than holding on to them
13:57:37 <Ian> ...I think we've tried to design with this in mind.
13:57:51 <MattS> q-
13:57:55 <Ian> zkoch: Payment request API is built to solve a real problem independent of payment apps
13:58:07 <Ian> ...there are goals that it independently accomplishes.
13:58:17 <Ian> ...I think there is value pushing PR API forward and getting implementation
13:59:29 <AdrianHB> q+
14:00:19 <nicktr> ack AdrianHB
14:00:21 <Ian> AdamR: I think there are dependencies that are not as stable as some are asserting
14:00:24 <Nicolas_A_> Nicolas_A_ has joined #wpwg
14:00:33 <Ian> AdrianHB: So we have an impasse regarding the dependency on payment apps
14:01:03 <Ian> AdrianHB: Perhaps we should accelerate both
14:01:09 <Ian> AdamR: That seems realistic
14:01:48 <Ian> zkoch: I support 5 weeks as a motivator to move the specs, test suite forward
14:01:58 <Ian> AdamR: What is the expectation of what happens at the end of the timeline?
14:05:03 <Ian> AdrianHB: I feel like the two groups (PR API and payment apps) need to help each other advance
14:05:05 <MattPi> q+
14:05:06 <nicktr> q?
14:05:11 <nick> q+
14:05:12 <olivexu> olivexu has joined #wpwg
14:05:49 <nicktr> ack MattPi
14:06:26 <Mike5> q?
14:08:03 <MattS> q+
14:08:12 <nicktr> ack nick
14:08:13 <MattS> q-
14:08:23 <Ian> AdamR: I feel that payment request API is not stable due to payment apps state
14:08:45 <Ian> NickS: Payment request API exists independently of the payment app spec. I am not convinced that PR API should be held until the payment app spec is ready
14:09:03 <Ian> Adam: Yes, I propose both enter CR together
14:09:15 <Mike5> q+ to comment
14:09:25 <Ian> NickS: I think it's odd that have that API that has implementers in the wild and we are going to gate moving into CR with a spec that depends on it
14:09:38 <Ian> AdamR: I think there are mutual dependencies..we want an ecosystem that includes payment apps with PR API
14:09:55 <Ian> ...if we discover the shape of the API is not suitable, we may need to be changes
14:10:10 <mountie> mountie has joined #wpwg
14:11:15 <Ian> AdrianHB: I hear AdamR's point about going to CR sending a signal of stability that is not accurate given state of payment apps
14:11:22 <JonathanJ> JonathanJ has joined #wpwg
14:11:24 <Ian> NickS: You're implying that there is a technical dependency
14:11:39 <Ian> AdrianHB: An example is push payments.
14:11:56 <Ian> ...does it require a new feature in payment request API (e.g., an event)
14:12:23 <Ian> NickS: There does not seem to be a clear timeline for payment apps, but we have a much clearer timeline for PR API
14:12:44 <Ian> ...both chrome and edge are implementing. It seems like we are doing a disservice not going to CR as quickly as possible
14:12:58 <Ian> AdrianHB: We want implementers to look at the payment app spec and say "this is on the right track"
14:13:18 <rouslan> q+
14:13:46 <Ian> ack M
14:13:46 <Zakim> Mike, you wanted to comment
14:14:25 <mountielee> mountielee has joined #wpwg
14:14:47 <Ian> Mike: [Speaking personally] Please find a precedent in W3C where a spec is held until another one is ready
14:14:57 <Ian> Manu: WebRTC (IETF and W3C discussions)
14:15:14 <nicktr> q+ manu
14:15:26 <Ian> Mike: Show me precedent; I think the burden is in part showing this has been done in the past.
14:15:30 <ShaneM> I disagree with Mike - this isn't about process precendent
14:15:38 <ShaneM> s/precendent/precedent/
14:16:08 <Ian> Mike: I think that it's reasonable who feel that we should start CR (for PR API) to ask that we get some Director input on this.
14:16:45 <MattS> q+
14:16:47 <Ian> q?
14:17:55 <nick> nick has joined #wpwg
14:17:59 <Ian> ack rouslan
14:18:02 <AdrianHB> zakim, close the queue
14:18:02 <Zakim> ok, AdrianHB, the speaker queue is closed
14:18:16 <Ian> Rouslan: There was a question about implementers giving a signal to the payment apps task force
14:18:39 <Ian> ...several weeks ago I reviewed that spec and I made several comments ... I think they were taken into account and incorporated
14:18:46 <Ian> ..I think the task force is on the right track.
14:19:05 <Ian> ...the technology that's being described in the payment app task force is the basis of the demo for Alipay
14:19:21 <nicktr> q?
14:19:26 <Ian> ...so I don't know that there are a lot of changes in payment apps that would break payment request API
14:19:46 <MattS> q-
14:19:52 <Ian> Manu: I think there are two points of trepidation (1) we don't have implementations of payment app spec
14:19:54 <nicktr> ack manu
14:19:54 <dezell> dezell has joined #wpwg
14:20:24 <Ian> ..the easiest way is to get at least an implementation of the payment app spec done at which point we'll be far more sure about the decision
14:20:30 <Ian> NickTR: I am not hearing consensus
14:20:41 <Ian> AdrianHB: I think we do want to set goals
14:21:40 <adamR> q+
14:23:23 <ShaneM> I disagree with Ian.   The spec in CR is meant to be stable except for things that are marked as at risk.
14:24:23 <dezell2> dezell2 has joined #wpwg
14:25:45 <AdrianHB> zakim, open the queue
14:25:45 <Zakim> ok, AdrianHB, the speaker queue is open
14:26:42 <Ian> IJ: You can make changes in CR. I am proposing we set the expectation both that changes may occur due to implementation of PR API and also payment apps
14:28:16 <Ian> IJ: Given that people agreed to read the spec yesterday by 3 October, we can have a payment app FPWD easily by second week of Oct
14:28:25 <Ian> MattS: Should we set the criteria?
14:28:56 <Ian> q+
14:29:24 <Ian> MattS: Maybe there are 2-3 key issues to address.
14:32:06 <shepazu> shepazu has joined #wpwg
14:32:38 <adamR> q+
14:32:45 <AdrianHB> ack ian
14:33:28 <AdrianHB> Goals following F2F:
14:33:42 <AdrianHB> 1. Review of Payment Apps spec (Zach, Max, Shane)
14:33:56 <AdrianHB> 2. Proposal to address push payments (Roy)
14:34:12 <AdrianHB> 3. Payment Method Identifiers (Zach)
14:34:21 <AdrianHB> 4. FPWD Payment Apps
14:35:08 <AdrianHB> PROPOSAL: Accomplish goals 1 - 4 in 5 weeks and if they are concluded assess readiness of Payment Request for CR
14:35:14 <Ian> AdamR: I am more comfortable saying "let's review the landscape in 5 weeks and see if we have got those things done"
14:35:20 <kazho> kazho has joined #wpwg
14:36:23 <Ian> s/PMI/PR API + Basic card + PMI
14:37:12 <ShaneM> GREAT EXPECTATIONS
14:37:42 <adrianba> the most critical part of a roadmap to CR is getting people to file issues with time to resolve them
14:37:47 <Ian> IJ: Proposal ok with additional expectation that reviews AFTER that period will not arbitrarily suggest changes
14:37:56 <Ian> s/change/large breaking changes
14:38:07 <Ian> MattS: Other things we wanted during this time
14:38:13 <Ian> - confirm that we have a second implementation
14:38:43 <Ian> -  test suite progress
14:39:50 <rouslan> +1
14:39:52 <Ian> AdrianHB: People ok with this proposal?
14:39:57 <AdrianHB> +1
14:39:57 <adamR> +1
14:39:58 <nicktr> +1
14:40:02 <ShaneM> +1
14:40:02 <Ian> +1 since I think it's as far as we will get today
14:40:14 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/20-wpwg-minutes.html Ian
14:45:31 <lilin> lilin has joined #wpwg
14:58:53 <dezell> dezell has joined #wpwg
14:59:56 <rouslan> rouslan has joined #wpwg
15:08:19 <adamR> adamR has joined #wpwg
15:13:35 <JonathanJ> JonathanJ has joined #wpwg
15:15:54 <JonathanJ1> JonathanJ1 has joined #wpwg
15:16:25 <pascal_bazin> pascal_bazin has joined #wpwg
15:17:20 <Jonathan_> Jonathan_ has joined #wpwg
15:18:24 <Ian> topic: Testing
15:19:45 <zkoch> zkoch has joined #wpwg
15:23:11 <Ian> [[@@Shane has slides]
15:25:28 <Ian> Shane: Service workers makes testing easier
15:25:58 <Max> Max has joined #wpwg
15:28:43 <Ian> [Light minuting]
15:30:05 <Mike5> for the record, zkoch and rouslan noted that clicking Buy button to initiate a payment request is not a trusted click event
15:30:48 <Mike5> can be initiated programatically (which makes it possible to automate that part of tests when we need to)
15:36:39 <bensmith> bensmith has joined #wpwg
15:42:14 <Ian> Roy: I am still available as a test reviewer
15:44:13 <Ian> Shane: I would like a way to refer to a "known" payment method (for testing) and to be able to turn on/off support for that
15:44:58 <Ian> Rouslan: Why not just "basic-card"?
15:47:49 <olivexu> olivexu has joined #wpwg
15:47:56 <Ian> zkoch: there should be a blocking user consent thing
15:52:47 <mountie> mountie has joined #wpwg
15:52:58 <weinig> weinig has joined #wpwg
15:54:16 <shepazu> shepazu has joined #wpwg
15:54:22 <Mike5> [discussion about Chrome adding an optional flag to enable test to automate the step that requires user action otherwise]
16:01:52 <sam> sam has joined #wpwg
16:05:32 <rouslan> rouslan has joined #wpwg
16:09:39 <Ian> Shane: Sounds like we've agreed to use basic card, with some user interaction
16:10:28 <Ian> http://www.planetpdf.com/codecuts/pdfs/tutorial/CredCard.pdf
16:11:21 <Ian> more test numbers:
16:11:21 <Ian> https://stripe.com/docs/testing
16:12:51 <pascal_bazin> EMV specification is that the PAN can be 12 to 19 digits
16:14:21 <Ian> implementation expectations of w3c process
16:14:21 <Ian> https://www.w3.org/2015/Process-20150901/#implementation-experience
16:17:03 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/20-wpwg-minutes.html Ian
16:17:19 <Ian> [Mike shows what we have so far]
16:18:17 <ShaneM> My presentation was at https://docs.google.com/presentation/d/1tAlj0FbGxEWo-wpmO8PIMRlC7BeLQqcnRwgk-s3wapc/edit?usp=sharing
16:33:33 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/20-wpwg-minutes.html Ian
16:33:40 <Ian> [ADJOURNED]
16:36:12 <zkoch> zkoch has joined #wpwg
16:38:12 <Ian> zakim, bye
16:38:13 <Zakim> leaving.  As of this point the attendees have been AdamR, zkoch, MattS, BenSmith, Manu, nicktr, MaheshK, Dongwoo, dezell, Roy, Shane, Rouslan, ShaneM, Max, JiaJia, Mountie, evgeny,
16:38:13 <Zakim> Zakim has left #wpwg
16:38:16 <Zakim> ... Ian, AdrianHB, LarsErik, William, Laurent, MattP, NickS, Jean-Yves, AlexandreB, lbolstad, !, jyrossi
16:38:21 <Ian> rrsagent, make minutes
16:38:21 <RRSAgent> I have made the request to generate http://www.w3.org/2016/09/20-wpwg-minutes.html Ian
16:38:25 <Ian> rrsagent, bye
16:38:25 <RRSAgent> I see 1 open action item saved in http://www.w3.org/2016/09/20-wpwg-actions.rdf :
16:38:25 <RRSAgent> ACTION: Zach to work with Max to revise the payment manifest proposal [1]
16:38:25 <RRSAgent>   recorded in http://www.w3.org/2016/09/20-wpwg-irc#T11-46-23