Automotive Working Group Teleconference

10 May 2017

11 May 2017


Peter, Eric_Seong(LG), Wonsuk, Adam, Kevin, Urata, Bernard, Ted, Hira, Frank_Serriere(Renault), Mathias_Le_Borgne(Renault), Paul, Junichi, Mike, Rudi, Ian
Peter, Paul


Implementation Report

Slides: https://lists.w3.org/Archives/Member/member-automotive/2017May/0016.html

Peter: first slide is a rough overview of the architecture

... on top applications, then implementation in C++/QT of W3CServer

... we used OpenDS signal similator developed by some university in Germany. we used the open source version, there is a more robust commercial version as well

... we modified it slightly for our needs

... next slide, flow diagram of a subscription

app->w3cserver->processrequest (runs as separate threads)->requestion handler->subscription handler->vss signal broker then down to CAN, flexaray

(there are a number of other possible flow paths in diagram)

(auth handler, auth manager, json request parser, get/set handlers, unsub hander,getvss handler, rvi, opends similator)

Peter: quite simple really

... some of the signals in our demo were not realistic

... we were really happy to find opends. JLR has another and believe they sometimes use a proprietary one

[discussion of threading in Qt]

Ted points out the benefits of HTML5... :P

Peter: the open source licensing of Qt is driving some people away

Urata: if you use an obd2 dongle to a real car instead of opends

... then this would be immediately useful

Peter: Magnus (Melco) is working on that, similar to what you did in the Prius

Wonsuk: I'm also looking for a good dongle

Peter: depends on what you are looking for for connectivity

Paul: problem is they're slower

... if there were an OEM willing to step up here...

... some cars expose high speed CAN

... you need the definitions to map

Kevin: I believe our vehicles are available at the dealership

Urata: too expensive for testing

Peter: Rudi did something with an ODB2 and python scripts, not sure if it was BT or USB

Adam: our networking folks are pretty hesitant about exposing those definitions

Urata: this going to be part of GDP?

Peter: not sure because of Genivi's licensing preferences and QT

Ted: I've been wanting an open OBD2 Linux platform Vinli or Samsung's for live signals. Sanjeev pointed me at a crowdfunded one that hopefully will be available soon

Paul: problem is subset of signals and signal speed to be useful

Urata: this will be open source?

Peter: it is presently on my github account and will be moved to a Melco one, they are willing to go open source here

... we have more brush ups

Urata: mine is just for testing and do not plan to improve it

[next slide]

Peter: Peter: on a raspberry pi, performance was no problem. opends is java based

...server + broker in Qt5.6

... we have demo apps for android, iphone, html5/js

... when you have it up and running it is very easy to use our specification. it is really easy to write applications against it

... showing how good the specififcation is

... client demos on separate gh repo

[next slide]

Peter: we haven't found any really big issues

... it would be better to return things in an array

... filter function becomes complicated and trying to match different types and units

... we might want to look at filtering again

... we also noticed different clients (eg on iphone) implementations of websockets vary widely

... some of those are not very active, simpler proof of concepts by individual developers and not polished commercial products

.... webview in android does everything well

... we haven't done any benchmarking but simply watching load on the rpi with many concurrent connections we only used 3% of the cpu

Urata: you check latency?

Peter: no

... we haven't implemented servername. device token needs to be added. need to add system test to test suite

... also need to configure and run Urata's test suite

Eric: is there only one server instance per device?

Peter: we are running one server for all devices

Eric: can you run multiple?

Peter: sure

Ted: why would you want to other than to perhaps sandbox one further?

Kevin: some companies will have different mental models about how they want to architect their head units

Adam: back to returning arrays

... it depends on what you are requesting, some times you'll just get a single leaf

Kevin: an array can have zero one or more elements

... we can raise the issue

Ted: sssh! wait until after we go to CR to file it :)


Slides: https://lists.w3.org/Archives/Public/public-automotive/2017May/0001.html

Urata opens test suite client in browser (URI not public)

Urata: in this example get and subscribe are available

Ted: remind me of the signal source, recorded and played back or?

Urata: mock data

[example doing get and then set on door lock]

Urata: data model coming from VSS definition

[next slide on VISS proto block diagram]

Urata: I'm using a simpler mock server than Peter's opends

[next subscribe flow diagram]

[subsribe and authorize models, next slides]

Urata: what I want to show is when client sends get method it converts to json, sent to server via websocket
... there is a ws receiver. request is tored in request queue
... request id is a unique key
... reqid is necessary since client doesn't know response is based on which request otherwise
... this is basic structure of this implementation

Peter: are you waiting for value to come

[next slide on multiple client handling]

Urata: there is only one web socket server instance, all clients connect to it
... but I create a "session instance" per client
... each with their own request queues
... if many clients are connected performance might decrease. I haven't benchmarked against multiple yet
... yesterday we had a discussion about what happens when multiple clients make a set

Ted: that can be a problem with different queues breaking the "last wins" model we discussed since a queue could be busier and break ordering

(across all queues)

Urata: that shouldn't happen but I cannot say it won't happen

Ted: remind me and apologies for not knowing but we have timestamps on requests?

Peter: yes

Ted: then we should have the central clearing from the multiple clients keep a cache and discard an outdated, conflcting set request so last still wins

Eric: that is the right way to handle it

Wonsuk: have you run your prototype against your test cases?

Urata: yes and will show the demonstration in a bit
... here is the W3C's automatic test framework with our tests
... presently we have 31 tests

[local server instance demonstrated]


Urata: they are separated by test categories and I added vehicle
... nearby is https://testthewebforward.org where W3C encourages people to contribute tests
... next slide on vehicle api case

<wonsuk> https://github.com/w3c/web-platform-tests

[test framework structure]

Urata: when I check out this repo from w3c's gh there is a web platform test framework and folders for each web api
... including a test runner html ui, there is a testharness.js helper library

[slide on simple test case]

[Urata demonstrates running his test suite in local instance of web-platform-tests]

<scribe> scribenick: ted___

Urata: be sure to adjust your timeouts when running the tests as they take awhile

[summary slide]

Urata: some data has value ranges in addition to typing

Frank: we have an abstraction layer on our side. we want to produce a standardized/semantic data definition
... we have a huge number of data and concern on data which is why we are interested in what you are producing
... we should be able to support all the vehicles

Urata: VISS is conforming to the specification and isn't looking at performance

Frank: understood, this is the necessary first step

Hira presentation on Implementation Plan

Urata shows Hira's latest implementation plan

Hira: I changed document style from powerpoint to html5

<wonsuk> https://www.w3.org/WebPlatform/WG/PubStatus

<wonsuk> Implementation report: https://w3c.github.io/test-results/pointerlock/all.html

<wonsuk> Implementation report for HTML Canvas 2D Context: http://w3c.github.io/test-results/2dcontext/all.html

<urata> <wonsuk> test report plan document name should be renamed to 'test guide' etc.

<urata> <wonsuk> this document should be put into github so that members can comment, send pull request.

<hira> https://github.com/w3c/automotive/issues/123

<urata> Sec1 to 5 should be separated as 'testing guide' document. (tentative name)

<urata> test assertion part should be separated to a document ( or 2 documents such as 'VISS test assertion' and 'VIAS test assertion')

Paul demos Busmaster for recording singals, works well from eg Mazda and Ford

<wonsuk> https://rbei-etas.github.io/busmaster/

Paul: you'll need to do mapping through VSS

... windows based, they tell you how to extend it

... FOSS

Paul: somewhere on open garage site is links to CAN ID from a number of different manufacturers

(Craig Smith)

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

Web Payments

<Stiepan> thanks ted

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

Ian: slide 9

... you are on your mobile or laptop/desktop browser. this slide was for demo at u.s. treasury department so we chose buying a national park pass

... it is a push payment model. in an improved payment model slide 14 shows the streamlined process

... merchant calls the api, (used chrome in this example)

... merchant can ask for contact info, shipping location and browser can send with user consent this information

... it shows some information stored by the browser previously

... payment methods known by the browser that the user has

... browser has credit card information goes to merchant's bank

(not the merchant itself)

Ian: in thinking of pay at the pump use case

... car has payment apps provisioned by the car owner, fleet manager or user so that there is pre-stored information (including card info)

... basically on the car there are payment apps

... when you go to the pump you are prompted by the fueling/charging station to determine what services you want gas, wash, other

... one scenario is that cvv code is required or it could be stored

... some sort of confirmation is required

... the flow from our perspective using this api is seeing if the web merchant model works

... the website of the service provider needs to interact with the vehicle

... our api is not specific to cards, could be bitcoin or whatever

... we have 3 kinds of payment apps that can live in the system

... first is in the browser themselves.

... they already streamline checkout with auto-fill. this is an improvement

... next is mobile payment apps (google pay, alipay etc)

... this week we saw a demo with square that used android specific protocols

... alipay is a proprietary payment method but can still be used - native payment apps

... the way they talk to the browser will be proprietary

... third is payments from websites, mastercard has native app but can process their payments through websites

... data storage is shifting to the user side

... one effect of having data on user side is improving security. payment tokenization is off sites and onto apps

... we are working on a tokenization payment system for increasing security

... two specs, one at cr maturity level and other going to fpwd

Paul: some OEMs may not be planning on including a browser runtime

Ian: we understand not wanting open web access. it can be restricted to known vendors' sites

... what we haven't worked out was how to pair phone (with payment apps installed on it) paired and process payments on behalf of cars

Wonsuk: are there any plans for a RESTful API (in addition to WebIDL, in browser)

<Ian> https://github.com/w3c/webpayments-http-api/issues

... then any client including native apps could

<Ian> https://w3c.github.io/webpayments-http-api/

<Ian> https://www.w3.org/TR/webpayments-http-messages/

Ian: Manu Spory and Web Payment have some ideas for out of browser payments

... using HTTP, including message format

... we decided as a group there was more interest starting browser based and after gaining experience

... there is interest but not pursuing actively until we see how this goes

Rudi: what is the southbound interface for the payment processing?

Ian: that is a native payment app (PSP) and its job is to initiate transfer

... it has user and payment data to be able to handle the payment and get response status (success, failure) client can convey to merchant

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

Ian: John (IFSF) has been putting in requirements in the wiki

... this abstraction layer lets you avoid custom integration with multiple individual proprietary payment apps

Paul: useable by drive-thru restaurants as well

Ian: some of the other conversations with John include how to send information from a beacon via BT or other, get the pump number etc

Ted: another colleague (Dom) relayed bits on existing BT api options at w3c that can provide that piece

Stiepan: my question is about car-phone pairing and next steps related to it

Ian: we have some technoligies to handle web notice or push api but I am not super familiar with them

Rudi: how does this differ from entering credit card information or paypal?

... on current sites

Ian: this is stored on the user side

... for the user less typing. merchant doesn't need forms nor do they need to store sensitive information

Rudi: they don't want to because of PCI

Ian: right they would have to go through eg braintree

... merchants can still collect information on users for customer service

Rudi: on chrome i can store my payment information already if I'm brave enough, is this an extension?

Ian: yes and it just does pre-fill, you still need to tab through the fields

... this doesn't require a form

... they can do more by knowing data is available and having the client send it on their behalf

... this streamlines the user experience

Rudi: now I'm getting the hang of it

... what are the security ramifications

Ian: api still results in data going to merchant. we are planning to increase security with tokenization

... the 70,000 user credit card site hackings will be reduced as a result of this approach

... our group isn't constraining any particular type of storage

Rudi: can a malicious website tease out a transaction without the user's knowledge

Ian: today if I visit a malicious website and am duped, nothing I can do

Rudi: what about a malicious site using this api

Ian: that is a misconception. we can do better than the status quo to phish users. it is harder to hack than a webpage

... underlying payment apps themselves can and will do their hueristics of sites before completing the transaction on behalf of the user

... these are the sort of conversations we are having

Rudi: agree, often convenience comes at the expense of security

Junichi: if user wants to user multi browsers, the user has to input his credential on each browsers. it seems to be disadvantage compared to amazon like site.

Ian: mozilla started with desktop, google from mobile

... it shouldn't matter which you are doing in the long run

Ian: the more merchants that start implementing this more we'll see it pervasive

<Ian> https://github.com/w3c/payment-request-info/wiki/FAQ

... some merchants may not adopt it. some prominent ones like shopify intend to. amazon, may not for their site although they are attending meetings but would like to see amazon pay elsewhere

Ian: please also see our FAQ

Rudi: for GDP since we're using chromium it makes sense. the secured storage model might have other interesting uses

<junichi-hashimoto> another question i could not ask was which module/app is responsible to check user identity. in the case of car scenario, I don't want my son use my credit card for instance.

Ted describes benefit of this abstraction layer to multiple payment apps, not needing to integrate each

Rudi: I could see JLR wanting to become a payment processor and have app of their own


Urata: only a couple issues remaining on VIAS

... I think Rudi's is already resolved


Urata: I think we can close

Ted: he reviewed the merge so ok to close


Urata: authorize should not be DOMString but changed to Object

Adam: that will allow for multiple tokens

Urata: next part of this issue report is about naming, the subscribe callback method

... Adam suggests SubscriptionCallback

... I understand the point but this function handles both on-subscribe and on-subscriptionNotificiation

... I thought having two callbacks is redundant and thought it would be nice to simplify

PatrickB: wouldn't promises be better?

... you will get either your callback or the error

Urata: yes, one idea on solution would be using a promise

... I inherited this interface from Powell's idea. more common way is using promise

Wonsuk: there are two different approaches. in case of connect our interface provides success or error callback

... subscribe only provides success callback

... why provide two different interfaces

Urata: connection can be lost for various reasons. disconnect callback should be called in such cases

Ted: I recalled this came up before but do not believe it was fully resolved due to end of year slowdown then CES scramble


[[powell: was there a decision on promise vs callback vs vanilla? rudi: vanilla ted: given how few callers we have that might be a good question to pose to the mailing list]]

(we were not giving Powell enough feedback at that point)

Ted: I think we can decide here on promises

Urata: I am fine with that

Adam: I like promises but do we have to be concerned with browsers not supporting promises

Paul: I know there are some older browsers in automotive

(webkit, especially in Qt)

<wonsuk> http://caniuse.com/#search=promise

<junichi-hashimoto> A minimalist implementation of a javascript promise https://gist.github.com/unscriptable/814052

Urata: do we have to support older browsers?

Adam: they can do callback

Wonsuk: I am in favor of promise

Junichi: we cannot translate simply error callback. error callback should only be called once

PatrickB: if you read the API you will get the promise only for the subscription

... if it fails you will enter the error path of the promise. when the connection breaks after you have to handle error on success anyway

... promise is on the subscription not on the connection

... you have to handle interruptions anyway

Urata: that is handled by the disconnect method

PatrickB: the success callback of the subscription needs to handle the subscription itself. the subscription object will have onmessage etc

... if we do multiple calls on the same callback then we need reactive programming

... that is highly valuable but far from a standard

... messages or errors could occur after the subsription

... you are confusing message and subscription callback

... I am a fan of promises

Urata: the onmessage cannot be used for continuous callback

PatrickB: think of a try {} catch {} block

Urata: will getVSS confuse the promise

<junichi-hashimoto> @23:53, I wanted to say that callback functions which could be called several times cannot be translated to Promise format

Urata: subcribe can't be handled by promise

[no ready solution making itself clear]

Wonsuk: promise has some limitations but we may be missing something

... we probably need to investigate more before we make a decision

Paul: criteria is to make the api more useful

Urata: we can leave this pending and go to FPWD

Paul: it can be a comment in the doc (since people don't look at issues list)

Ted: advantage of FPWD is we'll get more eyes on it and someone looking at it might have a good solution

Urata introduces WS in spec when we only support WSS in the spec

PatrickB: that becomes an issue with additional devices in the car (eg smartphones) and the vehicle not being able to update nor give an authorative (self signed) certificate

... self signed is a non-starter. also what if the root CA gets updated?

Ted: Junichi did a presentation at our Lisbon meeting on exactly this issue both to Auto WG and as an open session to rest of W3C TPAC

Urata: he opened a community group on it

<Stiepan> What is the link for the community group? (This relates to my previous question)

Ted: also surely an issue for WoT who were probably part of the Lisbon breakout session

<junichi-hashimoto> current wg consensus is to use special hostname, self-signed certificate and install self-signed root CA certificate into the client browser

<junichi-hashimoto> host file might be needed as well

<junichi-hashimoto> HTTPS IN LOCAL NETWORK COMMUNITY GROUP https://www.w3.org/community/httpslocal/

minutes of Junichi's presentation at Lisbon F2F

<junichi-hashimoto slides

<junichi-hashimoto> welcome:) --ad-- now the cg call for participants. https://www.w3.org/community/httpslocal/2017/02/06/call-for-participation-in-https-in-local-network-community-group/

<Stiepan> lost audio for some time; many thanks for the additional link Junichi, this looks really promising!

<urata2> https://www.w3.org/community/httpslocal/

<urata2> community group about http/wss in local network

issue-198 subsection 5...

Urata: I agree nullable can casue problems

Adam: our websocket spec has some get like functions

Urata: VIAS doesn't care if it is websockets or HTTP Rest underneath. having disconnect/connection optional isn't ideal

Paul: what happens when you have multiple subscribes?

Urata: VIAS was initially considered a JS library to sit on top of VISS. Hira/KDDI would like possibility of VIAS being on top of something else

Paul: does VIAS need to manage connections? how to handle unsubscribe when you have multiple subscriptions?

Urata: subscribe could be realized without web socket

... eg using web push technology

... VIAS doesn't care what is underneath

... connect/disconnect may not be needed by some

Paul: I would be inclined to drop them then

... have it handles under the covers

Ted: implementation specific can handle when it needs to subscribe

Wonsuk: handling multiple protocols underneath gets complicated especially for brower vendors

Ted: not necessary, they could choose and implement one

Wonsuk: think of the JS frameworks like Angular

... for example web storage which can be varied

... the more abstract and consistent the api you can make the easier it is for the developer

Wonsuk: frameworks at good at abstracting out complexities and varied browser capabilities

... what is the goal of this specification? we need to provide standard api to access vehicle signals

... here we want a more convenient api for developer

... not sure removing connect/disconnect and leaving it to the implementation is the right answer

Paul: as a convenience developers do not want to manage things like that

... framework yes, let it handle that but what are we defining here?

Ted: in addition to HTTP rest and sockets, some may choose to do WebIDL to talk to native libraries on the same host which will not have concept of connections

(at least not a network connection. connect method could check responsiveness to underlying c++)

choice is either leave it implementation or handle each (we identified three, potentially others) connection means (or hardwired if a browser extension or in browser

Ted: again we can go the comment route and people can tell us we're nuts or provide a solution based on elsewhere

... i can try to ask around beforehand

[discussion of next teleconference, cancel next tuesday due to travel/vacations. vias draft with comments can be done. call for concensus email can be done by any chair and doesn't have to wait until the following tuesday]

Genivi Security and Network Expert Group liaison

Ted: I want us to reboot our Privacy and Security TF. It has been fairly dormant apart from the https local topic. There was only one teleconference held and no mails to list in months.

... I have been partially participating in Genivi's Security Expert Group. We are in their queue for a review which starts with building an attack tree, then thinking on mitigation techniques. I made a presentation to them before lunch on how 3rd party app market could be structured with W3C Guidelines



Ted: We will have to cover other topics like rechartering, which at this point will not include RSI since that will follow BG report route at this stage, via email or subsequent teleconferences.

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/05/23 14:44:19 $