check values should be signatures

[BenGardiner]

As suggested by Jeremy Daily in review of the conceptual draft, the check values should be signatures and not just checksums

[BenGardiner]

I agree with Jeremy, these should be signatures and not just checksums. Getting this going will require

1. specifying a server secret, a signing algorithm (or negotiation) in the spec and requiring clients enforce validation checks
2. on servers: creating a 'canonical' JSON payload, signing it and including the signature instead of the checksums
3. 'reverse' of 2. in the clients.

As it turns out, getting a canonical form is non-trivial. See all the problems with JWT implementations as an an example: https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid (and the notes and references in #4).

We shouldn't require things like in JWT lest we end up with implementations like it too. I think the same solution to JWT problems would apply here; we could use PASETO to sign the JSON payloads. paragonie/paseto#90

However, for now (in v1); we already have transport level security that includes integrity protections and we are furthermore requiring that all Open Telematics API clients perform certificate pinning.

More layers of defense would be better, yes. But for the time being I think the thing to do is delete the checks fields and add in some real signing of objects in later versions. I opened issue #32 to delete checks fields and I'll schedule this for 'Later'.