Codel stores the minimum client data required to validate Documents, VRs, Audit Trails etc.
In all cases, we have four principal objectives.
First: we must store enough data to be able to prove our (your) case - in court if necessary.
Second: we must try to avoid storing data of significant value to an attacker.
Third: the integrity of what we store must be protected using our own Audit Trail Protection protocol
Fourth: we must do what we can to defend ourselves against attacks of all kinds.
what constitutes "enough" is context dependent.
To protect the copyright on a document, all we really need is its hash value. We create our own time-stamp.
On the other hand, if - when copyrighting a document - you also wish to log a claim in regard to the document (eg "this is the first documented description of how we can terraform Venus" or whatever), then you'll fill in the claim details (within the Codel Document Protection Software) and the hash of that claim will also be stored alongside the original hash.
Protecting Branded Goods again only "requires" the relevant hashes (of the VRs) but the database would be of little use to the supply chain if that's all it held. Hence, for reasons other than our primary authentication purpose, sundry non sensitive administrative details are also stored (eg type of product, consignment numbers, quantities, immediate destination etc)
Protecting a document for legal purposes is the most exacting role for the database. For this we can, optionally, store the hash of the document itself using our standard document validation procedure. But the legally required evidence is proof of the dates of sending and receipt and proof of the identity of sender and recipient. This is described in detail under our email validation protocol.
is a subjective judgement. What may seem of no significance to us might be enormously valuable to a particular attacker. All we can do is use common sense to weed out the obviously valuable data and then respond to events. If we find, for instance that attackers are showing interest in a particular class of data we've hitherto assumed to be be non-sensitive, we will take appropriate steps to remove the temptation.
The only awkward situations will arise when the client wants to include plaintext for administrative reasons. The most obvious example is the Brand Owner who will want shipping data on the system for the benefit of the supply chain. If a rival is sufficiently determined, they may well attack the system in order to extract details of shipments.
We will have to review such cases on an ad hoc basis. In some cases the Brand Owner or the supply chain will be able to live with reduced data. In other cases, we may need to set up a secure authenticated network just for a particular supply chain in order to continue providing the benefits of the data with minimum risk of data harvesting.
