18:02:20 RRSAgent has joined #auto 18:02:20 logging to https://www.w3.org/2021/05/25-auto-irc 18:02:22 RRSAgent, make logs Public 18:02:23 Meeting: Automotive Working Group Teleconference 18:06:53 Topic: Discovery 18:07:08 Ted provides background, summary of conversation with Peter 18:07:28 Gunnar: HTTP can handle multiple auth methods 18:08:05 Isaac: HTTP can do base and digest auth or provide a challenge 18:08:44 Gunnar: there is a longer list of auth methods than HTTP supports 18:08:59 scribenick: tguild 18:09:30 Present+ Carine, Ted, Peter, Gunnar, Isaac, MagnusG, Ulf 18:10:19 Present+ Arman 18:11:16 Ulf: not sure you've checked into issue where this is discussed as I proposed a solution for how a client can request the capabilities 18:12:47 https://github.com/w3c/automotive/issues/385 18:13:23 Ulf: we should have certain parts optional, next step is deciding what can be optional and then how a client can query on capabilities 18:13:43 ...my proposal is to use 'static-metadata' in ch7.4 of core 18:14:05 https://rawcdn.githack.com/w3c/automotive/3b84ac8b41586c1dbfc83aed5ca956a77a9f1445/spec/VISSv2_Core.html#metadata-request 18:14:58 Ulf: server capability keyword could contain that information. request needs a path so maybe best would be to use the root node 18:15:17 ...question then is what the response should contain? 18:15:50 ...we could tag optional features in spec and provide those 18:16:39 Peter: there is no way we can handle this with error messages? 18:16:52 Ulf: yes but client trying and failing multiple requests is tedious 18:17:22 Peter: having tag mechanism seems a bit complicated 18:18:09 Ulf: if for filtering we have curve logging optional for example, and we have xyz tag for it then response would not include xyz if it doesn't support it 18:18:18 Peter: I understand, just thinking it through 18:18:44 ...it could work, any other comments? 18:23:31 Ted: key issue is what the response should be imho 18:23:46 Peter: so capabilities request itself would be mandatory 18:23:54 Ulf: yes, it would have to be 18:24:41 ...and this particular mechanism is already required so we would be overloading it modestly 18:25:30 Gunnar: key question for me is are some features not needed by you and therefore even if deemed mandatory by spec you won't implement? 18:26:18 ...what is going to prevent people from treating other features as optional? 18:28:34 Ted: feasible people will create additional subscription filters besides what we define, what matters is client and server can communicate and choose what is understood and preferred 18:29:18 Gunnar: if you want to introduce optional features, it needs to be clear in the specification (must, should etc) 18:29:45 ... you need to name every optional feature so they can be communicated 18:31:13 MagnusG: agree 18:31:38 Ulf: should we give this some more time or go ahead and add to spec? 18:31:49 Peter: should wait so Bosch guys can respond 18:32:32 Gunnar: I'm wondering about an un-authenticated interface provide any capabilities about the server 18:32:38 Ulf: agree with that concern 18:33:53 Isaac: in TLS 1.2 handshake, you send capabilities in the clear. in 1.3 they want that encrypted as well 18:34:23 ...any information provided to an attacker is useful not that I can think of how this can be misused offhand 18:38:15 Ted: maybe mistake to try to provide client different auth methods this way but use for other optional features 18:39:03 Ulf: access control I agree is more complicated. Bosch guys are doing auth more simply nor using role based access control 18:40:30 ...maybe we can handle different auth scenarios more transparently to client or access grant is done once and not revokable 18:40:50 ...that would make access grant server itself optional, token would not expire 18:41:54 ...for the role based part, you could have a superuser role that allows client to do whatever 18:42:53 ...sent that to Isaac earlier today 18:43:15 Isaac: agree you can adapt a simpler scenario based on trust requirements 18:45:04 Ted: that could work for access grant but Bosch must still be doing some granular access on signals 18:45:09 Ulf: yes but not role based 18:53:11 Ted: @@mixed-both 18:59:37 Topic: Geofencing 19:00:37 Ulf encourages Ted to share details on Spatial Data on the Web 19:01:22 Ted: SDW folks meeting on Thursday and shared they have geofencing on their agenda, topic we asked them about 19:01:55 ... we want a simple convention or standard for representing these fences, know at least BMW and Geotab are doing so in practice 19:02:26 ...I'll share details for call @13GMT/15CEST to member-automotive@w3.org 19:03:15 ...actually see they have call details public https://lists.w3.org/Archives/Public/public-sdwig/2021May/0032.html 19:04:48 s/@@mixed-both/actually I could see some applications, such as from the OEM themselves, be trusted and not need access grant server but have persistent token whereas other applications due to privacy, business or other considerations be enabled or barred per trip and that can be handled out of band of our spec by access grant server/ 19:04:55 rrsagent, draft minutes 19:04:55 I have made the request to generate https://www.w3.org/2021/05/25-auto-minutes.html tguild