Re: Answers to chat comments

On vacation today, back in the discussion next week.
It seems we are converging:)
BR
Ulf

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

> Thank you, that makes stuff more clear to me. So basically “AGT Server” is
> the IAM backend. That makes sense (to me J ).
>
>
>
> Then my view would still be, that “roles” should only live in the AGT
> world. I agree with @Isaac about the usefulness of roles, just my
> conclusion what it means for the system architecture would be (I think)
> different. Modelling-vise roles can take away some complexity and give
> structure to the different access rights, which is good. What is lost, is
> some flexibility (compared to describe everything explicitly, who can
> access what rooms/data), which on the other hand may make the system hard
> to handle.
>
>
>
> So what I would like is to model a system with the concept of “roles”,
> because as Isaac pointed out, that is quite useful. At the same time I
> think, the actual implementation inside a vehicle should be as dumb/simple
> as possible. One rationale is, that updates here are more difficult. While
> actual consumers of the out API _*might*_ live in domains in a vehicle,
> where updates might be done App-style “just like that”, I assume the
> VISS/AT server to be in a more trusted part of the system (as it has some
> bindings to in-vehicle sensors and actors), so at the very least at the
> system level, which is harder to update. When leaving out the roles out
> here, because all access rights are explicitly listed in the AT tokens, it
> takes complexity out of the in-vehicle implementation while maintaining
> maximum flexibility. The roles can live in the AGT/IAM backend, which can
> flatten arbitrarily complex role concepts into AT tokens.  As a model,
> think of the backend as “code generator”: It takes the nicely modelled
> roles thingy and compiles an easily processable token for the in-vehicle
> side.
>
>
>
> 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 15:00
> *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,
>
>
>
> 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
>
>
>