IRC log of auto on 2021-10-12

Timestamps are in UTC.

17:55:27 [RRSAgent]
RRSAgent has joined #auto
17:55:27 [RRSAgent]
logging to https://www.w3.org/2021/10/12-auto-irc
17:55:28 [Zakim]
RRSAgent, make logs Public
17:55:29 [ted]
scribenick: ted
17:55:30 [Zakim]
Meeting: Automotive Working Group Teleconference
17:56:15 [ted]
Agenda: https://lists.w3.org/Archives/Public/public-automotive/2021Oct/0000.html
17:56:21 [ted]
Scribe: Ted
17:56:26 [ted]
Chair: Peter, Ted
18:00:14 [ted]
Present+ Andre, Ashish, Adnan, Ted
18:01:02 [ted]
Present+ Erik, Carine
18:01:23 [ted]
Present+ Ulf
18:01:34 [ted]
Present+ Peter
18:02:02 [ted]
Present- Andre
18:02:10 [ted]
Present+ Andre_Wendel
18:02:20 [ted]
present+ Manuel_Schiller
18:02:26 [ted]
Present+ Daniel
18:03:56 [ted]
Present+ Gunnar, Glenn
18:04:18 [ted]
Present+ MagnusG
18:10:26 [ted]
Topic: Introductions
18:10:36 [ted]
Topic: BMW PoC of VISSv2
18:11:45 [ted]
Manuel: before we start, there are some questions we have
18:12:27 [ted]
Ted: short ones fine here, otherwise preference to have on github and sometimes that prompts longer topics
18:13:57 [ted]
Present+ Isaac
18:15:52 [ted]
Manuel: we have a number of questions around access control, to use this protocol within the vehicle
18:16:48 [ted]
… one issue is we don't know the VIN at the outset which is needed for access control
18:17:11 [ted]
Ulf: the client first contacts the access grant token server which is meant to be run in the cloud
18:17:48 [ted]
… I guess out of band
18:18:33 [ted]
Manuel: isn't it possible to have the access grant server in vehicle?
18:18:56 [ted]
Ulf: general view has been it should be in the cloud but do not believe we made that mandatory
18:19:58 [ted]
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
18:20:19 [ted]
… it depends on what you need. you could run this without any cloud dependencies
18:20:36 [ted]
Manuel: we want to bring applications to vehicle in web browser context
18:21:06 [ted]
… the browser is running on the car and application calling VISS server needs to get access
18:21:52 [ted]
… 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
18:22:12 [ted]
Ulf: would having VIN optional facilitate?
18:22:32 [ted]
Manuel: there is a 1:1 relationship so that would help
18:23:15 [ted]
Adnan: for efficiency should we move this topic to GH?
18:23:37 [ted]
Ulf: yes and appreciate you are running into problems and we can work on the solution
18:24:15 [ted]
Erik: we have thought there may be use cases where authentication isn't needed
18:25:14 [ted]
Ulf: we are actually discussing a possible solution for how can we do authentication for your needs
18:26:36 [ted]
Isaac: would there be a way for owner to approve?
18:26:47 [ted]
Manuel: yes and we are taking approval fatigue into consideration
18:27:20 [ted]
Andre: I am working on a VISS implementation for our internal simulator, without having an actual car
18:27:50 [ted]
… for access token, I noticed there is one scope, the purpose and approved list of data points the client can access
18:28:01 [ted]
… could an application have multiple scopes?
18:28:13 [ted]
… would those need multiple tokens?
18:28:40 [ted]
Ulf: as it is written right now, you cannot have multiple scopes for a single token
18:28:56 [ted]
Isaac: is it a problem to handle multiple tokens in the client?
18:29:49 [ted]
Manuel: it could but maybe creating a specific scope for the need might be better
18:30:26 [ted]
… I would prefer a token with a defined scope
18:30:45 [ted]
Isaac: you could have a grant token with multiple scopes but the access token should be as narrow as possible
18:31:51 [ted]
Andre: so in my client application, I would need to manage multiple tokens. understand server implementation would be easier
18:32:04 [ted]
Isaac: yes understood but increases client overhead
18:32:12 [ted]
Andre: can we open an issue there as well?
18:32:19 [ted]
Ulf/Isaac: absolutely
18:33:04 [ted]
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?
18:33:30 [ted]
Ulf: we have not discussed that in any detail. my view is the ecosystem owner (OEM) that controls those policy lists
18:33:52 [ted]
… that is a list of services the OEM offers to third parties and fits well into a business model
18:34:00 [ted]
… it is up to OEM to define those lists
18:34:43 [ted]
… any potential client, even outside the vehicle, should be able to connect to OEM server to get those lists
18:35:12 [ted]
… we have intentionally not defined anything about OEM getting those lists to vehicles, outside the scope of our specs
18:36:05 [ted]
Andre: perhaps we can provide our experiences there
18:36:47 [ted]
Ulf: the idea behind scope list came from a requirement to assign different clients with different roles to have mutually excludable sets of data
18:41:21 [ted]
… you can look at the reference implementation @@link
18:42:07 [ted]
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
18:42:22 [ted]
Ulf: the VSS version is in VSS itself and should be available
18:42:33 [ted]
Gunnar: there is also service discovery
18:43:06 [ted]
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
18:43:48 [ted]
Andre: as a client application, I don't know anything about the car before connecting. so the first step is such a request?
18:44:07 [ted]
Ulf: yes, service discovery with root node is one way
18:44:23 [ted]
Gunnar: you can also ask for specific signals in service discovery?
18:44:33 [ted]
Ulf: no, everything below node you point to
18:44:57 [ted]
… if you have no knowledge of the tree at all, you have nothing to point to except the root (vehicle)
18:45:28 [ted]
[entire tree the client application has access to is what would be returned]
18:45:56 [ted]
Gunnar: either you know everything about the target vehicle for the application already or nothing and need to do discovery
18:46:29 [ted]
Andre: as the vehicle doesn't change, that is rather onerous
18:47:06 [ted]
Gunnar: you don't get data results, just what is available
18:47:15 [ted]
Andre: ok
18:51:12 [ted]
agenda+ TPAC
18:52:14 [ted]
Gunnar: regarding version string, it is possible to have OEM specific string at the end
18:52:18 [ted]
zakim, next agendum
18:52:18 [Zakim]
agendum 1 -- TPAC -- taken up [from ted]
18:53:39 [ted]
https://www.w3.org/2021/10/TPAC/
19:00:36 [ted]
https://www.w3.org/wiki/TPAC/2021/SessionIdeas
19:00:53 [ted]
Ted encourages people to propose topics for breakout sessions
19:02:02 [ted]
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)
19:02:25 [ted]
Ulf: that makes sense but let's start with building agenda to figure out how much time we need
19:02:33 [ted]
Ted: ok, I'll start a wiki
19:04:37 [ted]
s|@@link|https://github.com/MEAE-GOT/WAII|
19:04:38 [RRSAgent]
I have made the request to generate https://www.w3.org/2021/10/12-auto-minutes.html ted
19:09:41 [ted]
-> https://www.w3.org/auto/wg/wiki/Fall2021 Auto WG Fall meeting agenda
19:09:43 [RRSAgent]
I have made the request to generate https://www.w3.org/2021/10/12-auto-minutes.html ted