Meeting minutes
Authorization levels
Ulf: on a high level Erik and I have defined the steps a client needs to take to obtain a valid token in our approaches
… alignment seems possible but needed to clear up assumptions on the Bosch flow
Erik: we should be able to share the off-list exchange
[Ted looks for copy to forward to member-automotive list while Erik shares screen on call]
Ulf: we have long and short term formats but can gloss over that for now
… steps 1-6 that a client needs to do in VISSv2 model
… we have three roles, user, application and device
… if approved with credentials that back and match that client
https://
… also enumerate major use cases
Erik: what Sebastian and I did was create a corresponding client interaction without specifying how it gets the token to begin with
… assumption is vehicle running in vehicle, needs to be able to operate without a network connection necessarily
… we don't see the role base need
… our token format, we provided an example in email but suggest Kuksa VAL repo for better view
https://
Ulf: it is possible to combine some of our separated servers to be closer to Bosch model
… this policy representation for RBAC can be used for granular access approach as well
Erik: it might be possible to support both role and granular, just where you expand details of access control
Ulf: the variations should be negotiable by client and handle different token formats
… what you propose as a variability point is fine with me, might be worth giving this all some more thought
Erik: we left it as an unspecified method (token being issued) but need to know how it will be done practically. there are some open topics about how this would look/work in a vehicle
… we wouldn't want token reused across vehicles, does it get provisioned at install or?
Ulf: it doesn't have to be a single flow/solution
Isaac: we thought there may be scenarios that influenced our requirements about wanting an access grant server
Ulf: worth stepping back and enumerating scenarios with third party applications, whether this will only reside in-vehicle etc
… would Bosch produce that?
Erik: we could write it down but current view may differ, aspects evolve
Carine: we could have unspecified (out of scope) aspects but that can lead to interoperability issues as you mentioned
Erik: we will need something that generates a token obviously
Ulf: we could have variability on token generation
Ted agrees with Ulf, Bosch should come up with scenarios they want to support and think about tokens needing updating because of a security incident, allowing external devices etc
Ulf: we can have unspecified aspects but must make token formats clear at the least
Curve logging demo
Action: Ted to look for useful minutes on access control requirements to share
[Ulf shares screen]
Ulf: I'm using some prepopulated sample data for speed, lat and long. I went with a sawtooth sample as it is good for testing curve
… starting simulator, data store, VISS server
… you can see how values are being pushed into state storage
… now need to start a client and for it to be a request for a curve logging subscription
[Ulf has a file of sample client requests on screen, chooses appropriate one]
… have a WebSocket client launched and connected, you see the response to subscribe request on subscription id, etc
… we get an initial speed response and after some time you see we get additional values of speed, lat, long that match the error limit
… it found the right peaks and valleys, trust me, from the sample provided
… if you unsubscribe you get unsub response and rest of buffer is checked against curve and sends any there
… finally it gives the last location
Ted: thanks Ulf, that showed a dramatic savings on bytes that need to be transmitted to provide adequate representation
Ulf: typical reduction is 85%