- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Thu, 28 Jul 2016 22:41:17 +0900
- To: public-automotive <public-automotive@w3.org>
- Message-ID: <CAJ8iq9UMi0BpAgQovBapM65kgmAxCpPU49D+Vg_-SF-RQ53x+w@mail.gmail.com>
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