Re: Answers to chat comments

>>  so VSS(the data model) should in this case include this ?

Not as I see it, it will be handled in the Gen2 context, transparent to
VSS.
I think the proposal by Isaac to include a client public key in the token,
and the Gen2 server doing the encryption before dispatching the response is
a very compelling design.

BR
Ulf

On Wed, Feb 5, 2020 at 6:51 PM Winzell, Peter <peter.winzell@volvocars.com>
wrote:

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

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