Meeting minutes
Discovery
Ted provides background, summary of conversation with Peter
Gunnar: HTTP can handle multiple auth methods
Isaac: HTTP can do base and digest auth or provide a challenge
Gunnar: there is a longer list of auth methods than HTTP supports
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
https://
Ulf: we should have certain parts optional, next step is deciding what can be optional and then how a client can query on capabilities
… my proposal is to use 'static-metadata' in ch7.4 of core
Ulf: server capability keyword could contain that information. request needs a path so maybe best would be to use the root node
… question then is what the response should contain?
… we could tag optional features in spec and provide those
Peter: there is no way we can handle this with error messages?
Ulf: yes but client trying and failing multiple requests is tedious
Peter: having tag mechanism seems a bit complicated
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
Peter: I understand, just thinking it through
… it could work, any other comments?
Ted: key issue is what the response should be imho
Peter: so capabilities request itself would be mandatory
Ulf: yes, it would have to be
… and this particular mechanism is already required so we would be overloading it modestly
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?
… what is going to prevent people from treating other features as optional?
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
Gunnar: if you want to introduce optional features, it needs to be clear in the specification (must, should etc)
… you need to name every optional feature so they can be communicated
MagnusG: agree
Ulf: should we give this some more time or go ahead and add to spec?
Peter: should wait so Bosch guys can respond
Gunnar: I'm wondering about an un-authenticated interface provide any capabilities about the server
Ulf: agree with that concern
Isaac: in TLS 1.2 handshake, you send capabilities in the clear. in 1.3 they want that encrypted as well
… any information provided to an attacker is useful not that I can think of how this can be misused offhand
Ted: maybe mistake to try to provide client different auth methods this way but use for other optional features
Ulf: access control I agree is more complicated. Bosch guys are doing auth more simply nor using role based access control
… maybe we can handle different auth scenarios more transparently to client or access grant is done once and not revokable
… that would make access grant server itself optional, token would not expire
… for the role based part, you could have a superuser role that allows client to do whatever
… sent that to Isaac earlier today
Isaac: agree you can adapt a simpler scenario based on trust requirements
Ted: that could work for access grant but Bosch must still be doing some granular access on signals
Ulf: yes but not role based
Ted: 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
Geofencing
Ulf encourages Ted to share details on Spatial Data on the Web
Ted: SDW folks meeting on Thursday and shared they have geofencing on their agenda, topic we asked them about
… we want a simple convention or standard for representing these fences, know at least BMW and Geotab are doing so in practice
… I'll share details for call @13GMT/15CEST to member-automotive@w3.org
… actually see they have call details public https://