See also: IRC log
<inserted> scribenick: kaz
(self introduction by everybody)
peter: would like to add report from yesterday's demo
<inserted> scribenick: ted
[The following part of the minutes is Member-restricted]
PatrickB: VW group is also working on
service layer to HMI. VIWI VW Infotainment Web Interface
... multiple pre-dev since 2013, desire to connect html5 ui
... difficult to bridge initially with underlying
infrastructure
... makes sense to take the same approach for external and internal
devices
... created a platform that is shipped into production
... simple IVI paired with smartphone
... cars are currently being shipped, avail in EU market only at
present
... this specific vehicle is LG
base unit. this is an initial proof of concept
... will be available in future infotainment systemes, apps, dev
tooling, embeded hmi
... it is a RESTful interface, extended via websockets to allow
publish and subscribe
... there is a mechanism to push to client this way
... the API is more graph like, similar to Facebook graph API
... objects linking to other objects
... it is mult-client by design, doesn't care how many clients are
connected
... API allows to build system in microservices
... media, telematics etc
... we use authentication/authorization methods oauth etc
... uniform interface, self descriptive, stateless, cachable, c/s
architecture, layered system (to separate concerns) API
mashups
... code on demand - "server can extend a clients functionality by
delivering code on demand, eg html5"
... promotes performance, scalability, flexibility, managed
accessibility, portability...
... we shared (to member-automotive) viwi protocol docs
... we are interested in industry wide alignment
PatrickL: we are using this throughout our group, I am branching from his object definition for instance
PatrickB: VW consists of many brands
with different requirements
... nav system may be entirely different between Audi and VW for
instance
... essentially we are prototyping industry wide alignment within
diverse VW group
... our logic is separated into microservices for modularity,
testing advantages
... each service can be developed independently
... RESTful approach represents entire system as a database
"RESTful approach needs a change of the mental model similar to the change needed to go from procedural to object oriented programming"
Proposed W3C Infotainment Architecture
PatrickB: we are not too far away from each other, makes sense to try to align and be more common
Junichi: there are several microservers in the car?
PatrickB: yes
Junichi: how do you discover them?
PatrickB: there is a discovery service, each microserver registers itself, all clients connect and can listen to new ones being made available
PatrickL: private IP address is used so it is harder to have an external device eg a phone participate which is by design for security purposes
Junichi: private network provides TLS complications
PatrickL: what was the main problem?
Junichi: you cannot get one issued
PatrickL: we are our own CA
... current vehicles are IPv4 and future vehicles will be
IPv6
... all certificates for https and wss are signed by our own CA
Shinjiro: are all your services running over secure sockets?
PatrickB: yes but also we are using PIN numbers for identification
PatrickL: we are using preshared keys as a base
<kaz> RFC4279 on preshared key
Junichi: W3C WoT is also trying to come up with microservices, this architecture is similar
<paul> https://w3c.github.io/wot/architecture/wot-architecture.html
Kaz: I think WoT Servient is a bit different from the micro service here
Shinjiro: how are you separating https and wss calls?
PatrickB: we will do a demo
later
... the main API is a REST api which answers GETs but you can also
subscribe to a specific URL to get feed
PatrickL: you cannot push by HTTP
Kevin: we are similar in having VSS signal path and use websockets for subscription model
PatrickB: that was what we saw too
PatrickL: you have a tree like
structure and we only have one level of linked information
... tree lets you go deep
PatrickB: we explicitly decided not
to nest information
... this turned out to be quite difficult for media collection
Kevin: returning a tree of signals
allows you grab portions or entire tree
... you could then (within your client app) to filter and
search
... this allows us to have a Vehicle Object Model (VOM[it]) in
memory and treat similarly to DOM
Paul: the various WoT/IoT models are similar in nature
Kevin: we were contemplating both RESTful and websockets initially and focused on the latter initially due to time and resources
PatrickL: so far it is working quite well
PatrickB: we have two URLs for REST
and web sockets (https and wss) which helps with resources and
scaling
... you use the same path and subscribe with a GET
Kevin: human bandwidth not technical :)
Paul: re performance I see web sockets getting the nod in benchmark comparisons
Kevin: you also have to be careful about over-subscriptions or clients keeping a greedy subscription open beyond when it needs it
Peter: you are looking to expose all vehicle services through microservices, we have focused initially on signals and wondering how to expand
PatrickB: it makes more sense to
focus on the boundaries of the protocol and have the service
specific experts focus on their piece
... guidance, routing, etc
... we are more or less about making them uniform and
available
... viwi protocol handles subscriptions, error codes, etc
(see PDF files archived at https://www.w3.org/2016/10/vw/)
PatrickB: we limit our URI tree to a
level of 3
... specifically /// eg /vehicle/door/lock
... subscription takes parameters and allows filtering, fields,
paging and expands
... if you are just interested in musical artist in a media stream
you can just give the artist field
... paging is for larger lists, signifying how many elements you
want to receive at a time
... every object inherents from xobject, the X is there as a naming
placeholder and it just stuck :)
... every XObject contains an id, name and URI
... it only has primatives and references to other objects
... we adhere to W3C/IANA http status codes
Shinjiro: what about http polling?
PatrickB: you can do repeated GETs instead of subscribe but that is a waste of bandwidth/effort
Shinjiro: there is long polling to essentially get pushes
PatrickB: you eventually run into a
HTTP timeout and can only keep the GET connection open for so
long
... that was the motivation behind web sockets
... REST API allows cachability etc
... HTTP GET POST PUT DELETE and web socket subscribe
... you can give /// and POST all the elements back
... if you POST there you are creating a new element and
subscriptions will be alerted
... you can also subscribe to individual elements
... POSTing on a specific existing element is changing that
element
PatrickL: there are some logically immutable elements eg current temperature and some that are restricted by access control
PatrickB: we use oauth for that
... if you don't provide the right token to restricted information
then you get nothing
Kaz: who specificies that?
PatrickL: the individual
microservices using the common protocol mechanism
... you only authenticate once to the parent server and the
microservices can check if it is authorized
Kevin: is it passed in HTTP header?
PatrickB: yes, token is passed that
way
... tokens eventually expire and you will need to
re-authenticate
Kevin: what is the case for using PUT?
PatrickB: rare but example would be
to upload an image to the system
... you can use DELETE as well for total element deletion or
specific attribute[s]
... we use ETAGs to check if modified, otherwise use locally cached
copy
Ted: why not use Cache-Control?
Patrick: what is the advantage, how will you know if something has changed before the expiry?
Ted: it is a promise, expectation to reduce polling and doesn't prevent you from checking back if you want to be sure
PatrickB: true but we want to check
at specific times and the not-modified response is efficient
... we have a concept of element expansion to retrieve all elements
available, only available on JSON payload
PeterH: is this also explicable to vehicle maintenance history?
PatrickB: sure, you can expand from one table/object to another and apply a filter
[discussion of user ids and ability to have it follow individuals to different vehicles, of the same manufacturer]
Kevin: each entity is only exposed by a single microserver
PatrickB: correct, collision isn't
possible
... ids do not persist reboots but generated automatically
... I can see desire to have presets for persistency such as
wanting saved radio stations
... to subscribe on an event you send this sample json message,
identifying path with potentialy query parameters
... interval, updatelimit (number of messages sent),
authorization
... you can unsubscribe in the same fashion
Kevin: do you have a connection identifier for unsub?
PatrickB: #uniqueid-per-session is a client specified identifier so you can distinguish different subscriptions
Kevin: we can to the same conclusion, you might have multiple subscriptions with specific filter parameters and a separate subscription with another
PatrickB: the client side id is to be
able to distinguish them
... our query parameters is the filtering
Kevin: again similar
PatrickB describes data request (see spec from archives)
PatrickB: for security there is a
service registry which we have not provided with the other
materials and will have to check back if we can
... exploration is interesting, traversing links to see what is
available
... JSON object definitions, response object will have status and
payload
... also xobject covered earlier
... you can have binary data from cdn services
... we have reserved formats defined in schema
... categories a service can be in
... languages
... we have randomly generated uuids
... we have interface design patterns, what to do and not to
do
... do not use inline (nested) objects
... we use numeric semantic versioning major.minor.patch and
criteria for each
... we use the accept header Accept:
application/vdn.viwi.v1.4.2+json
... microservices may evolve differently and have different
versions
... this causes a problem with dependency management but preferred
that to a monolithic api
... JWT or oauth are possible at the same time
Kaz: regarding language options, why not use IANA Language Subtag Registry?
PatrickB: we have markets that differ from that registry eg american-spanish
Kaz: you can extend the subtag with regions based on BCP47 (Best Current Practice for Tags and Identifying Languages)
... also if you need a language which is not listed on the IANA registry, you can ask IANA to add that language.
Paul: they are very helpful to get people to understand what we're doing
Peter: we need to produce a reference implementation?
Ted: we need two implementations and
a test suite. we do not have to produce an implementation but cite
two existing ones
... test suite is for implementers to ensure theirs is meeting the
spec
Kaz: we are doing an extensions approach in the Web&TV IG for the test runner for TV browsers and may want to do the same
-> https://www.w3.org/TR/vehicle-information-service/ Vehicle Signal Server Specification FPWD
Rudi: we accomplished quite a bit, certainly more to do but I'm quite happy
Kevin: I've made it through about 1/2 of the actions/issues since lisbon
Ted: one of the main points of publishing is to get people to read it and give feedback
Rudi: who else did we get outside the WG in lisbon?
Kaz: we had a jont meeting with WoT and there were Siemens, Panasonic, Fujitsu, Softbank, etc.
<inserted> Lisbon minutes
[This part of the minutes is Member-restricted.]
VW demo minutes (restricted to Auto WG at present)
PatrickB: running a nodejs server
locally, it exposes a bunch of APIs
... as you can see you can explore by following the links
... using media for example. media has renders and collections
[various POST and GET interactions]
[simple media player app, run multiple clients to interact with the same server]
[discussion of acls]
Kaz: it would be helpful to have a rules manager
PatrickB: yes the services will tell
the access manager what capabilities they have and permit
... we decided not to use a proprietary web socket solution but
stick with standards so postman and other standard web dev tools
can be used
PatrickL: let's show them the code behind the demo
PatrickB: the backend is what we call our mock server
PatrickL: it is very handy to program
against, none of these tools are very complicated
... if you are at all familiar with json and web sockets you will
be able to code against this
Kevin: I have a simple test
implementation of our spec
... it helps considerably to debug
PatrickB: we're http1.1 and websockets but nothing preventing us from going http2.0
Shinjiro: client and server are
connected with a single connection
... if there are different microservices are they sharing a
connection?
PatrickB: each microservice is a connected to separately
Kevin: authorization is per service
PatrickL: correct, client is used by one user
Kevin describes scenario where one person authenticates and another may use it later
PatrickL: token needs to be invalidated, requiring client to re-authenticate
PatrickB: client needs to take care of the log out
Kevin: anonymous users permitted too?
PatrickB: yes, they do not send a token and get appropriate access
PeterH: is it possible to have tokens timeout?
PatrickB: yes, we're just using oauth tokens and they have that capability
[discussion on client use cases]
Paul: how do people thing this all fits? there is some different leveling and overlap
PeterW: microservices provide a
broader view
... we do not address media or navigation yet
Rudi: we are only presently defining signals from the drive train but there are also some for navigation in VSS and it is extensible
PeterW: question is which approach do we take or do we do a hybrid?
PatrickL: we need to agree on protocol first and separate from the different microservers
Kevin: there are not that many differences
[debate on differences of uses of web sockets]
[eg get/set vs get/post]
PatrickB: we are using gzipped and deflate to save on bandwidth
Rudi: there are advantages to having a large serialized json too
PatrickB: the RESTful approach provides more ability to create and debug the requests
[discussion of the supplier tree, need to know whether you are sending trouble tickets to front or backend supplier]
Paul tries to see if there is a possibility to converge or if w3c would permit both to go in parallel
PeterH: a variable needs to be speed of adoption, betamax vs vhs
[lengthy discussion about different approaches, benefits, other group approaches from different industry perspectives on other device types...]
(some minutes Kaz took while Ted stepped out for a phone call)
<scribe> scribenick: kaz
kevin: two possible data models for
VSS and Viwi
... in the spec they're similar to each other in high level
paul: for media capability, iHeart was involved
kevin: REST interface and WebSocket
interface
... both possibly return JSON
patrickB: HTTP+WebSocket vs
WebSocket-only
... both are possible
... we use HTTP header for both HTTP connection and WebSocket
connection
kevin: WebSocket would be effective for binary data transfer then HTTP connection
rudi: you have multiple methods, HTTP POST and WebSocket depending on the situation
patrickB: for the major parts, we
don't ned WebSocket
... btw, we had to write a library to access information for
WebSocket connection
... but it's not the major part
patrickL: how do you access a concrete data point using VSS?
rudi: via data tree path
paul: common data part for basic vehicle information and extension branch like media tuner or LBS
kaz: W3C WoT IG has been using existing IoT protocols for WoT servient module and has just started to consider WebSocket as well. might make sense to input their thread
<kaz> WebSocket discussion by the WoT IG (just started)
ted: we should be careful about the difference of purposes. we're interested in Automotive use cases
kaz: right. WoT guys are rather interested generic WoT framework
(some more discussion)
kevin: WebSocket is useful for subscription
rudi: traditional Web developers may
want to use high level APIs
... but that doesn't necesarily fit with embedded purposes since
embedded systems don't use usual Web browsers
patrickB: our IVI system is mini cloud server which provide various services via multiple micro services
rudi: personally don't think we would
like to expose complicated services to the developers
... and would like to understand your concept
patrickL: hiding complexity would be useful for developers
[ Slides ]
<kaz> scribenick: kaz
junichi: Background
... Vehicle Signal Server Spec (VSSS)
... client side Web API
... exposes vehicle signal to Web apps
... origin is the server
... so far: same origin policy + user permission
... for vehicle: access control requirements
... (Local Server Architecture)
... the left side is old architecture
... and the right one is new architecture
... pros are:
... accessible from 3rd parties' non-Web apps
... independently updatable from Web browsers
... enable token-based access control />
... (Access Control with Token)
... APIs just support this by:
... messagge format for sending token
... and error code for authentication
... need to consider:
... token details
... privilege level for requests2
... local server security
... (Local server is not a cloud server)
... didn't know about RFC4279 (pre-share key)
... cloud servers have its own names, e.g., www.kddi.com
... the local server has a specific name, wwwivi
... TSL certificate is self-signed
... managed by the service provider (=the manufacturer)
... owned by the user
... threats for the local server:
... well-know threats for the Web server
... threats from the user/malware
... local server implementation is out of scope, but would like to
generate some guideline for implementation
stacy: how to implement secure implementations?
junichi: right
... (TPAC Recap/Actions)
... local server name certification
... implementation guideline
... collaboration/discussion
stacy: GENIVI Security Team Lead
... a lot of discussions internally
... determine the level of security
... want to bring that to GENIVI
... (Researchers - Exploit but Disclose)
... windows-based DLL replacement attack
... mobile apps
... access battery status
... (Motivations - When Disclosure Stops)
... million dollars of attacks
... (Criminals - Exploit and No Disclosure)
... (Criminals - Exploit and Profit!)
... (Ransomware - Moving on From Mobile)
... targets hospitals
... (Ransomware - Willingness to Harm)
... (The How)
... (Methods - Wifi Hacking)
... Wifi Hacking, Wall of Sheep, ...
... (Methods - Cellular Hacking with IMSI-Catchers)
... (Methods - Mobile Device Malware)
... Fake anti-virus, Juice Jacking, Pokemon Go malware
... IoT fredge
... (Methods -TLS Exploits)
... pineapple module
... (Methods - Bad USB)
... USB sticks are dangerous
... (Mirai - Botnet on Steroids)
... KrebsOnSecurity.com knocked offline by 620Gbps DDos
... estimated 145,000 IoT devices were used as botnets for the
attack
... Botnet of passenger cars? would we even know it?
... (BotNet - Now Open Source)
... the developer made it Open SOurce
... they're very intelligent
... bringing money in
... (Our View - The car is a Hostile Environment)
... CVE details
... (How we help?)
... (Focus - A confident and Informed Customer)
... (Deliverable - Quality Deliverables to our Customer)
... detailed threat assessment of the GENIVI solution
... security mitigations including with the solution
... Security requirements around the use of the solution
... (Focus)
... (Deliverable - Recommendations and Information)
... malicious radio meta data
... (Example - Asset Description)
... Physical Vehicle Key
... Mobile Vehicle Key
... Mobile cryptographic key
... Vehicle cryptographic key
... Cloud cryptographic key
... Vehicle immobilizer
... (Example - Attack Tree)
... start with use cases
... (Example - Attack Vector Descriptions (EVITA)
... moving forward to VSS
... questions?
junichi: IVI tree?
stacy: vulnability may be outside
VSS
... have a private GitHub
... the document will be publisized
... regarding the tree, it's rather a private branch
junichi: need to be a GENIVI Member?
stacy: need to subscribe the list
junichi: TLS vulnability?
... limited and not completely blocked?
stacy: some of the attacks just middle
of the session
... login page might be not under HTTPS
... I can create a malicious version of that page
... TLS/SSL break also
paul: how can we access the information?
stacy: can send the information to
you
... GENIVI Security Web site
kaz: does that include the Attack tree?
stacy: that's on the GitHub
... Microsoft also works on security lifecycle
... we can adapt to that as well
... conditional access cracking was popular
... mobile apps have same issues these days
junichi: has the GENIVI site also been attacked?
stacy: not aware
... please note that as I mentioned, owners of video cameras are
not aware of being clacked
hira: BMW immobilizer clacking?
stacy: shows www.shodan.io
... geolocation information cracking
... Shodan is a bit scary
... shows the GENIVI Security wiki
paul: thank you very much!
... tomorrow, Peter and Rudi will leave earlier
... W3C Automotive working on Web runtime interface and our work is
very popular
stacy: mentions TV cracking
[ Day 1 adjourned ]
<kaz> scribenick: kaz
[This part of the mintues is Member-restricted.]
discussion on pros vs cons of each approach, viwi and W3C spec
patrickL: thinks we have to extend VSS
kevin: JSON object based on VSS
paul: something other than VSS could be standardized for the vechile data
... what do you want to have?
... the data model would be different from the access method
patrickB: we agree on the protocol
... we have our own data catalogue
... all the navigation stuff, etc.
paul: ideally, would be good to have common data model
... VSS is a useful data model
kevin: both the approaches are supported by the micro kernel model
... however, the protocol should be pure WebSocket rather than hybrid combination of REST and WebSocket
ted: agree partly
... for developers it would be better to have one consistent
approach
kevin: we want example use cases
paul: basically people can implement the system using WeSocket
... and we could hide the details if needed
peter: much easier with our approach (=WebSocket only)
... we ourselves had discussion and made a decision
kevin: keeping code clean and simple is one of the important points
... the simpler, the better from the engineering viewpoint
ted: you might have different versions of WebSocket with Android
paul: there are multiple ways to solve issues
... you have request/response
... diffrent approaches have different reasons
... in some cases, REST might have more sense
patrickB: using only WebSocket would be actually not really easy
... what if we want to create a playlist which is not available?
... the initial setting might be easy but it would be hard to understand the flow
scribe: have been working on a protocol for Linux (exldap?)
(Peter lefts)
paul: would see same type of things done
... would like to see how to take the best idea
kevin: agree with that basic policy and we can support micro service approach
scribe: however, pure WebSocket approach would be much easier
... we've already start implementing our spec draft
... can't understand the need for the hybrid REST+WebSocket approach
kaz: BG is in charge of incubation
... why don't we have more detailed discussion like the use cases for this approach in the BG?
scribe: and after that, we can see which part of viwi approach could be included in the W3C spec
patrickL: FYI, HTTP 2.0 has PUSH capability
ted: HTTP 2 got some push back
... and we're working on WebSocket now
... btw, have just put a URL on the IRC
... AC review discussion by Mozilla
... maybe a proxy outside the vehicle
... RESTful approach would be consistent with usual Web technology
patrickB: subscription for media, navigation, etc.
... RESTful approach is already used by various Web services
ted: should consider market share
justin: there are 2 kinds of
perspective
... platform side and developer side
... we can implement any kind of platform easily
... but should think about the developers' convenience
patrickB: we pay for platform developers but don't pay for Web developers...
ted: tier1s work for business
purposes
... OEMs have their own platforms
... not only the "usual suspects"
... should consider the market share
kevin: in our current implementation, would like to make the fear for the attacks as small as possible
scribe: what are you passing
... so the apps running on the process
... WebSocket-only approach fits well
... for me there is another merit about less attacks
patrickL: our approach is not that
complicated
... we can fix one specific component if any problems
patrickB: possible use case is turning off vide camera
... for micro services
kevin: it's OK to use micro services
ted: would be a technical architecture discussion within the W3C Team next week
scribe: JLR and Mitsubishi support
the current WebSocket approach
... we have to ask other people opinions
paul: would like to make things better
kevin: we should think about the timing as well
... we've just published a FPWD
... also the security footprint would become bigger if we use the viwi approach
ted: we should see the pros and cons of each approach
... in viwi approach only REST interface can set value?
patrickB: yes
ted: Web mechanism get attacks everyday
kevin: even GET could be
harmful
... car manufacturers have responsibility
patrickL: if we choose binary
mechanism, it would be safer
... the more safety relevan thing is we use widely deployed
mechanism to
set data
scribe: we use some method which is not yet standardized, though
ted: both the approaches have the rationale
(some more discussions)
kaz: wondering if we really need to
choose one of the two approaches
... for example, WoT framework let us use both of them
collaboratively
paul: that's my point as well
kaz: also WoT group has been holding
interconnected demos named PlugFest
... so we could try PlugFest including both viwi and VSSS
paul: yeah, we could try that kind of
collaboration
... we've just published VSSS spec draft and have momentam
now
... on the other hand, there is a bit different approach
kevin: not saying we need to choose
one based on the footprint
... but we need to see if viwi approach is what we need to
follow
... we can implement the VSSS
... it is a business decision to follow the W3C standards
patrickL: we have already implemented our approach and can't change it without enough rationale
patrickB: we need reasons
kevin: understand you guys
... what would be the compromise?
paul: Junichi, what do you think about security consideration?
junichi: at least we need to establish the same level of security
... don't see any specific advantage with either approach
urata: personal opinion
... the Charter says we concentrate on WebSocket
... and after that we could try other protocols
... and possibly include REST approach
... it's feasible theoretically
hira: not sure about the technical details but
... Technology is evolving endlessly, so we have to set up deadline to make recommendation
... Our charter is, so to speak, contract for our joint activities, so we should not change timeline
... I understand REST interface is important for the future IVI apps
paul: what about the JP manufacturers?
hira: they usually watch our activity
paul: Wonsuk?
wonsuk: similar to Urata-san's
opinion
... we're focusing on one specific approach (=WebSocket) now
... how about drafting within BG about the hybrid approach?
... first incubation cooking should be done by BG
... think the bigger problem is VSS as the data model
... we can extend the protocol part
... on the other VSS is more important
paul: everything to be followed by VSS?
kevin: object graph, etc., is fine
wonsuk: we have to make only one data
model
... we have to extend the protoco part depending on the market
needs
... but have to have only one data model
hira: that is the case with the JP manufacturers as well
paul: normalized object model
justin: what is important is reaching
a consensus
... we're here to make consensus
paul: +1
ted: tier1 guys have their own
approach for WebIDL
... would try to find a comprimise
... would encourage people to address their opinions
... people aside from this room also should participate
... maybe straw poll or maybe email
... would propose to send the minutes to the Member list and gather
opnions
... possibly joint calls
... sounds fair?
<scribe> ACTION: Ted to send a request for comments on viwi approach out to the WG list
patrickB: timeline?
paul: completion at Q3 2017
-> https://www.w3.org/2014/automotive/charter-2016.html proposed WG Charter
paul: the following is the proposed timeline:
- November 2016: FPWD of Vehicle Signal Server Specification
- December 2016: FPWD of Vehicle Signal Client Specification
- April 2017: CR of Vehicle Signal Server Specification
- April 2017: CR of Vehicle Signal Client Specification
- July 2017: PR of Vehicle Signal Server Specification
- July 2017: PR of Vehicle Signal Client Specification
- November 2017: REC of Vehicle Signal Server Specification
- December 2017: REC of Vehicle Signal Client Specification
ted: criteria for PR?
... two implementations?
kaz: right
ted: for CR?
kaz: tests, test suite and comment disposition
ted: possible implementations by JLR, GENIVI and Mitsubishi
patrickB: should involve more Tier1 guys
ted: Panasonic visited our meeting in Lisbon
paul: Sony attended the Paris
meeting
... would like to show the W3C Test site
-> https://github.com/w3c/web-platform-tests/ W3C Web Platform Test site
-> http://w3c-test.org/tools/runner/index.html Test Runner site
kaz: we should register tests on the
Web Platform Test site
... and we can use the test runner site for the usual HTML-based
side
... but need some extension for the vehicle side
<scribe> scribenick: ted
(existing ways to better protect REST)
-> https://www.w3.org/2014/automotive/charter-2016.html Updated WG Charter
[[
Timeline
November 2016: FPWD of Vehicle Signal Server Specification
December 2016: FPWD of Vehicle Signal Client Specification
April 2017: CR of Vehicle Signal Server Specification
April 2017: CR of Vehicle Signal Client Specification
July 2017: PR of Vehicle Signal Server Specification
July 2017: PR of Vehicle Signal Client Specification
November 2017: REC of Vehicle Signal Server Specification
December 2017: REC of Vehicle Signal Client Specification
]]
<kaz> scribenick: kaz
paul: other topics?
... LBS, payments?
wonsuk: had discussion on media tuner
in Lisbon
... also we need to consider how to add media-related items to VSS
for extension
... we need investigation
... need opinions from the media tuner guys
paul: media capability for VSS?
wonsuk: would be great to use the same data model for media tuner as well
kaz: maybe that is the case for LBS as well
wonsuk: think so
... need feedback from the media guys and the LBS guys
paul: everything on the data
structure
... we should look into that
... would see the better representation
kevin: we think that VSS tree should
be a logical structure
... shouldn't include position in the tree. position should be
attribute
patrickL: would agree
paul: (shows the Vehicle Signal
Specification slides)
... (the Problem)
... (VSS - Introduction)
... Standardizing signal spec
... (VSS Signal structure)
kevin: capture all the vehicle
information
... Rudi and Magnus working on VSS
... incubation so far
... not a research but between research and development
<ted> previous presentation to WG on VSS
paul: (Naming Convention)
... Body.Mirror.Left.Heated
... Body.Mirrors.Right.Heated
patrickB: viwi object collection is similar
paul: (Specification source format:
Attributes)
... (Spec file re-use)
... (Private Extensions)
<wonsuk> VSS github site: https://github.com/GENIVI/vehicle_signal_specification
<wonsuk> VSS JSON Tree: http://www.jsoneditoronline.org/?url=https://raw.githubusercontent.com/GENIVI/vehicle_signal_specification/develop/vss_rel_1.json
(Justin leaves)
-> https://github.com/GENIVI/vehicle_signal_specification/blob/develop/spec/VehicleSignalSpecification.vspec VSS definition
paul: discussion needed from the viewpoint of industry needs
kevin: Magnus represents the VSS
patrickB: any app developers here?
paul: my company
ted: Vinli as well
patrickB: what about Tier1s?
<ted> Carfit too
patrickB: there opinions are important
paul: we need to do client spec, tests, etc.
[ lunch ]
<ted> scribenick: ted
-> https://www.w3.org/TR/vehicle-information-service/ Vehicle Signal Server Specification FPWD
Kevin gives tour of spec to VW
Kevin: example 2, subscribe to
RPM
... we decided to not use request id for gets and sets but still
used for subscribe and unsubscribe
PatrickL: we do not have a single web socket signal server, we have several
Kevin: it is possible to do the same
here with alternate ports
... we covered a tour of Genivi VSS earlier which this spec
references
... it defines a user and a device for security purposes
[diagram 3, authorization]
Kevin: diagram is slightly out of
date, fragment that gets passed is different now
... in this example through the socket it does a get of speed,
tries to open the truck but is forbidden since it is still
moving
... we have taken the approach that we will only use wss
... even though we should be in control of this network
... we are still discussing self signed certificates
Junichi: we are not a fqdn however if
we can convince people to use this hostname then we can do self
signed (and add CA to vehicle)
... for sake of the spec we might leave this up to implementers and
drop the proposed hostname from the spec
[agree it is a potential issue to add to github as we never were 100% behind this but wanted to avoid choosing or defining a discovery mechanism]
Kevin reviews the various Action methods - get, set, getVSS, subscribe...
Kevin: there are appropriate response
for each method
... for example you ask for "get" with VSS path
PatrickB: how do you coordinate the request/response on get without the request id?
Kevin: we debated that, I didn't like because you may have made several requests and get them back in a different ordering
[timestamping of signals data]
Kevin: if you get a second response with an earlier timestamp you ignore it
Paul: you still don't know the order of the requests
Kevin: this is why I want to keep request ids
(on get/set actions)
[sample json data fragments on request and response]
PatrickB: is it possible to indicate 1* for rows 10-19?
Kevin: no, simple wildcarding for eg
all doors not a filtering
... basically we tried to keep with appropriate error codes
... next we have an example for sending lock signal to all doors
and a confirmation response
PatrickL: if i send multiple locks, the response with the latest timestamp indicates the current state?
Kevin: yes and again making the case
for including the request id
... in this example, trying to set RPM, the response if 403
forbidden but we also see fit to send additional error message with
more information
... onto subscriptions
... this demonstrates establishing the subscription, server
response if it is too busy...
... you can unsubscribe based on subscriptionId or all by passing
null/0
... you can subscribe to the same signal or set of signals as long
as the filtering conditions are different
... if a client tries to make a second subscription to same signals
with same filters, the server refuses
PatrickB: are you doing any throttling to prevent oversubscription?
Kevin: yeah, we'll get to that in a
minute
... way the spec is currently written you need to specify a leaf
node in the path
... structure for filters is an interval (ms), range (above and/or
below), minChange or combination of these filters
Kevin: we have error
definitions
... as noted there are a number of different reasons you could get
a 401 so reason string gives more details
PatrickB: we do the same, padding the error message
Kevin: we are about halfway through the issues list and pulling pieces out into a non-normative document
-> https://www.w3.org/2015/10/26-wpay-minutes.html#item01 Web Payments / Auto liaison meeting minutes
Ted: we had met with payments wg (gives brief overview of their work) and their specs are becoming mature with what appears to be widespread adoption. also have been hearing interest from others in getting payments in auto. we have some complex use cases eg vehicle/fleet owner and shared driving situations which would mean multiple and changing profiles
PatrickL: Are there thoughts on NFC or BT?
Ted: mostly because of the range?
PatrickL: yes
... definitely interest
Ted: I wonder if JLR/Genivi RVI may help as they abstract out the different connectivity protocols, negotiate based on what is available in challenging networking situations
Wonsuk: there is a lack of existing payment infrastructure in automotive and need to look at this more closely
Paul: there is one PSA is using
Ted: also WEX, formerly Wright Express
-> https://www.w3.org/standards/techs/webpayments#w3c_all Web Payments WG specs
[agreement to explore payments further in BG]
<kaz> scribenick: kaz
urata: wondering if the discussion on viwi would impact our timeline
ted+kaz: if we send the request for comments with some specific deadline, e.g., 1-2 weeks, there would be no big impact
wonsuk: kind of concerned about
having two different data models, i.e., VSS for W3C VSSS and object
model for viwi
... we could extend the protocol part easily, though
... think we should investigate what the differences are, and pros
and cons
... maybe we could ask the main Editors, i.e., Manus from the VSS
side and Patrick from the viwi side, to compare the two data
models
patrickB: maybe we could ask the other people to investigate like market research
hira: but we don't have much time for the investigation...
paul: would like to start with an initial request for comments for a couple of weeks
kevin: please note that the
WebSocket-based VSSS and VSS data model are both vendor neutral
specs
... what is the right thing to do?
paul: would try to get
consensus
... by asking the WG participants for opinions
[ meeting adjourned ]