Meeting minutes
MQTT PR continued
Ulf: the major change is scrapping VIN for an arbitrary identifier
… I changed the wording to vehicle identity
Ted suggests clarification that this is not necessarily VIN
Gunnar: there are cases where broker might be in-vehicle
Erik/Ulf think it is covered
Erik: diagram image rendering is different for changed terms
… font or clarity
Ulf: I did it in a pixel editor on the original diagram
[discussion on image edit and format]
https://
Ted to propose wording for his suggestion
Issues
https://
https://
Ulf: I proposed we have Signal Access Claim in the token as alternative to Role Based Access Control
… nothing more is said about how the topic is obtained, it is out of scope and left to the implementer
… this meets what has been asked for from Bosch side, less complex authentication
… Isaac came up with an idea to do essentially the same thing but more in-line with the existing mechanism
… I find it a fully valid proposal but found one issue. the main reason for introducing this new "flow" was to make an implementation that excludes policy document but also the authorization server
… this proposal goes beyond that. Sebastian took a look and prefers the earlier proposal that has the lower complexity
… Isaac commented further about HTTP API security
https://
Ulf: how do we handle discoverability?
Ted: we discussed before (and punted iirc?) leveraging something like uPNP for discovey or similar to VID or SAC token, outside the scope and handled by configuration
Carine: we could settle on port numbers
Magnus: this is deployment specific and could be out of scope
Carine: it could be part of a manifest file, a way to discover in all vehicles. is it using default port or something else
… we could narrow the scope. it would be better to specify what is deployed
Erik: is it clear there would only be one access grant server or could there be multiple?
Ulf: there is one within an ecosystem
Erik: another issue is information about what VSS version is being used. if you just know the name of the VISS server, you can get the additional information from it
… VISS server can provide that
Ulf: I don't think we should specify how a client obtains address for the VISS server, it is up to the OEM
https://
Ted: when we discussed for v1, it was a problem for other W3C groups as well. the static local network hostname was not preferred and I can look to see if the cross group discussion reached a conclusion
Ulf: let's leave this open then
https://
Ulf: access token server could sign with its private key and provision clients with public key
… if you don't have a VIN the token could possibly go to any vehicle as valid
Ulf: we can have it as optional
… I'll generate a PR for Erik's idea, having it in the token
Erik: sounds good to me
https://
Ulf: VIN parameter should be optional here too
[Isaac joins]
[return to issue 382, Ulf recaps conversation]
Ulf: anyone who implements an access control model will ensure they meet their security criteria
Erik: would we remove or deprecate any of the flows?
Ulf: no, which is used up to implementer and they could use both
… ideal is to have interoperability from client perspective
Isaac: my understanding was to try to find a middle ground and align with what people are likely to do
… if people want to skip access grant server, ok we can simplify the flows
… my proposal was a small simplification to the proposed flow to align better with the earlier solution
Ulf: understand and appreciate that
… Bosch wanted something simpler and asked Sebastian to describe better what they want
… my understanding is that it isn't rigidly defined but want it flexible
… token is then the lowest common denominator
Isaac: how the token is protected can be with HMAC
Ulf: I can bring forward a PR and have a final discussion on the details