AW: Gen2 access restrictions


Hello,

Answers inline



Mit freundlichen Grüßen / Best regards 

Dr. Sebastian Schildt

Communication and Network Technology (DS1) (CR/AEX1) 
Robert Bosch GmbH | Renningen | 70465 Stuttgart | GERMANY | http://www.bosch.com 
Tel. +49 711 811-15765 | Mobile +49 173 7124227 | mailto: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, 21. Januar 2020 14:47
An: Schildt Sebastian (CR/AEX1) <Sebastian.Schildt@de.bosch.com>
Cc: public-automotive@w3.org
Betreff: Re: Gen2 access restrictions

Hi,

>> 1 will only happen in development (and maybe better not even implement it), and I am not sure I understand the authlevels, I think access is more complex that just separating a tree (of thousands of elements) to n authlevels.
> I am not convinced 1 will only happen i development. Remember that the transports according to spec must be the secure versions (https, wss). During dev it is quite convenient, so I think it should be kept. 

I agree, during development it will be used/helpful and probably be implemented anyway, but it is a different issue, whether the there is a default setting/level that allows some kind of unrestricted access already inside the architecture/spec, or whether the security architecture says: Without a token you shall not pass. Of course, in a deployment may choose to have something which should be "world-readable", so you empower all apps and functions with the correct credentials. For me it is more of an argument thing (and I do argue a lot about this things). When you propose your technology that provides  access to someones car, is the answer to access control "Yes, you can restrict access", or is the answer "Without the correct credentials, access is not possible". I do understand, that from a technology point of view this is not so different.
Wrt transport security (i.e. TLS): It is different from data security, so while it is mandatory to have it, and it may help with authentication even, just because "you are in" should not mean now you are free what to do.

> Authlevels makes it possible to "layer" the tree into n levels, where authlevel=0 provides accessibility to the smallest set of tree nodes, then growing for each level to the complete tree at authlevel=9 (analogy could be an onion, where authlevel=9 is the complete onion). Authlevel=9 would typically only be assigned to OEM controlled clients, while authlevel=0 would be for third party apps, or the like. The authlevel would also control what is returned to the client when requesting a service discovery. On top of this there is also the access restriction model. 

I understand the layering, and I think for a given usecase, there might be some useful layer model, but it will depend on concrete implementation and maybe even legal regulations. For example, maybe I have an Android-like App runtime in my deployment, and I want to give all Apps in there that request basic vehicle one access level, which may be one of the auth layers. But in another usecase, maybe I only deploy one specific application/function co-developed with an insurance company, and will _only_give it access to the very specific data points needed for the pay as you drive service (consider, even if out of scope for W3C, there might be consent flows to be considered depending on legislation, as in DSGVO where you need to explain what kind of data you access for what. If I get all the "authlevel n" stuff, it might be more than I need).  I understand, that for this application/may deployment of course I could model this insurance app as "authlevel", but it sort of breaks the idea of being a "level".
I see access rights as more complicated overlapping jigswaw pieces, and if so, we need to be able to make access restrictions explicit anyway. (By describing it on a subtree/node level in tokens, and by empowering the implementation to check it). In this case I sort of feel "levels" to be redundant.

>> but I think the information WHO actually can access what cannot be stored in the data model / tree annotations itself.
> Both the access restriction metadata and the authlevel metadata are added to the tree by the layering mechanism, it is not part of the generic VSS tree. So how it is deployed in the tree is typically OEM specific. 
Yes, I like the layer idea, and I think in an implementation, once you  have authenticated and established your access level, I would assume there could be some "masking" layer is created, that makes sure only data I have access to is exposed. 

Tldr: Flexible access restrictions are needed. If we have them, I do not see the need to explicitly add a (limiting) "authlevel"  semantic to the spec, because it does not add any additional features.

> BR
> Ulf


Mit freundlichen Grüßen / Best Regards

Sebastian Schildt 
CR/AEX1
Threema / Threema Work: T8YWYXJ9

Received on Tuesday, 21 January 2020 15:33:27 UTC