Information Technology Reference
In-Depth Information
Fig. 13.5 Authenticity
protocol history
documentedBy
AuthProtocolHistory
AuthProtocol
workF l ow
AuthStep
step, must be revised and possibly a new execution required for the new (modified)
step. In this case also, the old and the new ASEs must be retained.
Authenticity should be monitored continuously so that any time a resource is
somehow changed or a relationship is modifies, an Authenticity Protocol can be
activated and executed in order to verify the permanence of the resource's relevant
features that guarantee its authenticity. Any event impacting on a resource should
trigger the execution of an appropriate protocol. For this reason the Authenticity
Protocol Execution is triggered by an Event Occurrence, i.e., the instantiation of
an Event Type that identifies any act and/or fact related to a specific Authenticity
Protocol.
The authenticity of a resource is strongly related to the criteria and procedures
adopted to analyse and evaluate it: the evolution of the Authenticity Protocols over
time should be documented - via the Documented By relation - in an Authenticity
Protocol History (Fig. 13.5 ).
13.3.5 Preservation of Evidence
The evidence which is collected itself must be preserved, and evidence for its own
authenticity must be collected. We will look at the use of digests of the evidence
about a digital object as used by one possible tool, but in trying to use that evidence
when making a judgement of the authenticity of that object, all of the considerations
of preservation apply. In particular, transformation and/or virtualisation of the evi-
dence are likely to be needed, for example when combining the evidence made over
a considerable period of time using a variety of tools and techniques. This is another
very clear example of the recursion which was discussed in Sect. 3.3 .
13.4 Overall Authenticity Model
Putting all these ideas together the overall model is shown in Fig. 13.6 .
 
Search WWH ::




Custom Search