Desde la acción colectiva

Identity meta-data must provide the most accurate information possible. It should ensure not only data quality but also data integrity and authenticity. Data quality can be maintained with well-designed XML ontologies applied at different identity metadata contexts. Data integrity gives assurance that data has not been amended since the last valid data change was committed. Authenticity ensures that the subject identified as the last data processor initiated the data transaction. Because changes made over the identity metadata are not accountable at the identity metadata level, they require dedicated functionality responsible for accounting. Identity metadata itself needs to deliver a basic integrity and an authenticity assurance. This assurance could be guaranteed with a digital signature applied to the part of the information that requires data integrity. As the digital signature could be derived not only from the information but could be bound with a unique identifier, it is used for information, which requires data authenticity [94].

As an example, in medical report authenticity of information is crucial to verify that diagnoses made have not been amended by the illegitimate party. When a patient’s personal record was updated by some medical personnel, and afterwards the same information was changed either by a patient or another healthcare staff member, this later change has to be uniquely distinguished from all previously made changes. For identity metadata, we need to ensure that a malicious or ignorant subject did not amend the information, that information was changed in the current identity context, and an entitled subject processed that information.

The access control models we described here use signing for non-repudiation and integrity enforcement; however, identity meta-data requires the same enforcement at the level of actual data. For instance, using an emergency access example, where a medical professional need to access a patient’s data to check their medical history if an unauthorised subject (including the data owner) amended medical history, it may have critical consequences leading to patient’s death.

Digital signing cryptography requires secure keys to derive a signature. Public-key infrastructure (PKI) and ID-based signing (IBS) are two different approaches we can use to deliver keys [95]. While PKI involves trusted certification authorities (CAs) to certify public keys and bind them with a digital identity, in IBS the public key consists of an identity unique identifier. Therefore, it simplifies the implementation model by

eliminating CA entity from key management lifecycle However, it introduces other required by IBS system entities.

To keep the identity metadata model as homogeneous as possible and therefore potential framework simple, we will focus on IBS as a preferred digital signing technique. IBS and IBE share the same concept for secure key management. IBS, unlike PKI, can use certificates issued by an involved trusted authority (TA) based on identity identifier and the assigned public key. IBS certificate does not require a CA, as it is a simple digital signature derived from a public key and a unique identity identifier [95]. As an alternative to certificates, IBS can utilise the hierarchical ID-based encryption (HIBE) discussed above as a preferred identity metadata encryption method. Hierarchical IBS (HIBS) schemas become very useful when combined with HIBE [96] as HIBE schema derived from content encryption can be transformed into HIBS schema. The digital signing and verification processes are therefore simplified.

2.7.1 XACML Accountability and Auditing

Furthermore, not only data, i.e. OOXML, but also access policy may require accountability allowing incident identification showing when, how and by whom the initial data owner access rights were tampered or simply legitimately changed. XACML policy could be signed. However, it does not guarantee non-repudiation and does not provide any historical information [97]. Same functionality used for OOXML could be leveraged for XACML policy as XACML data incorporated as a part of the OOXML package inherits security safeguards from its wrapper.

2.7.2 Merkle Trees applications

Various applications are leveraging Merkle trees construct designed to ensure distributed data or database integrity like in [98]. Blockchain and git repositories, the most popular, have the required functionality available already as a cloud-based service. For secure construct, the consistent OOXML data versioning requires a single globally available chain of all the changes. Document changes have to be consistent and relate only to one previous version. Users should not be able to commit the same version updates with two different contents simultaneously. Merkle Trees could ensure that and allow quick and efficient verification of data and its version in large data structures. Simple hashing, a cryptographic primitive leveraged by Merkle trees ensures the integrity of the current and the preceding tree leaf.

2.7.2.1 Data Versioning with Blockchain

Blockchain maintains one central chain of all the transactions. The single chain usually consists of the latest blockchain hash. XACML policy instance and OOXML package versions could be located on a centralised blockchain what guarantees document integrity. Data editor who wishes to commit a new version has to ensure that the version committed is a direct ascendant from the latest committed version. In the case where new version from a different version ancestor has to be committed to the chain, a new transaction for version cancelation has to be added to the blockchain by the authorised actor. Classical blockchain implementation maintains basic transaction metadata unlike Git repositories, where the entire data history is stored. Excluding the consensus available in blockchain, these are both very similar.

2.7.2.2 Changes History via Git Repository

In Git everyone may have several branches ascendant from the same data. Consequently, everyone could commit the latest version into a chain by resolving conflicts with the latest committed version. Unlike blockchain, in Git the content matters regardless of the branch while in blockchain the final consensus matters regardless of the content. Entire OOXML package and XACML policy history can be stored and hosted simultaneously using single Git repository. Package data could be either stored in unencrypted format, what has many functional features compared to a single branch consisting only encrypted versions.