Day 1

Introduction

<ted> scribenick: ted

Wonsuk: welcome to Auto WG meeting. we only have a partial turnout, the WG chairs aren't here and as BG chair I'm filling in
... there is another meeting in California next month which they and others will be in attendance

<urata_access> Hi, I can hear you.

<urata_access> ^_^

<hira> Hi, I'm attending meeting remotely.

<AdamC> Latest draft of Vehicle Signal Server Spec - https://w3c.github.io/automotive/vehicle_data/vehicle_information_service.html

Attendees: Raphael_Troncy(EURECOM), Jaesung_Han(Samsung), Wonsuk_Lee(ETRI), Ted_Guild(W3C), Kaz_Ashimura(W3C), Kevin_Gavigan(JLR), Adam_Crofts(JLR), Junya_Yoshida(Softbank), Matso_Suzuki(Softbank), YoungJae_Shin(Softbank), Yoshi_Tanaka(Softbank), Qing_An(Alibaba), Yingying_Chen(W3C), Junichi_Hashimoto(KDDI), Kazuaki_Nimura(Fujitsu), Tatsuhiko_Hirabayashi(KDDI), Shinjiro_Urata(ACCESS)

draft Vehicle Signal Server Spec

<kaz2> GitHub Repo

Kevin: the vehicle signal tree (vehicle object model - VOM) is ordered structurally so nodes are below logical parents

Adam: a quick example (example #1) shows establishing a web socket connection, application authorizing itself with an oauth token
... we use request ids to keep track of connections
... the code confirms the connection is established and then does a GET request for vehicle speed

Wonsuk: it is possible to do a get to see what parts of the tree are available before susbscribing

Adam: correct

Kevin: for subscriptions you will need your requestId
... we decided at the previous meeting to not bother using the id for a simple get
... in this example it confirms the return

[discussion of the higher level wrapper api, which will resemble the previous webidl approach and meant to be easier for web developers to use]

<scribe> scribenick: ted

Kevin: the server implementer (OEM) will impose access control for getting and more importantly setting signals

Wonsuk: the table of figures seems out of place here

Kevin: perhaps after TOC, not sure how to get it into the TOC since respec generates that
... introduction gives some background on vehicle network architecture, diagram is mean to help here
... there are two reasons why OEM want to protect these signals, business and security considerations
... in the diagram we distinguish web app and agent with the former being a browser interface the driver or a passenger is interacting with
... agent can be a headless service, for example aggregating information to send for off board (off vehicle) purposes
... native app/agent are other presentation platforms other than a browser/web runtime

[diagram showing external service interactions]

Kevin: the vehicle will not be addressed consistently as its dynamic IP address may be changing often
... the vehicle will need to send its information to an external service
... it is plausible but not advisable to keep track of the temporary IP and allow external interactions
... a V2X server can bridge interactions in a more controlled environment

[V2X - Vehicle To X - anything]

Wonsuk: what would be the protocol used?

Kevin: it could be anything and that is out of scope for what we're working on
... we added it since it is helpful to show the possibilities

Junichi: you could replace it with simply Internet

Kevin: true

Adam: it is for context

Junichi: do you intend to explain V2X more in this spec?

Kevin: in section "Sending Signals and Data off-board"
... we actually have multiple server roles, load balancers, etc in our particular setup
... main reason of having this in the spec is to explain that the vehicle needs to initiate the communication to the external server so it can in turn be contacted
... open to suggestions on improving clarity

Raphael: how coupled will the VSS be to this spec? will there be needs to revisit as VSS evolves?

Kevin: they will be independent but we will reference specific version of VSS with our publications

Raphael: what about the higher level client API?

Kevin: there will be some dependencies but hopefully we can minimize
... we have made a rather pronounced shift in how we approach this with this signal service spec compared to the previous spec

<kaz2> [ break for 30 mins]

<urata_access2> I leave for a while for battery reason.

Kevin: there is an example excerpt of a partial VSS tree
... there is a debate going on about including position for a node in a tree
... left wing mirror obviously is on the left side of the car
... we're arguing position as node versus a numeric index
... in some cases you won't care nor need to know where something is
... until this is settled our diagram will differ from VSS
... there is a get method to get the signal tree
... there is a section about getting signals off the vehicle that might do with a careful read on wording
... implementations by manufacturer will vary but applications built upon this spec can vary
... plus varying authentication levels
... we only cover two entities a user which might be a user or organization and other device
... a use case might be to allow emergency responders to disable [remaining] airbags but obviously you would not want to permit an attacker to do so
... device might be a driver assist (or autonomous) module that would use this spec to be able to send a set signal
... there might be a convoy of vehicles (V2V) that you would want share an alert about a hard braking event
... there will be cases where the combination of user and device will both need authentication to proceed
... an external security authority (out of scope for this spec) will issue user and device tokens
... the implementation of this service spec will be able to authenticate the tokens and impose proper access control

(see Figure 3)

Kevin: client could set auth token when prompted with a 401 or send it up front

Wonsuk: so the client can send the token only when needed

Ted: yes but the application might have more than one token and if denied with a given token could try another
... it might be worth adding a note for implementers to look for (in either server implementation or realtime log analyzer) to look for 401 loops to protect against dictionary style attack with a cache of stolen tokens

Kevin: client will need to reauthenticate if connection is closed
... we previously decided to require SSL for web sockets as a layer of defense

Junichi: an application can have more than one connection correct?

Kevin: yes

Junichi: then it would need to keep track of which connection has what access rights?

Kevin: correct, the application would need to keep track of its connections

Adam: we have touched on this topic before, the web socket can be established from a browser runtime or other app environment
... we have settled on wss://wwwivi for the local connection protocol and hostname uri

<urata_access> Hi, it looks webex audio has disconnected..

<hira> OK

<urata_access> Thanks!

Junichi: how would you handle other devices such as a smartphone in the car?

Kevin: the in-vehicle case can be handled by local wifi LAN routing to wwwivi
... outside the vehicle you would not want to permit a direct connection but to go through a V2X service managed by OEM

Wonsuk: wwwivi would route to IP

Kevin: correct and if the OEM chooses they may have the in-vehicle wifi LAN expose this hostname

Ted: it can impose firewalling to specific authenticated devices
... eg registering a MAC address (spoofable) for owner's phone so the LAN dhcp server gives it an IP within a trusted subnet on the LAN

(this would be on top of tokens for app on phone)

Junichi: is this testable?

Ted: it is, check the name resolution on the LAN replies for wwwivi. next test would be that you can open a wss connection with an ssl certificate that is verifiable, then a get to VSS results

Kevin: alternate is some sort of discovery mechanism

Ted: WoT or Device and Sensors groups might be working on that, we can ask

Philipp: I think they stopped work based on privacy concerns

Kaz: this might be a good topic with WoT folks this week
... not sure about the specific hostname, maybe something more generic

Kevin: sure but what should we call it?

Kaz: good question :)
... by generic I mean for accommodating other service roles
... we'll talk with WoT more

Adam: we are primarily using WebSocket.send and .onmessage
... we define all our corresponding get and set methods
... whenever the client sends a request to the server it expects requestId so it can keep track of connections on its side
... we've covered tokens. the timestamp is the time of the response from the server
... we are also returning a time to live (TTL) for the duration of the auth token

Junichi: what is the unit of measure for TTL, milliseconds?

Adam: good point, adding

Wonsuk: typically webIDL is for javascript APIs, not sure we should use some webIDL characteristics in this context

Kevin: we have seen others reference DOMstring in this manner
... we are trying to strike a balance here and chose to stick with types used in webIDL

[discussion on token expiration and renewal use case]

Kevin: these are the get request methods
... I have a preference for requestIDs here too but I was overruled at previous F2F...
... as such it is necessary to give enough information on the response so client can track it better
... you will get a success or error response but cannot be sure if there will be a subsequent and different response later

Adam: a classic example is time sensitive RPM signal data

QingAn: I can see a client sending multiple requests if it doesn't get a response quick enough
... even though you have timestamps on the responses you may ideally only want one response

Kevin: you can provide * wildcard in path to get for example all signal data for all doors at once

Adam: it would be up to the app developer to parse meaning such as left/right
... here is an example of making a request with an invalid path resulting in a 404
... I think these are helpful but wonder if there is a better way to represent this example in the spec

QingAn: it might be better to be able to discover/query the path available

Kevin: it is possible to ask for the whole tree, with their different access control

Ted: are we giving the whole tree or only what the current token is allowed to see?

Kevin: previously we resolved the whole tree
... which is why it is important to have a stable version of VSS in order for us to reference it when we publish

Wonsuk: what will be the format VSS will give us?

Kevin: VSS is YAML but implementers of our service spec will return JSON

Wonsuk: should we entertain multiple types of responses or stick with JSON?

Ted: that might get cumbersome and political so would suggest we stick with JSON initially for FPWD

Kevin: we could add a comment in the spec about future considerations

Ted: or create an issue in github which would allow for feedback on types desired

Adam: set methods are similar to get ones described

Kaz: WoT group has also been discussing type so perhaps a topic for our session with them

Adam: we have more detailed types of 404 responses - invalid path or private path

Kevin: even though we're returning JSON structures we felt sending http responses would be useful for web developers

Ted: private_path should be more of a forbidden
... also wonder about overloading error codes as we are. I don't have an answer for that and will need to think on who to ask
... fine as it is for now

Kevin: understood but there is a level of granularity for why you might be unauthorized that is helpful for the web developer
... we also left room for implementation specific error codes

Adam: we'll receive set status for lock signal sent (example)
... here is an example of trying to set RPM which is forbidden that gives the path as part of the response

Wonsuk: when client has VSS from the server and tries to parse it, how does it understand what it is permitted to do?
... is that described now or will be it be?

Adam: that is not part of VSS

Kevin: there was a discussion in Portland about providing this metadata
... for the time being we went the simpler route of showing the full tree
... basically you need to try to access (get or set) signal to see what is permitted and possibly try different tokens

Ted: it is a difficult problem but one that would be worth solving in the future given how widely permissions will vary by OEM, token
... app developers will have expectations but also need to fail gracefully when desired interaction isn't permitted

Kevin: there are two more sections to the spec is subscribe and unsubscribe

<urata_access> I leave again and back later.

<hira> I will be back at 2pm, too.

<kaz> [ lunch for 1 hour ]

<kaz> [ after lunch ]

<kaz> scribenick: kaz

Vehicle Service Spec (Contd.)

kevin: Subscibe and unsubscribe

-> http://w3c.github.io/automotive/vehicle_data/vehicle_information_service.html GitHub doc

kevin: explains what "subscribe" does

adam: explains "unsubscribe"
... unsubscribeRequest, unsubscribeSuccessResponse and unsubscribeErrorResponse
... examples on unsubscribing from a single subscription
... unsubscription from all subscriptions
... and error case (due to invalid ID)

wonsuk: branch of the VSS tree

kevin: the path could be the top of the tree
... and you can use the path flexibly

kaz: what would happen if somebody unsubscribe part of the VSS tree?

kevin: need to be exactly the same as the one used for subscribe

kaz: sounds reasonable

junichi: ID 0 is a wildcard?
... in case there is not subscription
... what would happen?

kevin: we should specify explicitly

adam: we need another user credential?

kevin: you have to close websocket connection

junichi: as a developer, want to open the websocket connection only once the app is invoked
... so should be just resetting the subscription rather than closing the websocket connection?

ted: the application may use one specific connection for multiple purposes

kevin: ok to send an authorization message?

ted: the developer may become confused

(some more discussion on how to handle multiple unsubscriptions)

ted: we should keep the model simpler

<ted> scribenick: ted

some of the nuances being discussed:

-in present scenario the developer would need to maintain different connections for different signal permissions

prompted with a 401 when trying to access a specific signal the app might try to close connection and reopen with different token[s] (user+device)

app would need to maintain a map of signals it wishes to follow and which connections have access to what, resubscribe accordingly when reconnecting

alternate idea is for an existing connection to be able to send additional tokens and for the server to determine the superset of signals information available for that combination

application code would likely be simpler with second approach

<scribe> scribenick: kaz

kaz: maybe better to have another explicit action for "unsubscribeAll" rather than using a specific magic number "0"?

kevin: sounds good

kaz: btw, this should be discussed tomorrow during the VSS session but Hira-san was wondering about the possible shorter alias for VSS paths

kevin: that's possible

adam: next
... 9. Server Side Filtering

-> http://w3c.github.io/automotive/vehicle_data/vehicle_information_service.html#server-side-filtering server side filtering

adam: goes through section "9. Server Side Filtering"

kaz: multiple elements for "range" tag means "and"
... and if we would like to mean "or", we need to your the filter once again

kevin: right

adam: When the range filter is used a final message will be sent when the value returned is outside of the specified range. For example, if the range states { "below": 100 }, a final value may be received at 101 to indicate that the value is now out of range.

junichi: what if I used very short term for the range?

kevin: may get 429 error

junichi: could I get the error immediately?

kaz: is your question related to who decides the minimum "interval"?

junichi: not really
... rather want to know when I can get the response

kaz: in that case, you want to know when the first response would come to you

kevin: there could be random delay for each signal transfered to the client

kaz: maybe would be better to have timestamp if there is random delay?

junichi: if the delay is too big, maybe I need to use "subscribe" again

<ted> kevin: i'm not sure if we have provisions for letting client know if connection is being closed

kaz: might want to have "maximum-acceptable-delay" as a filter tag?

kevin: maybe could use "subscriptionNotification" for that purpose

wonsuk: current spec couldn't cover when client requests for VSS branch.
... complicated to define the syntax...

kaz: Hashimoto-san, are you happy with the proposed solution?

junichi: would like to see the concrete text for that
... developers would like to know the response within certain time
... simple dialog is ok, though
... developers need to consider state chart diagram for this
... so we might want to generate some basic state handling model

wonsuk: we should clarify what should be included for the fpwd until when
... target publication day for that

ted: we could freeze the main branch

wonsuk: when would be the appropriate deadline?
... maybe before the GENIVI meeting in Oct.?
... from Oct. 18th

<junichi-hashimoto> developer have to imagine server state from its output. they would like to see state machine diaglam

wonsuk: so we might want to aim Oct. 7th as the target

ted: Kaz and I could work on that once getting the group approval
... we have to coordinate with the Webmaster for FPWD, CR, PR and REC

<ted> Proposed: publish vehicle signal service spec on 11 October

kaz: fyi, the MMI Architecture also has capability of state transition and event handling, so maybe it would be useful to have joint discussion with them

kevin: interesting idea
... maybe it would be possible to work on v2 version based on our spec and their spec

[ break till 4pm ]

<hira> WebEX has been disconnected!

<ying_ying> scribe: ying_ying

WG Rechartering

[some discussion on the timeline of the spec]

ted: we don't need to go through the new charter line by line. just some sections need to.

wonsuk and people are going through the scope section.

wonsuk: in the new timeline we will not work on REST. Better to remove it from scope.

kevin: yes.

wonsuk: we need to specify that first we will make the web socket service spec. Later we will work on REST.

-> http://w3c.github.io/automotive/charter-2016/index.html draft charter

[some discussion on the target vehicles for the spec. now it's limited to passenger vehicle]

Charter review

<ted> scribenick: ted

Ted: W3M has started reviewing, welcome suggestions from WG and will send email update and opportunity for corrections
... please do not make direct modifications but in a branch and send a pull request so I can have reviewers see diff
... we have extended the current charter through the end of the year while we recharter
... we have reviewed the current charter and should be able to publish fpwd of the vehicle signal server spec
... we likely will send this to the AC in a couple weeks

<scribe> scribenick: ying_ying

[some discussions on the deliverables]

wonsuk: how could we integrate the timeline into the deliverables expected completion date?

[review on other deliverables section]

junichi: do we have separate documents for use cases and requirements and implementation guidelines?

wonsuk: Ted do we need the document for use cases and requirements?

ted: we need a sort of document to help people understand the background.

wonsuk: for the vehicle data spec we have the section for use cases.
... one way is to move the use cases section to another document and elaborate it and provide a link in the web socket service spec.
... another way is to have it in the same spec.

example of use case document: http://w3c.github.io/wot/wot-ucr.html

wonsuk: what is your opinion Ted?

<AdamC> Security and Privacy Use Cases document - https://docs.google.com/spreadsheets/d/14ij-2I-H4HbilVQ_muCmUayVqmVfdbkoke690MA0kdo/edit#gid=1078984962

<ted> need supporting materials/explanation for client API - since that is derived from old webidl api perhaps we can find some materials

[kevin is going through the security and privacy use cases previously done.]

<junichi-hashimoto> https://w3c.github.io/automotive/vehicle_data/security/

junichi: I summarized 7 use cases in the security spec.
... I think use cases should be satisfied by the spec.

wonsuk: we need to make a decision.

ted: we need something to support the spec. I will take an action to follow up.
... we don't have the use cases for server spec but we could have it for client spec.

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

ted: we may have something for it but I am not sure what is it. Will check.

<scribe> ACTION: ted to check what we need for use cases to support the spec [recorded in http://www.w3.org/2016/09/19-auto-minutes.html#action01]

<trackbot> Created ACTION-24 - Check what we need for use cases to support the spec [on Ted Guild - due 2016-09-26].

wonsuk: do we need to add the security guideline here in other deliverables?

ted: we have the other non-normative document paragraph. I am fine with both: specifically or not.

wonsuk: any other comments on deliverables?

kevin: whether is the decision, suggest to keep the other non-normative document paragraph.

<scribe> ACTION: Adam to make a list of actions for the service spec(what needs to be done in the following months.) [recorded in http://www.w3.org/2016/09/19-auto-minutes.html#action02]

<trackbot> Created ACTION-25 - Make a list of actions for the service spec(what needs to be done in the following months.) [on Adam Crofts - due 2016-09-26].

[reviewing the timeline section]

wonsuk: could we change the PR time from July to Oct?

<ted> Maturity level for CR etc

wonsuk: because we need more time to exit the CR.

kevin: we can try our best to meet the timeline currently planned.

<hira_> As I mentioned in the last meeting, the end of March 2017 is preferable, in CR timing.

wonsuk: so we all agree to keep the current timeline.

[reviewing the liaison group list]

ted: please change the device API WG to generic sensor API WG.
... web of things IG is not there.

wonsuk: we have done.

[discussions on the topics of joint meeting with WoT tomorrow]

wonsuk: one topic might be WebIDL or other type when doing spec.

matthias: we are also working on data type. there is a talk from Google, schema.org.

wonsuk: this is tomorrow's agenda.
... could we follow the list Kaz sent out for topics of joint meeting with WoT?

matthias: are you interested in the general introduction of WoT, what are the building blocks we are working on?

wonsuk: yes.
... would create a wiki to add topics for the joint meeting.
... we will have a session for security and privacy. expect to have web security people.

ted: only 2 people responded. one will join this session.

wonsuk: any other suggestions for tomorrow's agenda?

[no]

[ Day 1 adjourned ]

---

Day 2

Auto BG update

<inserted> scribenick: ted

Wonsuk: we have two task forces, one on media tuning and other on location based services
... we are working on a draft for LBS and should hear more from Qing An
... for media tuning we are comparing use cases with tv controller api wg
... Ryan regularly joins their wg calls
... unfortunately he is not here to provide more details on their findings and any gaps
... perhaps Kaz as team contact there can provide some more information

Kaz: the expectation is the tv control specification will take into account Ryan's proposals
... it would also be nice if they changed their spec and variable names from tv to media

Wonsuk: Ryan already made a proposal including our use cases. have those been incorporated yet or still under discussion?

Kaz: still under discussion
... i wonder however if there should be some service level spec like we are doing for vehicle signals in addition to client side api

Wonsuk: we need to also line with Genivi

Kevin: there are others more involved in media in JLR than Adam or I

Adam: we have a[n internal] standard attribute naming convention

Kevin: drm is an issue in this area. there are often proprietary SDK necessary and not just opening a URI

<inserted> scribenick: kaz

(some more discussion on DRM and EME)

<hira> irc is still alive?

<hira> Could you open the files of powepoint and excel I sent by e-mail 7 hours before?

(disconnected from the Internet :( )

hira: question on the interface
... between what and what?

qa: trying to define some API which could be used commonly

kaz: this API is not WebSocket I/F layer but the Web App API I/F layer

hira: ok

wonsuk: what is your intention of this spec?
... Google has all the APIs to handle maps

qa: interact with the Map object
... different from the mobile map system
... for mobile apps, the user him/her-self handles the map apps
... however, in the driving case, most of the time the driver him/her-self doesn't want to handle the map apps
... so we need some more additional APIs to improve the user experience for driving use cases, e.g., controring the speed of map scroll
... many of the APIs could be similar to the Google Map API but we need to have some more universal API definition which could be applied to IVI use cases

kl: is it necessary to provide concrete Web APIs for that purpose?
... this API could be used within the car
... detailed Map API really needs to be (re)defined for IVI purposes?
... also maybe we should check the exisiting map-related APIs

qa: the reason why we need a Web API is the same as why we need vehicle information access API
... we need some method to access the information
... the second point is comparison with the exisiting map APIs
... not yet done the survey
... but we need a lot of addtional features than the existing Geolocation API

wonsuk: if Qing An is OK, we'd like to change the topic and continue this discussion in the afternoon, because we have Hira-san's comments on VSS and the joint session with the WoT IG

[ AM break for 15 mins ]

(network connection recovered)

VSS review - Hira

hira: yellow lines highlighted show missing features
... also location information is incompatible the existing Geolocation API
... some data is missing in both VSS and Vehicle data, e.g., fuel tank capacity, number of tires

kevin: good input

hira: comments appreciated

wonsuk: your proposal is very clear

ted: comments
... agree there are signals missing and they will extend over time
... they welcome contributions and would suggest doing so in logical modest sized pull requests in case any warrant further discussion before accepting

hira: user ID is important
... we've not defined user ID yet

<ted> some are controversial or open to debate such as vin (privacy but that can be addressed by access control) and number of doors is something that can be deduced with simple count of body.door.*

wonsuk: we need to keep discussing this topic
... and will discuss this during the upcoming Genivi meeting in October
... tx for your great contribution

<ted> [hira, looking at your spreadsheet more i wonder if you should use meters instead of centimeters for various things like acceleration]

<ted> [if your spreadhsheet of existing signals is correct it seems vss is inconsistent in units of measurement. grams in some places, kilos other, mm and inches. that might be because of what is commonly used terminology for a given part but in my opinion would be best to have in common]

<ted> [i'll take another look at vss and contact magnus about that]

Joint discussion with WoT

WoT guys have joined

introduction from the WoT side

Kajimoto: panasonic

Joerg: Siemens

Kangchan: ETRI

Matthias: Siemens

Wonsuk: ETRI

Sebasitian: Siemens

Ted: W3C

Kevin: JLR

Adam: JLR

Victor: Siemens

Natasha: GSMA

Matsumura: NHK

Daniel: Siemens

Takuki: Fujitsu

Bernard: W3C

Jonathan: ETRI

Michael: Intel

Kaz: W3C

Qing_An: Alibaba

Yingying: W3C

Junichi: KDDI

Hamid: Panasonic

Ohsumi: Panasoinc

Nunokawa: Keio

Andrei: UDL

Mohammed: Orange

Matsuo: Softbank

Yongjue: Softbank

wonsuk: shows the agenda on the screen
... current status
... host name of "wwwivi" and sub-protocol name
... description method
... HTTP error code
... security and privacy
... any comments?

mm: relationship with device and sensors?

ted: we had discussion with them

wonsuk: will explain the work of the Automotive WG

<urata_access> HI, It looks WebEx has disconnected..

<hira> WebEX has been disconnected!

<hira> TKS

kevin: we've changed our approach from JS API to WebSocket-based interface
... (shows Vechicle Signal Server spec)

<ted> [web socket service available in-vehicle network only]

@@@v

kevin: (shows slides)

@@@s

kevin: Proposed Vehicle Data Infrastructure

<ted> [800+ signals in Vehicle Signal Specification (VSS) at present and growing]

kevin: Data Structure (VSS) by GENIVI (Author: Magnus Feuer)
... Server Spec by W3C (Author: Kevin Gavigan, Adam Crofts)
... Client Spec by W3C (Author: Powell Kinney)
... (goes back to the spec draft)

<JonathanJ> tentative agenda - https://lists.w3.org/Archives/Public/public-wot-ig/2016Sep/0025.html

-> http://w3c.github.io/automotive/vehicle_data/vehicle_information_service.html spec draft

kevin: security and privacy considerations

mm: one on one security?

ted: token is used

seba: why do you define WebSocket connection?

kevin: initiated by Tobie from the Device API group
... as more generic interface

mm: can you bootstrap REST interface based on this?

kevin: JS library depends on the client spec
... (shows the architecture diagram)
... "System" at the bottom
... we need a secure gateway
... the "System" covers almost all the car environment
... (shows the VSS tree diagram)
... tree-based structure
... logical structure of vehicle-related signals

mm: popular design?

kevin: have been discussed within GENIVI
... (continues the explanation on the architecture diagram)
... WebSocket Vehicle Signal Server (WVSS)
... each node of the VSS tree is a class
... (goes back to the architecture diagram)
... JavaScript Library exposes high-level APIs for the Web clients

<ted> VSS

<ted> VSS presentation

ted: provides some more background information

mm: sounds like synchronized documents on two sides

kevin: the Vehicle Signal Client API is easier to handle for Web developers

matthias: why do you use websockets?
... sounds like reinventing protocols
... on the top of socket connection

kevin: good question
... WebSocket Vehicle Signal Server (WVSS) exposes Vehicle Signal Server API
... possibly with runtimes which don't have UI
... and possibly connected with devices without fixed IP address

daniel: data format?

kevin: first version considers JSON
... could add other formats later

ted: there are a number of different approaches
... subscription of data would make sense because data on vehicles is huge

mm: how to handle "sleep"?
... WebSocket connection always open?

kevin: examples of WebSocket APIs
... create WebSocket connection
... sending "ACTION: authorize"
... and the token
... and send "ACTION: get" with "path: signal.public.global.speed"
... another good example on "subscription"
... and message structure (http://w3c.github.io/automotive/vehicle_data/vehicle_information_service.html#message-structure)

mm: overlaps with CSS filtering and so on

Kevin: data tree search is similar to CSS filtering
... (explains the ladder diagram on the interface between the client and the server)
... this is the last slide
... client asks the server about "vehicle.speed" and the server responds to the client with the vehicle.speed

seba: access protection?
... only one way to handle the security token?

kevin: at the moment our spirit is to be open
... the client goes to some authority to get the token

mm: you have defined the mechanism inside
... don't care of the mechanism to get token from outside

seba: WoT's Thing Description also needs to handle security

kevin: the client should handle at least the error code of expired or invalid
... we can have a private tree

mm: one more thing to ask is use cases
... what kind use cases are in your scope?

kevin: getting/setting signal within the vehicle
... used on vehicle to talk with outside for convoy driving
... manufacturers need to see what to be exposed by the Vehicle Signal Specification
... VSS returns metadata

wonsuk: we're getting out of time

kaz: maybe would make sense to have joint calls on the regular basis?

matthias: should identify specific topics beforehand

WoT update

@@@slidesM

matthias: What is the Web of Things?
... Web of Things: applications
... W3C WoT Mission
... fill the gaps to interconnect different approaches by different consortia
... Status
... WoT IG for 1.5 years
... 4 IG Notes to be published
... several implementations based on the PlugFest experience
... AC review for WoT WG ongoing
... WoT demo on Wednesday at Auditorium III

wonsuk: when do you expect for the WG to get launched

matthias: in October?
... W3C WoT Building Blocks
... Protocol Bindings

<ying_ying> https://www.w3.org/WoT/IG/wiki/Roadmap

matthias: Thing Description
... Scripting API
... Cross-cutting Security & Privacy

-> http://w3c.github.io/wot/current-practices/wot-practices.html current practice doc

matthias: see the building blocks quickly
... Protocol binding
... Web API for Things
... various protocols
... multiple bindings per Thing possible
... Common Interaction Model
... Resource Model
... two loads: consuming Things is client role
... exposing Things is server role
... usually both roles at the same time
... so use "Servient" which has both the capabilities of server and client
... move on to Thing Description
... How to interact with Things?
... Thing Description (TD)
... linked data vocabularies
... no fixed classes or types but re-usable vocab
... machine-understandable semantics
... W3C Thing Description
... for now serialied as JSON-LD
... could be compressed using EXI, etc.
... extensible with domain-specific vocab
... maybe automotive or other consortia
... could be plugged in the Thing Description
... TD example (JSON-LD)
... @context, @type, name, uris, encodings, security, ...
... 3 interaction patterns: property, action and event
... next
... Scripting API
... common runtime enables portable apps
... from servient by vendor A to another servient by vendor B
... Discovery API, Server API and Client API
... Script example (Expose Thing)

mm: could be applied to virtual things

matthias: Script Example (Consume Thing) - client side
... summarization:
... Thing Implementation: WoT Servient
... application logic
... resource model
... Thing Description
... Thing Description includes all the metadata
... WoT Servient on Thing itself
... WoT Servient on Integration Hub
... WoT Servient in the Cloud
... Connected Car Scenario

kaji: the CAN layer is a proprietary layer
... on be half of the ECUs on CAN, the Gateway (as a WoT Servient) exposes data to the cloud side (as a WoT Client)

matthias: Online Resources
... we can continue discussions during break, etc.

wonsuk: questions?

kevin: how to manage trust?
... how to recognize if I can get connected

matthias: depending on the Web architecture
... we could use additional plugin to handle security to Thing Description
... we're not inventing new mechanism for security
... but working with IETF about authentication

mm: do we need some special mechanism for metadata?

kevin: we're working on the architecture document as well
... we can reuse the existing mechanism, e.g., OCF

(some more discussion about cooperation with other consortia)

matthias: shows the slide of "W3C WoT Mission"

kaz: the Automotive WG recenty has started its work on WebSocket-based generic client/server framework, so it might make sense for the WoT guys to see that framework as a possible infrastructure for the WoT Servient model
... also maybe automotive group might want the TD to have a capability to refer to external data definition, e.g., VSS

matthias: interesting point

seba: guess each manufacture has their own VSS tree?
... Thing Description is more abstract

kevin: powerful to have generalized level of data
... interested in how to bridge

mm: interested in finding use cases

kaji: shows a use case: Comfortable Welcome Home

mm: home and car, industry and car, car and car, etc.

kaji: IVI recognizes the distance between the current geometry positiom and my home
... if the distance becomes less than threshold such as 3km, then the air conditioner turns on
... the WoT Servient for IVI identifies who I am
... IVI gets home geometry, current geometry position of the car, and get current speed, etc.

wonsuk: tx

kevin: can quickly show another use case
... Potential Attackers
... external attackers and internal attackers
... lots of potential attackers
... Example Use Case
... ADAS - controller sets safety critical controls

mm: hand-over issue
... also how to do mash-up

jh: lots to think especially for car use cases

kevin: inputs into the ADAS control modlue, e.g., camera
... another example on convoy driving

jh: you're focused on the vehicle-internal communication
... but would be interesting to think of joint work with others

kevin: so far Automotive participants, e.g., JLR are interested in car use cases

matthias: could be involved in the demo even with some simple functionalities

kevin: like speed meter, steering wheel angle

mm: maybe we should start with sensing part of sensing and actuation

wonsuk: shows the agenda
... we're out of time with the first item (current status of each group activity)
... if you agree, we might want to have joint calls
... we need some more internal discussion too
... after we can set up a joint call

matthias: would suggest we have proposals on some specific topics
... maybe we could find some paring between your group and our group

wonsuk: sounds good
... any other opinions?

(none)

wonsuk: tx!

[ lunch till 2pm ]

[ after lunch ]

Comment from TAG

da: from TAG
... you can issue an issue on TAG's Github if needed

Map API (revisited)

hamid: what are the features in the navigation systems are already available
... are you recreating that mechanism?
... I use navigation with my car
... e.g., getting into some specific area and detect that is missing
... what is the real use case for this Map API work?

wonsuk: that (=use case discussion) was done before

qa: last year?
... there are many kinds of navigation system available
... compatibility with Web technology based on abstraction
... GENIVI also joins this work
... and discuss what the expected Web API should be
... this is the same to the other navigation service providers too

hamid: you'll provide the same service as the one we have today?

adam: we'll be able to integrate various IVI services with navigation service

kevin: we should be careful not to reinvent wheels

qa: goes ahead
... Interface 'Map'
... POI Use Cases
... point of interest
... keyword searching by default
... keyword searching nearby (geometrics)
... keyword searching within bound
... get detailed POI info
... (goes through the API description)
... basic POI object
... Driving API
... Inteface 'Driving'

<urata_access> Hi, could you reconnect WebEx?

qa: Interface 'DriveRoute'

-> https://lists.w3.org/Archives/Public/public-automotive/2016Sep/att-0027/LBS-api-webidl-draft.docx Qing An's writeup

<urata_access> WebEx is OK!

<ted> scribenick: ted

<urata_access> Thanks ted, ashimura-san

QingAn: API design is very detailed getting into eg roadID
... geocoder use cases are for forwarding or reverse geocoding

[geocoder interface definition]

QingAn: result of getLocation returns geographic coordinates and getAddress gets the address description
... objectives include api best practice and furthering use cases

Kevin: is there a spatial data group in w3c that may already be trying to come up with similar?
... there may be a number of ways to define the same thing for eg POI

<AdamC> https://www.w3.org/2015/spatial/wiki/Main_Page

QingAn: which groups?

<AdamC> Spatial Data on the Web WG^

Adam: spatial data

Kevin: they're involved with the open geospatial consortium

QingAn: Philippe Colliet has been intending to provide the Genivi API side for geo but understand only part of it would be ready for the AMM in October

Wonsuk: for vehicle signals we have client side and server side specs
... this is purely client side

QingAn: we have not found a very good solution based on web sockets
... we may need to get some outside assistance for such an approach

Wonsuk: we should make a clearer architectural picture for LBS

QingAn: for VSS/signal web socket we assume the server is located in the vehicle itself
... LBS service could be either on or off vehicle

Ted: or a mix with cache and remote eg traffic data

Dan_Kaminsky: what would you see cached and in what format?

QingAn: format will vary based on the customer

Kevin: one of the challenges for SOTA is updating large maps data over cell network

Dan: you might want to check instant.io and how they are handling sporadic connectivity issues

<wonsuk> https://instant.io/

Dan: it allows loss tolerate and latency aware communication

QingAn: we need to first define what data should be cached vehicle side and what needs to be updated in real time

Dan: it looks like you were integrating directly into the DOM. how do you see the integration?

QingAn: we initially took a webidl approach and you could have it available to the DOM

Dan: you could expose this as a REST endpoint and have a thin wrapper to get similar functionality
... we keep seeing people try to add things to the browser
... which provides a means for external sites (and advertisers) to potentially manipulate
... to the degree you can compartmentalize nicely it is really worthwhile

[high level vehicle architecture and security discussion - can't scribe and talk at the same time]

@@links to gunnar's diagram and previous meeting minutes

Kevin: we have other diagrams showing the various other levels touched up in brief here
... VSS provides tree like structure of signals information available

Dan: CAN to JSON essentially

Kevin: yes

Dan: and you are trying to control which clients can access which

Kevin: correct using a token structure that an app can provide to underlying socket service that can authenticate it and restrict

Dan: what else are you using to protect?

Kevin: wss - web socket over ssl

Dan: what about outside connectivity interactions?

Kevin: we are not focusing on that at present

Ted: i've had some on thoughts for third party developer guidelines if we later see level of cooperation necessary among OEM to impose them https://www.w3.org/2016/04/guidelines-article.html

Dan: the big question is what the bad guy might do in a situation like this?
... the secure gateway that wasn't part of the diagram was the first thing i was looking for
... critical systems should be completely separated
... an SELinux type approach is fine grained but a grain might be missed
... it is ok for a gas pedal to make the car accelerate not the radio
... scope the stuff that could kill someone out

Kevin: there are people who want to be able to have deliberate limited remote access

Dan: fine but it should be a separate and distinct system, unrelated to this
... you will be compromised components
... an ad can be downloaded and contain script that runs in your web runtime
... isolation is the name of the game
... forget fine grained
... there will be a bug discovered
... as simple as you can make the constraint between CAN bus and your web socket the better
... the crypto you should focus most on keys for protecting software updates
... I would probably define a chain model. define a finite number of chains of what you want to expose
... the components that are permitted to the web should be separate from ones that can talk to the can bus

Hamid: suppose someone lost a key to unlock and start their car. what kind of ability do you need to provide them?
... that is a threat analysis and defining the core problem
... OEM do not buy more computers readily

Dan: when you have to do something inconvenient you need to think of the worst thing someone can misuse that
... are you doing that sort of analysis in your spec?

Ted: we are doing threat tree analysis within Genivi security group

Dan: you need to think of the risks that exist already and you are adding
... you should define where to air gap

[discussion of ecosystem]

Dan: check out https://autoclave.run/ sometime :)

(re sandboxing)

Dan: how much is this similar to OBD2?
... in terms of data being exposed

Kevin: similar

Dan: maybe you work work on secure OBD2-like interface and go from there

Ted: some and hopefully in time all OEM will be creating those as secure gateways to CAN. essentially breaking pins to prevent writes in your RS232 model

Dan: check out what George Hotz did with his car and playstation

<drkevg> George Hotz: https://www.yahoo.com/news/george-hotzs-999-autonomous-driving-214211225.html

Dan: what about bluetooth?

Ted: not our part of the stack but the models we've been seeing definitely do not trust them

<urata_access> Hi, WebEx is disconnected again. Could you reconnect?

<hira> WebEX has been disconnected again!

<hira> Recovered, TKS

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

JS client API

Wonsuk summarizes methods Powell outlined in wiki

[group provides highlights of F2F to Rudi]

Wonsuk: we need to resync the client API with the socket one as there are some differences such as authenticate in client API only having concept of a single token
... also filters

Ted: yes re filters or the JS library implementation could potentially keep that simple and impose filters itself and not give the client the option

[group agrees we should sync with Powell]

Junichi: it is possible to do similar with authenticate

Ted: true, the client library could have token[s] and provide those to web socket in establishing connection

Kevin: there is no method for removing tokens

Ted: that could be done by passing no parameter to authenticate

Adam: callback method to subscribe

Wonsuk: what is the use case for raw?
... I guess we need to check with Powell

<wonsuk> https://www.w3.org/auto/wg/wiki/Vehicle_Information_Service_Specification#JavaScript_Library_Interface_Guidelines

HTTPS migration in local network

Junichi: This is for a session tomorrow at TPAC

<urata_access> It looks WebEx audio is lost..

<hira> RCVD

<urata_access> Thanks!

-> https://lists.w3.org/Archives/Member/member-automotive/2016Sep/att-0031/http-migration-in-local-network-r2.pptx Junichi's slides

<urata_access> thanks again!

Junichi: in this use case people want to store local video
... PLEX solution. provide uri and username
... browser will log into application server
... browser knows relationship. in example hostname is based on local IP address
... and domain name from external service
... certificate is a wildcard certificate for service domain name
... reason for this is CA generally consider .local hostnames and IP addresses as bad practice
... our wwwivi hostname in spec is a similar problem since we want to use wss
... this PLEX solution might provide some ideas for us
... we should have a plan for handling certificate

[slide of local device network]

Junichi: there are many stakeholders in our case with different spheres of influence (demonstrated by circles on diagram)

Ted: previously we discussed self signed under /etc/ssl/ but you very clearly demonstrate the bigger problem
... it is useful to be able to revoke certificates since a mitm attack with stolen private key could then in turn harvest tokens and data

Kevin: we need to be able to work when there is no connectivity (ability to verify certs with an external CA)
... there are devices (HSM) that can sign items passed to it with a private key

<inserted> scribenick: kaz

Kevin: QNX also has some mechanism

<ted> scribenick: ted

Kevin: wondering about MS' secure boot model

Web & TV IG's Cloud Browser TF report

Kaz: I attended joint meeting between WoT & TV IG
... they are interested in a cloud browser with tv being client
... they are discussing concrete use cases
... the model they are considering between cloud browser and tv is similar to ours
... we will talk with them more at a future point

Wonsuk: what would be the data format from cloud browser service
... this is useful for delivering features to a thinner client and offloading computation
... there are limitations with this model
... such as handling user interactions
... do they have ideas for formats after rendering in cloud browser?

Kaz: yeah, here is a more detailed diagram

<yingying_> https://www.w3.org/2011/webtv/wiki/Main_Page/Cloud_Browser_TF/Architecture

Kaz: there are several data formats and procedures for handling this

Ted: as Kevin just mentioned during Junichi's CA topic there are plenty of times where a vehicle looses its internet connection
... cloud browser would need to be on the vehicle and not sure how it would be useful for signals information, maybe for media tuning

Wonsuk: WoT&TV TF is looking at this for media stream and could make sense for us

<urata_access> Thanks everyone. Good bye!

<kaz> [ adjourned ]