IRC log of auto on 2021-10-26

Timestamps are in UTC.

18:01:59 [RRSAgent]
RRSAgent has joined #auto
18:01:59 [RRSAgent]
logging to https://www.w3.org/2021/10/26-auto-irc
18:02:01 [Zakim]
RRSAgent, make logs Public
18:02:02 [Zakim]
Meeting: Automotive Working Group Teleconference
18:02:08 [ted]
Chair: Peter, Ted
18:02:09 [ted]
scribenick: ted
18:02:23 [ted]
Present+ Ashish, Peter, Ted, Ulf, Isaac
18:03:32 [caribou]
present+
18:04:02 [ted]
Present+ MagnusG
18:04:43 [ted]
Present+ Erik
18:06:06 [ted]
Present+ Gunnar
18:07:13 [ted]
Present+ Adnan
18:07:48 [ted]
@@slides
18:08:05 [ted]
Topic: Access Control Framework Research
18:08:21 [ted]
Ashish: security, access control and privacy are key pillars
18:08:50 [ted]
… trying to keep scope reasonable and narrow. this is influenced by best practices discussions
18:09:33 [ted]
… requirements I considered is arbitrary signal access, controlling distribution of that data, polling frequency and computing constraints
18:09:55 [ted]
… yes resources in a vehicle are limited but potentially expandable as well
18:10:21 [ted]
… created a table for these areas, requirements and different access control models
18:10:35 [ted]
… attribute based access control seemed to be the best fit
18:11:18 [ted]
… did a survey of policy languages, no surprise XACML is a contender as it is widely used. they have data flow and policy models
18:11:42 [ted]
… first is the data flow model, different entities. [data flow model slide]
18:12:05 [ted]
[describes the decision flow cf diagram]
18:12:49 [ted]
Ashish: XACML also has a policy language model. you can have different rules and effects, algorithms can be combined
18:13:04 [ted]
… I want to take each of these requirements and see how they apply to automotive needs
18:13:19 [ted]
… I refer to data flow as decision model
18:13:41 [ted]
… various factors can apply such as location (geofence) and time (work hours)
18:13:56 [ted]
[Policy model slide]
18:14:31 [ted]
Ashish: this is how I envision the policy model could be used
18:15:26 [ted]
… regarding dissemination of vehicle data, the challenge is how to regulate after it leaves the vehicle. to do so requires accountability
18:15:54 [ted]
… specifically looking at a sticky policy and combining with proxy re-encryptino (which Isaac has previously explained to this group)
18:16:40 [ted]
… a sticky policy follows the data and as that would take storage space, it could be referenced instead of duplicated **q+
18:17:00 [ted]
… I still need to understand PRE better and would like to further my understanding with Isaac
18:17:10 [ted]
[slide on PRE]
18:22:10 [ted]
Ashish: I wanted to look at scalability of PRE+sticky policy, time to decrypt
18:22:38 [ted]
Isaac: happy to discuss with you and agree the combination is beneficial
18:23:04 [ted]
Ashish: there is no absolute way to protect data after it leaves the vehicle but this goes a far way
18:23:43 [ted]
… I introduce a watchdog to monitor frequency of data access
18:24:38 [ted]
… for regulating on-board computing resources. a scheduler and memory manager could be combined with the watchdog
18:25:35 [ted]
… I plan on evaluating these approaches, using formal methods for qualitative and quantitative
18:26:05 [ted]
… part of regulating computing resources is prioritizing some processes over others
18:26:29 [ted]
… comparison would require establishing a baseline in XACML
18:27:11 [ted]
… part of my research includes protecting the sensitivity of the data which may warrant different transmission means
18:27:37 [ted]
… we haven't accounted for purpose as required by GDPR yet
18:27:55 [ted]
… thank you for your time, appreciate any feedback you might have
18:33:56 [ted]
Ted encourages OEM and Tier 1s to give reactions or insights (on or off record) on what they know is taking place
18:34:10 [ted]
Ashish: how easy would it be to expand computing resources
18:35:17 [ted]
Ted: doubt they're interested in doing so, Tesla did for older vehicles as part of a recall on their MCU
18:35:23 [ted]
Peter: it won't happen
18:38:19 [ted]
Ted @@on GDPR+consent
18:38:35 [ted]
Ashish: regarding granular/attribute based access control
18:41:22 [ted]
[discussion on role vs attribute based]
18:41:40 [ted]
Gunnar: it depends on how many attributes are being taken into account re how complex it would be to manage
18:42:17 [ted]
… 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
18:42:39 [ted]
… identity of user, which application, where it is running from (external to vehicle, cloud or phone...)
18:43:11 [ted]
… the specification doesn't need to define all these, that can be left to the implementer
18:43:56 [ted]
… 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
18:47:33 [ted]
Topic: Issues and PR
18:48:29 [ted]
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
18:48:44 [ted]
… please read further for next week
18:49:05 [ted]
https://github.com/w3c/automotive/pull/427
18:50:28 [ted]
Ulf: Wonsuk noted a few error codes were missing and added these two
18:50:30 [ted]
https://github.com/w3c/automotive/pull/428
18:50:55 [ted]
… time duration we check somewhere and we should be able to report it as well as requested data not being found
18:51:28 [ted]
… without double checking, I am pretty sure he is correct and propose we merge this request
18:52:58 [ted]
Ulf: I provided feedback on https://github.com/w3c/automotive/issues/422 based on last week's discussion
18:53:41 [ted]
… 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
18:53:47 [ted]
(attribute based)
18:54:13 [ted]
Ulf: it is also possible with multiple requests using different tokens although less convenient
18:54:32 [ted]
… Adnan, have you heard back from your colleague?
18:54:43 [ted]
Adnan: we will have a look
18:54:45 [RRSAgent]
I have made the request to generate https://www.w3.org/2021/10/26-auto-minutes.html ted
18:55:57 [ted]
https://github.com/w3c/automotive/issues/425
18:56:18 [ted]
Ulf: there are various scenarios where the VIN isn't known or necessary
18:56:46 [ted]
… we agreed this is a valid point and could be solved readily by making the VIN parameter optional
18:57:13 [ted]
Adnan: it would be worth stating when it would be worth stating
18:57:25 [ted]
Ulf: question on whether it should be in best practices or spec
19:00:01 [ted]
Ted: depends, BP can evolve after spec is done. are we going to be general or detailed and expand over time
19:00:07 [ted]
… need to keep developer in mind
19:00:41 [ted]
Gunnar: want to emphasize that, best practices is more high level guidance whereas spec is more rigid definition
19:01:37 [ted]
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
19:03:25 [ted]
Adnan: agree with Gunnar, in the spec is better to have consistency
19:03:33 [RRSAgent]
I have made the request to generate https://www.w3.org/2021/10/26-auto-minutes.html ted
20:24:53 [Zakim]
Zakim has left #auto
21:00:22 [ted]
s|@@slides|https://lists.w3.org/Archives/Public/www-archive/2021Oct/att-0013/Conencted_Vehicle_Framework_for_Security_and_Privacy.pptx|
21:00:24 [RRSAgent]
I have made the request to generate https://www.w3.org/2021/10/26-auto-minutes.html ted
21:00:42 [RRSAgent]
I have made the request to generate https://www.w3.org/2021/10/26-auto-minutes.html ted