Meeting minutes
Introductions
BMW PoC of VISSv2
Manuel: before we start, there are some questions we have
Ted: short ones fine here, otherwise preference to have on github and sometimes that prompts longer topics
Manuel: we have a number of questions around access control, to use this protocol within the vehicle
… one issue is we don't know the VIN at the outset which is needed for access control
Ulf: the client first contacts the access grant token server which is meant to be run in the cloud
… I guess out of band
Manuel: isn't it possible to have the access grant server in vehicle?
Ulf: general view has been it should be in the cloud but do not believe we made that mandatory
Isaac: using PKI as analogy, the access grant server running in the cloud is preferred. you could however have self signed tokens provisioned and done so within the vehicle
… it depends on what you need. you could run this without any cloud dependencies
Manuel: we want to bring applications to vehicle in web browser context
… the browser is running on the car and application calling VISS server needs to get access
… the JS (VISS client in this case) would need to know how to find the VISS IP on vehicle and how to get the token
Ulf: would having VIN optional facilitate?
Manuel: there is a 1:1 relationship so that would help
Adnan: for efficiency should we move this topic to GH?
Ulf: yes and appreciate you are running into problems and we can work on the solution
Erik: we have thought there may be use cases where authentication isn't needed
Ulf: we are actually discussing a possible solution for how can we do authentication for your needs
Isaac: would there be a way for owner to approve?
Manuel: yes and we are taking approval fatigue into consideration
Andre: I am working on a VISS implementation for our internal simulator, without having an actual car
… for access token, I noticed there is one scope, the purpose and approved list of data points the client can access
… could an application have multiple scopes?
… would those need multiple tokens?
Ulf: as it is written right now, you cannot have multiple scopes for a single token
Isaac: is it a problem to handle multiple tokens in the client?
Manuel: it could but maybe creating a specific scope for the need might be better
… I would prefer a token with a defined scope
Isaac: you could have a grant token with multiple scopes but the access token should be as narrow as possible
Andre: so in my client application, I would need to manage multiple tokens. understand server implementation would be easier
Isaac: yes understood but increases client overhead
Andre: can we open an issue there as well?
Ulf/Isaac: absolutely
Andre: there is a sentence where it says the scope and purpose list are managed, is there a plan to have an interface to query scopes available and relevant data?
Ulf: we have not discussed that in any detail. my view is the ecosystem owner (OEM) that controls those policy lists
… that is a list of services the OEM offers to third parties and fits well into a business model
… it is up to OEM to define those lists
… any potential client, even outside the vehicle, should be able to connect to OEM server to get those lists
… we have intentionally not defined anything about OEM getting those lists to vehicles, outside the scope of our specs
Andre: perhaps we can provide our experiences there
Ulf: the idea behind scope list came from a requirement to assign different clients with different roles to have mutually excludable sets of data
… you can look at the reference implementation https://
Andre: the spec covers 404 for data points in tree that aren't present. shouldn't there be a way for the server to let you know what version of VSS is being used
Ulf: the VSS version is in VSS itself and should be available
Gunnar: there is also service discovery
Ulf: right, you can point to any node in the tree and get subtree underneath. you could even point to root/vehicle node and get the whole tree available to that client back
Andre: as a client application, I don't know anything about the car before connecting. so the first step is such a request?
Ulf: yes, service discovery with root node is one way
Gunnar: you can also ask for specific signals in service discovery?
Ulf: no, everything below node you point to
… if you have no knowledge of the tree at all, you have nothing to point to except the root (vehicle)
[entire tree the client application has access to is what would be returned]
Gunnar: either you know everything about the target vehicle for the application already or nothing and need to do discovery
Andre: as the vehicle doesn't change, that is rather onerous
Gunnar: you don't get data results, just what is available
Andre: ok
Gunnar: regarding version string, it is possible to have OEM specific string at the end
TPAC
https://
https://
Ted encourages people to propose topics for breakout sessions
Ted: not necessarily during TPAC dates but we have a growing backlog we should perhaps try to address with something like two days worth of meetings (4h per day)
Ulf: that makes sense but let's start with building agenda to figure out how much time we need
Ted: ok, I'll start a wiki