Meeting minutes
MQTT
https://
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
… I've implemented this as well, back in February
… there was some pushback at having a protocol on top of MQTT and wanted to get some MQTT experts to provide more input
… I find value in having VISS over MQTT instead of using their more traditional route with eg broker
Gunnar: I think it is perfectly fine emphasizing same is being done with WS and HTTP
Isaac: this might affect the security model of MQTT
… with that protocol, the different points would be talking through the broker
… we use long term tokens and could allow them to be used across protocols
Ulf: good point, wonder if that would be better as a feature for next release
… or as Isaac describes, we can do our own end to end encryption using the long term access control mechanism
Gunnar: perhaps later version indeed and based on interest of participants. with WS and HTTP we require use of TLS
Erik: would it be worth identifying use cases where we are fine without encryption?
Ulf: agree with Isaac the weak point in MQTT is the broker but one can presume it is well secured in vehicle implementations
Isaac: we need to emphasize importance of being sure where MQTT broker is running, maybe give a few scenarios where it would be acceptible
https://
Ted: suggest longer portions, eg example architecture scenarios where it is safer would belong on BP
Ulf: so are people alright with me proceeding with this proposal?
Gunnar: including making clear the risk/concern?
… how broker could expose data for instance
Ulf: alright, I'll try to write this
Isaac: willing to help
Issues and PR
https://
Ulf: currently in the model we have role based system and a purpose model requiring a policy document
… the access token are not explicitly shown but purpose, scope is provided and policy document used to map to specific signals allowed
… there was some discussion about having signals in the access token itself
… a simpler auth flow the client has received a token out of bounds of the spec
… this Signal Access Control (SAC) token would include explicit signals and remove the role based part along with policy document
Isaac: I meant to contribute to the issue based on previous discussion but forgot
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
Isaac: we could perhaps keep the access token server
Ulf: if you could write that please
Isaac: noted
Ted: ideal would be transparent to client application which auth path is provided
Isaac: there may be a couple alternatives to discuss
https://
Ulf: question is whether we can have multiple purposes in the same token
https://
Isaac: it is difficult to handle multiple tokens within a client
Ulf: the access grant token contains the authorized roles. with that single token it is possible the handle multiple purposes for that specific role
… one scope claim is possible
Isaac: if requesting multiple signals across purposes would you be able to send multiple tokens?
Ulf: no
Ted: two ideas, customizable new roles for specific purposes
[ick]
… or SAC we were just talking about for alternate auth path of previous issue
Ulf: interesting
… SAC could handle tailored access
Isaac: it could make sense
Ulf: I'll provide a comment to this issue