Re: Answers to chat comments

Hi Sebastian,

it is an interesting and valid use case you bring up. With role data in the
VSS tree, if you want to add a new role it becomes necessary to have a
means to modify the tree in the vehicle.
One possible solution, I do not necessarily recommend it, would be to
incorporate this into the "dynamic registry" mechanism that is a
discussed Gen2 feature.
I do not see any other realistic solutions.
This could be taken as an argument to go back to my initial proposal, where
role data was not in the tree:). Roles could still be part of the complete
model, but reside in the backend, as you suggest.

Regarding your proposal, I believe it relies on that the tree has a default
read/write access control on all nodes?
If so, personally I am not so fond of a "closed" paradigm like that. I
advocate a more "open" paradigm that require active choices to apply access
control.

BR
Ulf

On Wed, Feb 12, 2020 at 1:48 PM Schildt Sebastian (CR/AEX1) <
Sebastian.Schildt@de.bosch.com> wrote:

> Hi,
>
>
>
> Just read through it, but one thing is not quite clear to me. Of course in
> a system there are roles (and they can be as fine-grained or coarse as
> desired) and those roles imply certain access rights to the VSS data model.
> In your GIT discussion I saw:
>
>
>
> VSS nodes may be populated with the properties:
>
> “read-access”: [list-of-roles]
> “write-access”: [list-of-roles]
>
> I understand the semantic to be: “To read this node, you need to be one of
> those roles”. But isn’t the VSS tree representation a fundamentally a wrong
> place to store this?
>
>
>
> I assume inside a vehicle I have the VSS data model and corresponding
> server. Maybe I already know about some basic roles (i.e. OEM can do
> everything. Third party Android Infotainment App thingy can only read some
> non-critical stuff…)
>
>
>
> However, if some time after SOP I want to deploy a new
> component/function/app with some specific requirements to access data (i.e.
> a new role), I have lost, if the data model already lists roles (because I
> would also need to update the data model/server in the car). Shouldn’t
> rather the software component itself contain a manifest token, that
> describes specifically
>
>
>
> Read-acces: powertrain.trasnmission.*
>
> Write-Acces: cabin.doors.*
>
>
>
> That way you gain flexibility. I still thing that you need “roles”,
> however I would assume that generic roles (“OEM”, “third-party”,
> trusted-thirdparty”) live in the backend. So for example a Keycloak server
> might be used to model roles and stuff and then generate specific tokens to
> be deployed with specific software components. That way would also allow to
> change what rights are part of a role after deployment of the base software
> stack.
>
>
>
> Tldr; VSS data model should not reference “roles”
>
>
>
>
>
> If I misunderstood, please enlighten me J
>
>
>
>
>
>
>
>
>
> Mit freundlichen Grüßen / Best regards
>
>
> *Dr. Sebastian Schildt *
> Communication and Network Technology (DS1) (CR/AEX1)
> Robert Bosch GmbH | Renningen | 70465 Stuttgart | GERMANY | www.bosch.com
> Tel. +49 711 811-15765 | Mobile +49 173 7124227 |
> Sebastian.Schildt@de.bosch.com
>
> Registered Office: Stuttgart, Registration Court: Amtsgericht Stuttgart,
> HRB 14000;
> Chairman of the Supervisory Board: Franz Fehrenbach; Managing Directors:
> Dr. Volkmar Denner,
> Prof. Dr. Stefan Asenkerschbaumer, Dr. Michael Bolle, Dr. Christian
> Fischer, Dr. Stefan Hartung,
> Dr. Markus Heyn, Harald Kröger, Christoph Kübel, Rolf Najork, Uwe Raschke,
> Peter Tyroller
>
>
> *Von:* Ulf Bjorkengren <ulfbjorkengren@geotab.com>
> *Gesendet:* Dienstag, 11. Februar 2020 20:00
> *An:* Isaac Agudo Ruiz <isaac@lcc.uma.es>
> *Cc:* Adnan.Bekan@bmwgroup.com; public-automotive <
> public-automotive@w3.org>
> *Betreff:* Re: Answers to chat comments
>
>
>
> Hi Isaac,
>
>
>
> I got inspired by your proposal to use RBAC, and have modified my proposal
> accordingly.
>
> https://github.com/w3c/automotive/issues/322
>
> I would be very interested to hear your comments on it. Any by anyone else
> also.
>
>
>
> BR
>
> Ulf
>
>
>
> On Wed, Feb 5, 2020 at 5:57 PM Isaac Agudo Ruiz <isaac@lcc.uma.es> wrote:
>
> Hi,
>
>
>
> I don’t want to introduce more noise to this issue but it is important
> that we understand the implications of defining access control policies
> that are both flexible and effective. I was tempted to comment in the repo
> but I think I better explain my point of view by email.
>
>
>
> Assuming most nodes would be open, i.e. without any access restriction, it
> makes sense to opt for a blacklist-like restriction, where only those nodes
> that need some protection are tagged accordingly. However, I still think we
> should go for a RBAC-like model, as mentioned in a previous e-mail.
>
>
>
> My proposal would be to add the following two properties to the data model:
>
>
>
> “write” : [list of roles granted write access]
>
> “read” : [list of roles granted read access]
>
>
>
> This is the definition of an access policy, that applies to a particular
> node and all nodes below in the hierarchy, until a conflict is found, in
> which case, the properties of the node prevail and will become the default
> for nodes below it.
>
>
>
> In the token we need to add the path and the roles granted to the user:
>
>
>
> "scp": "path"
>
> “roles": [list of roles issued in the token]
>
>
>
> In order to gran explicit access to all nodes easily, we can define a base
> role and grant write and read to this role in the root node, so that all
> nodes behind it would be accesible, both read and write modes, by the base
> role without any explicit annotation.
>
>
>
> As an example, we could define only nine roles and name them from 0 to 9,
> in order to implement a similar functionality to Ulf proposal. Then, in the
> root we can place something like this:
>
>
>
> “write": [“0”]
>
> “read”: [“0”]
>
>
>
> That way, all nodes will be granted read and write access by default for
> role “0”. However in order to implement the requirement that higher roles
> will still gain access to nodes granted to role “0” we need to encode also
> a hierarchy in the roles, i.e. “0”<“1”<…<“9”, that in this case is very
> simple. If we plant to use general roles we would need to find a place
> where to define this role hierarchy. Another, less elegant, solution would
> be to grant multiple roles in the same token ...
>
>
>
> RBAC might seem more complex but it is also more flexible and allows for
> the definition of some meaningful role names, e.g. “CAR_OWNER”,
> “CAR_MANUFACTURER”, “ALL”, etc.
>
>
>
> If you find some value in my proposal I don’t mind elaborating it a bit
> more and describe it in the repo. Also, if you think this could be
> something to discuss in the f2f meeting please let me know. I would try to
> be there.
>
>
>
> As a side proposal, but also in the line of access restriction, I would
> like to get your feedback regarding the inclusion of end to end security
> guarantees in the model.
>
>
>
> Do you think it makes sense to request the values of some nodes encrypted,
> so that independently of the transport channel, they won’t be accessed
> until they reach their intended destination?
>
>
>
> That’s particularly relevant if the final user is requesting data using
> some kind of proxy. A solution would be to include in the token the public
> key of the requestor, and have the server encrypt the results using this
> key.
>
>
>
> Again, I’ll be happy to describe that as an issue if you find it
> interesting.
>
>
>
> Best,
>
>
>
> Isaac Agudo
>
>
>
> Associate Professor
>
> Network, Information and Computer Security Lab
>
> University of Malaga
>
> www.nics.uma.es/isaac
>
>
>
>
>
> El 5 feb 2020, a las 13:42, Ulf Bjorkengren <ulfbjorkengren@geotab.com>
> escribió:
>
>
>
> >> How would you keep 3 different scenarios in parallel, T1, T2, T3 with
> C1 C2 and C3?
>
> Only one of the scenarios A, B, or C is possible at a given time.
>
>
>
> >> In proposal we have option to specify only 1 Tag, for actuator, sensor
> or branch. I did not understand how to handle several Tags per actuator for
> varipus clients.
>
> A tag is inherited by underlying nodes, unless a different tag exists in a
> node.
>
> In the scenario I described, a tag was added to the vehicle.cabin.door
> branch node, thus all leaf nodes below it inherited the tag property.
>
> It is only possible to assign one tag per node.
>
>
>
> >> Proposal would work if we would have only 1 client.
>
> Please explain why it would not work as described in the scenarios.
>
>
>
> >> As well how to handle complexity  users x tags x paths?
>
> With flexibility comes some level of complexity, that is unavoidable.
>
> If flexibility is not a desired feature, then the VIWI model could be
> applied, and all nodes are statically assigned read-write access
> restriction, i. e. every client request must contain a valid token. Then
> this tag design can be scrapped.
>
>
>
> BR
>
> Ulf
>
>
>
> On Wed, Feb 5, 2020 at 12:02 PM <Adnan.Bekan@bmwgroup.com> wrote:
>
> >> how flow would look like for 4 diff clients, with tag read, write only,
> read/write and "no tag", and they would access to exactly same branch
> vehicle.cabin.door. Story with tokens I understand and all good, but with
> tags I did not see any additional benefit.
>
> Excluding the write-only case, the following I believe shows the benefits
> it can provide.
>
> The vehicle.cabin.door branch node has three different tagging options:
>
> T1: No tag
>
> T2: Validate: write-only
>
> T3: Validate: read-write
>
> The three clients have respectively: client 1:no token,client 2:
> read-only token, client 3: read-write token (tokens have a scope containing
> this subtree, and are non-expired).
>
> A: For the T1 scenario all clients are able to both read and write the
> leaf nodes of the subtree.
>
> B: For the T2 scenario clients 1 and 2 can read leaf nodes, client 3 can
> both read and write leaf nodes.
>
> C: For the T3 scenario client 1 can neither read nor write any leaf nodes,
> client 2 can read leaf nodes, and client 3 can both read and write leaf
> nodes.
>
> -----------
>
> How would you keep 3 different scenarios in parallel, T1, T2, T3 with C1
> C2 and C3? In proposal we have option to specify only 1 Tag, for actuator,
> sensor or branch. I did not understand how to handle several Tags per
> actuator for varipus clients. Proposal would work if we would have only 1
> client. As well how to handle complexity  users x tags x paths?
>
>
>
> Thank you
>
>
>
> --
>
> *BMW Group*
>
> Adnan Bekan
>
> Research, New Technologies, Innovations
>
> E/E Architecture, Technologies (LT-3)
>
> IoT and Software Technologies
>
>
>
> Parkring 19, 85748 Garching
>
>
>
> Telefon: +49-89-382-56368
>
> Mobile: +49-151-601-56368
>
> Mail: adnan.bekan@bmwgroup.com
>
> Web: http://www.bmwgroup.com
>
> --------------------------------------------------------------------
> Bayerische Motoren Werke Aktiengesellschaft
> Vorstand/Board of Management: Oliver Zipse (Vorsitzender/Chairman),
>
> Klaus Fröhlich, Ilka Horstmeier, Milan Nedeljković,
>
> Pieter Nota, Nicolas Peter, Andreas Wendt.
>
> Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board: Norbert
> Reithofer
>
> Sitz und Registergericht/Domicile and Court of Registry: München HRB 42243
> --------------------------------------------------------------------
>
>
>
> *From: *Ulf Bjorkengren <ulfbjorkengren@geotab.com>
> *Date: *Wednesday, 5. February 2020 at 11:42
> *To: *public-automotive <public-automotive@w3.org>
> *Subject: *Answers to chat comments
> *Resent-From: *<public-automotive@w3.org>
> *Resent-Date: *Wednesday, 5. February 2020 at 11:38
>
>
>
> >> how flow would look like for 4 diff clients, with tag read, write only,
> read/write and "no tag", and they would access to exactly same branch
> vehicle.cabin.door. Story with tokens I understand and all good, but with
> tags I did not see any additional benefit.
>
> Excluding the write-only case, the following I believe shows the benefits
> it can provide.
>
> The vehicle.cabin.door branch node has three different tagging options:
>
> T1: No tag
>
> T2: Validate: write-only
>
> T3: Validate: read-write
>
> The three clients have respectively: client 1:no token,client 2:
> read-only token, client 3: read-write token (tokens have a scope containing
> this subtree, and are non-expired).
>
> A: For the T1 scenario all clients are able to both read and write the
> leaf nodes of the subtree.
>
> B: For the T2 scenario clients 1 and 2 can read leaf nodes, client 3 can
> both read and write leaf nodes.
>
> C: For the T3 scenario client 1 can neither read nor write any leaf nodes,
> client 2 can read leaf nodes, and client 3 can both read and write leaf
> nodes.
>
>
>
>
> --
>
> *Ulf Bjorkengren*
>
> *Geotab*
>
> Senior Connectivity Strategist | Ph. D.
>
> Mobile
>
> +45 53562142
>
> Visit
>
> www.geotab.com
>
>
>
>
>
>
> --
>
> *Ulf Bjorkengren*
>
> *Geotab*
>
> Senior Connectivity Strategist | Ph. D.
>
> Mobile
>
> +45 53562142
>
> Visit
>
> www.geotab.com
>
>
>


-- 
Ulf Bjorkengren
*Geotab*
Senior Connectivity Strategist | Ph. D.
Mobile +45 53562142
Visit www.geotab.com