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

[wg-charter] template for the draft WG Charter on GitHub (was Re: [portland-f2f] minutes - Day 2 - 27 July 2016)

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Thu, 28 Jul 2016 23:31:54 +0900
Message-ID: <CAJ8iq9XJkDHqd95neB2mydFUgL_fuDB8LszjZ9Guv7FdQ_hU9g@mail.gmail.com>
To: public-automotive <public-automotive@w3.org>
Hi co-Chairs and the group,

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

I got an action item to install the template for the new draft WG Charter
on GitHub during the meeting yesterday, and I've just done that.

Please see:
- repo:
https://github.com/w3c/automotive/blob/gh-pages/charter-2016/index.html
- HTML rendered version: https://w3c.github.io/automotive/charter-2016/

Thanks,

Kazuyuki


On Thu, Jul 28, 2016 at 10:41 PM, Kazuyuki Ashimura <ashimura@w3.org> wrote:

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


-- 
Kaz Ashimura, W3C Staff Contact for Auto, WoT, TV, MMI and Geo
Tel: +81 3 3516 2504
Received on Thursday, 28 July 2016 14:33:11 UTC

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