Core Concepts
DataTrails Core Concepts
Tenancies
A Tenancy is an Organization’s private area within DataTrails, containing Event data that build over time to create Audit Trails. The user who created the Tenancy is by default the Administrator and has full control over everything in that Tenancy. An Administrator can also create granular Access Policies which allow Event metadata from their Tenancy to be shared to other Tenancies; for example, Organization A would share supply chain data from their Tenancy to Organization B’s Tenancy.
Administrators may invite other users into their Tenancy. The invited user will start off with no permissions and can then be given specific access rights (including being upgraded to an Administrator) by any existing Administrator in that Tenancy. For more details on this, see Identity and Access Management
Events
The fundamental purpose of DataTrails, like any transparency service, is to record and prove the origins and authenticity of the data that fuels the modern enterprise. This is achieved through the registration of immutable Events on the platform.
Events are attestations: individual pieces of evidence recorded as observations or claims about a thing from qualified witnesses. Each Event Record contributes to the ‘Golden Thread’ of the Audit Trail by building a rich picture of history.
Events can never be deleted or modified by anyone, not even administrators of the DataTrails platform. Once asserted, they cannot be shredded, tampered, or backdated.
Assets
Note: Assets will soon be deprecated for a more flexible and powerful concept of Trails.
The change is subtle, but where Assets only allow Events to be registered against a single thing or theme, Trails will enable Events to be free of any such restriction leading to more natural expression of what happened when or who said what about what.
To prepare for this change, when writing code integrations be sure to focus on Event attributes and not mutable
asset_attributes. This will ensure best performance and minimal code changes to take advantage of the newer API.
Asset Records represents a thing: this could be a file; a physical object; a smart device; or even a business process. Simply an Asset is just the subject that the Events are talking about.
A DataTrails Asset acts as a container for Events which share a topic or have a similar relationship. when combined with a complete history of Events that brought it to that state, we have an immutable Audit Trail. DataTrails Asset attributes track anything deemed important. For example, a Document Asset will trace the evolution of authors, versions and release dates. Modeling a Shipping Container as an Asset might have a handling history of movements through ports. Or the Asset could be something more abstract like all Events from a given day.
These are examples of completely different things that can have a Data Trails Audit Trail.
Each Asset has a fixed identity across all stakeholders, ensuring that all relevant parties are collaborating on the same object and see the same history of the Asset at any given time when shared through Access Policies.
Proving Provenance
Artifacts and Events are core to the DataTrails platform, and being able to quickly demonstrate proof that these artifacts have not been tampered is key to knowing the information is secure and trustworthy.
DataTrails attestations are committed to immutable storage that is underpinned by cryptographically verifiable Merkle Mountain Range data structures for long term verifiability, even when offline.
Four Increasing Trust Levels
At DataTrails we believe in holding ourselves to the same levels of accountability as our customers, and the Merkle Log proof mechanism provides the robustness, integrity and availability guarantees needed to ensure data authenticity in any digital or data supply chain. And you don’t have to just take our word for it: you can check.
Here’s how it works:
Without an Immutable Audit Trail, there is always the risk - or at least the suspicion - that data can be shredded, backdated or otherwise tampered with.
Once STORED in DataTrails and shared with partners, no party to the transaction can tamper, back-date or shred evidence. However while the security and integrity of our customers’ data is our top priority, there could still be a suspicion that DataTrails (or a hacker in our systems, or our cloud service provider under subpœna) could tamper with the data, or make it unavailable.
Once COMMITTED in the customer’s Tenancy Merkle tree in public blob storage, customers can prove their Events to 3rd parties, AND any tampering by DataTrails is detectable. Because this data is public, anyone can keep and maintain a copy just in case DataTrails’ version disappears. These copies are great for availability and holding DataTrails accountable, but there is a risk that a kind of Sybil attack could be mounted where the community creates forks and then tries to accuse the DataTrails version of being wrong.
By adding all Tenancies to the Merkle Mountain Range (MMR) and signing the root, Events move to the CONFIRMED stage. The signature on the root at once holds DataTrails to account and prevents forks and the Sybil attack mentioned above. Even so, a tiny chance of tampering remains: in principle, multiple MMRs could be signed, creating multiple versions of history.
To make the whole history and individual events UNEQUIVOCAL, the root hash of the Committed MMR is periodically broadcast so that it is clear that there is one, and only one, version of history to underpin your data authenticity.
Access Policies
Sharing the right amount of information with the consumers of your data is critical to creating a trustworthy shared history for any Asset. It is important that every participant be able to see and contribute to the Audit Trail without compromising security and personal private information. To ensure stakeholders can access only the information relevant to them, Events are private by default, unless posted to a Public Asset. Tenant Administrators define how much of the Audit Trail a user or partner can see so that they only see what they need to complete a task.
Like any high end transparency service, DataTrails operates a ‘once seen always seen’ system, so while you remain completely in control of what Audit Trail data you share with your partners, it cannot be deleted or modified later.
An Attribute-Based Access Control (ABAC) policy is used to share with Non-Administrators within a Tenancy. An Organization-Based Access Control (OBAC) policy is used to share with the Administrators of another Tenancy. The Administrator of the external Tenancy may then use an ABAC policy to grant permissions to the relevant Non-Administrators of their Tenancy. In both cases, attribute-specific read and write access can be granted using fine-grained controls.
The Public View
Every Audit Trail has a private view which is only visible to Tenancy Administrators and those who are given access through an Access Policy. Additionally some Trails, such as those that meet the requirements of the Document Profile, have a Public View which is visible to everyone. The purpose of this view is to allow anyone to verify that the document that they are using is genuine and has not been altered. When the document Audit Trail is combined with Instaproof a user of your data can easily find out which version of a document they have and confirm that it is genuine.
The Golden Thread
Putting all these concepts together, it is possible to create a Golden Thread of evidence that makes up the Data Trails Audit Trail. This has many use cases relating to content authenticity but can also be applied to supply chain integrity and standards compliance, or fact anything where stakeholders need transparency and trust.
