00:04:37 Song: everything is based on same origin policy 00:07:25 Kevin: I am not sure we need to solve the application distribution problem 00:07:39 Powell: correct, we can just say you need a token 00:08:41 Rudi: token is signed by OEM and when the token is verified, specific information that can be shared with the application a UI can prompt user to opt in 00:09:07 … subsequent times the app is run the IVI system will know it went through the verification and opt in 00:11:09 I have made the request to generate http://www.w3.org/2016/07/27-auto-minutes.html ted 00:20:09 Ted: you can send a subscribe to top of the tree with your token and get back all the data elements you are entitled to 00:20:57 Kevin: yes and a scenario is you might have a priviledged application like ADAS that is allowed full access 00:51:03 [whiteboard exercise led by Powell going over client server token interactions, verification] 00:51:17 I have made the request to generate http://www.w3.org/2016/07/27-auto-minutes.html ted 01:02:54 powell's picture 01:03:00 rrsagent, draft minutes 01:03:00 I have made the request to generate http://www.w3.org/2016/07/27-auto-minutes.html kaz 03:44:20 yingying has joined #auto 03:54:09 yingying_ has joined #auto 05:52:22 kaz has joined #auto 05:53:14 yingying_ has joined #auto 15:40:28 RRSAgent has joined #auto 15:40:28 logging to http://www.w3.org/2016/07/27-auto-irc 15:49:30 rrsagent, draft minutes 15:49:30 I have made the request to generate http://www.w3.org/2016/07/27-auto-minutes.html kaz 15:50:14 Day2 starts here 16:08:17 junichi-hashimoto has joined #auto 16:16:01 AdamC has joined #auto 16:22:50 hira has joined #auto 16:24:06 Topic: Tuesday recap 16:24:16 -Agreement on moving forward with VSS 16:24:33 -Add branch for static/configuration data (Magnus F) 16:24:44 -Add chassis information (Peter H) 16:25:18 -Continue to use row * column * level zone model for simple location eg body.door.front.left 16:26:07 -Adopt ISO8855 in VSS for for high precision location designation for sensors, cameras etc (Magnus F) 16:26:52 -Add access mode to signals ([r]ead [w]rite rw) VSS provides a default and OEM can restrict further with authorization model 16:27:14 -JS library 16:27:36 -WG members will implement a reference library, multiple are encouraged 16:28:14 -APIs for getting, setting, subscribing and unsubscribing to signals 16:28:33 -Set of APIs to query Vehicle Object Model as described by VSS 16:29:13 -if there is sufficient support the current Vehicle Information Access API could be the higher level wrapper around the service API 16:29:28 -CarFit presentation 16:31:47 action Kaz to survey Japanese OEM on interest in web socket and WebIDL approaches 16:31:47 Created ACTION-19 - Survey japanese oem on interest in web socket and webidl approaches [on Kazuyuki Ashimura - due 2016-08-03]. 16:32:40 -Security and Privacy, token model with a sequence diagram from Powell 16:32:47 wonsuk has joined #auto 16:34:32 present: Rudolf_Streif(JLR), Kevin_Gavigan(JLR), Adam_Crofts(JLR), Joonhyung_Kim(LG_Electronics), Wonsuk_Lee(ETRI), Song_Li(Newsky_Security), Powell_Kinney(Vinli), Peter_Winzell(Mitsubushi), Junichi_Hashimoto(KDDI), Shinjiro_Urata(ACCESS), Tatsuhiko_Hirabayashi(KDDI), Kaz_Ashimura(W3C), Ted_Guild(W3C) 16:34:40 rrsagent, draft minutes 16:34:40 I have made the request to generate http://www.w3.org/2016/07/27-auto-minutes.html kaz 16:34:51 Topic: Security and Privacy 16:35:05 Chair: Rudi, Peter 16:35:08 rrsagent, draft minutes 16:35:08 I have made the request to generate http://www.w3.org/2016/07/27-auto-minutes.html kaz 16:35:12 [Powell reviews his diagram which he'll export and add to wiki] 16:35:33 Powell: ...VSS discovery will depend on tokens 16:35:42 … some signals allowed without authentication 16:36:35 … case where client asks for signal that requires authorization. it goes out to oauth server or other model to acquire token 16:37:14 … server verifies token with auth source, server is responsible for enforcing policies 16:40:06 … choice of token generation, storage and verification is outside of the scope of our work, oauth is just one possibility we covered 16:40:41 Junichi: should we describe in the spec which data points require authentication 16:40:46 Kevin: that is up to the OEM 16:41:17 Powell: yes except perhaps the non-public VSS discovery 16:42:17 present+ Paul_Boyes(INRIX) 16:48:25 Song: what happens when the token expires? 16:48:34 Powell: you get a 403 16:50:27 jkim has joined #auto 16:50:42 … I could have an active subscription with a token that expires before closing that connection 16:50:59 [discussion on how to handle it and options available to implementors] 16:52:21 Karen_ has joined #auto 16:52:52 Kevin: diagram is great. It would be nice to have the multiple token scenario we discussed yesterday 16:53:01 I have made the request to generate http://www.w3.org/2016/07/27-auto-minutes.html ted 16:53:52 ted has changed the topic to: remote connection information for day 2 of Auto F2F https://lists.w3.org/Archives/Member/member-automotive/2016Jul/0021.html 16:55:44 Kevin: I'll work on token expiration, multiple token and async token verification scenarios 16:55:53 AdamC has joined #auto 16:56:00 s/Kevin: I'll work/Powell: I'll work/ 17:18:38 junichi: show slides on security&privacy 17:18:46 ... guideline here 17:19:18 KevG has joined #auto 17:19:48 http://w3c.github.io/automotive/vehicle_data/security/ 17:20:41 junichi: put into several categories 17:21:15 ... discussion on the service interface has started 17:21:20 ... so may be delayed 17:21:26 ... (Guideline TODO) 17:21:32 ... Revise 17:21:47 ... sec 2. ue case: categorization 17:22:26 ... sec 5. vehicle specific requirements and strategies: mapping table from use cases to requrements 17:22:40 ... all: RFC2119 conventions, workding 17:37:18 ... need feedback from vehicle service spec viewpoint 17:38:01 ... that should refer to the security/privacy guideline 17:38:13 ... (Vehicle Information Service Specification) 17:38:51 ... availability: need common/unique entry point 17:39:11 ... wss://localhost:4343 or wss://mycar 17:39:18 ... (Liaison&Collaboration) 17:39:45 ... list of security-related groups 17:40:02 ... re ones should be focused 17:40:27 ... Web Authentication WG (working on FIDO 2.0) 17:41:02 ... Web Application Security WG (Mixed Content) 17:41:19 ... https for all other domains 17:41:38 ... wss for local connection 17:42:25 ... discussion on "secure communication with local network devices" during TPAC 2015 17:42:48 ... to establish our security mechanism 17:43:01 ... for TV use cases, there is no router inside 17:43:13 ... we have to think about that 17:43:44 ... Web of Things IG has similar discussion on hardware and security 17:44:23 ... if you have any ideas, let me know 17:44:47 rudi: Web Authentication, etc., should be applied at some extent 17:45:09 junichi: shows th Charter of the Web Authentication WG 17:45:43 ... 2 derivelables, Web Authentication API, Data and signature formats 17:46:00 ... we should focus on this group 17:46:42 rudi: standardization work by the Web Application Security WG 17:47:00 junichi: they don't have token-based work 17:47:22 q+ 17:47:36 ... almost all their work is based on the same origin model 17:48:44 adam: do we want to mandate the use of token? 17:49:01 rudi: interoperability should be considered 17:49:17 powell: JWT format 17:49:44 ... application specific 17:50:34 junichi: we might standardize the way of token, etc. 17:50:43 ... but currently out of scope 17:51:01 ... JWT would be the starting point for the future work 17:51:10 rudi: token-based format 17:51:22 ... token has to contain time information 17:51:32 ... e.g., specified by UTC 17:51:51 ... we don't specify how the server interprets it 17:52:09 powell: we could specify messages for clients 17:52:36 junichi: we need scenario-based investigation 17:52:48 ... where to put this kind of information? 17:53:02 ... e.g., Powell's ladder diagram 17:53:38 paul: good thing of GitHub is we can use wiki and also issue tracker 17:54:00 rudi: we started with wiki 17:54:22 paul: GitHub is simple enough to use 17:54:29 ... even just for issue tracking 17:54:43 rudi: tracking artifacts too 17:55:37 kaz: if we use README on GitHub, that is kind of wiki 17:56:04 trackbot, status? 17:56:10 issue-1? 17:56:10 issue-1 -- For remote controle and wake-up signal, we may need some mechanism to identify the state and the mode of the car, the web runtime and the application -- raised 17:56:10 http://www.w3.org/auto/wg/track/issues/1 17:56:22 rudi: what is the issue tracking mechanism for the minutes? 17:56:31 kaz: that's W3C Issue Tracker tied with the IRC 17:56:39 ... and W3C email archive 17:57:30 ted: mentions the Web Authentication work 17:58:04 rudi: we've defined the flow for token handling 17:58:11 ... Powell has generated a ladder diagram 17:58:36 ... what does the token authorize? 17:58:55 (if we were only handling web runtimes webauthn might be interesting but headless apps would not likely be in environment with that implemented. jwt may be more suitable) 17:59:09 kevin: current stateful authorization 17:59:26 rudi: absolute time point by UTC, etc. 18:01:01 kevin: authorize sustainable position 18:02:00 powell: is that all on security? 18:03:45 ... we should capture all the best practices 18:03:54 kevin: at the moment, there is a wiki page 18:04:24 peterw has joined #auto 18:04:53 paul has joined #auto 18:04:55 urata_access has joined #auto 18:04:56 Song has joined #auto 18:05:02 I have made the request to generate http://www.w3.org/2016/07/27-auto-minutes.html ted 18:05:40 i/Tuesday recap/scribenick: ted/ 18:05:43 https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification 18:06:04 i/show slides on/scribenick: kaz/ 18:06:09 I have made the request to generate http://www.w3.org/2016/07/27-auto-minutes.html ted 18:06:54 i/Song: everything/scribenick: ted/ 18:06:56 I have made the request to generate http://www.w3.org/2016/07/27-auto-minutes.html ted 18:09:44 kevin: shows the wiki of the Vehicle Information Service Specification 18:11:58 ... localhost vs wwwivi (as 127.0.0.1) 18:13:05 rudi: we're done with security and move forward? 18:13:51 topic: Web Socket Server 18:16:02 rudi: Initialisation of the Web Socket 18:18:50 ... W3C Vehicle API Component Diagram 18:21:28 ted: static hostname (not localhost) would be a good fallback but we can also consider dhcp service discovery http://www.ietf.org/rfc/rfc6763.txt 18:22:01 song: starts to draw a diagram 18:22:03 [unsure how to handle outside vehicle clients] 18:23:52 [unless vehicle registers its public ip, if oem even want to permit outside connections] 18:24:41 paul: the blue network is the same network in the car? 18:24:43 song: yes 18:25:01 paul: do we want to have others on the same network? 18:25:32 kevin: internet connection is allowed only via the Agents 18:25:56 wonsuk has joined #auto 18:26:23 wonsuk has left #auto 18:26:29 wonsuk_ has joined #auto 18:28:47 rudi: the vehicle itself has some IP address 18:31:12 paul: this diagram (=W3C Vehicle API Component Diagram) captures the issue 18:32:01 rudi: in the car we need to use some local name resolution mechanism 18:33:11 kevin: Browser(Web page) can't be directly connected to the server on the vehicle 18:34:29 paul: what do we need to add to this diagram (=W3C Vehicle API Component Diagram)? 18:35:24 [ https://www.websocket.org/aboutwebsocket.html suggest using existing traditional https port 443 for wss and upgrade connection instead of trying to register a port with IANA] 18:36:29 ted: switch over to websocket using the same port 18:45:13 song: will redraw the diagram 18:46:36 kevin: how do we differentiate our own WebSocket connection from general ones? 18:48:04 adam: adds TODO update path to route multiple sockets through the same server 18:48:47 ted: you can remove the port number (4343) from the wss URL 18:49:20 adam: removes "4343" and make the URL "wss://wwwivi" 18:49:39 ... by using wss, the port will default to 443 18:49:54 PowellKinney has joined #auto 18:49:57 https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#Subprotocols 18:50:50 https://tools.ietf.org/html/rfc6455#section-11.5 18:54:29 s/URL/URI/ 18:54:30 s/URL/URI/ 18:55:05 rudi: how to handle the WS sub protocol? 18:55:21 powerll: initial web socket handshake 19:00:25 Paul has joined #auto 19:00:36 http://www.iana.org/assignments/websocket/websocket.xhtml 19:00:49 adam: sub protocol name will always be "VISS" and with a version number suffix, e.g. "VISS1.0" 19:02:32 https://tools.ietf.org/html/rfc7936 19:13:02 peter: why do we need restful websocket? 19:13:27 junichi-hashimoto has joined #auto 19:14:46 rudi: the Internet side service could be provided by REST-based cloud service 19:17:45 paul: what about performance? 19:18:47 rudi: RESTful Web services are out of scope for the first revision of this specification 19:19:12 ... but could be considered for addition in a later version 19:19:26 http://blog.arungupta.me/rest-vs-websocket-comparison-benchmarks/ 19:20:15 adam: TODO remove and/or websockets and RESTful Web services elsewhere in the document. 19:22:39 [ Paul, I also compared the benchmark between REST and WS 3-4 years ago :) ] 19:25:20 rudi: "Message Structure" after lunch 19:25:24 [ lunch ] 19:25:30 rrsagent, draft minutes 19:25:30 I have made the request to generate http://www.w3.org/2016/07/27-auto-minutes.html kaz 22:00:00 scribenick: ted 22:03:46 kaz has joined #auto 22:05:22 jkim_ has joined #auto 22:06:05 topic: OSTC1 Tour 22:06:11 topic: OCF Update 22:06:20 present+ Sanjeev_Ba 22:06:38 sb: (Updates since April F2F) 22:07:12 Sanjeev: I have sent a couple emails and a pull request 22:07:34 i/Sanjeev:/scribenick: ted/ 22:07:40 … contributing version of RVI library 22:07:42 s/sb: (Updates since April F2F)// 22:08:06 … I had to initiate an automotive project within OCF 22:08:36 … we are showcasing what we have done to OCF 22:08:49 … we organized a meeting during the OCF F2F 22:09:40 … we had a few months of reviews and feedback. we are expecting approval today 22:11:18 … we delivered three use cases to OCF 22:12:17 … mapping VSS to OCF 22:12:38 … we are using web linking (rfc 6690, 5988) 22:13:36 s/mapping VSS to OCF/mapping VSS branches to to OCF resource types/ 22:14:09 … we had to create OCF resource type definitions for vss 22:14:56 … we have issues trying to differentiate between eg and cabin and body light 22:15:34 … we are setting up liaisons with W3C, Genivi, OM Auto (October 2016) 22:16:32 … our eventual goal is to have a joint interop demo 22:19:03 Kaz: there are some more demo opportunities including at TPAC in Lisbon 22:19:13 … are you planning on being there? 22:19:18 Sanjeev: probably not 22:20:48 wonsuk has joined #auto 22:22:04 AdamC has joined #auto 22:24:55 Wonsuk: as you know we're going web socket. OCF is going with @@protocol 22:25:09 … it would be good to coordinate these standards 22:25:41 Sanjeev: open to that idea and want to figure out the best way to bridge them 22:26:16 Rudi: what are the current thoughts on the interop demo? 22:27:24 Sanjeev: I can try to coordinate with my colleagues and it will be dependent on the progress we make in the next four month 22:27:31 @ted CoAP I believe 22:27:53 s/@@protocol/CoAP/ 22:28:26 Rudi asks about the VSS YAML to OCF RAML tool 22:28:55 … wonder how we can coordinate better with Iotivity 22:29:19 … Powell is interested in exposing our web socket through Iotivity 22:29:52 Powell: web socket system running on IVI could communicate to OCF server somewhere else in the world 22:31:00 Sanjeev: we need to find the right balance on amount of data we're sending 22:36:03 [discussion on Genivi AMM venue for a possible demo] 22:37:06 Ted: Steve Crumb asked me by email today if we want to collocate and meet at their AMM in Burlingame 22:37:12 Rudi: Let's decide here and now 22:37:27 Paul: several of us will already be there and these make the most sense 22:38:05 Rudi: why don't you respond to Steve that we will be there and ideally be presenting on progress 22:39:15 Paul: individual schedules around these meetings vary so we should settle on specific F2F dates 22:43:06 Sanjeev: I'm inclined to host this under Iotivity repo 22:43:14 Rudi: any objection from others? 22:43:32 Sanjeev: some parts can make sense under W3C repo 22:45:01 Ted: nice to have bits in both places to get interest from both sides, following logical lines of what belongs where but also may cause some confusion to have it split 22:45:13 Sanjeev: I'll reflect and discuss that more here 22:45:44 Rudi: we'll be driving the specification forward and coordinate with you on VSS+socket server to OCF 22:49:24 Topic: HERE 22:49:47 @@uri 22:50:53 Paul: we had a couple HERE engineers join us at our F2F in Seattle last year 22:51:09 … there was some back and forth on this proposal after 22:53:44 s|@@uri|https://company.here.com/automotive/new-innovations/sensor-ingestion/| 22:54:28 Rudi: basically it is about sending data off to the cloud 22:54:40 Paul: who is using this? 22:55:23 … this is interesting but not an open environment 22:55:50 Kevin: this is useful for ADAS research etc and another silo comparable to Google 22:57:16 Rudi: this relates to what we are doing to some extent, question is what do we do? 22:57:29 hira has joined #auto 22:58:38 Ted: anyone can use what we are working on for their business needs. we haven't talked to them in awhile and perhaps should let them know what we are up to 23:01:32 Kevin provides link to article where MS and Amazon are looking to become minority stake holders in HERE (previously Nokia and bought by German OEM consortium) 23:02:36 Paul: 16 car companies were involved in HERE effort 23:02:53 … the question is why did they participate in this and not on our side? 23:05:22 Ted: W3C is a proponent of open data but reality is people build silos. they may be willing to work with us to bridge what we are working on for aggregating and anonymizing data for intake 23:05:32 … that would be useful for others 23:05:56 Kevin: as a courtesty maybe we should reopen communication 23:06:25 Paul: conversation last year just fizzled out 23:06:42 … it would be great to standardize the server side ingestion as well 23:07:03 … it shouldn't be a big deal to come up with that from our platform 23:08:16 Hira: they say on their site intent to make this an open standard 23:08:57 It is announced ERTICO has agreed to evolve the design into a standardized interface specification for broad use across the automotive industry and is now the directing organisation of the SENSORIS forum. (http://360.here.com/2016/06/28/here-standard-for-shared-car-data-wins-pan-european-backing/) 23:09:15 Rudi: why don't we reopen dialogue with them? 23:09:33 Paul: sure, I'll start a thread back up 23:10:07 s/Hira: they say/Hira: ERTICO says/ 23:11:12 Topic: ITU 23:12:29 Kaz: on the 4th and 5th of July Hira and I joined ITU event on future of connected vehicles 23:12:52 … I gave a presentation on our automotive standardization work 23:16:00 [presenting agenda for second day] 23:18:28 Kaz: their Vehicle Gateway Proxy is about connecting cloud services and vehicles 23:18:47 … I suggest we read their documents and provide feedback 23:21:22 [VGP is V2X - sending information between vehicles, cloud, phones, signs, tolls etc] 23:22:07 Rudi: wonder how much this relates to us and whether we need to engage them 23:22:20 … probably worth keeping it on our observation list 23:24:20 Kaz: I will be going to a workshop being organized by IEEE 23:25:21 s/workshop being/workshop on IoT and automotive being/ 23:25:53 … I'll report back on that workshop. one of their focuses is on security aspects 23:26:11 Rudi: Genivi is rechartering their security work and looking to liaison 23:26:55 Junichi: Genivi is looking at SOTA more 23:27:29 Rudi: also worth following but doesn't concern what we are doing directly from what I see 23:28:07 … thank you Kaz, please continue to follow this and keep us posted 23:28:20 I have made the request to generate http://www.w3.org/2016/07/27-auto-minutes.html ted 23:28:59 [ afternoon break ] 23:29:12 rrsagent, draft minutes 23:29:12 I have made the request to generate http://www.w3.org/2016/07/27-auto-minutes.html kaz 23:57:04 scribenick: kaz 23:57:43 topic: Amendment of the WG Charter 23:58:03 -> https://www.w3.org/2014/automotive/charter current charter 23:58:17 paul: timeline and deliverables