18:03:46 RRSAgent has joined #auto 18:03:46 logging to https://www.w3.org/2021/10/19-auto-irc 18:03:48 RRSAgent, make logs Public 18:03:49 Meeting: Automotive Working Group Teleconference 18:04:01 agenda+ MQTT 18:04:50 agenda+ MQTT 18:04:57 agenda+ Issues and PR 18:05:39 zakim, next agendum 18:05:39 agendum 1 -- MQTT -- taken up [from ted] 18:05:40 https://github.com/w3c/automotive/issues/369 18:06:37 Ulf: proposal I made earlier wasn't regular MQTT interface but an alternative that exposes the functionality of CORE spec over MQTT similar to how you can interact over WSS and HTTPS 18:07:47 … I've implemented this as well, back in February 18:08:30 … there was some pushback at having a protocol on top of MQTT and wanted to get some MQTT experts to provide more input 18:10:07 … I find value in having VISS over MQTT instead of using their more traditional route with eg broker 18:10:32 Gunnar: I think it is perfectly fine emphasizing same is being done with WS and HTTP 18:11:37 Present+ Isaac, Ulf, Peter, Gunnar, Ashish, Erik, MagnusG, Adnan 18:11:51 Isaac: this might affect the security model of MQTT 18:12:22 … with that protocol, the different points would be talking through the broker 18:14:52 … we use long term tokens and could allow them to be used across protocols 18:15:39 Ulf: good point, wonder if that would be better as a feature for next release 18:16:09 … or as Isaac describes, we can do our own end to end encryption using the long term access control mechanism 18:17:10 Gunnar: perhaps later version indeed and based on interest of participants. with WS and HTTP we require use of TLS 18:18:05 Erik: would it be worth identifying use cases where we are fine without encryption? 18:19:03 Ulf: agree with Isaac the weak point in MQTT is the broker but one can presume it is well secured in vehicle implementations 18:19:43 Isaac: we need to emphasize importance of being sure where MQTT broker is running, maybe give a few scenarios where it would be acceptible 18:21:14 https://www.w3.org/community/autowebplatform/wiki/Best_Practices 18:21:38 Ted: suggest longer portions, eg example architecture scenarios where it is safer would belong on BP 18:22:01 Ulf: so are people alright with me proceeding with this proposal? 18:24:00 Gunnar: including making clear the risk/concern? 18:24:15 … how broker could expose data for instance 18:24:25 Ulf: alright, I'll try to write this 18:24:31 Isaac: willing to help 18:26:27 zakim, next agendum 18:26:27 agendum 2 -- Issues and PR -- taken up [from ted] 18:26:28 https://github.com/w3c/automotive/issues/382 18:26:53 Ulf: currently in the model we have role based system and a purpose model requiring a policy document 18:27:37 … the access token are not explicitly shown but purpose, scope is provided and policy document used to map to specific signals allowed 18:28:02 … there was some discussion about having signals in the access token itself 18:29:53 … a simpler auth flow the client has received a token out of bounds of the spec 18:31:27 … this Signal Access Control (SAC) token would include explicit signals and remove the role based part along with policy document 18:32:28 Isaac: I meant to contribute to the issue based on previous discussion but forgot 18:34:52 Ulf: Erik, I encourage you to take a look at this proposal since we did so responding to desire to make an alternative path per Sebastian's request 18:37:24 Isaac: we could perhaps keep the access token server 18:38:45 Ulf: if you could write that please 18:38:49 Isaac: noted 18:40:14 Ted: ideal would be transparent to client application which path is provided 18:40:19 s/path/auth path/ 18:41:15 Isaac: there may be a couple alternatives to discuss 18:44:08 https://github.com/w3c/automotive/issues/422 18:44:42 Ulf: question is whether we can have multiple purposes in the same token 18:45:07 https://www.w3.org/2021/10/12-auto-minutes.html#t02 18:45:39 Isaac: it is difficult to handle multiple tokens within a client 18:46:42 Ulf: the access grant token contains the authorized roles. with that single token it is possible the handle multiple purposes for that specific role 18:48:49 … one scope claim is possible 18:49:45 Isaac: if requesting multiple signals across purposes would you be able to send multiple tokens? 18:50:16 Ulf: no 18:52:09 Ted: two ideas, customizable new roles for specific purposes 18:52:13 [ick] 18:52:33 … or SAC we were just talking about for alternate auth path of previous issue 18:52:38 Ulf: interesting 18:55:02 … SAC could handle tailored access 18:56:32 Isaac: it could make sense 18:56:52 I have made the request to generate https://www.w3.org/2021/10/19-auto-minutes.html ted 18:58:21 Ulf: I'll provide a comment to this issue 18:58:30 I have made the request to generate https://www.w3.org/2021/10/19-auto-minutes.html ted 18:58:50 Scribe: Ted 18:59:00 Chair: Peter, Ted 18:59:03 I have made the request to generate https://www.w3.org/2021/10/19-auto-minutes.html ted