Automotive Working Group Teleconference

Paul introduces new co-chairs Rudi and Peter

Paul: I encourage people to review the agenda and propose items

-> https://www.w3.org/auto/wg/wiki/Main_Page#April_26-29.2C_2016_in_Paris F2F Agenda

Rudi: I will have some conflicts with Genivi Expert Group meetings but hope to be present for most

Paul: if you can provide me more details that will help in arranging agenda

Peter: on Tuesday do we have a room settled yet?

Paul: I will coordinate with Genivi to see if we can have a space that day otherwise we will have to do ad-hoc
... I expect fewer people to be available on Tuesday

Peter: I hope to make it to the venue by noon

Paul: we have a meeting room for Thursday and Friday

Junichi: do we know who will be joining on Tuesday?

Peter: a colleague and I

Paul: Kevin by phone, Kaz, Junichi, myself, Ted

Robert: what is the Tuesday portion about?

<kaz> [ will bring my mic/speaker to Paris as well ]

Paul: Security

Rudi: I will be there then too

Paul: we may get some interlopers from Genivi as well
... one of the things about the new direction (issue 81) are concerns Kevin had about the architecture

<kaz> Issue-81

Kevin presents possible architecture model - PDF will be sent to list later

Kevin: left hand side is other systems, not an exhaustive list for sake of clarity
... along the bottom are network gateways
... a singular controlled means to get data on and off the vehicle

Volker: are you considering utilizing a smartphone for wireless connection hub?

Kevin: I have not included in this diagram but have others internally

Volker: I meant using the smartphone instead of the vehicle modem as your network upstream

Kevin: no but it could be added

Rudi: wouldn't the phone be transparent in this as the bridge or router outside of the vehicle?

Kevin: there are a number of ways it could flow
... at the top of the diagram are the different types of applications that can be running on the IVI
... in this example we are doing NodeJS
... the JS libraries in the browser runtime could talk to tha Application Server (node)
... CORS needs to be enable in the application server
... we could alternately run a native applicate, eg QT with web socket communication to the same application server
... could also be Java or C#
... the App server could be written in any number of languages
... we would have an underlying service wrapper between the app server and underlying resources (eg DBUS to CAN)
... vehicle signals are not access directly by any user or device. we can apply security tokens to check if person or device is authorized to access a given signal

<kaz> +q to ask what the difference between browser and runtime (not only GUI?); if secure gateway correspond to a specific car

Kevin: you will want to initially authenticate the vehicle and user
... first time a user logs into a vehicle it could retrieve their profile from an external portal to have preferences available to applications on the vehicle
... a SSO authority on the web can verify the user
... a person might want to store their details on the vehicle in which case we can allow them to provide a profile alias and a pin for later retrieval
... this is the model for a product we released a few months ago
... when the vehicle starts up and authenticate daemon gets invoked it does off board authentication by which the vehicle proves it knows a shared secret or uses PKI
... any requests for data that go off board can include vehicle and user tokens
... this is a quick overview and not the only way interfaces could be exposed

<Zakim> kaz, you wanted to ask what the difference between browser and runtime (not only GUI?); if secure gateway correspond to a specific car

Kaz: what is the difference between browser and runtime? I cannot see the explanation on the side. the difference the lack of GUI?

Kevin: it depends on what is retrieved, whether an app on the IVI or an external site
... you could have a browser not running on vehicle
... off board service provider could act as proxy or service provider

Kaz: you have two secure gateways at the bottom for interacting with CAN. is each gateway correspond to one vehicle or possible portal gateways with in one vehicle??

Kevin: the entire model is to represent a single vehicle

Kaz: can you elaborate on the different types of networks in the diagram?

Kevin: there will be different gateways to expose different available information on CAN buses, separate network for communication for the outside world

Volker: is this direct access to the internet or service provided by the manufacturer

Kevin: in this model the user could be allowed to communicate to a regular web service
... most services and applications will be interacting with managed data
... if we have a managed data partner collecting data from third parties and wrapping it then we can change backend providers over time
... there will be different security implications for these two models, a direct browser could interact with a site which might contain malware
... OEM can control more apps through their portal

Volker: I would be inclined to have some sort of firewall to protect the IVI against various forms of attacks

Kevin: in other versions of this diagram there is a firewall

Volker: I can share something we have done with other car manufacturers where we routed all communication to backend controlled by the OEM

Junichi: who will be providing the tokens in this model?

Kevin: it will mostly be the managed data service provider who will provide those

Junichi: outside of the vehicle?

Kevin: yes
... one of the main reasons is to authenticate the user and data services

Junichi: both browser and native applications would need to use these tokens?

Kevin: if the application is interacting with information from the vehicle then yes it would need a token
... vehicles will need a token to be able to interact with outside world
... the main benefit is to protect OEM from data consumption on the vehicle. this would not be a wifi hotspot where someone nearby can steal bandwidth

Rudi: we are developing an open source framework called Remote Vehicle Interaction for this
... this can be extended to services running on phones as well. there is a strong security concept associated with that
... a device needs to provide a certificate that it is allowed to invoke certain services on the vehicle
... we can elaborate about that more next week and make a presentation

Paul: this candidate architecture helps focus the discussion so it would be good to explore more next week
... thank you Kevin

Junichi: is the token visible to the application itself or not?

Kevin: for web runtime (app environment) clients that is definitely the case, for browser (interaction with web directly) it could be
... I want to see if we can open up browser enough to permit this. I want to see this working for myself

Rudi: there can be different certificates models for these paths

Peter: what are our deliverables here? previously it was clear that we would have a WebIDL for Vehicle API and guidelines for security concerns

Paul: we have a layered approach now
... a RESTful web [socket] service and JS library that allows higher level abstraction
... we need to see how this is going to be used to come up with ways to protect it
... clearly, either token or otherwise, needs to be authorized to talk with the vehicle and we need to control interactions with the outside world
... we have been meandering and need to settle this and focus so we can move forward
... we need to nail it down during the F2F
... this architecture is a variation of others I have seen
... this resembles the LBS Genivi model from Phillippe Colliot
... settling on the architecture will help

Dave: this is a great diagram
... we should take a look at servient architecture

<kaz> -> w3c.github.io/wot/architecture/wot-architecture.html WoT architecture document

Kaz: you mean the web of things proposal?

Dave: yes, there are some similarities here with your application server

Kevin: it can be structured a number of ways

Kaz: WoT had its F2F last week

Paul: Sonya will be attending our F2F as well

Kaz: we should be able to have some good discussions about possible integration

Paul: he is on the schedule for Friday. Kaz can you ask if he will be around Thursday too?

Kaz: ok

Paul: I'll see everyone next week and I encourage people to sends questions to list (or issues) as appropriate

<kaz> Soumya's slides in Montreal