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