Authenticity Capture Prototype

1. Authenticity Capture Prototype Matt Dunckley, STFC

2. Why we need tools • Demonstrable Authenticity • Trustworthiness (Implies Quality) • Need to capture all information deemed necessary to make an informed judgement as to the authenticity • Provide a customisable and flexible mechanism to define what is the important PDI that needs capturing • Design is based on the Authenticity Model, which provides a standard process and framework

3. Authenticity Model • Framework to record pertinent information using standard terminology • Events – Capture information about an Event of importance • Protocols – Executed in response to an event occurring • Steps – Details information to capture for the event • AuthProtocolExecutionReport – Result of execution used by community member to make a judgement

4. Nature of the Tool • Keeping it simple to start with • GUI tool • Capture mainly textual information (Evidence) when events occur • Consistent and Standard user experience to perform capture • Where possible allow automated capture through plug-ins & external tools

5. User Roles – Use Cases • Project Creator/Administrator • Sets up an Authenticity project - providing detailed project information - reasons, objectives, ie. the business case • Imports the projects Authenticity model, an XML ‘protocol’ document based on Authenticity Model • Authenticity Information Capturer • Registers to Project • Edit/Add User Profile Information i.e credentials, details of their role, qualifications, affiliations, accreditations. • Creates and instance of a project, i.e for a particular digital object • Follows authenticity protocols / steps a procedure to capturing the specified information for each step • Sign off Capture as complete • Researcher/Consumer / All users • Can search for authenticity information by project • Can browse the holdings • Export Captured information in various formats

6. Digests • To verify the collected Authenticity information is trustworthy it is important to detect any forgery and if the information has been tampered • To allow this to be determined by a consumer we use the digest for digital signing the captured information • A cryptographic hash function is applied to the captured text information, returning a (cryptographic) hash value, such that an accidental or intentional change to the data will change the hash value. • To investigate if there has been some change, the hash value can be recalculated and compared the original. • A Hash value is also know simply a digest • The digest will also inform as to whether digital corruption has ocurred • The properties of a good digest should mean it would be • impracticable to find a message that has a given hash, • impracticable to modify a message without changing its hash, • impracticable to find two different messages with the same hash.

7. Digests • At each information capture point a digest of the information is recorded • At the point of sign-off a digest of all captured information is recorded • Example of information captured for Ionosonde station Location <capture capturer="us01" confidence="85" dateTime="09-09-2009 15:09:36" hashAlorithum="md5“ hashValue="7a1e512cef9cfd93af44832749200cc2“ pdiID="Ionosonde-01_step1_pdi2" pdiValue="BUDAPEST - HUNGARY Geographic Latitude (WGS-84) 47.00°N Geographic Longitude (WGS-84) 19.00°E Magnetic Latitude (IGRF-10(2005) 45.93°N Magnetic Longitude (IGRF-10(2005)) 101.33°E“ projectID="Ionosonde" stepID="Ionosonde-01_step1" timestamp="1252507896"/>

8. XML Protocol Document • Defined by XML Schema – Based on Authenticity Model

9. User Experience / Flow diagram

10. Case Study • Applied Auth Model - Ionosonde WDC, STFC • To allow us to design of the Auth Protocols • 1st Statement of policy (Authenticity Recommendation) by which we can measure if we have captured enough evidence “Record all PDI necessary to verify the authenticity and quality of received data files for long term archival within the WDC” • 2nd Identify Events • Ingestion of raw data files in varying formats • Transformation of received data files into IIWG format • Final validation and archival of IIWG file within WDC • 3rd Design Protocols and steps

11. Ingestion Protocol • Ingestion of raw data files in varying formats • Recommendation (Policy) “In order for this digital data to be accepted as Ionosonde data of sufficient quality the reliability of its source must be verified and recorded by a WDC accredited archivist” • Steps will capture • Source of dataset • Evidence that this is indeed the source • Archivist name and details • Ideally some form of credentials would be attached

12. Transformation Protocol • Transformation of received data files into IIWG format • Recommendation (Policy) “For the received data file to be deemed as sufficient quality to support data analysis it must have been successfully transformed into standard IIWG data format, the use of processing software must be recorded” • Steps will capture • Details of transformation used • Software details including name, version, source • Time/date of process • System details • Details of person responsible • Reason for believing this software is reliable • Details of Transformational Information Properties checked • Information Property descriptions • Values checked • Details of how checked • Details of who was responsible for the check

13. Archival Protocol • Final validation and archival of IIWG file within WDC • Recommendation (Criteria) “Successful validation of the IIWG structure and syntax must be achieved and recorded before long term archival can take place” • Steps will capture • Details of validation process • Details of checks performed • Details of person responsible • Details of transfer to storage • Details of person responsible • Checks performed on transfer e.g. Fixity checks • Details of archive and storage system • Date/time of transfer