See also: IRC log
<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)
<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
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
[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]
<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.
<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[End of scribe.perl diagnostic output]