Automotive Working Group Face to Face meeting

Spec logistics

PatrickL: we should speak about editorial duties as I would like to know myself
... but we have to wait for Ted to catch up on scribing... hopefully that isn't in the notes

Ulf: how much should we rely on the data model within the spec?
... how should we divide up the specs?

PatrickL: I don't want to be completely agnostic, I see:

* Interface

Basic data model

All the necessary methods

* Protocol

allows the interface to communicate through a connection

* Cool Services and Solutions and Stuff

Registry

Consent

Identity Stuff

(Data Model for Domain)*

a data model for a sepcific domain

e.g. media, POI, vehicle position, VSS

Ted explains editor role at W3C, staff contact as facilitator, how we use github, other tooling and introduces Philippe (PLH)

PLH: gh allows everyone to be able to contribute and remove bottleneck
... you need to have clear editors however who ensure quality and continuity
... we have some nice tools around it
... we have about 1300 commits every month to W3C repos at github
... we have a number of tools that help, I encourage you to use respec

PatrickL: on gh we have our automotive repo
... I would create a new directory and/or branch initially

Adam: we rely on gh-pages branch and things tied to it

PLH: we have some good docs on using gh at W3C

Ted: I will send links and if you have questions ask me

PLH: do not get stuck on tooling, we will help. we can setup an editor's training session if people want

https://w3c.github.io/

Adam: being an editor was not a scary process, we used peer review conventions

Spec areas

* Queries and Filters

* Auth and Identity

* Addressing

* Status Codes

* Data Types

* Versioning

* Objects

* Structure / Ontology

* Grouping

PatrickL: put in an Internationalization section

PLH: that is something you need to be mindful throughout if you are manipulating strings for different languages
... Privacy and Security deserve dedicated sections
... I encourage you to get review early on instead of waiting until the end
... based on what you are doing a11y and i18n probably less of a concern

PatrickL: of the three specs we identified, focusing on interface initially
... we can start with that one and after we get our workflow going start the others

Ulf: I am interested

PatrickL: as people express interest please say which areas
... while the others in the group will contribute you will be subject experts for those areas

Benjamin: structure and ontology for sure
... also queries and filtering

PatrickL: data and versioning for myself

Glenn: will the open source implementation be iterated in parallel with the spec?

[yes]

[discussion of audiences for PoC and other considerations on language]

Timeline

[Goal protocol and data model by end of January]

PatrickL: we could reasonably have a full solution by end of March

Magnus: how much to align with WoT?

PatrickL: we need to continue to coordinate and design with them in mind but not to the point of preventing us from starting

<hira_> To clarify the differences between WoT and Automotive WG and between V1 and v2, use cases will be important.

Data Model

[slides]

Benjamin: Daniel, Ulf and I have been looking at proposals for a VSS v2
... some changes might not be fully backwards compatible
... leafs can be attributes or signals for dynamic. if we look in more detail we have three trees

[attribute, signal and private]

Benjamin: first problem, you don't have the same tree in signals and attributes

[slide 3]

Benjamin: there was some early breakage that needs to be corrected. you can create a private tree and since you don't belong to a root you are unsure if you are an attribute or a signal
... the root should not be signal or attribute, it is also awkward
... branches can mismatch between different trees
... we should merge into single VSS tree, extend leaf metadata, use / instead of . in VSS names
... if you already have a mapping on where to find a singal you can create URIs to find those concepts
... the root should be the vehicle (body, ADAS, Cabin, Chassis, Drivetrain, OBD)
... the main change would by to have one tree
... it can be more detailed on function - attribute, sensor, actuator, sensor-actuator
... it would be worth identifying which data points are available for streaming purposes
... we would add URL in JSON with path to that explicit signal

PatrickL: if we are embedding private (OEM specific) branches in the main tree that would be confusing, I would prefer it separate

Benjamin: you would have your own proprietary branch
... we could provide some extensions in private branch as examples
... there is little for example on HMI within the vehicle which is why I played with that one

PatrickL: I would like it clear to the developer that the proprietary pieces appear where they logically belong - eg additional attributes about an engine
... as a developer I don't care where that element comes from but having to look at two branches would be tedious

Ulf: should we consider a notion of overlay?

Benjamin: currently if you overwrite a private branch it overwrites what exists and see that as potentially problematic

Ted: that breaks benefits of common data model, some OEM might be unlikely to conform as they won't understand benefits of conforming and impose their view/representation instead

Guru: I see it is better to have attributes and signals separate since former are static

PatrickL: representation of a real vehicle in data model outweigh to me separating out the static bits
... it will be possible with the querying/filtering capabilities to get only the static

Guru: I am thinking from the implementer perspective and what would be easier to create

PatrickL: we need to think of the developer though

Magnus: you mentioned in the beginning issues with OBD2 since it duplicates data as it is a representation of existing signals

Benjamin: there are signals not available to OBD2 for instance

Magnus: I equate wanting a branch with subset of same signals as a UNIX directory and symlinks

PatrickL: OBD2 is the diagnostic view and it consists out of data elements and includes key indicators of the state of the vehicle

Benjamin: I think this is more in the domain specific data models
... the question is what is the status of VSS compared to the rest. do we continue the style or simply include

Magnus: currently we are assuming all the OEM specific stuff will end up in the private branch
... sometimes you might want to expose something in the open area

PatrickL: when I say private, it is still being made accessible it is just that I am defining the data model for those signals
... a better term would be vendor-specific

Adam: I can see converting to this model easily
... on the private/vendor-specific branch I can see it being proxied and filtering out what is private and what is not
... I can change the signals on the fly and agree to make it simpler for the implementer and OEM to be nearby to where the underlying signals are
... I am not a fan of the word function, seems more like a class as it determines what you can actually do with it

Ulf: agree and take responsibility
... what is a better term?

PatrickL: Structure Type?

Adam: regarding URI field, it includes the domain and it might not be useful necessarily for web socket implementations and might be better to use a path parameter
... if we can make it available to both that would be more appropriate

Benjamin: you can provide different URIs similar to how WoT does it for their thing description

Magnus: this could also be applicable for web socket case
... you could have multiple services within car and some of them might be directly accessible

PatrickL: it should fit to style of addressing regardless of protocol
... if we are using URI style then slashes make the most sense
... if we use a more file based separator than . would make sense

[OBD2 branch discussion]

Urata: would this input go into GENIVI VSS or a separate copy?

[recap of past call discussions and emails including with Rudi and Gunnar on branching]

Ted: we will branch and have a milestone release we will point to in VISS, VSS 1.nn can continue to evolve and get additional signals

Hira: can you create a conversion function?

Urata: it is possible

Adam: we should have some tools to convert the data model and it should not be too difficult

Authentication

PatrickL: access keys and tokens, that enough?

Ulf: the token can describe what it gives access to

PatrickL: something like JWT

Adam: in VISS it is token based but we do not say what that token is, just some sort of string and up to OEM
... application sends the token during authentication function, VISS service checks against authenticating service

PatrickL: does this restrict gets and sets as well?

Adam: the getMetaData returns what signals you are allowed to use (based on your token)

PatrickL: it would be nice for an application to indicate what information it seeks. they want to rely on a specified interface to receive tokens

<AdamC> VISS perspective:

<AdamC> https://rawgit.com/w3c/automotive/gh-pages/vehicle_data/vehicle_information_service.html#fig-diagram-showing-conceptual-websocket-security-token-flow

[how tokens are used by a given OEM for providing applications access to signals we have deliberately left out of scope]

PatrickL: if I can mainly access data that is behind some type of authentication, if it differs then I cannot use one set of interactions between vendors

Magnus: one comment. we should not try to create something on our own here and should follow a commonly accepted method
... Oauth perhaps

PatrickL: Oauth not the way to go because it requires human interaction
... are you concerned about the generation of the token, validation or what?

Magnus: all of those

PatrickL: a few failure codes if things don't work. we just need ways to generate/acquire token and yes not something new

[Ted describes several of the things he has in mind that can be part of an app manifest that would increase network efficiency, remove known attack vectors, etc. A token and corresponding policy language description on what that application is permitted to use on and off board can be part of the manifest as well.]

PatrickL: there are scenarios where the token is generated every 5 minutes on the vehicle itself

Ulf: should we specify fields within the token?

PatrickL: if we want more a JWT instead of a simple string identifier

Ulf: we will need to use the token to link into manifest and information it contains

PatrickL: you can say it is just a string that needs to be checked against a registry
... it could be a signed key checked with a public key
... keeping this outside the interface

Ted: simple tokens run the risk of being stolen and used by malicious apps akin to how passwords are intercepted and reused

PatrickL: a token is like an access key but not as static
... you can generate on the fly and the implementation is responsible to handle it

Ted: an app registry could reissue tokens more frequently for sensitive signals, every few minutes or even single use like OTP

RESOLUTION: stick with tokens for now as in VISS, explore how WoT and other similar solutions w/o human solve it for consideration

Ted: for example Decentralized IDs might be appropriate

PatrickL: it might be more complicated than we need but could be suitable

[discussion of DIDs]

Ted: the DID URI could be the token used

Magnus: seems to me we should standardize verification of tokens so as to allow more interop

Ted: yes should not reinvent wheel and leverage what is state of art security wise with respect to tokens or alt authentication

https://tools.ietf.org/html/draft-ietf-oauth-device-flow-13#page-4

PatrickL: Oauth 2.0 flow is great but requiring a user to authenticate regularly in a trusted system would be tedious

<scribe> ACTION: Magnus, Glenn and Ted to research different authentication options to bring back to group

<trackbot> Error finding 'Magnus,'. You can review and register nicknames at <https://www.w3.org/auto/wg/track/users>.

<scribe> ACTION: PatrickL to get and translate authentication excerpt from internal ViWi 1.9 to group

<trackbot> Error finding 'PatrickL'. You can review and register nicknames at <https://www.w3.org/auto/wg/track/users>.

Introspection

PatrickL: we want an introspection interface?

All: yes

PatrickL: we use $spec for ourselves and would propose that. the way we do it you can put at any point in URI path and get the appropriate parts back that fall under that logical container

Ted: I am fine with whatever, we should look at IETF URI Template that Yves pointed us at yesterday to see if there is a clearer convention

PatrickL: I liked your (W3C) ,access tool for readability
... there may be other metadata to be handled by similar appendages to URIs we might want to create

Other domains

Ted: we have and should continue to prioritize around signals. we could start work on the other domain data models (media, nav, notifications etc) and then come up with tooling to produce specification fragments for them.
... for navigation we have something rudimentary from researcher at VW partner that PatrickB knows.
...NAV is very complicated and we have been seeking to do more with Tomtom, Garmin or HERE. Not successful still and may approach Open Street Maps and/or Google at some point.
... for now we just need some basics

PatrickL: are there any that people care about?
... I would think we want vehicle position

Ted: heading, destination and calculated distance would be nice too...

PatrickL: that gets us into nav
... that gets us into routing state from vehicle, estimates on duration

Ted: is there existing ontology for navigation?

Benjamin: I can look

Ted: certainly for location

Benjamin: yes, late 1990s vintage even

Summary

PatrickL: I like we covered all we set out to. the timeline is not as defined and validated as we would want
... we have understanding on what we concentrate on

Ted explains what he is happy about

Glenn: Ted covered several of my take aways. what I want to do is focus on implementation and bring in the various university resources from Neutral Vehicle and elsewhere
... drawing some automotive security minds for review (in addition to those in W3C community) is worthwhile

Armin: we discussed purpose based authentication so will give that more thought
... looking forward to what happens and willing to help

Harjot: nice to be able to put faces to names
... my strategic goal is to work on the Data Contract part, in particular the sampling methodology used

Urata: I was involved in this activity for awhile but my attention in ACCESS is bringing me to another project and cannot spend time with this group
... one of my interests is where VISS and VIAS will be going
... I am looking forward to watching the progress

Hira: I too have been involved since the early beginning and am looking forward to the outcome

Ulf: I had the hopes we could get sufficient alignment so we can get started on v2 spec
... we have achieved that and feel good about this meeting

Magnus: this convergence discussion has been a bit slow and drawn out and pleased we are moving forward
... having that settled and start of a plan and timeline is good
... that JLR finds the proposed VSS 2 changes acceptable is great since the common model is very important
... I am less concerned about the WoT approach and think there are more possibilities there
... we are doing kind of the same thing but at different scales

Benjamin: I had low expectations based on the last F2F meeting
... especially looking forward to this implementation/practice as it will help get feedback

Guru: I have not been able to attend so much given the timezone differences, good for me to get summary, learn more about ontology
... looking forward to the implementation

Jinkyu: appreciate the work you are doing since I am a developer that will benefit from this work

[adjourned]