Improve efficiency, multi-implementation support, and future proofing

[jwrosewell]

Optimises the none RTB data model to reduce the number of bytes needed when performing crypto graphic operations thus improving overall performance and efficiency of the solution. Additional changes address future proofing issues or multi-implementation complexity with the current design.

The changes here fully address issues #264, #194, #193, #184, #179.

These changes relate to #139.

The changes to reduce the bytes needed for signing are:

• Version is a single byte not a string or double. One byte rather than minimum of four bytes.
• Identifier’s ID type is an enum of “rid” or “sid”. These now require four bytes.
• Require base 64 representations of byte arrays to be converted to byte arrays before being used in data for signing. The length of the byte array is written as a 4 byte unsigned integer, followed by the array of bytes. Therefore a 64 byte UUID will consume 68 bytes.
• Removed the Unicode separator used to concatenate data for signing saving two bytes.
• The source domain as a null terminated string saving one byte.
• The source timestamp is a four byte unsigned integer representing the number of minutes since the epoch of 1/1/2020 are used for the source data when signing. See comments add to the timestamp entity for the reasons for storing the timestamp in minutes and not seconds. This saves four bytes.
• Remove the relationship between the identifier and the preference data entities. They are signed and changed independently of one another.

Other changes are:

• Source includes a version field to support changes to the cryptographic algorithm.
• Identifier and preferences both contain a persisted field.
• Added the RID, SID (Signed in Identifier not currently used in the MVP), and preferences to the Seed. This ensures the seed contains all the necessary information to support the transmission requests and responses in a single location reducing complexity.
• Removed the type field from the identity response as we do not need to know the role of the signer in the eco-system, and in any case some signers will have multiple roles.
• Removed the “end” timestamp from the identity response public key as this is not relevant.
• Changed the name of the timestamp in the identity response public key to “created” as this is the information that is needed.
• Changed the “type” field name to “id_type” to avoid name space conflicts in languages where “type” is a reserved word.
• Add the type terms-url together with the rules associated with the HTML response provided including the addition of a element to make the response machine readable and to learn the version of the Model Terms being used by the signer.

Considerations:

• This PR does not resulting in an operational project as the changes are breaking changes. Once reviewed the dependent code will need to be refactored by the mantainers. This includes the simple task of renaming or removing fields (created not start), using new value types (byte instead of string), and then modifying the signing definitions logic to use byte arrays rather than strings.
• This commit/pull request does not yet apply the same direction of efficiency improvements to the transmission OpenRTB data entities. The reviewer’s opinion on these changes is sought before a further modification is submitted.

A concrete implementation of these changes can be found on the SWAN go repository - https://github.com/SWAN-community/swan-go/tree/feature/ok-refact which is currently being refactored to support a hybrid addressability framework that would include these efficiency and future proofing improvements ahead of live deployments.

[jwrosewell]

@OlivierChirouze @RomainLofaso @broggeri @BasileLeparmentier - I see other PRs are being approved which over time will impact this one and make integration harder. Is there any chance of initial review this week?

[jwrosewell]

@OlivierChirouze @broggeri @RomainLofaso @BasileLeparmentier To update you on progress we have now made the entities needed to support this direction available on the SWAN-Community organization. We'd like to progress this PR here to ensure efficiency, performance, and consistency of approach across multiple implementations.

I believe the classes will fit neatly into the OneKey implementation should others wish to use them. Specifically, the tight coupling of the signing and verification logic, and the different entities. The approach also aligns very well to other programming languages include Go, C#, and Java.

These classes are the basis of the code used in https://preference.express which is progressing to trials.

Adding @bwschmidt in case there is additional interest in reviewing/commenting.