Re: Answers to chat comments

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> 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
>
>
>
>
>