Day 1

Introduction

<inserted> scribenick: kaz

(self introduction by everybody)

Agenda

peter: would like to add report from yesterday's demo

Viwi, RSI and the REST of it - Patrick Bartsch, Audi & Patrick Luennemann, Carmeq

<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

VIWI protocol

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

Report from yesterday's demo

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

Vehicle Signal Server Spec FPWD

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

VW demo

[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

Security - W3C Vehicle API Security - Junichi Hashimoto

[ 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

GENIVI Security Architecture Overview - Stacy Janes

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 ]

---

Day 2

VW collaboration

<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

Updated WG Charter

<scribe> scribenick: ted

Mozilla review of draft spec

Web Application Firewall

Apache mod_security

(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
]]

Other topics

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

Vehicle Signal Server Spec FPWD (revisited)

<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

Payments

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]

Next steps

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