See also: IRC log
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