Tim Churches wrote: > > OK, that sounds good. An alternative modus operandi for digital > notarisation is for the EHR to generate a self-signed digest for each > new version of a record, send that digest to a third-party notary, who > then counter-signs the digest and sends it back to the EHR, which then > stores the counter-signed disgest in the repository alongside the record > to which it applies. That means that the digital notary does not need to > store anything other than their complete history of private signing > key(s), and anyone can check the validity of the notary's > counter-signature by referencing the public signing key for that notary > for the date on which the record was counter-signed. The notary does not > have to be consulted or bothered for that validity check to occur. If > the counter-signature is valid, then the stored digest is valid, and if > a new digest calculated from that version of the record matches teh > stored digest, then it provides strong evidence that that version of the > record existed in that state at some time prior to the counter-signing > date. Because notaries don't need to remember anything other than their > signing keys, they can be very cheap to set up and operate, and can be > made very secure eg run a hardened Web server with minimal facilities > and no writable storage. But there needs to be somewhere in the openEHR > record to store the counter-signed digest. Or maybe more than one - it > is possible that several separate notaries could be used to provide > "triangulation" of their attestation functions. > Tim, this is a very nice model - I have not seen this exact variant before, but as you say, it would be cheap to run and require less in terms of cross-service requests to work. At the moment, you won't see any "digest" attribute in the class ORIGINAL_VERSION (which is one place you might expect to see it), because doing this complicates digest generation. Usually to generate a digest reliably from a set of objects, you have to convert them to a known serial form (e.g. some XML variant, or we might mandate dADL, which is more object-oriented, unambiguous, and half the size), and generate the digest from that. To do this conveniently, it is better if you can just serialise a network of objects starting from some root object. Now, if the object we want to logically generate the digest from is the ORIGINAL_VERSION object (= the data being stored plus the audit trail, any attestations, the version id, previous version id and Contribution id) then adding a digest to this same object means that you have to have some way of not including the digest attribute itself in the computation. While it is not that hard to model or implement, it is in my experience a guaranteed invitation for 50% programmers to get it wrong.
So we have left open the possibility that digests instead will be generated from the ORIGINAL_VERSION object, and stored in a table in the VERSIONED_OBJECT container object; for any given Version you can ask what the digest is. This digest can then be obtained for inclusion in the EHR Extract for each Version included. We have not yet put this change into the model, but I think it is probably the right one. - thomas
