Automotive Working Group Teleconference

20 Oct 2020



Armin, Ashish, Ted, MagnusF, Steven, Ulf, Arman, Adnan, Glenn, Daniel, Gunnar, Peter, MagnusG, Karen


<scribe> Scribe: Ted

<scribe> scribenick: ted


Ted: anything else people would like to see on the charter besides what we discussed earlier in the week? (VISS, Gen2, RPC and Best Practices). If EURECOM makes a Member Submission in time, we will add VSSo


Gen2 name

MagnusF: VIPS


Vehicle Information Service Specification - VISS (version 2) has the most votes

Ted to announce to the mailing list

Ulf: when updating documentation should we use VISS or VISS v2?

Ted: VISS and in title we will have 'version 2'

Vehicle Assurance


Arman: this topic relates to best practices, Ashish's desire to validate data coming off the vehicle
... work we are doing in W3C crucial to bringing standardization and subsequent privacy and security considerations
... people should be familiar with UNEC and supply chain concerns
... use cases and reliance coming off the data is useful
... how can we manage integrity of the data, not discussing the encryption
... encryption is useful for protecting integrity indeed. protecting and preserving data and having single version of the truth eg after an accident is important
... best practices can address right to repair, possible different parts - but they may alter the vehicle significant
... you want to verify origin of the different parts. will avoid blockchain, but see them as series of hashes
... control of ledger a potential issue
... anyone should be able validate integrity of information based on the hash and not necessarily revealing the data itself
... managing keys is an issue when you do not have a prior relationship, no trust established

Gunnar: you keep saying publish, which is a key part. if coming from a single server a single point of failure

Arman: a discovery I made was how Estonia digitized their government. they top hash is advertised in the financial times paper around the world
... I will add a link to the paper. it is being viewed by the rest of the EU
... I highlight the challenges with red arrows
... you can use these hashes to reference individual vehicles during its life cycle
... this will allow you to identify and verify data coming off that vehicle, creating a single version of the truth
... idea was to open the discussion and see what this group thinks about this need

Ted: reminds me a bit of Decentralized Identifiers, used for many purposes including tracking shipping containers


Ulf: I have a question, how would this relate to Gen2? would it be visible at data or protocol level?

Arman: unsure, basically a use case for best practices and further reflection more than implementation
... at the end of the day it is just a keyless signature added to the data

Ulf: would there be a signature added or incorporated into responses from Gen2 server, where would they appear

Arman: perhaps accompanying recommendations
... too often there is zero proof data corresponds to a given vehicle

Ulf: it sounds you would like to see a signature added to data being offboarded

Arman: yes

Ulf: we do not have that support right now but could discuss

Arman: this is why I suggest adding it to best practices initially

Daniel: you store hash with data then?
... interesting

Ted: VIN alternative as I was hesitant seeing it as part of access control, don't necessarily want to share it and may have suggested a hash as an alternative
... alternately, once off-boarded and in cloud a hash can be applied

Ulf: yes, we said it could be a psuedo VIN

MagnusG: I was curious about attaching hash to payload all the time. if it stays the same we could optimize it, have in TLS cert or TCP handshake header

Arman: no, based on the data
... you could also have possibility to validate provenance of the components of the vehicles

Ted: that wrecks some use cases like asset management as hash changes when component does, treat as a different vehicle

Gunnar: this a security wrapper of sorts?

Arman: hash is the only thing attached to it. if you receive hash that doesn't match, different digit you know someone manipulated the data

Ted: reminds me of John Schmotzer (Ford) interest in getting 'engineering data' from underlying ECU not just signals.
...data integrity should be part of a Best Practices document

Layered Policy Language

Ashish: I am here to present my research topic, vehicle access control policy framework
... I am starting my research next month


Ashish: vehicles are operating in a more complicated environment with many stakeholders besides even those listed
... owner, their friends, GPS, cloud data marketplace, v2v...
... smartcities
... with sharing data comes responsibility
... this brings us to the challenges we face, first and foremost protecting personal data
... GDPR covers location, route as protected data
... second challenge is interoperability
... different owners of proprietary data models. there needs to be a seemless way to share this data
... design model for access control needs to be able to adapt to types of vehicles. cars have limited computing resources
... remote access to sensor data needs to be restricted
... use case I considered for my research is based on our previous discussion
... settled on a core use case
... could be different profiles for vehicle owner and shared users
... this is a the use case I want to work on, including access rules given to different people and capturing consent
... need to protect and anonymize data for distribution based on LPL
... there are several domain specific languages
... settling on XACML for the actual representation
... LPL ensures access control, what is being done with the data and why
... Alice (owner) needs to provide access to her car. not focused on safety just access control
... first want to identify the stakeholders, look at purpose space access control then add profiles to it
... want to do analysis with this group at W3C and get advice on practicality of approach
... given connectivity issues the decision on access needs to be local to the car
... Ford has a large corpus of publicly available data that could be used
... a basic example of access based on a profile

Ulf: I see you mentioned RBAC and purpose as that is what Isaac and I are using in our access control model
... there are some common denominators and perhaps a way to tie them together

Ashish: I did have a brief read and believe I can use it as a basis to extend further
... I would welcome a separate call on possible extensions

Ted: @@services

Ashish: keeping a basic structure at first, API add profiles and go from there

Gunnar: this industry or university research?

Ashish: funding is from University of Lyon, work in conjuction with University of Passau
... I welcome feedback and sharing resources to refine requirements

Gunnar: anyone perhaps connected from an auto manufacturer?

Ashish: I intend to reach out as this advances and seek further support then

Gunnar: I am certainly interested in finding alignment. for me it is a bit stricter than saying there may be overlap. either there is or isn't
... if there isn't feel free to suggest we adjust our thinking

Best Practices


https://www.nist.gov/video/ndn-community-meeting-day-1-part-1 58 minutes in

Glenn: we obviously have interest in this and will be reviewing internally and providing comment
... it is a super important topic. it might be difficult for this group since we focus on technical aspects
... there is current EU regulatory discussion seeking industry best practices as input
... I am unsure if there is balance in the input

Gunnar: quite a bit to digest but you are touching on the right points and these are areas than need best practices
... security is one of those
... as far as the politics, we can expect those who don't want data to be shared with third parties to slow down or subvert technology
... I want to solve the technical

Arman: I do believe UNECE WP29 is more relevant than the ISO standard since it includes regulatory framework, not just a standard

Gunnar: when there is a standard in place, it becomes considered best practice and if you are not adhering what the rest of the industry is doing

Summary of Action Items

Summary of Resolutions

    [End of minutes]

    Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
    $Date: 2020/10/20 19:56:01 $