W3C home > Mailing lists > Public > public-automotive@w3.org > July 2016

[portland-f2f] minutes - Day 2 - 27 July 2016

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Thu, 28 Jul 2016 22:41:17 +0900
Message-ID: <CAJ8iq9UMi0BpAgQovBapM65kgmAxCpPU49D+Vg_-SF-RQ53x+w@mail.gmail.com>
To: public-automotive <public-automotive@w3.org>
available at:
  https://www.w3.org/2016/07/27-auto-minutes.html

also as text below.

Thanks,

Kazuyuki

---
   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

             Automotive WG F2F Meeting in Portland - Day 2

27 Jul 2016

   [2]group photo

      [2] https://www.w3.org/auto-f2f/photos/27/DSC_0139.JPG

   See also: [3]IRC log

      [3] http://www.w3.org/2016/07/27-auto-irc

Attendees

   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), Paul_Boyes(INRIX), Sanjeev_Ba(Samsung;
          remote)

   Regrets
   Chair
          Rudi, Peter

   Scribe
          ted, kaz

Contents

     * [4]Topics
         1. [5]Tuesday recap
         2. [6]Security and Privacy
         3. [7]Web Socket Server
         4. [8]OSTC1 Tour
         5. [9]OCF Update
         6. [10]HERE
         7. [11]ITU
         8. [12]Amendment of the WG Charter
     * [13]Summary of Action Items
     * [14]Summary of Resolutions
     __________________________________________________________

   <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>
   [15]http://w3c.github.io/automotive/vehicle_data/security/

     [15] 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> [16]http://www.w3.org/auto/wg/track/issues/1

     [16] 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>
   [17]https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service
   _Specification

     [17]
https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification

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

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

Web Socket Server

   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
   [18]http://www.ietf.org/rfc/rfc6763.txt

     [18] http://www.ietf.org/rfc/rfc6763.txt

   song: starts to draw a diagram
   [19]Song's diagram

     [19] https://www.w3.org/auto-f2f/photos/27/DSC_0132.JPG

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

     [20] https://www.websocket.org/aboutwebsocket.html

   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>
   [21]https://developer.mozilla.org/en-US/docs/Web/API/WebSockets
   _API/Writing_WebSocket_servers#Subprotocols

     [21]
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#Subprotocols

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

     [22] https://tools.ietf.org/html/rfc6455#section-11.5

   rudi: how to handle the WS sub protocol?

   powerll: initial web socket handshake

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

     [23] 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> [24]https://tools.ietf.org/html/rfc7936

     [24] 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>
   [25]http://blog.arungupta.me/rest-vs-websocket-comparison-bench
   marks/

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

   <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

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

     [26]
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.
   ([27]http://360.here.com/2016/06/28/here-standard-for-shared-ca
   r-data-wins-pan-european-backing/)

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

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

     [28] https://www.w3.org/2014/automotive/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

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

     [29] https://www.w3.org/2002/09/wbs/35125/TPAC2016/?login

   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

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

     [30]
https://github.com/w3c/charter-drafts/blob/gh-pages/charter-template.html

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

     [31] https://w3c.github.io/charter-drafts/charter-template.html

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

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

Summary of Action Items

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [33]scribe.perl version
    1.144 ([34]CVS log)
    $Date: 2016/07/28 13:37:41 $

     [33] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [34] http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 28 July 2016 13:42:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 24 October 2017 18:52:51 UTC