<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
https://www.w3.org/2002/09/wbs/76043/Gen2name/
MagnusF: VIPS
Ulf: CVIS, VIPS, VISS
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'
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
https://w3c.github.io/did-core/
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
Ashish: I am here to present my research topic, vehicle access control policy framework
... I am starting my research next month
[slides]
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
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