<inserted> scribenick: ted

Tuesday recap

-Agreement on moving forward with VSS

-Add branch for static/configuration data (Magnus F)

-Add chassis information (Peter H)

-Continue to use row * column * level zone model for simple location eg body.door.front.left

-Adopt ISO8855 in VSS for for high precision location designation for sensors, cameras etc (Magnus F)

-Add access mode to signals ([r]ead [w]rite rw) VSS provides a default and OEM can restrict further with authorization model

-JS library

-WG members will implement a reference library, multiple are encouraged

-APIs for getting, setting, subscribing and unsubscribing to signals

-Set of APIs to query Vehicle Object Model as described by VSS

-if there is sufficient support the current Vehicle Information Access API could be the higher level wrapper around the service API

-CarFit presentation

action Kaz to survey Japanese OEM on interest in web socket and WebIDL approaches

<trackbot> Created ACTION-19 - Survey japanese oem on interest in web socket and webidl approaches [on Kazuyuki Ashimura - due 2016-08-03].

-Security and Privacy, token model with a sequence diagram from Powell

Security and Privacy

[Powell reviews his diagram which he'll export and add to wiki]

Powell: ...VSS discovery will depend on tokens
... some signals allowed without authentication
... case where client asks for signal that requires authorization. it goes out to oauth server or other model to acquire token
... server verifies token with auth source, server is responsible for enforcing policies
... choice of token generation, storage and verification is outside of the scope of our work, oauth is just one possibility we covered

Junichi: should we describe in the spec which data points require authentication

Kevin: that is up to the OEM

Powell: yes except perhaps the non-public VSS discovery

Song: what happens when the token expires?

Powell: you get a 403
... I could have an active subscription with a token that expires before closing that connection

[discussion on how to handle it and options available to implementors]

Kevin: diagram is great. It would be nice to have the multiple token scenario we discussed yesterday

Powell: I'll work on token expiration, multiple token and async token verification scenarios

<inserted> scribenick: kaz

junichi: show slides on security&privacy
... guideline here

<AdamC> http://w3c.github.io/automotive/vehicle_data/security/

junichi: put into several categories
... discussion on the service interface has started
... so may be delayed
... (Guideline TODO)
... Revise
... sec 2. ue case: categorization
... sec 5. vehicle specific requirements and strategies: mapping table from use cases to requrements
... all: RFC2119 conventions, workding
... need feedback from vehicle service spec viewpoint
... that should refer to the security/privacy guideline
... (Vehicle Information Service Specification)
... availability: need common/unique entry point
... wss://localhost:4343 or wss://mycar
... (Liaison&Collaboration)
... list of security-related groups
... re ones should be focused
... Web Authentication WG (working on FIDO 2.0)
... Web Application Security WG (Mixed Content)
... https for all other domains
... wss for local connection
... discussion on "secure communication with local network devices" during TPAC 2015
... to establish our security mechanism
... for TV use cases, there is no router inside
... we have to think about that
... Web of Things IG has similar discussion on hardware and security
... if you have any ideas, let me know

rudi: Web Authentication, etc., should be applied at some extent

junichi: shows th Charter of the Web Authentication WG
... 2 derivelables, Web Authentication API, Data and signature formats
... we should focus on this group

rudi: standardization work by the Web Application Security WG

junichi: they don't have token-based work
... almost all their work is based on the same origin model

adam: do we want to mandate the use of token?

rudi: interoperability should be considered

powell: JWT format
... application specific

junichi: we might standardize the way of token, etc.
... but currently out of scope
... JWT would be the starting point for the future work

rudi: token-based format
... token has to contain time information
... e.g., specified by UTC
... we don't specify how the server interprets it

powell: we could specify messages for clients

junichi: we need scenario-based investigation
... where to put this kind of information?
... e.g., Powell's ladder diagram

paul: good thing of GitHub is we can use wiki and also issue tracker

rudi: we started with wiki

paul: GitHub is simple enough to use
... even just for issue tracking

rudi: tracking artifacts too

kaz: if we use README on GitHub, that is kind of wiki

<ted> trackbot, status?

<ted> issue-1?

<trackbot> 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

<trackbot> http://www.w3.org/auto/wg/track/issues/1

rudi: what is the issue tracking mechanism for the minutes?

kaz: that's W3C Issue Tracker tied with the IRC
... and W3C email archive

ted: mentions the Web Authentication work

rudi: we've defined the flow for token handling
... Powell has generated a ladder diagram
... what does the token authorize?

<ted> (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)

kevin: current stateful authorization

rudi: absolute time point by UTC, etc.

kevin: authorize sustainable position

powell: is that all on security?
... we should capture all the best practices

kevin: at the moment, there is a wiki page

<AdamC> https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification

rudi: we're done with security and move forward?

Web Socket Server

kevin: shows the wiki of the Vehicle Information Service Specification
... localhost vs wwwivi (as 127.0.0.1)

rudi: Initialisation of the Web Socket
... W3C Vehicle API Component Diagram

<ted> 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

song: starts to draw a diagram

<ted> [unsure how to handle outside vehicle clients]

<ted> [unless vehicle registers its public ip, if oem even want to permit outside connections]

paul: the blue network is the same network in the car?

song: yes

paul: do we want to have others on the same network?

kevin: internet connection is allowed only via the Agents

rudi: the vehicle itself has some IP address

paul: this diagram (=W3C Vehicle API Component Diagram) captures the issue

rudi: in the car we need to use some local name resolution mechanism

kevin: Browser(Web page) can't be directly connected to the server on the vehicle

paul: what do we need to add to this diagram (=W3C Vehicle API Component Diagram)?

<ted> [ 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]

ted: switch over to websocket using the same port

song: will redraw the diagram

kevin: how do we differentiate our own WebSocket connection from general ones?

adam: adds TODO update path to route multiple sockets through the same server

ted: you can remove the port number (4343) from the wss URI

adam: removes "4343" and make the URI "wss://wwwivi"
... by using wss, the port will default to 443

<PowellKinney> https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#Subprotocols

<PowellKinney> https://tools.ietf.org/html/rfc6455#section-11.5

rudi: how to handle the WS sub protocol?

powerll: initial web socket handshake

<Paul> http://www.iana.org/assignments/websocket/websocket.xhtml

adam: sub protocol name will always be "VISS" and with a version number suffix, e.g. "VISS1.0"

<PowellKinney> https://tools.ietf.org/html/rfc7936

peter: why do we need restful websocket?

rudi: the Internet side service could be provided by REST-based cloud service

paul: what about performance?

rudi: RESTful Web services are out of scope for the first revision of this specification
... but could be considered for addition in a later version

<Paul> http://blog.arungupta.me/rest-vs-websocket-comparison-benchmarks/

adam: TODO remove and/or websockets and RESTful Web services elsewhere in the document.

[ Paul, I also compared the benchmark between REST and WS 3-4 years ago :) ]

rudi: "Message Structure" after lunch

[ lunch ]

<ted> scribenick: ted

OSTC1 Tour

OCF Update

Sanjeev's slides

<inserted> scribenick: ted

Sanjeev: I have sent a couple emails and a pull request
... contributing version of RVI library
... I had to initiate an automotive project within OCF
... we are showcasing what we have done to OCF
... we organized a meeting during the OCF F2F
... we had a few months of reviews and feedback. we are expecting approval today
... we delivered three use cases to OCF
... mapping VSS branches to to OCF resource types
... we are using web linking (rfc 6690, 5988)
... we had to create OCF resource type definitions for vss
... we have issues trying to differentiate between eg and cabin and body light
... we are setting up liaisons with W3C, Genivi, OM Auto (October 2016)
... our eventual goal is to have a joint interop demo

Kaz: there are some more demo opportunities including at TPAC in Lisbon
... are you planning on being there?

Sanjeev: probably not

Wonsuk: as you know we're going web socket. OCF is going with CoAP
... it would be good to coordinate these standards

Sanjeev: open to that idea and want to figure out the best way to bridge them

Rudi: what are the current thoughts on the interop demo?

Sanjeev: I can try to coordinate with my colleagues and it will be dependent on the progress we make in the next four month

<AdamC> @ted CoAP I believe

Rudi asks about the VSS YAML to OCF RAML tool

scribe: wonder how we can coordinate better with Iotivity
... Powell is interested in exposing our web socket through Iotivity

Powell: web socket system running on IVI could communicate to OCF server somewhere else in the world

Sanjeev: we need to find the right balance on amount of data we're sending

[discussion on Genivi AMM venue for a possible demo]

Ted: Steve Crumb asked me by email today if we want to collocate and meet at their AMM in Burlingame

Rudi: Let's decide here and now

Paul: several of us will already be there and these make the most sense

Rudi: why don't you respond to Steve that we will be there and ideally be presenting on progress

Paul: individual schedules around these meetings vary so we should settle on specific F2F dates

Sanjeev: I'm inclined to host this under Iotivity repo

Rudi: any objection from others?

Sanjeev: some parts can make sense under W3C repo

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

Sanjeev: I'll reflect and discuss that more here

Rudi: we'll be driving the specification forward and coordinate with you on VSS+socket server to OCF

HERE

https://company.here.com/automotive/new-innovations/sensor-ingestion/

Paul: we had a couple HERE engineers join us at our F2F in Seattle last year
... there was some back and forth on this proposal after

Rudi: basically it is about sending data off to the cloud

Paul: who is using this?
... this is interesting but not an open environment

Kevin: this is useful for ADAS research etc and another silo comparable to Google

Rudi: this relates to what we are doing to some extent, question is what do we do?

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

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)

Paul: 16 car companies were involved in HERE effort
... the question is why did they participate in this and not on our side?

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
... that would be useful for others

Kevin: as a courtesty maybe we should reopen communication

Paul: conversation last year just fizzled out
... it would be great to standardize the server side ingestion as well
... it shouldn't be a big deal to come up with that from our platform

Hira: ERTICO says on their site intent to make this an open standard

<hira> 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/)

Rudi: why don't we reopen dialogue with them?

Paul: sure, I'll start a thread back up

ITU

Kaz: on the 4th and 5th of July Hira and I joined ITU event on future of connected vehicles
... I gave a presentation on our automotive standardization work

[presenting agenda for second day]

Kaz: their Vehicle Gateway Proxy is about connecting cloud services and vehicles
... I suggest we read their documents and provide feedback

[VGP is V2X - sending information between vehicles, cloud, phones, signs, tolls etc]

Rudi: wonder how much this relates to us and whether we need to engage them
... probably worth keeping it on our observation list

Kaz: I will be going to a workshop on IoT and automotive being organized by IEEE
... I'll report back on that workshop. one of their focuses is on security aspects

Rudi: Genivi is rechartering their security work and looking to liaison

Junichi: Genivi is looking at SOTA more

Rudi: also worth following but doesn't concern what we are doing directly from what I see
... thank you Kaz, please continue to follow this and keep us posted

<kaz> [ afternoon break ]

<kaz> scribenick: kaz

Amendment of the WG Charter

-> https://www.w3.org/2014/automotive/charter current charter

paul: timeline and deliverables

kaz: extended till the end of September

ted: should be updated with our needed deliverables and reasonable timeline

paul: scope should be extended with the vehicle service
... service spec
... reference API spec
... VSS and data model
... test specifications, API and service spec
... do we need to mention reference implementation?

ted: no, we don't need to mention that within the Charter

paul: we need to go through this document
... can provide draft updated text for the scope section
... what about test suite?

ted: already mentioned in the "other deliverables" section
... we need to consider the timeline in addition to the deliverables

paul: service spec, API library spec and test suite?

<ted> Kaz: test suite is not a REC-track doc. also template has changed as well. we don't need to use table view for milestones

hira: would like to finish the test suite work by March 2017

<ted> q4 2016 fpwd, q1 2017 cr, q2 2017 pr, q3 2017 rec

<ted> Kaz suggests condensing rec into q2 2017

hira: would suggest we aim q3 2016 for fpwd

<ted> [goal to have fpwd before Genivi AMM in mid October]

<ted> Kevin: would be good to have fpwd for TPAC

paul: Automotive WG meeting is registered

-> https://www.w3.org/2002/09/wbs/35125/TPAC2016/?login TPAC registration form

wonsuk: would be better to get review by the GENIVI side
... so think it would be better to publish the FPWD in October

(discussion on VSS)

wonsuk: we should have some simple spec for VSS, e.g., as datamodel snapshot

ted: may have maintenance work including VSS, media tuner, etc.

<ted> [VSS may continue to evolve with additional signals beyond when the W3C WG is done with the deliverables for service and JS API. when we publish we should state what version of VSS we tested against]

<ted> [we should also state we expect to be future proof with subsequent VSS. VSS work should remain at Genivi]

hira: three deliverables in the end?
... service spec, JS spec and VSS?

paul: VSS is rather snapshop

kaz: will generate a template HTML for the updated WG Charter under the W3C/Automotive GitHub repo

-> https://github.com/w3c/charter-drafts/blob/gh-pages/charter-template.html new charter template

-> https://w3c.github.io/charter-drafts/charter-template.html HTML version of the template

<scribe> ACTION: kaz to generate a template HTML for the updated WG Charter under the W3C/Automotive GitHub repo [recorded in http://www.w3.org/2016/07/27-auto-minutes.html#action01]

<trackbot> Created ACTION-20 - Generate a template html for the updated wg charter under the w3c/automotive github repo [on Kazuyuki Ashimura - due 2016-08-04].

kaz: please note that we need a specific editor for the spec drafts

paul: Powell would be a good candidate for the service spec

(some more discussion expected tomorrow morning)

[ Day 2 adjourned ]