W3C

Automotive Web Payments Task Force

18 Jan 2018

Agenda

Attendees

Present
Ted, Marty, Gustav, Ian, Adam, KarenMyers, dezell, Rodrigo, linda, Glenn, ltoth, JohnC
Regrets
Chair
Rod
Scribe
Ian

Contents


Agenda

Reconvening

<Ian> Rod: Happy 2018 and welcome back

<Ian> ...would like today to hear an overview about the work going on at w3c around automotive

<Ian> ...what is vision / current plan related to automotive and Web

<Ian> ...Ian presented similar around payments last year

<Ian> ...useful to build shared understanding of the different activities

W3C Automotive Activity

<Ian> slides:

<ted> W3C Auto overview

<Ian> IJ: What does it mean that the browsers aren't interested in implementing the standard?

<Ian> Ted: there are browsers available in vehicles (e.g., chromium / genivi)

<Ian> ...as to why the reluctance, might be related to fragmentation or business reasons

<Ian> ...there has been discussion of implementation in an extension

<Ian> ...this would imply a maintenance burden for security updates

<Ian> ...so in the end we are adopting a service based approach

<Ian> IJ: So no hampered by browser implementation choices?

<Ian> Ted: Correct

<Ian> ...there are also use cases where there is no UX

<Ian> Ted: "Can't cruise without tunes"

<ted> Ian: I want to get a better sense of the architectural tendencies for the WG and what that means for browser based payment approach

<ted> … if things aren't all going to be in a browser engine, then web payments doesn't make as much sense

<Ian> IJ: PR API is in the browser, so if moving to a service model (that is, with no browser) what does that mean?

<Ian> Ted: Many will be shipping browsers. One appeal of Qt is benchmarks; another is that one programs in (familiar) C

<Ian> ...many content providers are, however, Web developers

<Ian> ...and because they have apps, it will be easier to port them to Web than to Qt

<Ian> ..so It think you are likely to see both platforms in use

<Ian> ...Genivi dev platform is shipping with browsers

<Ian> https://at.projects.genivi.org/wiki/pages/viewpage.action?pageId=11567210

<Ian> ...so you'll see both in use

<Ian> ...let's ask the auto folks for their perspectives

<Ian> Gustav: It's in our strategy to have automation of payments

<Ian> Ted: Volvo is focusing on Android, using VIIS

<Ian> ...the project lead for that is working with JOA and also has a Volvo hat

<Ian> ...so there is an Android environment where W3C's spec can be used.

<Ian> ...Android also ships with chrome (which supports Payment Request API)

<Ian> ...so web sites running on chrome in the car can make use of the API for payments

<Ian> ...Ian drafted a PayAtThePump explainer to talk about how PR API might be used

<Ian> https://github.com/w3c/automotive-pay/wiki/PayAtPumpExplainer

<Ian> Gustav: How does the station/pump send info to the car (or user device)

<Ian> Ted: There are big concerns about hacking of cars

<Ian> ...there are multiple ways one could send info: QR codes, Bluetooth beacon, NFC, manual entry of data

<Ian> ...videos of Shell implementation by Jaguar suggest some manual data entry may be likely

<Ian> JohnC: I was involved in the Shell FillAndGo project

<Ian> ...I wanted to ask as a general question...are we covering in this WG everything to do with auto, or just pay at the pump?

<Ian> ...in IFSF we were trying to identify offsite vehicle communications in an abstract way

<Ian> ...pump or garage barrier or bridge toll or parking meter

<Ian> ...one of the things that is fundamentally different between automotive payments and standard web payments

<Ian> ..is the LINK to a nearby machine

<Ian> ...so car washing, tools, etc. are all part of the same story

<Ian> ...what is the scope of this group?

<Ian> ..in many cases, the transaction of interest may not be a payment (in that moment) but just registration of information

<Ian> ..and, e.g., payment might occur at a later time

<Ian> ...IFSF and Conexxus are interested in device integration

<ted> Ian: I agree with the architectural perspective

<ted> … there is a challenge in extending how people view the web. today they see it as using a laptop, phone or tablet interacting with web services

<ted> … here we are talking about the "physical web", tying the physical and online worlds

<ted> … there are benefits to using the web in these new scenarios. i am not yet understanding the acceptance of this new paradigm

<ted> … we need to hear people say they want to see this progress

<Ian> JohnC: I have 2 motorway tags because I use my vehicle on different tolls

<Ian> ...those tags are incompatible...and both need to be installed IN THE SAME PLACE

<Ian> ...and due to lack of standards I will run out of window space soon

<ted> [per John's other question - we are focused on pay at the pump as initial use case as a priority but are looking at other payment use cases]

<Ian> JohnC: Also, if you travel with your car to other places, your tags may not work there

<Ian> ...we need standardization to reduce fragmentation

<Ian> Gustav: There are some policy approaches to reducing fragmentation

<Ian> ...payments can happen through prepaid accounts

<Ian> ...there may be legal demands for the customer to be able to confirm a payment

<Ian> JohnC: Agree that there might be a variety of payment models (e.g., manufacturer picks of costs, or where the fleet owner picks up the costs and there is a monthly subscription)

<ted> David: I want to remind people of the essential beauty of the W3C Web Payments API

<ted> … it keeps the data for the user in control of their data. they can make payments without sharing sensitive information

<ted> … it can be done by a laptop, phone or vehicle

<ted> … it also provides a common user experience

<ted> … the common ux is part of the emerging web part

<ted> … payment itself isn't the most important, protection of private information and user experience

<ted> Adam: the scope we (JLR) want from this project is see the feasability of using web payments within vehicles

<ted> … we are looking at subscription model and this may be applicable. we are cognizant regarding keeping personal information private

<ted> … SPII Sensitive Personally Identifiable Information

<ted> David: that covers lots of things

<Ian> Ted: We chose PayAtThePump as an initial use case but we are interested more use cases than that

<ted> * Discuss Q1 2018 Goals:

<ted> ** Solicit real world experiences from participants

<ted> ** Increase participation and awareness

<ted> ** Complete Pay at Pump use case

<ted> ** Perform mock implementation excercise

<ted> ** Assess User Experience and Workflow

<ted> ** Conclude Gap Analysis, emphasis on improving UX and Flow

<dezell> Note: here's an example of a bad interface. I paid with a card to inflate tires this morning. The interface was not what I was expecting. It took 10 minutes to figure out how to turn the thing on. This is how UX plays here.

<Ian> Ted: We'd like to hear from companies here on real-world experience to be sure what we are doing is realistic

<Ian> ...at 6 Feb Auto WG call, we will focus on myriad data from vehicles into the cloud / data silos

<ted> ISO20078

<Ian> ...there are 3 activities: ISO (Daimler, Peugeot, et al)

<ted> Neutral Vehicle

<ted> Sensorsis

<Ian> Ted: I'll send call info to the payments task force list

next meeting

<Ian> 25 January, 9am ET

<Ian> Rod: Thank you for the call today

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/01/18 18:00:55 $