You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During the TPAC sensor session [1], the question of making sure that the sensor API allows to transfer some sensor's data which are protected from reading. The use case is : a sensor is protecting itself from reading its measures (aka, only communicating ciphered data), and transfer its data to a server which will have means to read the ciphered data. In that case, the web app handling the data may have some interest to know that sensor's data van not be interpreted without special treatment.
The API should allow to tag this kind of protected data, to avoid wrong data interpretation.
So as discussed F2F, the current design allows for this. For example, you could add a boolean encrypted member to the constructor's dictionary or pass the recipient's public key via the same mean. The sensor would then emit OpaqueSensorReading objects instead of regular ones, and the recipient only would be able to decrypt the data, the application then simply becoming a pipe for it.
Now, I don't know what interest there is for something like this at this point, so it seems very early to bake it into this spec. Have you heard from implementors interested in enabling this use case?
During the TPAC sensor session [1], the question of making sure that the sensor API allows to transfer some sensor's data which are protected from reading. The use case is : a sensor is protecting itself from reading its measures (aka, only communicating ciphered data), and transfer its data to a server which will have means to read the ciphered data. In that case, the web app handling the data may have some interest to know that sensor's data van not be interpreted without special treatment.
The API should allow to tag this kind of protected data, to avoid wrong data interpretation.
[1] http://www.w3.org/2015/10/28-dap-minutes.html
The text was updated successfully, but these errors were encountered: