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
Adam: being an editor was not a scary process, we used peer review conventions
* 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]
[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.
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
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:
[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>.
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
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
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]