Re: Answers to chat comments

Hi Isaac!
“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. “

This is interesting as this could be useful for v2v data exchange where trust in some/many cases are important… so VSS(the data model) should in this case include this ? I think it would be interesting to hear more about your proposal.

/pw


From: Ulf Bjorkengren <ulfbjorkengren@geotab.com>
Date: Wednesday, February 5, 2020 at 9:16 AM
To: Isaac Agudo Ruiz <isaac@lcc.uma.es>
Cc: "Adnan.Bekan@bmwgroup.com" <Adnan.Bekan@bmwgroup.com>, public-automotive <public-automotive@w3.org>
Subject: Re: Answers to chat comments
Resent-From: <public-automotive@w3.org>
Resent-Date: Wednesday, February 5, 2020 at 9:15 AM

Hi Isaac,
I find your proposal very interesting, and I would be very interested in hearing more about it.
One question, your model would always require a token in a request?
BR
Ulf

On Wed, Feb 5, 2020, 17:57 Isaac Agudo Ruiz <isaac@lcc.uma.es<mailto: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<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.nics.uma.es%2Fisaac&data=02%7C01%7Cpeter.winzell%40volvocars.com%7C9b145bf9e92a42f5309c08d7aa5f123d%7C81fa766ea34948678bf4ab35e250a08f%7C0%7C0%7C637165197628633249&sdata=mE%2FCRJPqw2l44iEGeP8Ugp9E1ZmeqGFUu01bCIb9Euw%3D&reserved=0>



El 5 feb 2020, a las 13:42, Ulf Bjorkengren <ulfbjorkengren@geotab.com<mailto: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<mailto: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<mailto:adnan.bekan@bmwgroup.com>
Web: http://www.bmwgroup.com<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.bmwgroup.com%2F&data=02%7C01%7Cpeter.winzell%40volvocars.com%7C9b145bf9e92a42f5309c08d7aa5f123d%7C81fa766ea34948678bf4ab35e250a08f%7C0%7C0%7C637165197628643252&sdata=sKeEkJvLvIBNrkufBKOliiWrdGpJsUbEcIllT6Ryiiw%3D&reserved=0>
--------------------------------------------------------------------
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<mailto:ulfbjorkengren@geotab.com>>
Date: Wednesday, 5. February 2020 at 11:42
To: public-automotive <public-automotive@w3.org<mailto:public-automotive@w3.org>>
Subject: Answers to chat comments
Resent-From: <public-automotive@w3.org<mailto: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<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.geotab.com%2F&data=02%7C01%7Cpeter.winzell%40volvocars.com%7C9b145bf9e92a42f5309c08d7aa5f123d%7C81fa766ea34948678bf4ab35e250a08f%7C0%7C0%7C637165197628653243&sdata=6UGsC5c6q7Hd6lg2vb2DeKl%2Be90V5spgM%2BYyzMgqibs%3D&reserved=0>