Re: Answers to chat comments

Hi Sebastian,

the reason I included the "role" is that I believe it can be used to tie
the access control subsystem together with a policy document/subsystem that
is also being discussed in the W3C automotive group.
If I am wrong on that it could be removed.

The AGT server is supposed to live in the cloud, while the AT server is
deployed on the same vehicle as the Gen2 server.
A client first goes to the AGT server, where it is properly authenticated,
and where it also provides input on which vehicle it is asking access to
(VIN). If all goes well, the AGT server returns a signed AGT token to the
client, with which it goes to the AT server on the vehicle, inputs the
token, and requested scope, permission (and role in the token). To assess
whether the request should be granted or not, the AT server may use a
policy document, which could contain access profiles per "role", etc.
If all goes well here also, the client gets the signed token that will
later be used in requests to the bouncer:).

This model with an AGT server and an AT server is inherited from VIWI ,
thanks to the generosity of VW who open sourced it.

This access control model with AGT and AT servers is already available in
the Gen2 implementation project found at
https://github.com/MEAE-GOT/W3C_VehicleSignalInterfaceImpl.
Some details differ from my latest proposal, but the basic architecture
model is there.
You are very welcome to have a look at it, and also to help move it
forward:).

BR
Ulf

On Thu, Feb 13, 2020 at 2:17 PM Schildt Sebastian (CR/AEX1) <
Sebastian.Schildt@de.bosch.com> wrote:

> Hi Ulf,
>
>
>
> I like the “validate” approach. It basically gives us the opportunity to
> define “restricted” areas, and it even allows for both extremes: Everything
> is free, or everything is restricted.
>
>
>
> I am not yet clear why here:
>
> “scope”: “path”
> “permission”: “z”, where z is either “read-only” or “read-write”
> “role”: Y, where Y is either an integer, enum value, or string (open
> design choice)
>
>
>
> It needs “role”, but I think it is because I am still confused in your
> model about the difference of Access Grant Token, Access grant Token
> Server, Access Token and Access token Server. I tried reading the Github
> issue and the Gen2 document, but maybe you can still line out for me, what
> lives where.
>
>
>
> I assume a VISS client has a (JWT) Access token, that is checked by the
> server. Here I still do not need the reason to encode (at least as
> mandatory) a role, if all permissions are explicit (because my thinking
> model is still, a backend service would have “flattened” it from some
> internally roles) . But I am confused where the AGT and AGT server live in
> your architecture.
>
>
>
> 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:* Donnerstag, 13. Februar 2020 10:54
> *An:* Schildt Sebastian (CR/AEX1) <Sebastian.Schildt@de.bosch.com>
> *Cc:* Isaac Agudo Ruiz <isaac@lcc.uma.es>; Adnan.Bekan@bmwgroup.com;
> public-automotive <public-automotive@w3.org>
> *Betreff:* Re: Answers to chat comments
>
>
>
> This discussion encouraged me to update my access control proposal as
> found here
>
> https://github.com/w3c/automotive/issues/322
>
>
>
> BR
>
> Ulf
>
>
>
> On Thu, Feb 13, 2020 at 9:34 AM Ulf Bjorkengren <ulfbjorkengren@geotab.com>
> wrote:
>
> Hi Sebastian,
>
> I like your analogy:).
>
> And in my story there is no difference in that the guests will have to
> come with a signed list of which rooms they want to visit.
>
> Going back to my original proposal, the only difference is that the
> bouncer only requires the guests to show the list for certain rooms (like
> the kings more private rooms).
>
> By just adding one line in the root of the tree, “validate”: “read-write”,
> the stories actually become identical, the bouncer will require a list
> signed by the king by all visitors, for all rooms.
>
> But at the same time it gives flexibility in that for certain rooms the
> bouncer do not require a list, and for some the bouncer only require the
> list if the guest plan to stay over the night (write), not for day visits
> (read).
>
> The concept of roles can still be utilized, in the model described in
> chapter 6 of the Gen2 Core spec the guest would have to tell (and prove)
> the AGT-server not only its name, but also the role it wants. In the
> contact thereafter with the AT-server the guest name and role is on the
> (first) list signed by the king, and this server then uses this trusted
> information together with a policy document the king has provided it to
> assess whether the request for rooms to visit shall be granted to a guest
> with that role. If accepted this results in the signed list the guest
> brings to the bouncer.
>
> So I would say that we are aligned in the general concept, the difference
> is whether the bouncer shall require a signed list for all rooms per
> default, or whether the king shall be able to instruct the bouncer to leave
> some rooms unchecked (or only check stayover guests).
>
> BR
>
> Ulf
>
>
>
>
>
> On Wed, Feb 12, 2020 at 4:13 PM Schildt Sebastian (CR/AEX1) <
> Sebastian.Schildt@de.bosch.com> wrote:
>
> Hi Ulf,
>
>
>
> I think turning this around does not necessarily means to be less open.
> Yes, in our use cases we always require/use “mandatory” access control,
> however in practice this would not preclude to for example configure parts
> of the tree “free for all” (i.e. you can use them if you can reach the vis
> server port). That would be like OBD, where the access control model is: If
> you have (in case of OBD physical) access, you can get a certain
> standardized set of information. In that case the only access/Security kind
> of information in the tree nodes would be “public-writable” or
> “public-readable”
>
>
>
> In another use case you might have a certain amount of access right, if
> you run in a specific domain/runtime environment. For examples sake maybe I
> am on an autonomous driving ECU,  I might assume all
> programs/runnable/whatever in that domain have full access.
>
>
>
> For some shared ECUs I might really have fine-grained access controls on a
> per-app basis.
>
>
>
> The main difference here is: We do not provide the bouncer (VIS server)
> with a complete list of names and which rooms every  guy might access
> beforehand, but instead every guest brings his own list of rooms  signed
> and sealed by the king himself. Whether I got my papers from the king
> directly, or whether I just have a default set, because I am member of the
> royal guard does not concern the bouncer. Ok, I stop:  Let’s not
> overstretch the metaphor here J Another advantage is, you can also revoke
> those rights, limit them in time etc…
>
>
>
>
>
> 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:* Mittwoch, 12. Februar 2020 15:38
> *An:* Schildt Sebastian (CR/AEX1) <Sebastian.Schildt@de.bosch.com>
> *Cc:* Isaac Agudo Ruiz <isaac@lcc.uma.es>; Adnan.Bekan@bmwgroup.com;
> public-automotive <public-automotive@w3.org>
> *Betreff:* 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
>
>
>
>
>
>
> --
>
> *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