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
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
https://www.eclipse.org/kuksa/blog/2020/08/18/2020-08-18-dbc/
[adjourned]