- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Tue, 2 Aug 2016 13:31:33 +0900
- To: public-automotive <public-automotive@w3.org>
- Message-ID: <CAJ8iq9XNJsHYLBK2Cesx18drdEqoLbzFieoyjwE_wA7-pHjAVA@mail.gmail.com>
Hi group, Sanjeev's slides on OCF update has been added to the minutes from Day 2 (July 27th) at: https://www.w3.org/2016/07/27-auto-minutes.html#item05 The presentation slides (PDF) themselves are available at: https://www.w3.org/2016/07/auto-f2f/slides/W3C_Auto_OCF_Presentation.pdf 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 Tuesday, 2 August 2016 04:39:15 UTC