Meeting minutes
Access Control Framework Research
Ashish: security, access control and privacy are key pillars
… trying to keep scope reasonable and narrow. this is influenced by best practices discussions
… requirements I considered is arbitrary signal access, controlling distribution of that data, polling frequency and computing constraints
… yes resources in a vehicle are limited but potentially expandable as well
… created a table for these areas, requirements and different access control models
… attribute based access control seemed to be the best fit
… did a survey of policy languages, no surprise XACML is a contender as it is widely used. they have data flow and policy models
… first is the data flow model, different entities. [data flow model slide]
[describes the decision flow cf diagram]
Ashish: XACML also has a policy language model. you can have different rules and effects, algorithms can be combined
… I want to take each of these requirements and see how they apply to automotive needs
… I refer to data flow as decision model
… various factors can apply such as location (geofence) and time (work hours)
[Policy model slide]
Ashish: this is how I envision the policy model could be used
… regarding dissemination of vehicle data, the challenge is how to regulate after it leaves the vehicle. to do so requires accountability
… specifically looking at a sticky policy and combining with proxy re-encryptino (which Isaac has previously explained to this group)
… a sticky policy follows the data and as that would take storage space, it could be referenced instead of duplicated **q+
… I still need to understand PRE better and would like to further my understanding with Isaac
[slide on PRE]
Ashish: I wanted to look at scalability of PRE+sticky policy, time to decrypt
Isaac: happy to discuss with you and agree the combination is beneficial
Ashish: there is no absolute way to protect data after it leaves the vehicle but this goes a far way
… I introduce a watchdog to monitor frequency of data access
… for regulating on-board computing resources. a scheduler and memory manager could be combined with the watchdog
… I plan on evaluating these approaches, using formal methods for qualitative and quantitative
… part of regulating computing resources is prioritizing some processes over others
… comparison would require establishing a baseline in XACML
… part of my research includes protecting the sensitivity of the data which may warrant different transmission means
… we haven't accounted for purpose as required by GDPR yet
… thank you for your time, appreciate any feedback you might have
Ted encourages OEM and Tier 1s to give reactions or insights (on or off record) on what they know is taking place
Ashish: how easy would it be to expand computing resources
Ted: doubt they're interested in doing so, Tesla did for older vehicles as part of a recall on their MCU
Peter: it won't happen
Ted @@on GDPR+consent
Ashish: regarding granular/attribute based access control
[discussion on role vs attribute based]
Gunnar: it depends on how many attributes are being taken into account re how complex it would be to manage
… I think we were there early on in access control where we should make a list of attributes, circumstances on whether something should be accessible
… identity of user, which application, where it is running from (external to vehicle, cloud or phone...)
… the specification doesn't need to define all these, that can be left to the implementer
… not sure which is more common, attribute or role. Android is straight forward, signals are grouped and applications given access to groups with user consent
Issues and PR
Ulf: last time we discussed MQTT and created a PR based on it, not sure we can make a decision on it today but encourage others to read through it and I would need time to digest Erik's comments
… please read further for next week
https://
Ulf: Wonsuk noted a few error codes were missing and added these two
https://
… time duration we check somewhere and we should be able to report it as well as requested data not being found
… without double checking, I am pretty sure he is correct and propose we merge this request
Ulf: I provided feedback on https://
… we shouldn't support multiple scopes within an access token but it can be addressed with this new authentication protocol flow where we have access per signal defined within the token itself
(attribute based)
Ulf: it is also possible with multiple requests using different tokens although less convenient
… Adnan, have you heard back from your colleague?
Adnan: we will have a look
https://
Ulf: there are various scenarios where the VIN isn't known or necessary
… we agreed this is a valid point and could be solved readily by making the VIN parameter optional
Adnan: it would be worth stating when it would be worth stating
Ulf: question on whether it should be in best practices or spec
Ted: depends, BP can evolve after spec is done. are we going to be general or detailed and expand over time
… need to keep developer in mind
Gunnar: want to emphasize that, best practices is more high level guidance whereas spec is more rigid definition
Ulf: I am seeing some other points raised in this issue besides just the VIN. they also want access control a MUST instead of optional/SHOULD
Adnan: agree with Gunnar, in the spec is better to have consistency