Meeting minutes
Github issues
https://
Ulf: I submitted a PR which I would like to go over as well
https://
Ulf: related is https://
… there are cases when current value differs from target (set) value
… for updates you get confirmation the request is accepted but cannot guarantee how the underlying vehicle will handle it
… it is up to the client to check back for progress/completion of desired change
https://
Ulf: that is done by subsequent reads
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
… a sentence or two about possibilities without being exhaustive
Ulf and Gunnar agree
https://
Ulf: Wonsuk pointed out authorized read might not be clear enough, there is one example
… it can be applied to more cases than the one shown here
… 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
… a sentence saying other scenarios may exist would be enough
Ted: makes sense, we cannot predict every possible contingency like just discussed on PR
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
… token can be quite big, a couple kb even, and whether we should optimize with eg cookies
… I understand from Ted that there is a plot to do away with cookies
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
… if the client wants to re-request within a short time period it is possible
… if an attacker can sniff an entire token they can use it
Peter: shouldn't we encourage using subscription if you need regular reads of same signals?
Ulf: that is up to the client
… you may have more complex, custom logic than what subscription filters can deliver
MagnusG: subscription not supported by HTTP, only web sockets
Gunnar: saves bandwidth for asking for different signals as well
Ulf: depends on what a token is granted
Gunnar: it looks similar to cookie solution
Ted: 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
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
Ulf: reusing signature instead of creating a new nonce not worse, nonce in fact would be more complicated
… resending signature a pretty good idea
… server can still honor expiry time
… the signature is 40 bytes long
Ted: 40 bytes can be tried by brute force
Ulf: yeah but still a number of combitions
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
Gunnar: we can update VISS by then and rely on cookies for now
Carine: as Ted said, cookies are not standard HTTP
… cookies are not good, we could use other HTTP headers instead
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
Ulf: we could send the signature instead of the token
Ulf brings up spec showing Authorization:Bearer
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
… I'll link minutes and pose question to Isaac in issue
Gunnar: there may even be something easier available
Ulf: the signature SHA256 and then base64 encoded should be reasonable against brute attacks
… agree we should pull in Isaac
https://
Ulf: Sebastian noted we are not consistent in sending timestamps and agree we should
… 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
… best would be for responses to consistently send a timestamp
… agree we should add
… it will make things more uniform which is a generally good practice. any comments?
Gunnar and Ted: make sense
https://
Ulf: Sebastian noted we always return values as strings
https://
(JavaScript and JSON types are simpler and in JS degrade to string as in example, see link)
Ulf: there is certainly a convenience of treating things as strings
… I advocate keeping the string format but specify what valid data type transformations are, eg including a . in a float
Ted: JS and JSON are more primitive with their types
Ulf: you are only transporting data, you are not adding values together
Gunnar: this may pertain to VISS only, not other uses for VSS
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)