17:58:02 RRSAgent has joined #auto 17:58:02 logging to https://www.w3.org/2021/08/24-auto-irc 17:58:04 RRSAgent, make logs Public 17:58:05 Meeting: Automotive Working Group Teleconference 17:58:16 scribenick: ted 18:01:51 zakim, next agendum 18:01:51 I do not see any more non-closed or non-skipped agenda items, ted 18:01:59 zakim, take up agendum 3 18:01:59 agendum 3 -- Github issues -- taken up [from ted] 18:02:01 https://github.com/w3c/automotive/issues 18:02:07 Chair: Peter, Ted 18:03:18 Present+ Peter, Ted, Gunnar, Glenn, MagnusG, Ulf 18:05:14 Present+ Carine 18:05:44 Ulf: I submitted a PR which I would like to go over as well 18:07:07 https://github.com/w3c/automotive/pull/400 18:08:52 Ulf: related is https://github.com/GENIVI/vehicle_signal_specification/issues/327 18:09:58 … there are cases when current value differs from target (set) value 18:10:59 … for updates you get confirmation the request is accepted but cannot guarantee how the underlying vehicle will handle it 18:11:16 … it is up to the client to check back for progress/completion of desired change 18:11:17 https://github.com/UlfBj/automotive/commit/4a84f72b8aeaa0d6e1f316e74d8229597c471746 18:11:42 Ulf: that is done by subsequent reads 18:14:29 Ted: there may be a variety of factors why a target value will not be achieved, eg invalid value and vehicle provides a proper one or some other client or actuator influences it subsequently 18:14:55 … a sentence or two about possibilities without being exhaustive 18:15:05 Ulf and Gunnar agree 18:15:42 https://github.com/w3c/automotive/issues/399 18:16:00 Ulf: Wonsuk pointed out authorized read might not be clear enough, there is one example 18:16:09 … it can be applied to more cases than the one shown here 18:16:54 … he proposed to extend examples for all of them. my response was that would be tedious to read and most can generalize from a short number of examples 18:17:18 … a sentence saying other scenarios may exist would be enough 18:17:56 Ted: makes sense, we cannot predict every possible contingency like just discussed on PR 18:18:51 Ulf: exactly. this issue also led to another discussion point, Sebastian notes for authorized requests currently you must send the token every time unlike a subscription 18:19:36 … token can be quite big, a couple kb even, and whether we should optimize with eg cookies 18:20:01 … I understand from Ted that there is a plot to do away with cookies 18:21:19 Ulf: we could use some sort of unique nonce, shorter and easier. after a request with a token, if the client wants to request again then it could send only the signature part of the token instead of the full token 18:21:34 q+ to suggest we ask Isaac 18:22:17 … if the client wants to re-request within a short time period it is possible 18:23:10 … if an attacker can sniff an entire token they can use it 18:24:51 Peter: shouldn't we encourage using subscription if you need regular reads of same signals? 18:25:06 Ulf: that is up to the client 18:25:40 … you may have more complex, custom logic than what subscription filters can deliver 18:26:39 MagnusG: subscription not supported by HTTP, only web sockets 18:26:53 Gunnar: saves bandwidth for asking for different signals as well 18:27:15 Ulf: depends on what a token is granted 18:28:04 Gunnar: it looks similar to cookie solution 18:29:30 Ted: @@history of cookies 18:29:32 Ted: security and convenience is always a trade-off. this may be opening to replay attacks and not appropriate in some place esp writes. agree worth asking Isaac. we have a concept of token time out which would not need to be tracked by nonce in implementations. also wonder if Carine is following the current cookies debate or has other ideas on adding state/session in HTTP 18:31:41 Ulf: reusing signature instead of creating a new nonce not worse, nonce in fact would be more complicated 18:32:00 … resending signature a pretty good idea 18:32:18 … server can still honor expiry time 18:33:09 … the signature is 40 bytes long 18:33:41 Ted: 40 bytes can be tried by brute force 18:35:44 Ulf: yeah but still a number of combitions 18:38:49 Carine: there is an ongoing discussion to replace cookies with http state token but it will need to be incremental to not break the web, it will take years 18:39:08 Gunnar: we can update VISS by then and rely on cookies for now 18:39:18 Carine: as Ted said, cookies are not standard HTTP 18:39:56 … cookies are not good, we could use other HTTP headers instead 18:41:18 Ted: that was going to be my next question, which existing header would be best. we could do X-one but that is not preferred 18:41:34 Ulf: we could send the signature instead of the token 18:46:09 Ulf brings up spec showing Authorization:Bearer 18:46:47 Ted: that is defined by Oauth2 and may complicate things, suggest we table and get input. might be an alternative in Oauth2 we can use 18:47:01 … I'll link minutes and pose question to Isaac in issue 18:47:30 Gunnar: there may even be something easier available 18:47:59 Ulf: the signature SHA should be reasonable against brute attacks 18:48:52 s/SHA/SHA256/ 18:49:11 s/SHA256/SHA256 and then base64 encoded/ 18:49:26 … agree we should pull in Isaac 18:49:53 https://github.com/w3c/automotive/issues/387 18:50:12 Ulf: Sebastian noted we are not consistent in sending timestamps and agree we should 18:51:31 … getSuccess returns data point and timestamp but setSuccess just sends a 200 OK and HTTP header timestamp so figured we don't need another here 18:51:44 … best would be for responses to consistently send a timestamp 18:52:52 … agree we should add 18:52:54 I have made the request to generate https://www.w3.org/2021/08/24-auto-minutes.html ted 18:53:35 … it will make things more uniform which is a generally good practice. any comments? 18:53:54 Gunnar and Ted: make sense 18:54:48 https://github.com/w3c/automotive/issues/386 18:55:06 Ulf: Sebastian noted we always return values as strings 18:56:46 https://www.w3schools.com/js/js_datatypes.asp 18:57:22 (JavaScript and JSON types are simpler and in JS degrade to string as in example, see link) 18:57:56 Ulf: there is certainly a convenience of treating things as strings 18:59:16 … I advocate keeping the string format but specify what valid data type transformations are, eg including a . in a float 19:00:50 Ted: JS and JSON are more primitive with their types 19:01:18 Ulf: you are only transporting data, you are not adding values together 19:03:00 Gunnar: this may pertain to VISS only, not other uses for VSS 19:07:12 Ted: given how JS/JSON treat types I think it is fine to stay string. data validation when bringing to data server should take place (and a bug that munges type in client is still a bug) 19:07:13 I have made the request to generate https://www.w3.org/2021/08/24-auto-minutes.html ted 19:08:16 s/@@history of cookies/actually cookies are not part of HTTP, they and nonce in querystring were a workaround that became a common convention to add session state to a stateless protocol/ 19:08:18 fm 19:08:26 s/fm// 19:08:27 I have made the request to generate https://www.w3.org/2021/08/24-auto-minutes.html ted 22:15:53 Zakim has left #auto