16:01:07 RRSAgent has joined #auto 16:01:07 logging to http://www.w3.org/2016/04/19-auto-irc 16:01:09 RRSAgent, make logs public 16:01:09 Zakim has joined #auto 16:01:11 Zakim, this will be 16:01:11 I don't understand 'this will be', trackbot 16:01:12 Meeting: Automotive Working Group Teleconference 16:01:12 Date: 19 April 2016 16:01:17 KevG has joined #auto 16:01:25 junichi-hashimoto has joined #auto 16:02:45 Present+ Paul_Boyes, Adam_Crofts, Junichi_Hashimoto, Kaz_Ashimura, Ted_Guild, Peter_Winzell, Qing_An, Robert_Sharpe, Rudi_Streif, Kevin_Gavigan, Volker_Fricke 16:03:07 Present+ Dave_Jensen 16:03:33 scribenick: ted 16:03:50 Paul introduces new co-chairs Rudi and Peter 16:04:04 PowellKinney has joined #auto 16:04:23 Paul: I encourage people to review the agenda and propose items 16:04:42 -> https://www.w3.org/auto/wg/wiki/Main_Page#April_26-29.2C_2016_in_Paris F2F Agenda 16:05:23 Rudi: I will have some conflicts with Genivi Expert Group meetings but hope to be present for most 16:05:33 rrsagent, make log public 16:05:37 rrsagent, draft minutes 16:05:37 I have made the request to generate http://www.w3.org/2016/04/19-auto-minutes.html kaz 16:05:44 Paul: if you can provide me more details that will help in arranging agenda 16:05:57 Peter: on Tuesday do we have a room settled yet? 16:06:28 Agenda: https://lists.w3.org/Archives/Member/member-automotive/2016Apr/0004.html 16:06:34 Chair: Paul 16:06:38 Paul: I will coordinate with Genivi to see if we can have a space that day otherwise we will have to do ad-hoc 16:06:56 … I expect fewer people to be available on Tuesday 16:07:09 Peter: I hope to make it to the venue by noon 16:07:35 Paul: we have a meeting room for Thursday and Friday 16:07:47 Junichi: do we know who will be joining on Tuesday? 16:07:59 Peter: a colleague and I 16:08:21 Paul: Kevin by phone, Kaz, Junichi, myself, Ted 16:08:51 AdamC has joined #auto 16:08:54 Robert: what is the Tuesday portion about? 16:08:58 [ will bring my mic/speaker to Paris as well ] 16:09:06 Paul: Security 16:09:07 Rudi: I will be there then too 16:09:18 urata_access has joined #auto 16:09:37 Paul: we may get some interlopers from Genivi as well 16:10:03 … one of the things about the new direction (issue 81) are concerns Kevin had about the architecture 16:12:22 -> https://github.com/w3c/automotive/issues/81 Issue-81 16:14:17 Kevin presents possible architecture model - PDF will be sent to list later 16:14:40 Kevin: left hand side is other systems, not an exhaustive list for sake of clarity 16:15:10 … along the bottom are network gateways 16:15:28 … a singular controlled means to get data on and off the vehicle 16:15:49 Volker: are you considering utilizing a smartphone for wireless connection hub? 16:16:02 Kevin: I have not included in this diagram but have others internally 16:16:24 Volker: I meant using the smartphone instead of the vehicle modem as your network upstream 16:16:31 Kevin: no but it could be added 16:17:09 Rudi: wouldn't the phone be transparent in this as the bridge or router outside of the vehicle? 16:17:21 Kevin: there are a number of ways it could flow 16:17:25 rrsagent, draft minutes 16:17:25 I have made the request to generate http://www.w3.org/2016/04/19-auto-minutes.html kaz 16:17:42 … at the top of the diagram are the different types of applications that can be running on the IVI 16:17:57 … in this example we are doing NodeJS 16:18:45 present+ Greg_Brannon, Powell_Kinney, Shinjiro_Urata 16:18:47 rrsagent, draft minutes 16:18:47 I have made the request to generate http://www.w3.org/2016/04/19-auto-minutes.html kaz 16:18:49 … the JS libraries in the browser runtime could talk to tha Application Server (node) 16:19:17 … CORS needs to be enable in the application server 16:19:39 … we could alternately run a native applicate, eg QT with web socket communication to the same application server 16:19:51 … could also be Java or C# 16:20:39 … the App server could be written in any number of languages 16:21:46 … we would have an underlying service wrapper between the app server and underlying resources (eg DBUS to CAN) 16:22:31 … 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 16:22:36 +q to ask what the difference between browser and runtime (not only GUI?); if secure gateway correspond to a specific car 16:23:18 … you will want to initially authenticate the vehicle and user 16:24:19 … 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 16:24:49 … a SSO authority on the web can verify the user 16:25:30 … 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 16:25:40 … this is the model for a product we released a few months ago 16:26:22 … 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 16:26:59 … any requests for data that go off board can include vehicle and user tokens 16:27:39 q+ 16:28:03 Kevin: this is a quick overview and not the only way interfaces could be exposed 16:28:22 kaz, you wanted to ask what the difference between browser and runtime (not only GUI?); if secure gateway correspond to a specific car 16:28:33 ack k 16:29:07 Kaz: what is the difference between browser and runtime? I cannot see the explanation on the side. the difference the lack of GUI? 16:29:51 Kevin: it depends on what is retrieved, whether an app on the IVI or an external site 16:31:10 … you could have a browser not running on vehicle 16:31:31 … off board service provider could act as proxy or service provider 16:32:23 Paul has joined #auto 16:32:34 Kaz: you have a secure gateway on the bottom for interacting with CAN is that one vehicle? 16:32:58 Kevin: the entire model is to represent a single vehicle 16:33:26 Kaz: can you elaborate on the different types of networks in the diagram? 16:34:14 Kevin: there will be different gateways to expose different available information on CAN buses, separate network for communication for the outside world 16:35:04 Volker: is this direct access to the internet or service provided by the manufacturer 16:35:13 s/a secure gateway on/two secure gateways at/ 16:35:44 Kevin: in this model the user could be allowed to communicate to a regular web service 16:36:01 … most services and applications will be interacting with managed data 16:36:23 s/CAN is that one vehicle/CAN. is each gateway correspond to one vehicle or possible portal gateways with in one vehicle?/ 16:37:21 … if we have a managed data partner collecting data from third parties and wrapping it then we can change backend providers over time 16:37:52 … there will be different security implications for these two models, a direct browser could interact with a site which might contain malware 16:38:09 … OEM can control more apps through their portal 16:38:36 Volker: I would be inclined to have some sort of firewall to protect the IVI against various forms of attacks 16:38:46 q+ to mention that Hira-san was proposing a user-specific agent proxy before 16:38:46 Kevin: in other versions of this diagram there is a firewall 16:39:46 Volker: I can share something we have done with other car manufacturers where we routed all communication to backend controlled by the OEM 16:40:06 Junichi: who will be providing the tokens in this model? 16:40:29 Kevin: it will mostly be the managed data service provider who will provide those 16:40:37 Junichi: outside of the vehicle? 16:40:39 Kevin: yes 16:40:51 … one of the main reasons is to authenticate the user and data services 16:41:23 Junichi: both browser and native applications would need to use these tokens? 16:41:52 Kevin: if the application is interacting with information from the vehicle then yes it would need a token 16:42:26 … vehicles will need a token to be able to interact with outside world 16:43:18 … 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 16:43:38 Rudi: we are developing an open source framework called Remote Vehicle Interaction for this 16:44:16 … this can be extended to services running on phones as well. there is a strong security concept associated with that 16:44:33 … a device needs to provide a certificate that it is allowed to invoke certain services on the vehicle 16:44:45 … we can elaborate about that more next week and make a presentation 16:45:16 Paul: this candidate architecture helps focus the discussion so it would be good to explore more next week 16:45:21 … thank you Kevin 16:45:52 Junichi: is the token visible to the application itself or not? 16:46:53 Kevin: for web runtime (app environment) clients that is definitely the case, for browser (interaction with web directly) it could be 16:48:43 … I want to see if we can open up browser enough to permit this. I want to see this working for myself 16:48:43 q+ to mention there is a CDM-related spec for HTML5 named Encrypted Media Extension: https://www.w3.org/html/media/ 16:50:30 Rudi: there can be different certificates models for these paths 16:51:56 Peter: what are our deliverables here? previously it was clear that we would have a WebIDL for Vehicle API and guidelines for security concerns 16:52:17 Paul: we have a layered approach now 16:52:48 … a RESTful web [socket] service and JS library that allows higher level access 16:52:59 s/access/abstraction/ 16:53:22 … we need to see how this is going to be used to come up with ways to protect it 16:54:05 … clearly, either token or otherwise, needs to be authorized to talk with the vehicle and we need to control interactions with the outside world 16:54:36 q- as Volker covered core of my questions and time is running out 16:54:38 q- 16:54:42 q? 16:55:09 Paul: we have been meandering and need to settle this and focus so we can move forward 16:55:26 … we need to nail it down during the F2F 16:55:44 … this architecture is a variation of others I have seen 16:55:59 … this resembles the LBS Genivi model from Phillippe Colliot 16:56:20 … settling on the architecture will help 16:56:30 Dave: this is a great diagram 16:57:07 … we should take a look at servient architecture 16:57:14 -> w3c.github.io/wot/architecture/wot-architecture.html WoT architecture document 16:57:24 Kaz: you mean the web of things proposal? 16:57:35 Dave: yes, there are some similarities here 16:57:53 s/here/here with your application server/ 16:58:02 Kevin: it can be structured a number of ways 16:58:20 Kaz: WoT had its F2F last week 16:58:30 Paul: Sonya will be attending our F2F as well 16:58:43 Kaz: we should be able to have some good discussions about possible integration 16:59:17 Paul: he is on the schedule for Friday. Kaz can you ask if he will be around Thursday too? 16:59:57 Kaz: ok 17:00:23 Paul: I'll see everyone next week and I encourage people to sends questions to list (or issues) as appropriate 17:00:24 I have made the request to generate http://www.w3.org/2016/04/19-auto-minutes.html ted 17:00:28 -> http://www.w3.org/2016/04/WoT-vehicles_W3CTrack.pdf Soumya's slides in Montreal 17:00:30 I have made the request to generate http://www.w3.org/2016/04/19-auto-minutes.html ted 19:00:29 Zakim has left #auto 21:15:04 ahaller2 has joined #auto 22:55:18 ahaller2 has joined #auto 23:12:03 ahaller2 has joined #auto