Introduction

<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

<ted> … 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

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

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

<ted> Adam: a quick example (example #1) shows establishing a web socket connection, application authorizing itself with an oauth token

<ted> … we use request ids to keep track of connections

<ted> … the code confirms the connection is established and then does a GET request for vehicle speed

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

<ted> Adam: correct

<ted> Kevin: for subscriptions you will need your requestId

<ted> … we decided at the previous meeting to not bother using the id for a simple get

<ted> … in this example it confirms the return

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

<ted> 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> some of the nuances being discussed:

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

<ted> 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)

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

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

<ted> application code would likely be simpler with second approach

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

<ying_ying> [some discussions on the deliverables]

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

<ying_ying> [review on other deliverables section]

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

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

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

<ying_ying> wonsuk: for the vehicle data spec we have the section for use cases.

<ying_ying> ...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.

<ying_ying> ...another way is to have it in the same spec.

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

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

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

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

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

<ying_ying> junichi: I summarized 7 use cases in the security spec.

<ying_ying> ...I think use cases should be satisfied by the spec.

<ying_ying> wonsuk: we need to make a decision.

<ying_ying> ted: we need something to support the spec. I will take an action to follow up.

<ying_ying> ...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

<ying_ying> ...we may have something for it but I am not sure what is it. Will check.

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

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

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

<ying_ying> wonsuk: any other comments on deliverables?

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

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

<ying_ying> [reviewing the timeline section]

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

-> https://www.w3.org/2015/Process-20150901/#Reports Maturity level for CR etc

<ying_ying> ...because we need more time to exit the CR.

<ying_ying> 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.

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

<ying_ying> [reviewing the liaison group list]

<ying_ying> ted: please change the device API WG to generic sensor API WG.

<ying_ying> ted: web of things IG is not there.

<ying_ying> wonsuk: we have done.

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

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

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

<ying_ying> wonsuk: this is tomorrow's agenda.

<ying_ying> ...could we follow the list Kaz sent out for topics of joint meeting with WoT?

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

<ying_ying> wonsuk: yes.

<ying_ying> ...would create a wiki to add topics for the joint meeting.

<ying_ying> wonsuk: we will have a session for security and privacy. expect to have web security people.

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

<ying_ying> wonsuk: any other suggestions for tomorrow's agenda?

<ying_ying> [no]

<ying_ying> [adjourned]

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/topic: Vehicle Information Service Spec//
Succeeded: s/Raphael_Troncy(EUROCOM)/Raphael_Troncy(EURECOM)/
Succeeded: s/devlopers/developers/
Succeeded: s/the same/exactly the same/
Succeeded: s/filter is used for some specific path/current spec couldn't cover when client requests for VSS branch./
Succeeded: s/ previously done./ previously done.]/
Succeeded: s/ meet the timeline/ meet the timeline currently planned/
Succeeded: s/device WG /device API WG /
Succeeded: s/generic sensor WG/generic sensor API WG/
WARNING: No scribe lines found matching ScribeNick pattern: <ying_ying> ...
Found ScribeNick: ted
Found ScribeNick: kaz
Found Scribe: ying_ying
Inferring ScribeNick: ying_ying
Found ScribeNick: ted
ScribeNicks: ted, kaz, ying_ying
Present: 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;remote) Shinjiro_Urata(ACCESS;remote)
Agenda: https://lists.w3.org/Archives/Public/public-automotive/2016Sep/0026.html

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 19 Sep 2016
Guessing minutes URL: http://www.w3.org/2016/09/19-auto-minutes.html
People with action items: adam ted