Automotive Web Payments Task Force

Rodrigo: welcome, it is a pleasure to have more starting to join these calls. I am from WEX
... for the agenda we'll be discussing the charter, cadence, TPAC, use cases
... we will be meeting there the morning on the 9th

Ian: I want to be sure to cover ramping up to TPAC today

Ian: welcome, I am not sure I met all of you
... we are looking forward to our first F2F meeting at TPAC
... I am leading the Web Commerce Interest Group and Web Payments Working Group
... we have enough maturity with our Web Payments specifications that we are looking beyond the online marketplace checkout use case
... we decided to focus on automotive needs, fueling/charging, tolls, parking...
... we want to explore auto's use cases, see how the web standards we have can solve them or new work needed (gap analysis)
... evaluate needs, trends, challenges
... 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
... interested in hearing others' thoughts as well

<Ian> https://www.w3.org/Payments/IG/wiki/Automotive/UseCase_PayAtPump

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...

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

Ian: one way to view the world, if they are able to open a web page they could easily make payments
... we have some assumptions in this early exploration of fueling use case that needs to be flushed out more
... this amounts to writing stuff down - what is needed from your perspective for that given use case

<Ian> https://github.com/w3c/automotive-pay/wiki/Agenda-20171012#considerations-when-writing-up-use-cases

Ian: we find having flow diagrams helpful as well

[Rodrigo starts presentation]

Rodrigo: we are early exploration with initial focus on pay at the pump. we also want to start exploring other use cases
... we want to know how these systems can benefit from a common web standard

[slide 2 - flow diagram for pay at pump]

Rodrigo: this is a high level description and does not go into minutia nor handle exceptional cases like autonomous vehicles or EV
... you'll note the concept of external wallets - eg Samsung, Google or other
... the purpose of the task force does not intend to handle the entire landscape but how the web can add to it

Ian: goal is to go deep enough so the group understands the needs so we can see how the web can solve it
... we will strive to bring in all the needed expertise to provide that perspective

[slide 4]

Rodrigo: this slide shows the area we will focus on for fueling
... how a cloud based payment can behave, including risk mitigation
... using certificates or other ways to valid and approve the transaction

Dave: in the existing systems today when they are paying with their phones
... not standardized. there are essentially two models
... the first is site level activation (SLA) where the phone pretends to be a payment device
... example being ApplePay talking NFC to the pump
... 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
... the preauth before enabling pump, sending notice after
... the other way is above site activation
... the service provider through its relationship activates the pump. it might be helpful if we choose which model we want to focus on
... 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

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
... everything else beyond that is likely out of W3C's scope
... can we do better than that?
... can we avoid having to get out of the car?

<Ian> ted: I think the scope is correct - the payment details need to get to somebody

<Ian> ...we can look at other areas to "do better" than swiping the card

<Ian> ..e.g., through beacons

<Ian> [Interesting question - whether drivers authorizing sharing of vehicle data creates any new opportunities [and privacy risks]]

<Ian> John: +1 to David's comment...it would be difficult to connect a browser to a pump.

<Ian> ..I wouldn't want it to do that.

<Ian> ...a pump is just a device

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

<scribe> scribenick: ted

John: what is seeking payments will be varied, tolls, parking garages etc
... we are managing a device (pump, toll, etc) and we need to keep it as generic as possible

<Ian> John: The interface is to some device controller....

<Ian> ...phone appears as just another terminal to get credentials to on-site

John: we see SLA as having the phone or car be an alternate onsite payment system

<Ian> John: +1 to payment request combined with device request

John: there will be timing issues for things like preauthorizing

<Ian> John: Part of pre-auth request is "what" you are authorizing

<Ian> ...you don't just pre-auth value

<scribe> scribenick: Ian

John: it's "$50 of SOMETHING" that is authorized
... not "of anything"
... that's what makes automotive different
... 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.
... it's slightly more complicated than a payment
... payment has product restrictions with it.

[IJ thinks those restrictions are managed by servers]

scribe: that's where I think auto payment differs
... if you have an electric car and you are next to gas dispenser you would not want to authorize the gas dispenser

dezell: usually fuel transactions are unattended
... for unattended, our card brands and also major oil networks require us, after the fact (after payment)
... they require us to ask them if they want a receipt
... with site-level activation, there are more bumps in the road

<ted> scribenick: 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

<Ian> https://www.w3.org/2017/Talks/ij_uspayments_20170912/w3c.pdf

Rodrigo: that would be beneficial

Ian: mostly I am going to show some screen shots
... 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
... these are screenshots of some of the deployed implementations
... the user has stored information in the browser, similar to autofill
... you can store your credentials directly in the browser (less cvv) or give you access to other payment applications
... all sorts of payment methods/wallets can flow through this standard pipe
... in the case of pay at the pump you won't need shipping information
... some web server receives the data. as long as i can talk to it I don't care
... we can buy gas in two clicks
... now the hard question is how did i (or my car) get to that web page?
... you might want to allow for multiple means of doing so
... one approach might be a qr code that my phone (or camera on car) can use to pull up a URL
... it could be a beacon challenge but then we have a granularity question (which pump)
... similar approach if NFC
... regardless we can use this payments API for handling the transaction
... 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
... I should be able to go into an arbitrary gas station and pay quickly and be on my way

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
... if that is true that carries us toward SLA and is viable

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
... 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
... there are scenarious where 3G might not be available and we can address them with other networking options
... from the web perspective it is just a web server

Dave: I caution against over-simplifying
... there is a win for SLA
... user can control their credentials and not need to send them to a third party

Ian: correct
... we can build on top of this with loyalty programs and optional apps

Dave: who wants to control the web server? the browser should not talk directly to the pump
... the web server plays a central role but is not in the current landscape yet

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
... those exist worldwide now

<Ian> +1 to identifying the assumptions of the use cases

<Ian> (e.g., whether connectivity is present)

Rodrigo: this use case already exists and in part due to connectivity issues
... it would be possible to rely on wifi
... EU and US has different flow and capabilities than some other parts of the world
... the experience we are describing will have some mandatory requirements
... do we agree blue box is where we should focus?

Ian: we can increase security as well with tokenized payments after strong authentication and that would be a big win
... please send the slide deck to the list

<Ian> ACTION: Rodrigo to work with Ian to publish the slides [recorded in http://www.w3.org/2017/10/12-autopay-minutes.html#action01]

Next meeting

<Ian> 19 October

<dezell> FWIW, I >do< think the blue box is fine for discussion. The ? is in the right place.

Ian: consider use cases people want to bring forward and we will look for intersecting interests

<Ian> https://rawgit.com/w3c/automotive-pay/gh-pages/charter.html

Ian: please review the charter. this call served as an intro and we can get more details written down in use cases

[adjourned]