IRC log of wpwg on 2017-03-24

Timestamps are in UTC.

02:55:21 [Max]
Max has joined #WPWG
03:20:25 [Ian]
RRSAgent, make minutes
03:20:25 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/03/24-wpwg-minutes.html Ian
03:20:33 [Ian]
RRSAgent, bye
03:20:33 [RRSAgent]
I see no action items
13:37:36 [RRSAgent]
RRSAgent has joined #wpwg
13:37:36 [RRSAgent]
logging to http://www.w3.org/2017/03/24-wpwg-irc
13:37:38 [trackbot]
RRSAgent, make logs public
13:37:38 [Zakim]
Zakim has joined #wpwg
13:37:40 [trackbot]
Zakim, this will be
13:37:40 [Zakim]
I don't understand 'this will be', trackbot
13:37:41 [trackbot]
Meeting: Web Payments Working Group Teleconference
13:37:41 [trackbot]
Date: 24 March 2017
13:37:57 [Ian]
Agenda: https://github.com/w3c/webpayments/wiki/FTF-March2017
13:37:58 [Ian]
Chair: Nick
13:39:06 [Ryladog]
:-)
13:39:56 [Ian]
present+
13:40:28 [schuki]
present+
13:41:23 [Ryladog]
Present+ Katie_Haritos-Shea
13:42:03 [michel_cc]
present+
13:43:25 [nicktr]
present+
13:43:26 [nicks]
nicks has joined #wpwg
13:46:28 [m_and_m]
m_and_m has joined #wpwg
13:46:57 [Li_lin]
Li_lin has joined #wpwg
13:50:04 [Tommy]
Tommy has joined #wpwg
13:52:12 [mweksler]
mweksler has joined #wpwg
13:53:09 [mweksler]
mweksler has joined #wpwg
13:53:30 [todd_a]
todd_a has joined #wpwg
13:53:38 [todd_a]
present +
13:53:45 [mweksler]
present+
13:53:46 [rouslan]
rouslan has joined #wpwg
13:53:58 [dezell]
dezell has joined #wpwg
13:55:09 [AdrianHB]
present+ AdrianHb
13:55:17 [AdrianHB]
scribe: AdrianHB
13:55:21 [m_and_m]
present+
13:55:21 [rouslan]
present+
13:55:22 [pierre]
pierre has joined #wpwg
13:55:23 [zkoch]
zkoch has joined #wpwg
13:55:26 [mathp]
mathp has joined #wpwg
13:55:32 [marcosc]
marcosc has joined #wpwg
13:55:41 [MattPi]
MattPi has joined #wpwg
13:55:41 [AdrianHB]
topic: Payment Handler Spec Issues
13:55:48 [AdrianHB]
[Ian slides]
13:55:51 [pascal_bazin]
pascal_bazin has joined #wpwg
13:56:06 [AdrianHB]
https://www.w3.org/2017/Talks/ij_apps_201703/ij-apps-wpwg-201703.pdf
13:56:28 [AdrianHB]
ian: going to go through main issues and look for WG attention
13:56:37 [AdrianHB]
... 4 keys themes
13:56:48 [AdrianHB]
... 1. Reuse web tech
13:57:05 [AdrianHB]
... 2. Impact of Payment Req spec
13:57:33 [manu]
rrsagent, draft minutes
13:57:33 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/03/24-wpwg-minutes.html manu
13:57:43 [AdrianHB]
... 3. Data exchange with PR API
13:57:55 [Manash_MC]
Manash_MC has joined #WPWG
13:57:56 [fdold]
fdold has joined #wpwg
13:58:00 [nicktr]
q?
13:58:06 [AdrianHB]
... 4. Merchant preferences
13:58:12 [manu]
present+ manu
13:58:28 [zkoch]
present+
13:58:32 [nicktr]
zakim, who is here?
13:58:32 [Zakim]
Present: Ian, schuki, Katie_Haritos-Shea, michel_cc, nicktr, mweksler, AdrianHb, m_and_m, rouslan, manu, zkoch
13:58:35 [Zakim]
On IRC I see fdold, Manash_MC, pascal_bazin, MattPi, marcosc, mathp, zkoch, pierre, dezell, rouslan, todd_a, mweksler, Tommy, Li_lin, m_and_m, nicks, Zakim, RRSAgent, Ryladog,
13:58:35 [Zakim]
... AdrianHB, dick, alyver, Max, michel_cc, cweiss, pea13, canton_, MikeSmith, DavidM_GSMA, hober, schuki, dlehn, trackbot, dlongley, Ian, manu, mkwst, ShaneM, slightlyoff, nicktr,
13:58:35 [Zakim]
... adrianba, oyiptong, JakeA, emschwartz, Dongwoo, davidillsley_
13:58:43 [alyver]
present+
13:58:45 [marcosc]
present+
13:58:50 [nicks]
present+
14:00:34 [pierre]
present+
14:00:52 [DavidM_GSMA]
pressent+
14:01:25 [AdrianHB]
[ian talking through latest proposals - see slide 5]
14:02:12 [jean-yves]
jean-yves has joined #wpwg
14:02:18 [CyrilV]
CyrilV has joined #wpwg
14:02:22 [jean-yves]
present+ jean-yves
14:02:24 [frank]
frank has joined #wpwg
14:02:25 [CyrilV]
present+
14:02:27 [nicktr]
q?
14:03:01 [AdrianHB]
zkoch: there's a few aspects to the options discussion. It's fundamentally a UX thing so we can't have normative reqs
14:03:09 [Li_lin]
present+
14:03:11 [AdrianHB]
... why don't I like it in practice:
14:03:23 [AdrianHB]
... 1. space limited on mobile
14:04:06 [AdrianHB]
... 2. consistency in display of same instruments (cards shown differntly by diff apps)
14:04:06 [AdrianHB]
... 3. high likelihod of duplicates
14:04:30 [AdrianHB]
... 4. not convinced by benefit if you still have to end up in the application
14:05:11 [nicktr]
q?
14:05:15 [rouslan]
q+
14:05:16 [AdrianHB]
... chrome has strict design rules and others have other rules we should let everyone deal with this themselves (including apps)
14:05:44 [Tommy]
q+
14:05:44 [AdrianHB]
ian: if you can see detail and click directly there may be a faster path (forgot to mention in presentation)
14:05:52 [nicktr]
ack zkoch
14:06:00 [adamR]
adamR has joined #wpwg
14:06:26 [AdrianHB]
rouslan: i often hear argument that the browser can decide if it displays options or not but I think that is poor as apps will need to define two handlers
14:06:33 [dezell]
q?
14:06:52 [MattS]
MattS has joined #wpwg
14:07:01 [nicktr]
q?
14:07:05 [nicktr]
ack rouslan
14:07:29 [mike_mastercard]
mike_mastercard has joined #wpwg
14:07:34 [nicktr]
ack Tommy
14:07:43 [AdrianHB]
zkoch: you'll usually find the ecosystem settling on lowest common denominator so if one browser doesn't support then none will
14:08:11 [nicktr]
q?
14:08:15 [AlanSamsungPay]
AlanSamsungPay has joined #wpwg
14:08:21 [ken]
ken has joined #wpwg
14:08:22 [AdrianHB]
tommy: I disagree with zkoch on point 4 above. If the user has configured the app for optimized flow then the app may never even need to show UI.
14:08:23 [adamR]
present+
14:08:23 [adamR]
q+
14:08:43 [AdrianHB]
zkoch: agree this is possible but don't see this being used in the real world.
14:08:45 [AdrianHB]
q+
14:08:46 [dick]
q+
14:09:07 [AdrianHB]
tommy: for low sums (micropayments) then I see this happening
14:10:30 [AdrianHB]
zkoch: this is an optimization. I see the challenge of simply getting the apps into the selections screen as hard enough. lets do that first
14:10:34 [zkoch]
TYPE FASTER ADRIANHB!
14:11:03 [AdrianHB]
adamR: this is a checkout flow and clicks increase abandonment. we don't want this to be worse than the current web experience.
14:11:11 [nicktr]
ack AdrianHB
14:11:24 [nicktr]
ack adamR
14:11:26 [Manash_MC]
+manash
14:11:30 [AdrianHB]
dick: +1 to adamR
14:11:32 [nicktr]
ack dick
14:12:04 [CyrilV]
q+
14:12:06 [AdrianHB]
... user experience where options are surfaced early is v important
14:12:22 [AdrianHB]
... the options the user has are hidden which is also problematic
14:12:37 [dezell]
q?
14:13:53 [mathp]
+1, I foresee UX problems if each payment app can show, say 3-4 instruments inside the browser UI
14:13:58 [nicktr]
q+ manash
14:14:06 [AdrianHB]
zkoch: this pushes the UX problems onto the browser. The app can have defaults set at registration so that the user doesn't need to choose an instrument.
14:14:22 [betehess]
betehess has joined #wpwg
14:15:02 [AdrianHB]
zkoch: payment apps still need to solve UX problems at registration
14:15:43 [AdrianHB]
dick: issue is that the user may not understand what options they have available if they pick the payment app (they don't remember what instruments they registered)
14:15:51 [AdrianHB]
zakim, close queue
14:15:51 [Zakim]
ok, AdrianHB, the speaker queue is closed
14:16:11 [vkuntz]
vkuntz has joined #wpwg
14:16:31 [vkuntz]
present+
14:16:41 [dezell]
present+
14:16:46 [mathp]
present+
14:16:56 [AdrianHB]
cyril: this seems like the discussion is about the merchant concerns (i.e. cart abandonment) whereas for financial service providers we care about the user's concerns like consent of the payment
14:16:57 [mike_mastercard]
present+
14:17:03 [Max]
present+
14:17:05 [frank]
present +
14:17:35 [AdrianHB]
... it is important that we don't forget that the user always consents to a payment
14:17:45 [nicktr]
q?
14:17:49 [nicktr]
ack CyrilV
14:17:50 [manu]
present+ Frank
14:17:53 [nicktr]
ack Manash_MC
14:18:03 [nicktr]
ack Manash
14:18:38 [AdrianHB]
manash: stats on conversions show that card on file converts 40% whereas for example PayPal 1-touch has 80% conversion so there is evidence that conversion is impacted by clicks
14:19:23 [AdrianHB]
zkoch: when a PayPal user pays with PayPal they just pick PayPal. They seldom care what the underlying instrument is.
14:19:43 [AdrianHB]
... this optimized checkout flow is still possible.
14:20:16 [AdrianHB]
ian: we have in the spec a definition of a data structure and no UX reqs. We have 3 options to go forward:
14:20:26 [AdrianHB]
... 1. drop this data structure
14:20:52 [AdrianHB]
... 2. provide the data to browsers but they choose what depth of display they implement
14:21:45 [AdrianHB]
... 3. put display reqs in the spec that force borwsers to display all instruments and details the app registers
14:22:13 [AdrianHB]
[ian takes a strawpoll on the WG feeling aboyut these options]
14:22:28 [AdrianHB]
alan: could option 2 include guidance on display?
14:23:33 [AdrianHB]
alan: there is a power shift from merchant to browser. We are giving browsers more control than they have today.
14:23:39 [CyrilV]
CyrilV has joined #wpwg
14:24:06 [AdrianHB]
12 votes for option 1
14:24:17 [AdrianHB]
12 votes for option 2
14:24:29 [AdrianHB]
4 votes for option 3
14:24:33 [dezell]
I would have voted option 1 (repeal) if I thought there would be a replace, so i went with 2.
14:24:58 [rouslan]
q+
14:25:00 [manu]
q+ to ask if this is mostly an implementation complexity concern among option 1
14:25:11 [AdrianHB]
zakim, open the queue
14:25:11 [Zakim]
ok, AdrianHB, the speaker queue is open
14:25:17 [manu]
q+ to ask if this is mostly an implementation complexity concern among option 1
14:25:41 [rouslan]
q?
14:25:44 [rouslan]
q+
14:25:48 [AdrianHB]
ack manu
14:25:48 [Zakim]
manu, you wanted to ask if this is mostly an implementation complexity concern among option 1
14:25:57 [dezell]
q+
14:26:04 [adamR]
q+
14:26:11 [mike_mastercard]
q+
14:26:11 [AdrianHB]
manu: for those in favour of option 1, is the primary concern implementation complexity?
14:26:26 [AdrianHB]
ian: I heard many concerns (beyond that)
14:26:37 [nicktr]
I'd like to point out an inconsistency in the existing implementations - essentially "basic card" handler is extra privileged because it displays all the instruments, whereas the other handlers (bobpay, androidpay as examples) only display origin/handler name
14:26:49 [nicktr]
q?
14:27:01 [AdrianHB]
marcos: my experience is that we are trying to do too much too fast. We should be more incremental.
14:27:30 [AdrianHB]
... we have good infra in place. We still have many things to solve so let's start with option 1
14:28:05 [nicktr]
ack rouslan
14:28:08 [nicktr]
zakim, close queue
14:28:08 [Zakim]
ok, nicktr, the speaker queue is closed
14:28:24 [AdrianHB]
rouslan: +1 to marcos. primary concern is complexity. Let's do 1 first then expand to 2
14:28:38 [AdrianHB]
... also UX concern on mobile
14:29:08 [AdrianHB]
q+ to ask if basic card expansion might go away fi there are apps?
14:29:31 [AdrianHB]
... in chrome we prefer to not use basic card so they get pushed to the bottom fi there are other options
14:29:38 [nicktr]
ack dezell
14:30:30 [nicktr]
notes (in response to Adrian's question) that this does seem to be another example of the basic card fudge getting in the way (see also short names, filters...)
14:30:32 [AdrianHB]
dezell: most money spent on payment apps (traditional) is spent on preventing user deception
14:30:43 [nicktr]
ack adamR
14:31:16 [zkoch]
q+
14:31:18 [AdrianHB]
adamr: I don;t thing 1 is backwards compatible with 2 or 3
14:31:21 [zkoch]
finnneee
14:32:14 [nicktr]
ack mike_mastercard
14:32:15 [AdrianHB]
... i think 3 is the way this shoudl work but I have sympathy for implementers. I see option 1 as deviation from the correct order of constituencies
14:32:35 [AdrianHB]
mike_mastercard: I can sympathize with both sides of this
14:32:51 [AdrianHB]
... apps in market today have their own experiences that differentiate them
14:33:24 [AdrianHB]
... so I am inclined to say 1 but I also sympathize with the desire to have an equal positioning with basic card
14:34:06 [AdrianHB]
... there is always a learning process the first time you do something so we should not neglect the opportunity to optimize that
14:34:10 [AdrianHB]
ian: propose the TF will take this input and come back with updates
14:34:38 [AdrianHB]
ian: [discusses new issue - 116 which we'll not cover now]
14:35:44 [AdrianHB]
ian: another new issue which needs to be logged relates to syncing of state between payment app window and payment app service worker
14:35:50 [nicktr]
zakim, open the queue
14:35:50 [Zakim]
ok, nicktr, the speaker queue is open
14:36:45 [AdrianHB]
marcos: there are many other issues we need to still figure out like additional permissions and other overlay windows etc.
14:36:57 [AdrianHB]
ian: yes, so let's pick this up in the TF
14:37:22 [AdrianHB]
ian: big issue to discuss is impact of payment handler on PR before PR can go to CR
14:37:50 [AdrianHB]
[back to slides - do we have what we need?]
14:38:06 [zkoch]
^^ yes
14:38:22 [marcosc]
MC: should also mention memory issues on mobile with running 2 browser windows at the same time each running a service worker
14:38:26 [marcosc]
(adding to minutes)
14:38:54 [dezell]
May I suggest (I know everybody knows about this ) https://www.owasp.org/images/f/f8/OWASP_Top_10_-_2013.pdf especially focusing on A10, A8, and maybe A3.
14:39:24 [mweksler]
mweksler has joined #wpwg
14:39:55 [nicktr]
q?
14:39:58 [rouslan]
q+
14:40:06 [AdrianHB]
ian: have those that have done payment app testing got feedback on PR?
14:40:20 [AdrianHB]
rouslan: no problems for us. no changes needed to PR API required
14:40:31 [nicktr]
ack rouslan
14:41:36 [manu]
q+ to waaait
14:41:41 [AdrianHB]
ian: confidence in PR has gone up since Lisbom
14:41:52 [AdrianHB]
s/Lisbom/Lisbon/
14:42:02 [manu]
q+ to ask whether we're actually going to discuss that last item.
14:42:15 [AdrianHB]
[next slide on PR API data to be passed to Payment Apps]
14:42:32 [AdrianHB]
ack manu
14:42:32 [Zakim]
manu, you wanted to waaait and to ask whether we're actually going to discuss that last item.
14:42:39 [AdrianHB]
nicktr: we will discuss later
14:44:11 [AdrianHB]
ian: propose that PR API spec removes mention of using line items for details of products
14:44:27 [AdrianHB]
zkoch: okay but had assumed that is just Google's position
14:45:01 [AdrianHB]
marcos: people will use this for product items
14:45:37 [manu]
q+ to mention that I thought we WERE going to use this for product details.
14:45:59 [nicktr]
ack manu
14:45:59 [Zakim]
manu, you wanted to mention that I thought we WERE going to use this for product details.
14:46:22 [AdrianHB]
manu: this is why we objected to this before
14:46:39 [nicks]
q+
14:47:10 [AdrianHB]
nicktr: implementors are saying that if it exists people will use it but the WG wants to give strong guidance on how to use it
14:47:23 [nicktr]
ack nicks
14:48:06 [AdrianHB]
PROPOSAL: Drop the mention of "products" in the displayItems definition
14:48:12 [AdrianHB]
[filed as issue 477]
14:48:49 [nicks]
q+
14:49:14 [rouslan]
q+
14:49:29 [nicktr]
ack nicks
14:49:33 [frank]
q+
14:49:35 [AdrianHB]
ian: can the payment app get permission to get user data like email and shipping from the browser
14:49:36 [manu]
q+ to agree w/ Marcos, note that we may be working on that via Verifiable Claims or Credential Management API, multiple reasons for it to NOT be dealt with in this group.
14:49:49 [AdrianHB]
marcos: this is already available through autofill
14:50:51 [AdrianHB]
nicks: sometimes this data is not just auto-fill data. eg: current location
14:50:54 [nicktr]
ack
14:50:57 [nicktr]
ack rouslan
14:51:01 [manu]
q+ to note that this isn't a critical part of checkout flow
14:51:26 [AdrianHB]
rouslan: I have heard more important than shipping is email. This allows payment app to optimize user experience
14:51:29 [nicktr]
ack frank
14:51:53 [nicktr]
q?
14:52:06 [AdrianHB]
frank: I disagree that autofill is enough. If the user chose an address already then why make them choose it again in the payment app
14:52:50 [AdrianHB]
zkoch: a) very difficult to reason about privacy consent b) why is that critical information?
14:53:05 [AdrianHB]
frank: b) we use it for real time credit?
14:53:26 [AdrianHB]
zkoch: a) the privacy consent messaging sees very hard to figure out
14:53:47 [adamR]
q+
14:54:06 [AdrianHB]
marcos: there are ways to hack around this anyway
14:54:09 [nicktr]
zakim, close queue
14:54:09 [Zakim]
ok, nicktr, the speaker queue is closed
14:54:28 [nicktr]
ack manu
14:54:28 [Zakim]
manu, you wanted to agree w/ Marcos, note that we may be working on that via Verifiable Claims or Credential Management API, multiple reasons for it to NOT be dealt with in this
14:54:31 [Zakim]
... group. and to note that this isn't a critical part of checkout flow
14:54:51 [AdrianHB]
manu: there are not core use cases that require this
14:55:17 [nicktr]
ack adamR
14:55:17 [AdrianHB]
.. and it feels like we could push it off 'til later
14:55:40 [frank]
q+
14:55:52 [AdrianHB]
adamr: for things that don't change often it's likely that the app will already have this info
14:56:34 [nicktr]
notes that as push payment use cases increase, the requirement to do fraud screening against things like shipping address will increase on the payment app side. In other words, more use cases like Klarna...
14:56:35 [AdrianHB]
... second, this is not trusted info so we shouldn't treat it as such
14:57:02 [AlanSamsungPay]
q+
14:57:30 [zkoch]
AdrianHB: We’re taking first world, card-centric view of this whole thing. Real time credit is a reality of developing world. Becoing a big industry
14:57:45 [zkoch]
… every scrap of data increases chance of credit. Making this more difficult is just making it more difficult to give people credit
14:57:50 [manu]
AdrianHB: I think we're taking a very first world, client-centric view of this. Realtime credit is a big thing in the developing world, it's important that a provider can get any scrap of data they can get to. Making it difficult for them to collect that data is going to make it difficult for them to provide credit.
14:57:58 [zkoch]
see, this is why i don’t try to help
14:58:00 [dick]
dick has joined #wpwg
14:58:42 [zkoch]
::hand breaks::
14:58:56 [nicktr]
+1 to adrianHB's point - this is another example of the inherent skew to cards in the spec
14:59:23 [AdrianHB]
frank: we still do verification. we don't assume the data is trusted
14:59:41 [AdrianHB]
adamr: this sounds like an optimization
14:59:51 [AdrianHB]
frank: yes, but so is a lot of what we are discussing
15:00:06 [AdrianHB]
nicktr: are there implications for PR
15:00:26 [AdrianHB]
ian: no, this would all be spec'd in Payment Handler spec
15:00:57 [mweksler]
mweksler has joined #wpwg
15:01:03 [AlanSamsungPay]
q+
15:01:16 [AdrianHB]
zakim, open the queue
15:01:16 [Zakim]
ok, AdrianHB, the speaker queue is open
15:01:36 [AdrianHB]
ian: [discussing merchant recommendations - back to slides]
15:01:44 [AlanSamsungPay]
q+
15:02:46 [AdrianHB]
ian: point has been made that merchant ordering of payment methods may be sufficient
15:03:28 [nicktr]
ack AlanSamsungPay
15:03:40 [AdrianHB]
... also there is a complex layering of preferences between methods, apps and browser preferences (e.g. rouslan has has that Chrome deprioritizes basic card)
15:05:08 [AdrianHB]
alan: Use case: Merchant wants the user to use the merchant issued instrument. Also express that a 3rd party app should use that instrument.
15:06:10 [AdrianHB]
... also notion of instant credit may be available for specific merchants
15:06:20 [AdrianHB]
1. express pref as an app
15:06:35 [AdrianHB]
2. express pref for instrument within 3rd party app
15:07:00 [AdrianHB]
3. express pref for payment method from specific app
15:07:49 [nicktr]
q?
15:08:30 [AdrianHB]
ian: browser can try to match app and request based on origin and merchants can also define their own payment method and have their own app that is the only app supporting that method
15:09:00 [AdrianHB]
nicktr: there is a way to order by method but not by app/handler or instrument
15:09:50 [nicks]
q+
15:10:10 [nicks]
q-
15:10:43 [AdrianHB]
ian: observation, on the question of do we have what we need to take PR to CR, let's have that chat later
15:10:46 [AdrianHB]
+1
15:11:12 [AdrianHB]
manu: we want to deploy this using web apps and we don't see a clear path to doing so.
15:11:30 [AdrianHB]
... so the question is are we interested in doing a polyfill
15:12:06 [AdrianHB]
ian: I think this is out of scope because our job is to write a spec not code
15:12:18 [nicks]
q+
15:12:35 [AdrianHB]
manu: I'm not suggesting that. There is a tradition in W3C that we give a polyfill to people so they can experiment.
15:13:35 [AdrianHB]
I think it easier to go to CR if the group knows there is a polyfill for handlers being developed in parallel
15:14:12 [AdrianHB]
ian: I think we may learn more from the polyfill but not in time to impact a decision about going to CR
15:14:36 [AdrianHB]
manu: is anyone else interested in working on a polyfill?
15:16:06 [AdrianHB]
marcos: I agree with manu but don't have the same conclusions. There are payment apps already working using PR API so I like the idea of a polyfill but not as a means to help learn more about PR API
15:16:25 [AdrianHB]
manu: not enough web based payment apps and those being done are all on Tommy's fork
15:16:54 [zkoch]
zkoch has joined #wpwg
15:17:39 [AdrianHB]
ian: experience we'll get from hacking is critical but we have buy in from implementors on PR API and we have been working hard to get it ready for CR. We have addressed what we can ito impact of payment handler.
15:17:52 [AdrianHB]
q?
15:18:04 [nicktr]
ack nicks
15:18:06 [AdrianHB]
ack nicks
15:18:48 [AdrianHB]
nicks: I am wary of tying PR and payment handlers together because of dependencies on Service Worker in payment handlers and not in PR
15:19:33 [manu]
q+ to clarify that his position has softened.
15:19:33 [MattS]
q?
15:19:36 [AdrianHB]
nicktr: any other strong feelings about readiness of payment handler impacting PR readiness for CR
15:20:07 [AdrianHB]
... my sense is thag the handler spec is much more mature and the general confidence in it is sufficient
15:20:13 [AdrianHB]
... to take PR to CR
15:20:20 [nicktr]
q?
15:20:32 [adamR]
q+
15:20:50 [AdrianHB]
ian: is the PR spec better since Sept?
15:21:05 [AdrianHB]
marcos: yes but it could still change a lot. CR doesn't mean it won't
15:22:06 [AdrianHB]
ian: testing is not on the agenda but we have made a small amount of progress on it. there are companies that can help with this if any members want to sponsor this.
15:22:19 [AdrianHB]
marcos: remember we can't leave CR without a full test suite
15:23:01 [nicktr]
q?
15:23:55 [nicktr]
ack adamR
15:24:01 [nicktr]
ack manu
15:24:01 [Zakim]
manu, you wanted to clarify that his position has softened.
15:24:10 [AdrianHB]
adamr: if we go with option 1 (earlier) then we have a lot of revisions to make to PH spec
15:24:45 [AdrianHB]
manu: I am not saying we can't go to CR without a polyfill. We should set realistic expectations about how long we might be in CR
15:26:06 [AdrianHB]
... this impacts merchant merchant adoption
15:26:25 [AdrianHB]
... how easy we can show devs that this works
15:26:40 [AdrianHB]
ian: do WG publish "official" polyfills?
15:26:55 [AdrianHB]
marcos: some do. WhatWG has a great streams polyfill
15:27:25 [marcosc]
https://github.com/whatwg/streams/tree/master/reference-implementation
15:27:34 [marcosc]
so good
15:27:37 [AdrianHB]
ian: alan raised issue yesterday about apps exposing functions they have to browser
15:27:49 [AdrianHB]
alan: happy to take that into TF dicussions
15:28:06 [AdrianHB]
break for coffee
15:28:07 [AdrianHB]
s/coffee/vodka/
16:00:38 [MattPi]
MattPi has joined #wpwg
16:02:04 [marcosc_]
marcosc_ has joined #wpwg
16:04:18 [Tommy]
Tommy has joined #wpwg
16:07:09 [alyver]
alyver has joined #wpwg
16:07:17 [MattS]
MattS has joined #wpwg
16:07:38 [AdrianHB]
scribe: Ian
16:07:44 [CyrilV]
CyrilV has joined #wpwg
16:07:44 [mathp]
mathp has joined #wpwg
16:07:44 [Ian]
RRSAgent, make minutes
16:07:44 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/03/24-wpwg-minutes.html Ian
16:07:47 [CyrilV]
present+
16:07:48 [zkoch]
zkoch has joined #wpwg
16:07:55 [Ian]
RRSAGent, set logs public
16:07:56 [Max]
Max has joined #WPWG
16:08:11 [Ian]
Topic: Credit Transfer Payment Method
16:08:17 [nicktr]
Spec -> http://w3c.github.io/webpayments-methods-credit-transfer-direct-debit/
16:08:45 [Ian]
vkuntz: Here's how we came up with the data fields => Common global implementation market practice group (CGI-MP) did this work
16:09:46 [dick]
dick has joined #wpwg
16:09:46 [Ian]
[Vincent reviews a bit of the history of the CGI-MP; will defer to slides once available]
16:10:49 [Ian]
CGI-MP is driven by customer demand for multi bank coordination of implementation tations
16:10:50 [nicktr]
q?
16:11:43 [Ian]
vkuntz: We validated the previous SEPA draft against CGI and found only a small number of discrepancies that we addressed
16:12:08 [mweksler]
mweksler has joined #wpwg
16:13:36 [Ian]
vkuntz: CGI-MP has produced templates for ACH payments, for cross-border payments, etc.
16:14:39 [mike_mastercard]
mike_mastercard has joined #wpwg
16:15:24 [Ian]
vkuntz: For me a recurring payment is a direct debit
16:15:28 [nicktr]
q?
16:15:35 [Ian]
nicktr: I would say rather that a direct debit is a kind of recurring payment
16:16:07 [manu]
Ian: I'd like us to have sufficient understanding of credit transfer spec.
16:16:23 [Ian]
vkuntz: Who are likely implementers of the credit transfer spec
16:16:31 [Ian]
s/vkuntz/adrianhb
16:16:33 [nicktr]
nick notes that the credit transfer spec is actually called "webpayments-methods-credit-transfer-direct-debit"
16:16:53 [Ian]
cyril: Companies in europe are developing APIs to initiate credit transfer
16:17:06 [zkoch]
q+
16:17:07 [Ian]
q+
16:17:17 [Ian]
q+ to say "no" to whatever zkoch says
16:17:50 [Ian]
cyril: The timing is good to share with European companies this work since they are working on this sort of thing
16:18:32 [Ian]
adrianHB: We need to validate the payment method with Atos or Sofort or Ideal or a bank
16:18:47 [Ian]
q+ Frank
16:18:55 [Ian]
CyrilV: BPCE will consider implementing this
16:19:10 [MattS]
q+
16:19:13 [Ian]
vkuntz: 30% of payments in Belgium on the internet today are done through transfer
16:19:39 [Ian]
zkoch: Looking at the spec, does it make sense to have a generic credit transfer spec, or should there be scheme specific specs?
16:20:54 [Ian]
zkoch: I am not sure how IBAN is required in practtice
16:21:06 [Ian]
vkuntz: What is required is account number.
16:22:03 [Ian]
(Vincent shows the ACH documentation and mappings to CGI-MP)
16:22:43 [Ian]
MattS: We want to get to FPWD to get feedback from ACH and BACS and SEPA and other schemes.
16:23:09 [Ian]
...we have sense that there's commonality; need to verify this
16:23:22 [CyrilV]
q+
16:23:28 [Ian]
zkoch: We support credit transfer and want to publish this....I am happy to advocate getting feedback
16:23:32 [nicktr]
ack zkoch
16:23:49 [AdrianHB]
q+ to say that example requests per scheme may be easier than actual implementations as a start
16:23:56 [manu]
Ian: Zach had mentioned, "can you find a common data set"?
16:24:07 [AdrianHB]
ack ian:
16:24:38 [manu]
Ian: We had the word of Cyril and Vincent, but that's what led to the NACHA outreach, that's what led to Todd getting this document to us. I think FPWD would help us to raise awareness. It would also help wrt. other Credit Transfer systems.
16:24:43 [nicktr]
q?
16:24:50 [nicktr]
ack Ian
16:24:50 [Zakim]
Ian, you wanted to say "no" to whatever zkoch says
16:24:50 [manu]
Ian: We're in the early phases, filtering looks like it could be useful here.
16:25:00 [nicktr]
ack frank
16:25:01 [Ian]
ack Frank
16:25:09 [Ian]
Frank: We can help implement to validate the spec
16:25:13 [Ian]
ack M
16:25:33 [MattPi]
MattPi has joined #wpwg
16:25:40 [Ian]
MattS: Worldpay (and other aggregators) would be interested in implementing this. We will need a polyfill to experiment
16:25:48 [nicktr]
q?
16:25:50 [pierre]
pierre has joined #wpwg
16:26:04 [Ian]
vkuntz: Today people are routed to banking sites to log in
16:26:05 [mweksler]
mweksler has joined #wpwg
16:26:39 [Ian]
AdrianHB: That arose in 3DSecure...it required a redirect...do you know if the schemes have a way to get to the bank without a URL?
16:26:53 [mweksler]
q+
16:26:58 [Ian]
nicktr: Berlin group and other groups are trying to build read/write APIs....so you don't need to screen scrape web sites
16:27:25 [Ian]
adrianHB: I suggest that part of validation of this payment method involve a native payment app
16:27:32 [nicktr]
q?
16:27:47 [Ian]
ack Cyr
16:27:48 [nicktr]
ack CyrilV
16:28:32 [Ian]
CyrilV: In the spec, we may need to change the name from IBAN to "payeeBankAccount" and then include comments about what that will mean in different jurisdictions
16:28:53 [Ian]
...so yes, we may need to review the field names to make them more generic
16:29:19 [zkoch]
Random question: Do we have a known set of possible “networks” that would be in here? SEPA, ACH… are there others?
16:29:36 [zkoch]
Would we define those somewhere on w3.org like we do for card networks?
16:30:16 [Ian]
(Yes)
16:30:23 [Ian]
(We don't have the list yet. We have a set of examples in the spec)
16:30:46 [zkoch]
The bit in the appendix? ACH, SEPA, BACS, and CHAPS?
16:31:06 [Ian]
yep
16:31:14 [nicktr]
ack AdrianHB
16:31:14 [Zakim]
AdrianHB, you wanted to say that example requests per scheme may be easier than actual implementations as a start
16:31:14 [zkoch]
Cooool
16:31:18 [nicktr]
q?
16:31:18 [Ian]
AdrianHB: Please put examples in the spec for different transfer networks
16:32:50 [Ian]
vkuntz: I would be reluctant to put examples in the spec since they are changing rapidly
16:32:56 [Ian]
...but +1 to examples, but maybe inked
16:33:17 [nicktr]
ack mweksler
16:33:29 [Ian]
mweksler: Why is this about credit transfer between two entities. The merchant is more fixed.
16:33:50 [Ian]
vkuntz: That is direct debit.
16:34:14 [Ian]
CyrilV: It's hard to authorize a direct debit due to accounting challenge
16:34:43 [Ian]
...we have more credit transfers in france than card payments...lots of b2b credit transfers
16:35:28 [Ian]
vkuntz: Direct debits can be revoked up to 60 days; another reason people like credit transfers
16:35:40 [Ian]
...credit transfers are generally not revokable (except for some exceptions)
16:35:51 [nicktr]
q?
16:36:40 [MattS]
https://github.com/w3c/webpayments-methods-credit-transfer-direct-debit/issues/46
16:36:44 [Ian]
topic: Tokenized Card Payment Method Spec
16:36:58 [Ian]
https://w3c.github.io/webpayments/proposals/tokenized_cards.html
16:37:34 [Ian]
roy: the spec has changed a lot; mostly things have been deleted.
16:37:38 [Ian]
...it's now an extension of basic card
16:38:01 [MattS]
q+
16:38:04 [nicktr]
q+
16:38:05 [Ian]
...the filter is supportedTokenTypes (which takes two values)
16:38:06 [manu]
q+ to ask if EMVCo is aware and engaging on this spec?
16:38:37 [alyver]
q+
16:39:00 [Ian]
Roy: The other three fields are cardLast4, tokenType, tokenRequesterId
16:39:10 [manu]
q-
16:39:14 [Ian]
nickTR: TokenrequesterID is who the token service provider gave the token to
16:39:26 [Ian]
Roy: Spec shows some examples of inputs and outputs
16:39:44 [Ian]
ack Mat
16:39:46 [nicktr]
ack MattS
16:39:52 [AlanSamsungPay]
q+
16:39:58 [manu]
q+ to clarify what Ian said out loud, because the group should be aware of it.
16:40:13 [Ian]
MattS: The PMI is card-token....how does this spec relate to what others are doing?
16:40:20 [Ian]
Roy: This spec has no notion of merchant onbaording
16:40:25 [Ian]
s/onbaording/onboarding
16:40:35 [Ian]
MattS: So is FB PMI a specialization of this?
16:40:37 [Ian]
Roy: Yes
16:40:42 [nicktr]
q?
16:41:37 [mweksler]
q+
16:41:45 [Ian]
Roy: It's easy to adopt tihs spec
16:41:50 [Ian]
s/tihs/this
16:42:13 [Ian]
...this doesn't require other steps like merchant onboarding that involve friction
16:42:32 [Ian]
..this supports easy one-time use tokens, auth for certain amounts, ....
16:42:46 [Ian]
nicktr: I am really glad that we've got this payment method but I think there's a lot of work still to do on this
16:42:58 [pascal_bazin]
q+
16:43:04 [Ian]
...one of the concerns that I have is that it's a bit uneven. We talk about EMV tokens and issuer tokens
16:43:19 [Ian]
...but the Stripe token is a gateway token (not in scope)
16:43:29 [Ian]
...issuer tokens are effectively proxy cards...you can run those on basic card.
16:44:06 [Ian]
...merchant can't tell in that case
16:44:22 [zkoch]
q+
16:44:36 [Ian]
nicktr: There's also a mismatch between "emv" with our card network identifies (which are not emv)
16:44:56 [Ian]
...we are extending a spec that isn't bound to emvco to a domain that is
16:45:14 [Ian]
...and also the extension of the spec to use CVV for a token makes my hair stand up
16:45:28 [Ian]
...that's not where token would sit in an emv transaction
16:45:28 [Ian]
q?
16:45:36 [Ian]
ack ni
16:45:55 [Ian]
nicktr; I'm glad we have a framework to have a crack at this, but I think there's more work to do to align and make it complete
16:46:01 [manu]
q-
16:46:24 [oyiptong]
q+ define questions and where to go from this?
16:46:28 [Ian]
nicktr: Regarding EMV and this spec; this would fall within the scope of a W3C/EMV conversation
16:46:30 [kriske]
kriske has joined #wpwg
16:46:34 [oyiptong]
q?
16:46:57 [oyiptong]
q+ to define how to go forward
16:46:59 [nicktr]
q?
16:47:02 [Ian]
ack aly
16:47:41 [Manash_MC]
Manash_MC has joined #WPWG
16:47:41 [Ian]
alyver: Nick said my part....regarding terminology....for android pay....I've seen "network" and "gateway" tokens and we should perhaps use those terms
16:48:08 [Ian]
Roy: Gateway tokens not included here since inputs and outputs are so different
16:48:16 [Ian]
...each would likely be its own payment method
16:48:17 [Ian]
q?
16:48:20 [Ian]
ack Alan
16:48:57 [Ian]
AlanSamsungPay: I don't see what the goals of this spec are.
16:49:14 [Ian]
NickTR: The use case we are trying to cover is that the payments industry is pushing towards tokens....
16:49:25 [Ian]
...you can't process a tokenized card payment with basic card data alone
16:49:58 [Ian]
...you need (at least) the cryptogram
16:50:49 [Ian]
Alan: Is this in the category of dynamic tokens and dynamic CVVs
16:51:16 [MattS]
q?
16:52:11 [adamR]
+1 to Ian’s point
16:52:35 [Ian]
AdrianHB: What entity would provide a token for this spec?
16:52:38 [nicktr]
q?
16:52:39 [Ian]
q?
16:53:11 [Ian]
AdrianHB: Is the same question as for credit transfer....who would write a payment app for this and what feedback will they give us
16:53:46 [Ian]
Roy: It's feasible (can be done) that FB could create tokens
16:53:50 [Ian]
q?
16:54:05 [nicktr]
akc mweksler
16:54:14 [AdrianHB]
ack mweksler
16:54:34 [Ian]
mweksler: When I think about how this would be implemented at airbnb, I think a slightly different version could be useful - gateway
16:54:37 [Ian]
...if we had ONLY the token and not the PAN
16:54:53 [Ian]
...I'm curious what is the use case of having a token alongside a full PAN?
16:55:13 [Ian]
...second question is how this would apply to the token-only case
16:55:57 [MattS]
q+
16:56:45 [nicks]
nicks has joined #wpwg
16:57:05 [Ian]
[Discussion of likely lack of commonality among gateway token inputs]
16:57:34 [nicktr]
q?
16:57:38 [Ian]
pascal: Having at the same place a checksum and a token is considered a weakness and is forbidden by PCI/DSS. It depends on how the token is produced
16:57:39 [nicktr]
ack pascal_bazin
16:58:33 [Ian]
ack zkoch
16:58:48 [Ian]
zkoch: I think the use case you outlined is what we want...right now merchants have to establish N relationships and this is costly
16:59:14 [Ian]
....I'd like to figure out how to move this spec forward to something useful
16:59:24 [Ian]
...I think it would be useful but want industry experts to step up to help fix it
16:59:36 [Ian]
q+
16:59:56 [Ian]
nickTR: That's the motivation for this spec. Matt and I would be happy to volunteer for this!
17:00:08 [Ian]
...I'd like to hear from the other XPay vendors
17:00:09 [nicks]
q+
17:00:12 [Ian]
q-
17:00:21 [Manash_MC]
+q cloud based tokens
17:00:58 [mweksler]
mweksler has joined #wpwg
17:01:00 [nicktr]
q?
17:01:00 [Ian]
zkoch: It is helpful to have something to point to when we have internal discussions
17:01:46 [Ian]
PROPOSED: Take up Tokenized Card Payment as a work item
17:01:52 [manu]
q+ Manash to discuss cloud based tokens.
17:01:54 [Ian]
AdrianHB: I want to clarify that the scope includes gateway tokens
17:02:58 [Ian]
PROPOSED: Take up Tokenized Card Payment as a work item with gateway tokens in scope
17:03:29 [Ian]
MattS: I think a lot of discussion has jumped around....in the case of Credit Transfer we've established that there is commonality
17:04:18 [Ian]
PROPOSED: Take up Gateway tokens (and NOT issuer or network)
17:05:08 [Ian]
PROPOSED: Form a tokenized payment task force
17:05:22 [Ian]
q?
17:05:29 [Ian]
ack oy
17:05:29 [Zakim]
oyiptong, you wanted to define how to go forward
17:05:37 [MattS]
q-
17:05:57 [Ian]
oyiptong: Zach mentioned a desire to move forward. I agree. +1 to gateway token flavor and I volunteer.
17:06:09 [Ian]
...once we support tokenized cards we can make it easier for merchants to accept payments
17:06:12 [Ian]
ack ni
17:06:25 [Ian]
nickS: I'd rather this be framed in terms of networks and gateways
17:06:34 [Ian]
..it's not particularly helpful to speak to XPay.
17:06:44 [Ian]
...Apple Pay supports other types of cards than EMV cards
17:07:23 [Ian]
..a lot of wallets like to add additional security features
17:07:36 [MattS]
+1 to Nick's reframe
17:07:37 [Ian]
...I could see people using the responses with custom data
17:07:47 [Ian]
...want to see more input from networks on this spec
17:07:48 [Ian]
q?
17:07:51 [Ian]
ack Manash
17:07:51 [Zakim]
Manash, you wanted to discuss cloud based tokens.
17:08:00 [Ian]
Manash: Once MC joins the group we'd love to contribute
17:08:13 [Ian]
...tokenization is important both for XPay and browsers
17:08:27 [nicktr]
q?
17:08:31 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/03/24-wpwg-minutes.html Ian
17:09:01 [Ian]
NickTR: I hear consensus that we should do this work. The proposal is to form a tokenized payment task force. They would take the draft as input but could explore areas like different flavors of tokens
17:09:39 [betehess]
betehess has joined #wpwg
17:09:45 [Ian]
Interested in participating: NickTr, Olivier, Roy, Michel, Andre, DavidM, Ken, NickSFence
17:09:59 [Ian]
...and MattS
17:10:12 [manu]
Ian: Roy, are you going to take charge of that Task Force?
17:10:13 [Ian]
Roy is the chair of that task force
17:10:24 [manu]
+1
17:10:25 [Ian]
PROPOSED: Do that task force!
17:10:25 [rouslan]
+1
17:10:25 [oyiptong]
+1
17:10:27 [AdrianHB]
+1
17:10:27 [pascal_bazin]
+1
17:10:28 [nicktr]
+1
17:10:29 [zkoch]
+1
17:10:29 [mweksler]
+1
17:10:30 [dezell]
_1
17:10:33 [dezell]
f+1
17:10:37 [alyver]
+1
17:10:41 [dezell]
+1
17:10:44 [DavidM_GSMA]
+1
17:10:46 [fdold]
+1
17:10:47 [Ian]
RESOLVED: To create a tokenization payment method task force
17:10:48 [frank]
+1
17:10:49 [Max]
+1
17:10:54 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/03/24-wpwg-minutes.html Ian
17:11:48 [Ian]
Topic: Payment Method Manifest
17:12:04 [Ian]
Proposal => https://github.com/zkoch/zkoch.github.io/blob/master/pmi-v2.md
17:12:38 [Ian]
Max: We have a new proposal. Have not yet updated the draft spec
17:12:53 [zkoch]
Here’s my updated explainer: https://github.com/zkoch/zkoch.github.io/blob/master/pmi-v2.md
17:13:17 [Ian]
Use cases involve authorizing payment apps (especially those associated with proprietary payment methods)
17:13:44 [Ian]
...Alipay wants the browser to verify applications are in fact released by Alibaba.
17:14:12 [Ian]
Max: Second use case is for payment method owner to authorize other parties to distribute payment apps that support the payment method
17:14:39 [Ian]
Max: Third use case is for mediator to provide improved user experience by enabling run-time registration
17:14:58 [Ian]
Max: Here's how it works:
17:15:15 [Ian]
* Payment method identifier combined with HTTP Header enables browser to get the payment method manifest (JSON) file
17:15:58 [Ian]
* File includes two instructions: (1) pointer to apps from the origin that can be used (2) list of other origins that are authorized to distribute payment apps
17:16:35 [Ian]
...in our information about apps we enhance web app manifest with some digital signature information
17:17:00 [cweiss]
cweiss has joined #wpwg
17:17:13 [kriske]
q+
17:17:34 [nicktr]
q+
17:17:53 [Ian]
zkoch: Web App Manifest gets a lot of the job done, plus a couple of fields we need.
17:18:38 [Ian]
zkoch: Use case - user likes bobpay...gets a new phone....would like to be able to install bobpay on the fly...this is do-able with payment method manifest file
17:19:14 [kriske]
q-
17:19:14 [Ian]
zkoch: Use case for supported origins - most of the time in the world there is a 1:1 relation between method/payment app
17:19:32 [Ian]
...but there are cases like masterpass where there are multiple apps for a given payment method
17:19:44 [Ian]
...we need alipay or masterpass to be able to indicate trusted app distributors
17:20:06 [nicktr]
q?
17:20:24 [Ian]
zkoch: supported origins is just origins, not a URL
17:20:43 [Ian]
...we prefer a looser coupling so that origins can update their manifests independnetly
17:20:50 [Ian]
...we piggyback on the origin model.
17:21:01 [Ian]
s/independnetly/independently/
17:21:07 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/03/24-wpwg-minutes.html Ian
17:21:16 [manu]
q+ to ask if you can put multiple link headers? Can you have multiple apps in link header?
17:21:39 [Ian]
[Zach reviews three use cases (1) limit apps (2) masterpass (3) runtime installation]
17:21:50 [nicktr]
ack nicks
17:22:00 [rouslan]
q+
17:23:04 [MattPi]
MattPi has joined #wpwg
17:23:10 [Ian]
https://w3c.github.io/webpayments/proposals/Payment-Manifest-Proposal.html
17:24:00 [Ian]
ack m
17:24:00 [Zakim]
manu, you wanted to ask if you can put multiple link headers? Can you have multiple apps in link header?
17:24:01 [nicktr]
ack me
17:24:34 [Ian]
zkoch: The way you get the payment manifest file is by doing a HEAD on the payment method identifier
17:24:44 [Ian]
q?
17:25:05 [Ian]
manu: Is there a use case where you have multiple link headers?
17:25:15 [Ian]
zkoch: I think that we are asserting a 1:1 mapping between origin to manifest file
17:25:32 [nicktr]
ack rouslan
17:25:34 [Ian]
ack rou
17:26:02 [Ian]
rouslan: There are already points where we can fork supported applications (1) we can mint multiple PMIs or (2) we can add links to multiple apps in the array
17:26:17 [AdrianHB]
q+ to clarify defaults vs restrictions
17:26:23 [Ian]
rouslan: Web app manifest has an extension point....tells you where to add extra data
17:26:34 [Ian]
ack ad
17:26:34 [Zakim]
AdrianHB, you wanted to clarify defaults vs restrictions
17:26:35 [nicktr]
ack AdrianHB
17:26:56 [nicktr]
q+ to ask if we need new text in payment request spec?
17:27:21 [MattS]
q+
17:27:58 [Ian]
IJ: I want to say out loud please require an explicit way to say "none" rather than 'lack of supported_origins"
17:28:02 [nicktr]
ack nicktr
17:28:02 [Zakim]
nicktr, you wanted to ask if we need new text in payment request spec?
17:28:09 [AdrianHB]
propose to call it "allowed_origins" or similar
17:28:16 [Ian]
nicktr: Do we need new explicit language in PR API to talk about the behavior of the mediator
17:29:08 [nicktr]
ack MattS
17:29:13 [Ian]
IJ: There MAY be a dependency of PR API on this ... or at least we want to make clear that this can affect matching
17:29:39 [Ian]
mattS: Are there performance issues?
17:29:53 [Ian]
rouslan: Maybe for more than 10000
17:30:02 [Ian]
...maybe useful to have a server-side solution in some cases
17:30:07 [Ian]
...but there are also limitations there
17:32:24 [Ian]
(IJ adds https://github.com/w3c/browser-payment-api/issues/478 regarding relationship between manifest and matching in PR API )
17:32:44 [Ian]
zkoch: I think caching plays a role in implementation
17:33:26 [nicktr]
q?
17:34:41 [Ian]
NickTR: Should PMM be in PMI?
17:34:49 [Ian]
Ian: I prefer not since PMI mature; let's get that to CR
17:35:00 [Ian]
zkoch: Agree that PMM should be separate
17:35:06 [Ian]
PROPOSED: Take up payment method manifest as a work item
17:35:19 [manu]
+1
17:35:35 [Ian]
zkoch: Do people feel this is a good idea?
17:35:59 [Ian]
zkoch: We need this to do third party payment apps; Alipay needs it too
17:36:12 [Ian]
...I would like to do this in a way that plays nicely with Payment Handler
17:36:28 [betehess]
betehess has joined #wpwg
17:36:43 [AdrianHB]
+1
17:36:46 [rouslan]
q+
17:36:47 [Ian]
zkoch: Does group think this seems reasonable?
17:36:53 [Ian]
nickTR: Anyone see this as a bad idea?
17:36:55 [rouslan]
q-
17:36:55 [Ian]
(NO hands)
17:37:06 [Ian]
PROPOSED: Take up payment method manifest as a work item
17:37:15 [AdrianHB]
+1
17:37:15 [Ian]
...and Zach and Max would be editors
17:37:16 [nicktr]
+1
17:37:16 [Ian]
+1
17:37:16 [rouslan]
+1
17:37:20 [alyver]
+1
17:37:21 [Max]
+1
17:37:22 [manu]
+1
17:37:23 [DavidM_GSMA]
+1
17:37:25 [pascal_bazin]
+1
17:37:26 [fdold]
+1
17:37:26 [dezell]
+1
17:37:29 [jean-yves]
+1
17:37:36 [mweksler]
mweksler has joined #wpwg
17:37:41 [Ian]
zkoch: +1
17:37:43 [mweksler]
+1
17:37:44 [Roy]
Roy has joined #wpwg
17:37:45 [Roy]
+1
17:37:49 [Ian]
RESOLVED: To take up payment method manifest as a work item
17:37:50 [Tommy]
+1
17:37:54 [Ian]
LUNCH
17:37:59 [Ian]
RRSAgent, make minutes
17:37:59 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/03/24-wpwg-minutes.html Ian
17:38:41 [CyrilV]
q?
17:41:08 [marcosc]
marcosc has joined #wpwg
17:50:41 [nicks]
nicks has joined #wpwg
18:00:17 [cweiss]
cweiss has joined #wpwg
18:00:45 [Tommy]
Tommy has joined #wpwg
18:25:01 [Max]
Max has joined #WPWG
18:29:50 [marcosc]
marcosc has joined #wpwg
18:32:02 [marcosc]
marcosc has joined #wpwg
18:32:15 [alyver]
alyver has joined #wpwg
18:32:39 [alyver]
alyver has joined #wpwg
18:32:47 [marcosc]
marcosc has joined #wpwg
18:33:18 [alyver]
alyver has joined #wpwg
18:35:22 [marcosc]
marcosc has joined #wpwg
18:36:31 [alyver]
alyver has joined #wpwg
18:37:01 [mweksler]
mweksler has joined #wpwg
18:37:05 [AdrianHB]
AdrianHB has joined #wpwg
18:43:42 [pierre]
pierre has joined #wpwg
18:44:26 [manu]
scribe: manu
18:44:27 [Ian]
RRSAgent, make minutes
18:44:27 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/03/24-wpwg-minutes.html Ian
18:44:31 [CyrilV]
present+
18:44:41 [manu]
Topic: W3C Process of Moving Specs Forward
18:44:57 [manu]
Ian: Getting to CR...
18:45:13 [MattPi]
MattPi has joined #wpwg
18:45:56 [nicktr]
zakim, who is here?
18:45:56 [Zakim]
Present: Ian, schuki, Katie_Haritos-Shea, michel_cc, nicktr, mweksler, AdrianHb, m_and_m, rouslan, manu, zkoch, alyver, marcosc, nicks, pierre, jean-yves, CyrilV, Li_lin, adamR,
18:46:01 [Zakim]
... manash, vkuntz, dezell, mathp, mike_mastercard, Max, Frank
18:46:01 [Zakim]
On IRC I see MattPi, pierre, AdrianHB, mweksler, alyver, marcosc, Max, Tommy, Roy, CyrilV, ken, AlanSamsungPay, adamR, pascal_bazin, dezell, rouslan, Li_lin, m_and_m, Zakim,
18:46:01 [Zakim]
... RRSAgent, Ryladog, pea13, canton_, MikeSmith, DavidM_GSMA, hober, schuki, dlehn, trackbot, dlongley, Ian, manu, mkwst, ShaneM, slightlyoff, nicktr, adrianba, oyiptong, JakeA,
18:46:03 [Zakim]
... emschwartz, Dongwoo, davidillsley_
18:46:03 [manu]
Ian: Good to understand what the process requires for CR... CR means "Candidate Recommendation", which means - we're ready to implement.
18:46:29 [manu]
Ian: But first, getting to CR.... administrative things, we make a decision - it's a "call for consensus" - Chairs assess consensus, it's our guide for talking w/ the Director.
18:46:44 [zkoch]
zkoch has joined #wpwg
18:46:48 [manu]
Ian: We need documentation on substantive changes, we'll point to Github repo for that.
18:47:45 [manu]
Ian: We have 3 issues lists, we are going to postpone issues, closed all other issues... That's the role of the issues list.
18:47:59 [manu]
Ian: Are there any formal objections on the work? Not aware of any.
18:48:45 [manu]
Ian: Even though we don't have provably interoperable implementations yet, we should show them the demos for PaymentRequest API.
18:48:57 [manu]
Ian: For CR specifically, have you met WG requirements, have there been changes to dependencies?
18:49:20 [jean-yves]
jean-yves has joined #wpwg
18:49:29 [jean-yves]
present+ Jean-Yves
18:49:41 [AdrianHB]
q?
18:50:00 [manu]
Ian: How long will CR last - during that time, you receive comments on the spec... those comments will typically be from outside of the group.
18:50:09 [manu]
Marcos: We have to keep a list of that... disposition of comments.
18:50:13 [AdrianHB]
q+ to ask if test suite is sufficient "implementation" experience?
18:50:35 [manu]
Ian: Before you go to CR, we need wide review... pretty good footing, but least good footing.
18:51:16 [manu]
Ian: I sent out note to groups for review... have met with Privacy Interest Group... we're on the W3C Technical Architecture Group of groups list...
18:52:04 [manu]
Ian: We go on Github issues list, and get feedback... Baron and Leithead participated. TAG did a review... archived.
18:53:03 [manu]
Ian: a11y folks provided feedback, we want more formal eval from EMV, PCI, implementation from parties not in the room.
18:53:34 [manu]
Ian: I think we're okay there, but external review would be helpful.
18:53:56 [manu]
Ian: CR enables this ability to say features at risk, if we don't get two interop implementations, we'll drop them.
18:55:17 [manu]
Ian: Are there features at risk. Default expectation for leaving CR is two implementations. We may want to say more.
18:55:26 [nicks]
nicks has joined #wpwg
18:55:42 [manu]
Ian: progress on payment apps, add requestID, test suite progress...
18:56:06 [manu]
Ian: Do we need to invest more in testing to get our of CR, do we do that?
18:56:34 [manu]
nicktr: CR provides IP exclusion opportunity.
18:57:01 [manu]
Ian: There is a new window for exclusions that is 60 days long, covers differences between FPWD and CR.
18:57:19 [manu]
Ian: Visa leveraged exclusion, managed it, nothing to see here, but window opens up for 60 days at CR.
18:57:51 [manu]
nicktr: Orgs need to figure out how to deal w/ IP issues and CR.
18:57:51 [AdrianHB]
q?
18:58:42 [manu]
q+ to request web-based payment app implementations against Payment Request and note CR length.
18:58:59 [nicktr]
q?
18:59:03 [manu]
nicktr: How quickly do we want to go through CR?
18:59:35 [AdrianHB]
ack me
18:59:35 [Zakim]
AdrianHB, you wanted to ask if test suite is sufficient "implementation" experience?
18:59:37 [manu]
Marcos: We would like to be a part of CR testing... we'd like to wait even longer if we could get more.
18:59:58 [manu]
AdrianHB: You listed test suite as implementation experience, test suite isn't implementation expereince.
19:00:22 [manu]
Ian: Test suite shows implementation report...
19:00:28 [manu]
AdrianHB: What about coverage?
19:00:46 [manu]
Ian: The default is that we cover features in spec.
19:01:08 [nicktr]
manu: are we at the point where we talk about expectations to come out of CR?
19:01:17 [manu]
q-
19:02:43 [manu]
Ian: Just getting list of items that we need to talk about done.
19:03:01 [manu]
AdrianHB: Can you do normative but optional.
19:03:07 [manu]
Marcos: We don't have any of those.
19:03:14 [dezell]
q?
19:03:20 [dezell]
q+
19:03:50 [manu]
AdrianHB: People have feature detection, payment handler is an example, this is how we want wallet to work, possibly.
19:04:01 [manu]
Ian: You should have implementation experience about it.
19:04:16 [AdrianHB]
q?
19:04:26 [manu]
AdamR: We could split spec out.
19:04:32 [manu]
dezell: Are there no features at risk?
19:04:34 [mweksler]
mweksler has joined #wpwg
19:05:19 [manu]
dezell: Things like the wallet could be a feature at risk... if you have things that you think might be optional, it's a good idea to make them features at risk.
19:05:23 [manu]
Ian: Expectation is basic card is a note
19:05:40 [manu]
Ian: So, we don't need to do anything w/ that...
19:05:47 [vkuntz]
vkuntz has joined #wpwg
19:05:48 [manu]
AdrianHB: It's a note, do we write tests for it?
19:05:50 [vkuntz]
present+
19:06:08 [manu]
Marcos: We may want to make it a spec
19:06:17 [manu]
nicktr: We may not want to do that conversation now.
19:06:27 [manu]
Ian: Features at risk
19:06:28 [manu]
zkoch: Currency systems
19:06:45 [manu]
Ian: For currency, keywords that are not in the ISO standard, we said "What about BTC? ETH?"
19:07:12 [marcosc]
+q
19:07:23 [manu]
Ian: We said we would use ISO standard, so you can use those, but you can support other repo, and pair is sufficient for non-standard token. I don't know if we have experience with a token in that repo.
19:07:32 [manu]
ack dezell
19:07:32 [nicktr]
ack dezell
19:07:35 [manu]
ack marcosc
19:07:49 [manu]
marcos: We need implementation experience to understand it better.
19:07:52 [Roy]
q+
19:08:18 [manu]
Roy: The billing address concept seems problematic...
19:08:26 [manu]
Ian: That feature isn't in... isn't a feature at risk.
19:08:28 [frank]
frank has joined #wpwg
19:08:38 [Molly]
Molly has joined #wpwg
19:09:09 [manu]
Ian: If we're in CR for a year, we can find the best process route to getting there...
19:09:17 [manu]
Ian: Any objections to marking that as feature at risk?
19:09:19 [manu]
None
19:09:23 [manu]
Ian: Are there any others?
19:09:32 [manu]
zkoch: That's the only one I can think of...
19:09:53 [manu]
Marcos: It'll be marked in the spec as feature at risk...
19:10:08 [manu]
AdrianHB: If it's marked as at risk - provides additional incentive to show that it's useful.
19:10:22 [AdrianHB]
q?
19:10:24 [manu]
Ian: Exit Criteria
19:10:26 [AdrianHB]
ACK ROY
19:10:56 [MattS]
MattS has joined #wpwg
19:11:03 [manu]
nicktr: We had a conversation about payment app, and in terms of ordering, can we take PH to FPWD first.
19:11:17 [manu]
nicktr: We need to examine if we want to put exit criteria to CR to PR on maturity of Web App piece.
19:11:43 [pierre]
pierre has joined #wpwg
19:11:48 [manu]
AdrianHB: We want implementations on mobile and desktop?
19:11:58 [manu]
AdrianHB: I think we need two implementations on both.
19:12:01 [manu]
zkoch: No
19:12:35 [manu]
Ian: We have implementations on mobile, some on desktop...
19:13:24 [manu]
mattP: We have implementations on both mobile/desktop - it'll be there, Windows works on both.
19:15:21 [manu]
Marcos: Who wants to tie implementations together Payment Handlers and Payment Request?
19:15:26 [manu]
AdamR: Yes, me.
19:15:48 [manu]
marcos: Different DNA in implementations is good.
19:16:04 [manu]
nicktr: Any other exit criteria
19:16:07 [nicktr]
q?
19:16:27 [manu]
Rouslan: Two implementations, one from Samsung/Chrome - not same rendering engine... browser process is different.
19:17:07 [manu]
Ian: Two things - do we have confidence in Web App manifest in some way, then what to say about mobile vs. desktop.
19:18:51 [manu]
Ian: Two of each, any strong objections?
19:19:21 [manu]
A few objections noted ... unclear whther they're strong.
19:20:03 [manu]
Adam: Is there criteria for the assertion of leaving... test suite?
19:20:10 [manu]
Ian: Usually, showing green through the report.
19:20:41 [manu]
AdrianHB: We're saying what we hope to achieve...
19:20:56 [zkoch]
q+
19:21:03 [manu]
s/Adam: Is/AdamR: Is/
19:21:11 [mathp]
mathp has joined #wpwg
19:21:17 [manu]
s/AdamR: Is/Alan: Is/
19:21:41 [manu]
zkoch: Everyone has minimal time, priorities, etc... that doesn't reflect nature of the world... traditional is two implementations, that seems sufficient.
19:22:14 [manu]
AdrianHB: Mobile vs. desktop... implementations differ between desktop and mobile.
19:22:30 [manu]
Marcos: We turn off UI... that's what we're testing.
19:22:47 [adamR]
q+
19:22:56 [nicktr]
ack zkoch
19:23:35 [manu]
ack adamR
19:23:52 [betehess]
betehess has joined #wpwg
19:24:06 [manu]
adamR: I've heard issues raised pertaining to user experience to justify design experience... that makes it valid to say we need to have multiple renderings of this, multiple form factors before we consider this done.
19:25:11 [manu]
adamR: We don't want to get into a position of where we don't have experience before exiting.
19:25:20 [manu]
q+ to ask if we don't already have two different implementations.
19:25:34 [ken]
q+
19:25:39 [manu]
MattP: It's the same code base for us... if we pass test criteria, it's not going to matter...
19:26:12 [AdrianHB]
q?
19:26:33 [AdrianHB]
manu: I thiught we already had 2 impl on both desktop and mobile
19:27:31 [AdrianHB]
Are we saying 4 different companies with 2 diff form factors?
19:29:30 [Roy]
q+
19:29:58 [DavidM_GSMA]
q+
19:30:12 [manu]
ack manu
19:30:12 [Zakim]
manu, you wanted to ask if we don't already have two different implementations.
19:30:25 [Roy]
q-
19:30:50 [manu]
ack Ken
19:31:43 [manu]
Ken: From an Amex point of view - we'd be advocates that mobile and desktop are done... device doesn't always provide distinction between mobile/desktop... desktop transactions and purchasing behavior, hae legs... product development perspective would be good.
19:32:06 [manu]
q+ to ask AdrianHB which implementations he thinks we have on mobile AND desktop...
19:32:16 [manu]
ack DavidM_GSMA
19:32:24 [AdrianHB]
q+ to say that implementation experience can't just be technical compatibility with spec as it is today
19:33:06 [manu]
David: I understand where AdrianHB is coming from, proven product that works... two different code bases, solution is the same... if you are implementing on desktop, implement it on mobile.
19:33:20 [nicktr]
ack AdrianHB
19:33:20 [Zakim]
AdrianHB, you wanted to say that implementation experience can't just be technical compatibility with spec as it is today
19:34:16 [nicktr]
q?
19:34:23 [nicktr]
ack manu
19:34:23 [Zakim]
manu, you wanted to ask AdrianHB which implementations he thinks we have on mobile AND desktop...
19:34:26 [dezell]
q+
19:34:30 [mweksler]
q+
19:34:51 [adamR]
q+
19:35:11 [manu]
AdrianHB: If we limit ourselves to do implementations are one for mobile and one for desktop, we may not have it complete.
19:35:24 [manu]
Marcos: It has to interoperate... it doesn't happen in vacuum.
19:35:46 [dezell]
q-
19:35:50 [alyver]
alyver has joined #wpwg
19:36:01 [manu]
AdrianHB: We need to have two implementations so there is discussion around things that are happening.
19:36:03 [manu]
ack mweksler
19:36:27 [manu]
mweksler: Another perspective, tension I sense is between how much we want to constrain the exit criteria, trusting our future selves for exit critiera....
19:37:17 [manu]
mweksler: The counter proposal seems to be a bit more strict.... I like the proposal with more wiggle room.
19:37:56 [manu]
AdrianHB: As with everything, when we leave wiggle room, why bother... if committment is when we get there.
19:38:01 [manu]
zkoch: Let's just do 2 and 2.
19:38:04 [adamR]
q-
19:38:23 [manu]
PROPOSAL: Two implementations from two different vendors on both mobile and desktop.
19:38:30 [adamR]
With that proposal, I see no reason to push my point. If the proposal changes, I’ll want to requeue
19:38:58 [manu]
That proposal carries based on number of hands raised.
19:39:03 [manu]
rrsagent, make minutes
19:39:03 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/03/24-wpwg-minutes.html manu
19:39:26 [manu]
Ian: What's the goal of Web-based Payment Apps exit criteria?
19:39:41 [manu]
nicktr: We're trying to protect that charter requirement...
19:39:55 [nicks]
q+
19:41:13 [betehess]
betehess has joined #wpwg
19:41:36 [manu]
nicktr: Do we want to take Payment Handler to FPWD?
19:42:31 [manu]
nicks: I would have to discuss w/ my WebKit colleagues ... we may object to that.
19:42:36 [Roy]
q+
19:42:42 [AdrianHB]
ack nicks
19:45:35 [AdrianHB]
ack roy
19:45:42 [manu]
Ian: I'm not hearing objections for Payment Handler , but let's not go here...
19:46:12 [zkoch]
q+
19:46:27 [manu]
Roy: I disagree that there is no dependency between PR and PH APIs... there is a lot of useless stuff if we don't have web-based payment apps... so, I think we've failed if we never get web-based payment handlers implemented.
19:46:30 [adamR]
q+
19:46:38 [manu]
zkoch: We'd love to see a 3rd party ecosystem...
19:46:43 [nicktr]
ack zkoch
19:47:16 [manu]
zkoch: Mozilla is in favor... we don't want to create dependencies on one or the other... let's get payment request out there, move it forward... happy to support PaymentHandler, let's thing abou tthem separately.
19:47:25 [manu]
zkoch: I support 3rd party, separate and move foward...
19:48:16 [AdrianHB]
q+
19:48:20 [manu]
adamR: I wanted to agree mostly with Roy... I think we failed to get a good 3rd party ecosystem out there... the right answer may bear on PR API.... how do we expres sfilter/matching criteria, it bears on PR... there are real dependencies here. We may need to change it. I agree with Nick, we need some kind of interlock so we don't need to change it.
19:48:21 [AdrianHB]
ack adamr
19:48:22 [nicktr]
ack adamR
19:48:56 [manu]
Ian: As a WG we don't expect one REC before the other... we have all implementation we need before we do REC... they're both important.
19:49:34 [manu]
AdrianHB: Part fo the motiviation for multiple implementnations on both form factors, PR may change when we implement 3rd party apps.
19:49:51 [manu]
AdrianHB: If we have existence of decent number of Payment Apps, maybe we can tie CR to that.
19:50:07 [manu]
q+ to support what AdrianHB is saying.... exit criteria more about implementation xperience.
19:50:14 [nicktr]
ack AdrianHB
19:50:20 [nicktr]
ack manu
19:50:20 [Zakim]
manu, you wanted to support what AdrianHB is saying.... exit criteria more about implementation xperience.
19:51:35 [Roy]
+1, I assumed spec process was a good proxy for third-party implementations existing, but the latter is the goal
19:52:59 [AdrianHB]
q?
19:53:42 [nicks]
q+
19:53:49 [nicktr]
ack nicks
19:53:51 [manu]
AdrianHB: if we combine it with multiple implementations on mobile - web-based as well, would prefer... hard requirement for Web Handler spec.
19:54:30 [nicktr]
q?
19:54:55 [manu]
nicks: I disagree, don't see PR to have exit criteria on apps... we don't need that.
19:55:02 [Roy]
q+
19:55:02 [MattPi]
q+
19:55:07 [manu]
Marcos: We don't need that dependency.
19:55:34 [manu]
AdrianHB: That would be a bad spec.
19:55:54 [nicktr]
ack Roy
19:56:03 [manu]
Roy: I think the problem is not that AndroidPay is good or not. it's that they're tied to a specific form of payment request.
19:56:48 [manu]
nicks: To be clear, that is not technically true... webkit is open source, you can see that.
19:56:56 [manu]
Rouslan: Firefox could support android pay tonight.
19:57:19 [manu]
zkoch: You shouldn't confuse business policy decisions with implementation decisions...
19:57:27 [nicktr]
ack MattPi
19:57:33 [rouslan]
q+
19:57:42 [nicktr]
q+ to note goals of charter
19:58:19 [manu]
MattP: It's an interesting conversation, as a group, we said payment methods and support... support of 3rd party payment apps... multiple demonstration of 3rd party payment apps, that original intent is there. Sad irony is that we're not pushing to CR.
19:58:25 [nicktr]
q?
19:59:02 [nicktr]
ack rouslan
19:59:06 [manu]
zkoch: What's limiting ability to do it is not technology, it's business.
19:59:30 [AdrianHB]
q?
20:00:00 [manu]
Rouslan: Alipay has exposed android intents in a way that's interoperable with any application out there... need to have an agreement with whoever calls them... calls into Alipay... they are a 3rd party payment app. Anyone could call into Alipay, get Alipay in their browser... Alipay needs to knonw where money is going.
20:00:09 [manu]
q+ to note Web apps and why we want them.
20:00:26 [nicks]
q+
20:00:30 [manu]
nicktr: I'm finding it difficult how this helps us meet demands of our charter.
20:01:19 [manu]
nicktr: First deliverable is registering digital payment instrument... I can't see how we can object tieing these things together... maybe right time to tie them together is not CR or PR, want to deliver what we're chartered to do rather than limited subset.
20:01:20 [manu]
q-
20:01:30 [AdrianHB]
ack nicktr
20:01:30 [Zakim]
nicktr, you wanted to note goals of charter
20:01:42 [AdrianHB]
ack nicks
20:01:42 [alyver]
alyver has left #wpwg
20:01:51 [manu]
nicks: Charter doesn't specify the order of delivery
20:01:51 [nicktr]
q?
20:02:26 [betehess]
betehess has joined #wpwg
20:02:49 [manu]
nicks: What's in the charter that says spec A and spec B should be tie together
20:03:18 [manu]
nicks: We don't have service worker, this makes this a much taller ask.
20:03:30 [AdrianHB]
q+
20:03:36 [rouslan]
q+
20:03:49 [manu]
adamR: There are dependencies, technical dependencies.
20:04:09 [nicktr]
q?
20:04:40 [manu]
nicks: What's in the charter that stops this from happening?
20:05:14 [Roy]
q+
20:05:19 [manu]
AdamR: We may shoot ourselves in the foot if we do that. where we keep changing things.
20:06:07 [michel_cc]
michel_cc has joined #wpwg
20:07:03 [manu]
AdrianHB: There is not a dependency between the specs, ther eis a dependency on PR on supporting payment apps... that's the technical dependency.
20:07:11 [MattS]
?
20:07:19 [MattS]
q?
20:07:25 [nicktr]
ack AdrianHB
20:07:36 [manu]
... some concept of apps. If Safari supported apps, that would probably be sufficient to say that PR is fully implemented in Safari.
20:08:18 [manu]
... while I appreciate the concern that Nick raised, that there are risks here, Zach and Rouslan make a good point, business relationshpis that we can't influence directly... design specs that don't prejudice people. Lot's that are left up to impelemntations.
20:08:36 [MattS]
q+
20:08:56 [manu]
Rouslan: I thought we made a decision to implement PR PH, for sequential delivery of both implementations. this decoupling ended up making specs orthogonal.
20:09:17 [manu]
Rouslan: We don't have payment apps? No, we do - it's hard to integrate... kinda... intents makes it easier.
20:09:22 [Ian]
q+ to make a proposal
20:09:25 [nicktr]
ack rouslan
20:09:30 [nicktr]
ack Roy
20:09:34 [rouslan]
q+
20:09:55 [nicktr]
q?
20:10:07 [manu]
roy: Why do we care about this?
20:10:12 [manu]
marcos: IP committments...
20:10:31 [rouslan]
q-
20:10:43 [manu]
AdrianHB: To implement PR, you have to get PH forward, and Apple can't implement.
20:11:54 [manu]
nicks: We want to lock this down, multiple reasons, you end up adding something that implementers can't achieve... we did separate these two specs out, we should have put them together.
20:12:06 [manu]
MattS: When we separated them, we wanted to progress them at a different pace...
20:12:24 [manu]
ack MattS
20:12:26 [manu]
ack Ian
20:12:26 [Zakim]
Ian, you wanted to make a proposal
20:13:04 [manu]
Ian: I think we should set an expectation but not a hard requirement... for CfC to PR, those that don't see enough implementations, they can object.
20:13:36 [manu]
Ian: We go ahead and get implementation experience, but still a mechanism for weighing in at that time, with no surprises.
20:14:06 [manu]
AdrianHB: In the status of the document, we expect to show implementations of payment apps to demonstrate implementability of this API.
20:14:45 [Ian]
PROPOSED: Set expectation at CR of imlementation experience of payment apps (native and/or web based) to demonstrate stability and usefulness of PR API.
20:14:56 [Ian]
(Noting that people can object when the CfC happens to go to PR)
20:15:02 [zkoch]
+1
20:15:03 [AdrianHB]
+1
20:15:04 [rouslan]
+1
20:15:10 [kriske]
kriske has joined #wpwg
20:15:13 [mathp]
+1
20:15:15 [DavidM_GSMA]
+1
20:15:17 [manu]
+1
20:15:50 [Roy]
-1, want more aggressiveness
20:16:20 [mweksler]
+1
20:17:21 [Ian]
SO RESOLVED
20:17:51 [manu]
Ian: I'd like to hear from editors first wrt. what needs to happen before CfC.
20:17:56 [manu]
Marcos: We have a list on Github
20:18:14 [manu]
rrsagent, draft minutes
20:18:14 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/03/24-wpwg-minutes.html manu
20:18:16 [marcosc]
https://github.com/w3c/browser-payment-api/milestone/8
20:18:48 [manu]
scribe: zkoch
20:19:02 [zkoch]
nicktr: I see 7 open issues [goes through the issues]
20:19:27 [zkoch]
MattS: Also some outstanding pull requests
20:19:37 [zkoch]
Ian: Also some things that have been noted (e.g. editorial stuff, other questions)
20:19:49 [zkoch]
Marcos: We should issue them ASAP and assign people to work on them
20:19:53 [zkoch]
Ian: Happy to help
20:20:08 [zkoch]
Marcos: Over next year we can fix editorial, but we have to identify critical. We have 7 there. Are there others?
20:20:09 [marcosc]
https://github.com/w3c/browser-payment-api/issues
20:20:29 [AlanSamsungPay]
q+
20:20:37 [zkoch]
Ian: 478. Given that we know we’re going to do method manifest, we should at least look at
20:20:50 [Ian]
please include https://github.com/w3c/browser-payment-api/issues/478
20:21:03 [nicktr]
q?
20:21:41 [zkoch]
Alan: Would like clarity on one issue: the requirements in the spec that dictate or guide the user agents on how they will display the payment apps
20:21:47 [zkoch]
… what is the current spec on that
20:21:53 [zkoch]
… im unsure of where that is
20:22:08 [zkoch]
nicktr: [reads from spec text on appropriate section]
20:22:26 [zkoch]
nictr: item 8 in section 3.3 show
20:22:37 [zkoch]
s/nictr/nicktr
20:22:51 [nicktr]
q?
20:22:53 [zkoch]
[group silence]
20:22:58 [nicktr]
ack AlanSamsungPay
20:23:09 [zkoch]
Ian: I thought you were going to point to 10 of 3.3
20:23:32 [Ian]
"The user agent MAY show payment methods in the order given by supportedMethods, but SHOULD prioritize the preference of the user when presenting payment methods and applications. "
20:23:33 [zkoch]
Alan: I’m in the right section now, thanks!
20:23:49 [nicktr]
q?
20:24:17 [zkoch]
nicktr: Any issues that anybody things need fixing before CfC should be marked as such. 2 week timeframe. Give editors 2 weeks to respond
20:24:35 [zkoch]
Ian: Some minor concerns about 100 new issues.
20:24:59 [molly]
molly has joined #wpwg
20:25:26 [zkoch]
Ian: There is a balance between existing implementations and stuff. We should note spec has been in development for a year. So people should act in good faith. Do homework. See if issues have been raised and resolved.
20:25:44 [MattS]
q+
20:25:55 [zkoch]
AdrianHB: Amendment. IF you want to raise issues, tag with milestone, editors may say no. Chairs can make call if disagreement
20:26:09 [zkoch]
MattS: Not everyone has ability to add milestone label
20:26:16 [nicktr]
ack MattS
20:26:18 [zkoch]
AdrianHB: Raise issues and ask for CR rec
20:26:29 [zkoch]
… if disagreement, chairs can make a call
20:26:55 [zkoch]
Ian: What is the statement about when?
20:27:05 [zkoch]
Nicktr: 2 and 2, but open to challenges. In light of IETF, 1 week to raise issues too small
20:27:12 [zkoch]
Ian: Have issues in by Apr 7
20:27:19 [Ian]
NickTR: Please raise your issues by 6 April WPWG teleconf
20:27:28 [zkoch]
… correction, April 6th call we will review
20:27:36 [Ian]
...and we will agree on that call what issues are on the list
20:28:16 [zkoch]
Ian: Summarizing, 1 at risk feature, things in status section about exit criteria (one expectation, one # of implementations)
20:28:30 [MattS]
q+
20:28:34 [MattS]
q?
20:28:40 [zkoch]
… didn’t say how much time. Why don’t we say on 6 Apr as other piece of discussion editors or implementors can have opinion on CR expectation
20:28:52 [zkoch]
… todo list is essentially the issues list
20:29:13 [zkoch]
… other reviews. may hear back from TAG. privacy review. can fix those comments into the 2 week window
20:29:31 [zkoch]
nicktr: lampshade where we are, feels like there is expectation that we are moving towards CfC
20:29:38 [zkoch]
… sounds like that will happen ~4 weeks from now
20:29:51 [zkoch]
AdrianHB: Would be good to know if others will object
20:30:04 [Ian]
scribe: Ian
20:30:10 [nicktr]
ack MattS
20:30:36 [Ian]
matts: Thank you for the summary. Are we taking about PR API only?
20:30:47 [Ian]
Topic: PMI SPec
20:31:09 [Ian]
Features at risk?
20:31:15 [Ian]
AdrianHB: What about short strings?
20:31:18 [Ian]
Marcos: Probably too late
20:32:39 [Ian]
IJ: Features at risk is about implementation, not features we don't like. We already have implementation of short strings
20:33:48 [Ian]
Features at risk? [None]
20:34:28 [Ian]
TIme: Aligned with PR API
20:35:07 [Ian]
AdrianHB: Regarding payment method manifests, I think PMI depends on it
20:37:09 [Ian]
RESOLVED: For PMI to exit CR, need at least FPWD of payment method manifest spec
20:37:32 [Ian]
AdrianHB: What is an implementation of PMI?
20:37:39 [Ian]
Marcos: There is an algorithm for URL matching
20:38:09 [Ian]
...should just be parsing and matching
20:38:45 [Ian]
....implementation expectation is 2 interoperable
20:39:20 [Ian]
....6 April todo list
20:39:47 [Ian]
Marcos: I need to check the spec...and am comfortable by 6 April doing so
20:39:52 [nicktr]
q?
20:40:08 [AdrianHB]
https://github.com/w3c/webpayments-method-identifiers/issues/
20:40:49 [Ian]
[Basic Card]
20:41:14 [MattS]
q+
20:42:01 [Ian]
[Note or Rec?]
20:42:24 [Ian]
IJ: note that if we change the expectation about going to Rec, we trigger IPR things
20:43:02 [zkoch]
zkoch has joined #wpwg
20:43:13 [Ian]
[Payment Handler API]
20:44:10 [manu]
Ian: Who would object for Payment Handler going to FPWD?
20:44:19 [manu]
Marcos: We have to look carefully for what's going out there.
20:44:21 [MattS]
q+
20:44:23 [zkoch]
q+
20:44:29 [Ian]
IJ: Any objections to going to FPWD?
20:44:30 [MattPi]
q+
20:44:35 [Ian]
Marcos: My concern is going out "too soon"
20:44:41 [Ian]
Marcos...we can help with big warnings
20:45:24 [MattS]
q-
20:46:17 [manu]
No objections for going to CfC for FPWD for Payment Handler API
20:46:17 [AdrianHB]
no objections to taking Payment Handlers API to FPWD
20:46:26 [nicktr]
ack zkoch
20:46:36 [Ian]
ack Matt
20:46:54 [Ian]
MattPi: When we went to FPWD for PR API we had implementers. who are the implementers in this case?
20:47:04 [Ian]
Rouslan: Google is one implementer
20:47:25 [Ian]
MattPi: Do we have app decelopers?
20:47:32 [Ian]
Mozilla
20:47:36 [Ian]
Worldpay
20:47:36 [Ian]
Ripple
20:47:38 [Ian]
Gemalto
20:48:15 [manu]
Digital Bazaar as well
20:48:19 [Ian]
Facebook
20:48:29 [Ian]
Klarna
20:49:28 [manu]
Ian: When CfC comes up, you can say +0 or +1....
20:49:32 [Ian]
q?
20:49:50 [Ian]
---
20:49:51 [Ian]
* wallet granularity: none or some but not required to display
20:49:51 [Ian]
* payment app instrument ordering (and relation to payment method order)
20:49:51 [Ian]
* event.OpenWindow()
20:50:11 [Ian]
https://github.com/w3c/webpayments-payment-apps-api/issues
20:51:58 [frank]
q+
20:52:03 [Ian]
NOTED: Nobody asked that these be RESOLVED before going to FPWD.
20:52:37 [Ian]
Frank: Please add the issue about payment apps getting customer data; I'll add to the issues list
20:52:43 [nicktr]
ack frank
20:52:54 [rouslan]
q+
20:52:54 [Ian]
Ian: We will ensure that these four issues are called out in the spec and perhaps general shape as well
20:53:06 [Ian]
ack rouslan
20:53:18 [Ian]
rouslan: None of the issues have an impact on PR API.
20:53:25 [MattS]
q+
20:53:40 [Ian]
Marcos: Please also get rid of respec warnings
20:53:42 [Ian]
Ian: +1
20:53:52 [Ian]
Marcos: We also need a stricter review process
20:54:26 [Ian]
Marcos: Please also rename the repo to reflect new spec name
20:54:29 [MattS]
q-
20:54:34 [nicktr]
q?
20:55:11 [Ian]
NickTR: Time scale?
20:55:22 [Ian]
Manu: Can we do it after PR API?
20:56:01 [Ian]
MattS: Would rather see them all the same time
20:56:53 [Ian]
(Maybe sooner than PR API?)
20:57:47 [Ian]
[Tokenization]
20:58:05 [Ian]
ACTION: Ian to work with Roy to set up a repo for future tokenization spec(s)
20:58:05 [trackbot]
'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., IFSF-EFT-WG-Lead, ijacobs, ijmad).
20:58:14 [Ian]
[Credit Transfer]
20:58:23 [Ian]
Adrian: I think the task force is going to look for implementations
20:58:42 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/03/24-wpwg-minutes.html Ian
20:59:23 [mweksler]
mweksler has joined #wpwg
21:00:09 [mweksler]
mweksler has joined #wpwg
21:00:57 [mweksler]
mweksler has joined #wpwg
21:01:46 [mweksler]
mweksler has joined #wpwg
21:02:33 [mweksler]
mweksler has joined #wpwg
21:03:21 [mweksler]
mweksler has joined #wpwg
21:04:10 [mweksler]
mweksler has joined #wpwg
21:04:57 [mweksler]
mweksler has joined #wpwg
21:05:45 [mweksler]
mweksler has joined #wpwg
21:06:34 [mweksler]
mweksler has joined #wpwg
21:07:05 [nicktr]
notes a strong preference to CFC Payment Handler API FPWD _before_ the CFC for PR API to go to CR
21:07:21 [mweksler]
mweksler has joined #wpwg
21:07:42 [betehess]
betehess has joined #wpwg
21:08:09 [mweksler]
mweksler has joined #wpwg
21:08:57 [mweksler]
mweksler has joined #wpwg
21:09:46 [mweksler]
mweksler has joined #wpwg
21:10:33 [mweksler]
mweksler has joined #wpwg
21:11:21 [mweksler]
mweksler has joined #wpwg
21:12:10 [mweksler]
mweksler has joined #wpwg
21:12:58 [mweksler]
mweksler has joined #wpwg
21:13:45 [mweksler]
mweksler has joined #wpwg
21:14:50 [mweksler]
mweksler has joined #wpwg
21:14:53 [Matt_]
Matt_ has joined #wpwg
21:15:06 [MattS]
MattS has joined #wpwg
21:19:38 [Ian]
Ken: I wanted to share some thoughts in the last session but did not have a chance
21:19:41 [manu]
rrsagent, make minutes
21:19:41 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/03/24-wpwg-minutes.html manu
21:19:56 [manu]
scribe: manu
21:20:13 [Ian]
scribe: Ian
21:21:07 [Ian]
Ken: I support this effort and think that the success of this effort can be enhanced by greater support from the card payment industry
21:21:55 [Ian]
...here's an issue that I have with the specs
21:22:04 [MattPi]
MattPi has joined #wpwg
21:22:14 [Ian]
...there's a potential commercial advantage given to merchants given their ability to specify payment method preferences
21:22:31 [Ian]
...my proposal is to remove the language
21:23:01 [zkoch]
q+ to clarify
21:23:08 [Ian]
...in show() 3.3, step 8
21:28:18 [Ian]
...the ask to the group is to remove the merchant preference language
21:28:20 [Ian]
ack zk
21:28:20 [Zakim]
zkoch, you wanted to clarify
21:28:25 [nicks]
q+
21:28:32 [AlanSamsungPay]
q+
21:29:13 [dezell]
q?
21:29:15 [dezell]
q+
21:29:17 [Ian]
Ken: Example: The user agent SHOULD prioritize the preference of the user when presenting payment methods and applications.
21:29:19 [nicktr]
q+
21:30:00 [AdrianHB]
ack nicks
21:30:02 [Ian]
nickS: I am ok with this change; some others may object
21:30:10 [Manash_MC]
Manash_MC has joined #WPWG
21:30:50 [Ian]
Alan: Payment method ordering can also be used to guide merchant preferences
21:31:14 [Ian]
Ken: Language that encourages one use case may conflict with another. My proposal is to eliminate language and allow different market behavior.
21:31:26 [mweksler]
q+
21:32:21 [zkoch]
FYI: filed issue https://github.com/w3c/browser-payment-api/issues/481
21:32:41 [manu]
Ian: If you could express an order, you could use that order to show a brand first, or despite a contractual obligation to do that... the language of the spec itself might allow the other.
21:32:47 [nicktr]
ack AlanSamsungPay
21:33:28 [Manash_MC]
q+
21:34:17 [nicktr]
q?
21:34:24 [Ian]
ack dezell
21:35:38 [molly]
molly has joined #wpwg
21:35:40 [AdrianHB]
q+
21:36:09 [Ian]
dezell: Merchant interests are important per our charter; just a reminder
21:36:41 [Ian]
ack nicktr
21:38:51 [Ian]
ack mwe
21:41:06 [Ian]
mweksler: Is not having any statement about merchant preference more problematic?
21:41:22 [Ian]
Ken: No, preferable to say nothing
21:41:37 [Ian]
q?
21:42:05 [Manash_MC_]
Manash_MC_ has joined #WPWG
21:42:25 [Ian]
Marcos: I think removing the language gives user agents more flexibility
21:42:41 [Ian]
...I want the flexibility
21:42:43 [Ian]
q?
21:43:28 [Ian]
ack Man
21:44:25 [dezell]
just noting that our charters - intentionally or not - favor customers and merchants.
21:44:52 [nicks]
q+
21:44:54 [jean-yves]
About choice of PI, as far as the EU is concerned, have a look upon art 8.6 of Regulation (EU) 2015/751 on interchange fees for card-based payment transactions: http://eur-lex.europa.eu/eli/reg/2015/751/oj
21:45:02 [AdrianHB]
zakim, close the queue
21:45:02 [Zakim]
ok, AdrianHB, the speaker queue is closed
21:45:03 [Ian]
Manash_MC: Payment app exclusion is a related topic
21:45:13 [AdrianHB]
q?
21:45:15 [AdrianHB]
ack me
21:45:39 [Ian]
adrianHB: We have an order of constituents that we speak to, leading with users
21:45:53 [Ian]
...we don't have detailed naming of some parties in the ecosystem
21:46:52 [Ian]
IJ: I think language in our charter is about use cases, not order of constituents
21:46:57 [Ian]
q?
21:47:00 [Ian]
ack nicks
21:47:23 [Ian]
nicks: One other point in favor of omitting the language....regulatory requirements can be very different in different parts of the world.
21:47:44 [Ian]
...omitting the language might help us avoid conflicts
21:47:55 [Ian]
AdrianHB: By omitting the language we put the onus on the browsers.
21:48:10 [Ian]
NickS: Omitting language doesn't prevent providing an order.
21:48:12 [michel_cc]
michel_cc has left #wpwg
21:48:28 [AlanSamsungPay]
q+
21:48:43 [michel_cc]
michel_cc has joined #wpwg
21:48:54 [Ian]
David: Be aware also of regulatory impact on mobile money
21:49:19 [Ian]
Alan: I don't think there's a lot of retail representation in the room .They are going to be interested in expressing preferences.
21:49:54 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/03/24-wpwg-minutes.html Ian
21:51:02 [Ian]
FAQ => https://github.com/w3c/payment-request-info/wiki/FAQ
21:51:17 [manu]
Ian: We have 60 questions in there now,
21:51:33 [manu]
Ian: For usage scenarios, we have a FAQ, let's keep building it up, review would be great.
21:51:53 [Ian]
Topic: Next FTF meeting
21:52:20 [manu]
Ian: There is a venue for last two weeks of July... that's in 3.5 months.
21:52:58 [Ian]
Noting:
21:53:07 [Ian]
* Not much enthusiasm in tired room for July FTF
21:53:12 [Ian]
* Prefer to address later based on need
21:53:15 [zkoch]
but… i heard paris?
21:53:22 [Ian]
Topic: Next teleonferene
21:54:11 [Ian]
No WG meeting 30 March
21:54:16 [Ian]
Next WG meeting is 6 April
21:56:25 [Ian]
IJ: I am happy to have a call with Marcos, and others
21:56:34 [Ian]
Marcos: Let's make more explicit that decisions are async
21:58:02 [Ian]
Topic: Comms at CR
21:58:04 [Ian]
Support!
21:58:14 [Ian]
ACTION: Ian will work with Marcomm on comms plan for CR for PR API
21:58:14 [trackbot]
'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., IFSF-EFT-WG-Lead, ijacobs, ijmad).
21:59:25 [Ian]
AdrianHB: Another topic is what to do since mozilla may not be at Thursday calls
21:59:28 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/03/24-wpwg-minutes.html Ian
22:00:42 [Ian]
AdrianHB: Thanks to everyone! Seeing implementation is exciting. Seeing apps is exciting!
22:02:17 [Ian]
RRSagent, make minutes
22:02:17 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/03/24-wpwg-minutes.html Ian
22:02:20 [Ian]
RRSAgent, set logs public
22:04:59 [marcosc]
marcosc has joined #wpwg
22:37:02 [nicks]
nicks has joined #wpwg
22:50:47 [Ian]
RRSAgent, bye
22:50:47 [RRSAgent]
I see 2 open action items saved in http://www.w3.org/2017/03/24-wpwg-actions.rdf :
22:50:47 [RRSAgent]
ACTION: Ian to work with Roy to set up a repo for future tokenization spec(s) [1]
22:50:47 [RRSAgent]
recorded in http://www.w3.org/2017/03/24-wpwg-irc#T20-58-05
22:50:47 [RRSAgent]
ACTION: Ian will work with Marcomm on comms plan for CR for PR API [2]
22:50:47 [RRSAgent]
recorded in http://www.w3.org/2017/03/24-wpwg-irc#T21-58-14