Automotive Working Group Teleconference

18 Aug 2020


Arman, Ted, Ashish, Ulf, Ted, Peter, MagnusF, MagnusG, Harjot, Sebastian


Vehicle Access Control Policy Framework


Ashish: I am starting my PhD in October and looking at use cases and requirements to take into consideration

[slide 2, what is interesting]

Ashish: vehicles collect data from a wide variety of sensors which have quite a few uses, fleet management, collision avoidance, etc
... the problem with the data integration include privacy issues, security, interoperability
... in context of gdpr, sensitive data needs to be protected including location, information about driver, regular routes
... all personal identifying information need to be protected
... W3C (and GENIVI) already working on standardized data model for the data
... rules for transmitting sensitive data needs to be enforcible
... want an overall access control framework for off-boarding and in-vehicle use
... want to identify target use cases and requirements

[state of art slide]

Ashish: there are several domain specific policy languages and Armin's Layered Policy Language implemented on top of XACML
... it is human readable as well, near natural language
... my approach is to start with research, understanding stakeholder requirements, next look at architecural design
... need to define where the access control decision is made. if it is in the cloud, not usable in the vehicle
... I want to share some possible use cases
... vehicle owner wants to provide data access to a 3rd party - eg a mechanic or to get location for service or delivery
... vehicle to cloud/data marketplace, emergency situations
... want to hear about your interests

MagnusF: it is a concrete problem in need of a solution. looking at it from GENIVI/CCS point of view and catalog service as well
... it is not only sensors but actuators, eg to open door and any actuation carries physical risks
... pushing a destination to a vehicle nav system even. it is critical to have stringent access control
... there are situations you may want to open a subset of capabilities to additional parties. current state of art is bring your own device
... I have not seen this solved yet

Ashish: I agree and it is a practical problem and appreciate the feedback

Peter: one important piece of tech becoming increasingly uptake of Android

MagnusF: there is keen interest with us as well for at least IVI
... looking at how to package it... you are right ECU are generally C++
... we are running virtualized machines inside of ECU
... we are running a QNX hypervisor and mix of Linux
... can you explain a bit more about the domain specific policy languages?

Ashish: I am only familiar with XACML which includes access control and intend to research them further

Peter: real data from this working group, that is going to be difficult and something we have been trying for months

Ted clarifies the data marketplace topic, how we are going to remain focused on technical solutions avoid the politics

MagnusF: domain in need of a solution

Arman: there has been a long discussion in CCC about GDPR
... if there is an incident, accident for instance, you also want to ensure the integrity of the data
... I'll look for some public information I can share

Access control

Ulf: only comments I have seen so far is from Peter and appreciate them on github
... I followed up on those comments there already
... not sure how the best way to work on this in these calls as my preference is to have them in writing
... it is quite a big chapter and expect a number of questions

Peter: I agree, there could be mix of simple and substantive questions and comments better to have them combined than scattered between call and github

Ulf: if there is need for clarification, feel free

MagnusG: I am not finished with my review but have a question about the proof mechanism, how that will work
... it is mentioned in several places, 6.3.1, 6.4.2

Ulf: there are two different types of proof and we use the term for authenticating the client when interacting with access grant server
... there is also proof of freshness of the public key

MagnusG: my question is related to the first one

Ulf: second one is rather simple, client encrypts a timestamp with a private key to the one who wants to verify it with the public key
... that prooves the client has the private key and its fresh
... want Isaac for conversation on the other
... can use x509 certs to proove client as well

MagnusG: that is where I'm getting stuck a bit
... I'm also curious about long/short term use of public keys
... I see freshness as a signed timestamp and fine with that
... I'll pose my question offline in writing and collect thoughts a bit more

Ulf: that also gives me more time to get answer and get Isaac
... anyone else with quick question?
... I'll follow your advice from your comments

Peter: and likewise find time for yours

Ulf: hope to get more reviewers...
... encourage people to read it in its entirety


Ted: we need to finalize RPC call schedule, next week or following (resolved)
... do reach out internally on potential use cases/services to add to the catalog. a few of us have been discussing CCC's digital key which is getting uptake

Sebastian: today we posted a video showing off what we can do with VISS and CAN data, will share link



Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version (CVS log)
$Date: 2020/08/24 16:13:26 $