IRC log of autopay on 2017-10-12

Timestamps are in UTC.

12:57:42 [RRSAgent]
RRSAgent has joined #autopay
12:57:42 [RRSAgent]
logging to http://www.w3.org/2017/10/12-autopay-irc
12:58:26 [Ian]
Meeting: Automotive Web Payments Task Force
12:58:30 [Ian]
Agenda: https://github.com/w3c/automotive-pay/wiki/Agenda-20171012
12:58:32 [Ian]
Chair: Rodrigo
12:59:13 [Rodrigo]
Im on the call, can see Ian joined but can't hear him.
12:59:58 [Ian]
present+ Rodrigo
12:59:59 [Ian]
present+
13:00:05 [Ian]
present+ Ted
13:01:17 [ted]
Present+ Marty
13:02:58 [ted]
Present+ Wonsuk
13:03:00 [wonsuk]
wonsuk has joined #autopay
13:03:04 [ted]
Present+ John
13:04:54 [Ian]
scribe: Ted
13:04:55 [ted]
scribenick: ted
13:05:45 [ted]
Rodrigo: welcome, it is a pleasure to have more starting to join these calls. I am from WEX
13:06:09 [ted]
… for the agenda we'll be discussing the charter, cadence, TPAC, use cases
13:06:24 [Ian]
present+ Mikel
13:06:32 [ted]
present+ Adam
13:06:40 [ted]
… we will be meeting there the morning on the 9th
13:06:50 [ted]
Ian: I want to be sure to cover ramping up to TPAC today
13:06:54 [ted]
Rodrigo: please
13:07:07 [ted]
Ian: welcome, I am not sure I met all of you
13:07:20 [ted]
… we are looking forward to our first F2F meeting at TPAC
13:07:38 [ted]
… I am leading the Web Commerce Interest Group and Web Payments Working Group
13:08:04 [ted]
… we have enough maturity with our Web Payments specifications that we are looking beyond the online marketplace checkout use case
13:08:26 [ted]
… we decided to focus on automotive needs, fueling/charging, tolls, parking...
13:09:13 [ted]
… we want to explore auto's use cases, see how the web standards we have can solve them or new work needed (gap analysis)
13:09:28 [ted]
… evaluate needs, trends, challenges
13:09:54 [ted]
… between now and TPAC we should start writing some of these use cases down so at the F2F meeting we can delve deeper into them
13:10:07 [ted]
… interested in hearing others' thoughts as well
13:11:09 [Ian]
q+
13:11:34 [Ian]
https://www.w3.org/Payments/IG/wiki/Automotive/UseCase_PayAtPump
13:11:35 [ted]
John: you're right about the difference between online and automotive. for the latter there are physical devices that need instructions, enabling charger, power on fuel pump, raising toll or parking gate...
13:12:17 [ted]
Ian: John and I sat down and looked at the pay at the pump scenario and it was extremely instructive in what the needs of the industry are
13:13:09 [ted]
Kupa: woof!
13:13:42 [ted]
Ian: one way to view the world, if they are able to open a web page they could easily make payments
13:13:58 [Ian]
present+ dezell
13:14:56 [ted]
Ian: we have some assumptions in this early exploration of fueling use case that needs to be flushed out more
13:15:11 [ted]
… this amounts to writing stuff down - what is needed from your perspective for that given use case
13:15:12 [Ian]
https://github.com/w3c/automotive-pay/wiki/Agenda-20171012#considerations-when-writing-up-use-cases
13:15:27 [ted]
Ian: we find having flow diagrams helpful as well
13:16:30 [ted]
[Rodrigo starts presentation]
13:16:40 [Ian]
agenda+ Who wants to write down use cases?
13:18:31 [ted]
Rodrigo: we are early exploration with initial focus on pay at the pump. we also want to start exploring other use cases
13:18:52 [ted]
… we want to know how these systems can benefit from a common web standard
13:19:22 [ted]
[slide 2 - flow diagram for pay at pump]
13:21:30 [ted]
Rodrigo: this is a high level description and does not go into minutia nor handle exceptional cases like autonomous vehicles or EV
13:22:34 [ted]
… you'll note the concept of external wallets - eg Samsung, Google or other
13:23:22 [ted]
… the purpose of the task force does not intend to handle the entire landscape but how the web can add to it
13:23:44 [ted]
Ian: goal is to go deep enough so the group understands the needs so we can see how the web can solve it
13:24:04 [ted]
… we will strive to bring in all the needed expertise to provide that perspective
13:24:17 [ted]
[slide 4]
13:24:42 [ted]
Rodrigo: this slide shows the area we will focus on for fueling
13:24:56 [ted]
… how a cloud based payment can behave, including risk mitigation
13:25:17 [ted]
… using certificates or other ways to valid and approve the transaction
13:25:56 [ted]
Dave: in the existing systems today when they are paying with their phones
13:26:08 [ted]
… not standardized. there are essentially two models
13:26:19 [Ian]
zakim, who's here?
13:26:19 [Zakim]
Present: Rodrigo, Ian, Ted, Marty, Wonsuk, John, Mikel, Adam, dezell
13:26:21 [Zakim]
On IRC I see wonsuk, RRSAgent, Zakim, Rodrigo, Ian, ted
13:26:28 [ted]
… the first is site level activation (SLA) where the phone pretends to be a payment device
13:26:43 [ted]
… example being ApplePay talking NFC to the pump
13:27:26 [ted]
… there are also closed loop systems where a service provider provides a fake card number to help identify the actual user that is forwarded to the partner provider who recognizes it
13:27:49 [ted]
… the preauth before enabling pump, sending notice after
13:27:58 [ted]
… the other way is above site activation
13:28:07 [Ian]
q?
13:28:30 [ted]
… the service provider through its relationship activates the pump. it might be helpful if we choose which model we want to focus on
13:28:55 [ted]
… from what I am seeing in these slides it seems we are looking at SLA which I'm not convinced is the right approach here
13:29:35 [ted]
Ian: if I understood correctly this is about how the pump gets activated and I see that as an implementation detail and what I am concerned with is getting the payment information to the right party
13:29:50 [ted]
… everything else beyond that is likely out of W3C's scope
13:29:51 [ted]
q+
13:30:07 [ted]
… can we do better than that
13:30:23 [ted]
… can we avoid having to get out of the car?
13:30:29 [ted]
s/than that/than that?/
13:30:42 [Ian]
ack me
13:30:53 [Ian]
q+ dezell
13:30:56 [Ian]
ack ted
13:31:11 [AdamC]
AdamC has joined #autopay
13:31:14 [Ian]
ted: I think the scope is correct - the payment details need to get to somebody
13:31:27 [Ian]
...we can look at other areas to "do better" than swiping the card
13:31:37 [Ian]
..e.g., through beacons
13:32:15 [Ian]
[Interesting question - whether drivers authorizing sharing of vehicle data creates any new opportunities [and privacy risks]]
13:32:16 [Ian]
q?
13:32:49 [Ian]
John: +1 to David's comment...it would be difficult to connect a browser to a pump.
13:32:54 [Ian]
..I wouldn't want it to do that.
13:32:57 [Ian]
...a pump is just a device
13:32:57 [ted]
John: I support what David says. the focus will be difficult to connect a browser directly to the pump nor would i want to do that
13:32:59 [Ian]
q+
13:33:00 [ted]
scribenick: ted
13:33:18 [ted]
… what is seeking payments will be varied, tolls, parking garages etc
13:33:42 [ted]
… we are managing a device (pump, toll, etc) and we need to keep it as generic as possible
13:33:43 [Ian]
John: The interface is to some device controller....
13:34:15 [Ian]
...phone appears as just another terminal to get credentials to on-site
13:34:21 [ted]
… we see SLA as having the phone or car be an alternate onsite payment system
13:34:41 [Ian]
John: +1 to payment request combined with device request
13:34:44 [Ian]
q?
13:34:58 [ted]
… there will be timing issues for things like preauthorizing
13:35:00 [Ian]
John: Part of pre-auth request is "what" you are authorizing
13:35:09 [Ian]
...you don't just pre-auth value
13:35:11 [ted]
scribenick: Ian
13:35:23 [Ian]
...it's "$50 of SOMETHING" that is authorized
13:35:30 [dezell]
dezell has joined #autopay
13:35:30 [Ian]
...not "of anything"
13:35:34 [Ian]
...that's what makes automotive different
13:35:58 [Ian]
...a lot of fleet cards include constraints in the interface...e.g., if you buy a car wash you can only buy a particular grade of fuel.
13:36:04 [Ian]
..it's slightly more complicated than a payment
13:36:10 [Ian]
...payment has product restrictions with it.
13:36:36 [Ian]
[IJ thinks those restrictions are managed by servers]
13:36:50 [dezell]
q?
13:36:57 [Ian]
...that's where I think auto payment differs
13:37:13 [Ian]
..if you have an electric car and you are next to gas dispenser you would not want to authorize the gas dispenser
13:37:35 [Ian]
ack dezell
13:37:55 [Ian]
dezell: usually fuel transactions are unattended
13:38:15 [Ian]
...for unattended, our card brands and also major oil networks require us, after the fact (after payment)
13:38:25 [Ian]
...they require us to ask them if they want a receipt
13:38:50 [Ian]
..with site-level activation, there are more bumps in the road
13:40:02 [Ian]
ack me
13:40:04 [ted]
scribenick: ted
13:40:35 [ted]
Ian: do people here want a two minute explanation of the web payment api? it will help people understand how it might fit in
13:40:53 [Ian]
https://www.w3.org/2017/Talks/ij_uspayments_20170912/w3c.pdf
13:40:55 [ted]
Rodrigo: that would be beneficial
13:41:44 [ted]
Ian: mostly I am going to show some screen shots
13:42:11 [ted]
… payments API is a browser API, it is being implemented in all major browsers and smartphones. it should be pervasive by the middle of next year
13:42:26 [ted]
… these are screenshots of some of the deployed implementations
13:42:39 [ted]
… the user has stored information in the browser, similar to autofill
13:43:04 [ted]
… you can store your credentials directly in the browser (less cvv) or give you access to other payment applications
13:43:22 [ted]
… all sorts of payment methods/wallets can flow through this standard pipe
13:44:11 [ted]
… in the case of pay at the pump you won't need shipping information
13:44:33 [ted]
… some web server receives the data. as long as i can talk to it I don't care
13:45:12 [ted]
… we can buy gas in two clicks
13:45:26 [ted]
… now the hard question is how did i (or my car) get to that web page?
13:45:40 [ted]
… you might want to allow for multiple means of doing so
13:46:01 [ted]
… one approach might be a qr code that my phone (or camera on car) can use to pull up a URL
13:46:43 [ted]
… it could be a beacon challenge but then we have a granularity question (which pump)
13:46:52 [ted]
… similar approach if NFC
13:47:08 [ted]
… regardless we can use this payments API for handling the transaction
13:47:09 [dezell]
q?
13:47:13 [dezell]
q+
13:47:54 [ted]
… I don't want to have to download an app, have a preexisting account with the fueling station although that is optional for things like loyalty programs
13:48:17 [ted]
… I should be able to go into an arbitrary gas station and pay quickly and be on my way
13:50:25 [ted]
Dave: a simplist way forward is let's imagine a world where we have samsung pay available and what you are hoping for instead of an in-app solution we can instead use payment api
13:50:35 [ted]
… if that is true that carries us toward SLA and is viable
13:51:00 [dezell]
q+
13:51:15 [ted]
Ian: what I think happens is I drive up and I get a message on my phone or head unit and I get a message asking if I want to buy gas
13:52:06 [ted]
… if I say yes, they show me the relevant web page and I select pump and seek preauth. server communicates with the service station to turn on the pump
13:52:39 [ted]
… there are scenarious where 3G might not be available and we can address them with other networking options
13:52:58 [ted]
… from the web perspective it is just a web server
13:53:11 [ted]
Dave: I caution against over-simplifying
13:53:44 [ted]
… there is a win for SLA
13:54:02 [ted]
… user can control their credentials and not need to send them to a third party
13:54:37 [ted]
Ian: correct
13:55:00 [ted]
… we can build on top of this with loyalty programs and optional apps
13:55:55 [ted]
Dave: who wants to control the web server? the browser should not talk directly to the pump
13:56:11 [ted]
… the web server plays a central role but is not in the current landscape yet
13:57:03 [ted]
Rodrigo: the reason there is a relationship between a web artifact and the pump, we can envision a possible POS relies on prepaid accounts and offline transactions
13:57:11 [ted]
… those exist worldwide now
13:57:13 [Ian]
+1 to identifying the assumptions of the use cases
13:57:17 [Ian]
(e.g., whether connectivity is present)
13:57:30 [ted]
… this use case already exists and in part due to connectivity issues
13:57:55 [Ian]
q?
13:57:56 [ted]
… it would be possible to rely on wifi
13:58:16 [Ian]
q+ to talk about modeling and strong auth
13:58:22 [ted]
… EU and US has different flow and capabilities than some other parts of the world
13:59:51 [ted]
Rodrigo: the experience we are describing will have some mandatory requirements
14:00:27 [ted]
… do we agree blue box is where we should focus?
14:01:49 [ted]
Ian: we can increase security as well with tokenized payments after strong authentication and that would be a big win
14:02:00 [ted]
… please send the slide deck to the list
14:02:55 [Ian]
ACTION: Rodrigo to work with Ian to publish the slides
14:03:05 [Ian]
Topic: Next meeting
14:03:12 [Ian]
19 October
14:03:30 [dezell]
FWIW, I >do< think the blue box is fine for discussion. The ? is in the right place.
14:03:47 [ted]
Ian: consider use cases people want to bring forward and we will look for intersecting interests
14:03:51 [Ian]
https://rawgit.com/w3c/automotive-pay/gh-pages/charter.html
14:04:26 [ted]
… please review the charter. this call served as an intro and we can get more details written down in use cases
14:04:34 [ted]
[adjourned]
14:04:34 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/10/12-autopay-minutes.html ted