The architecture we developed consists of five main components; 1) blockchain for recording events, 2) business rules for setting the conditions to share information, 3) access control to ensure only authorised access, 4) metadata and context information to understand whether the context enables information to be shared, and 5) encryption and decryption.
Blockchain technology is used to create a general ledger of events that are accessible to customs and that enable the secure sharing of reliable information. Business rules are used to set parameters about under what conditions to share information. Metadata and context information about the requester of access to data, together with the business rules, are used as input for the decision component to reach a decision about whether to share data. In this way, data sharing is context-dependent and is controlled by businesses. Access to data is prevented or granted by respectively encrypting and decrypting data elements using a key.
In each of the following subsections, we discuss an element of the architecture and its relationship to other elements. Section 5 provides an illustration and evaluation of the architecture.
Information sharing using blockchain technology
According to Pilkington (2016, p. 11), a blockchain is a “secure public ledger platform shared by all parties through the Internet or an alternative distributed network of computers”. Although blockchain technologies are usually associated with applications in the domain of cryptocurrencies such as Bitcoin, they can also be used outside the monetary domain (Pilkington & Zhegu 2016; Walport 2015). For instance, ledgers can be used to track the origin and transformations of goods in a supply chain (Pilkington & Zhegu 2016).
The architecture we developed is based on a distributed ledger model in which events, such as the stuffing, departure or arrival of a container are recorded. The idea of using events in information sharing is not new; event-driven architectures for information sharing in the supply chain domain already exist (see e.g. Overbeek et al. 2012). The combination with a blockchain is new, however. We discuss the elements required to combine blockchain technology and events in the following subsections.
Blockchain is based on the six steps described by Nakamoto (2008) in the paper in which Bitcoin was introduced. Since cryptocurrency is not our domain, some changes needed to be made to these steps. Most apparent is the skipping of the first two steps described by Nakamoto (2008, p. 3), viz. “New transactions are broadcast to all nodes” and “Each node collects new transactions into a block”.
In the case of Bitcoin, nodes can gain bitcoins by adding blocks to the chain (Nakamoto 2008). To make this difficult, they therefore have to provide a proof of work first (Nakamoto 2008). The proof of work involves finding a value that satisfies certain properties (Nakamoto 2008). The finding of this value requires a lot of work, but once found it is easy to check whether the required properties are satisfied (Nakamoto 2008). We do not need proof of work to add a new event. Instead of making it difficult to put a block on the chain because currency can be earned by it, it should be easy for parties to add a block to share information.
The remaining steps for the proposed architecture are the following:
- Step 1.:
-
A node adds a new event to the ledger as a new block
- Step 2.:
-
The new block is broadcast to all other nodes
- Step 3.:
-
Nodes accept the block according to a consensus mechanism (see Section 4.1.5)
- Step 4.:
-
If the block is accepted, a new block that is added contains a hash of its header.
The blockchain in our architecture consists of a network in which a ledger containing infor-mation is distributed. The information is captured in events that have a body and a header. The events are accepted by nodes in the network according to a consensus mechanism. In the following subsections, we discuss these elements based on the steps above. We also worked the steps out in detailed sub-steps to provide a procedural overview of the use of the blockchain technology in our architecture. These are presented in the last subsection.
The network in which the ledger is distributed
In our architecture, events are shared in a network of systems of businesses and government organisations. For distributed ledgers several variants are possible, namely permissioned or permissionless ledgers, public or private ledgers, and variants in between (Mainelli & Smith 2015; Pilkington & Zhegu 2016; Walport 2015). Whether a ledger is public or private determines who can use copies of the ledger (Walport 2015; Buterin 2015). Whether a ledger is permissioned or permissionless determines who maintains the ledger (Walport 2015; Buterin 2015).
All parties in the supply chain should be in the network, as they all might have information to share. However, there is no clear reason for letting parties other than those businesses and government organisations be part of the network. In addition, there is no reason to restrict the right to determine consensus to a single party, such as in a fully private and permissioned ledger. Having multiple parties maintain the ledger and determine consensus improves reliability. All parties in the network should thus be able to maintain the ledger.
The information that is recorded in the ledger
In the monetary domain, blocks with sets of transactions are added to the ledger. In our architecture, events correspond to such blocks, while the associated data elements roughly correspond to the transactions. When an event is added to the ledger, it contains its associated data elements and their metadata. The data elements should at least contain the type of event, the time the event happened and an ID for the object that the event happened to (e.g. a container number). This is needed to make it possible for customs and others to link the event chronologically to other events concerning the same object.
An example of an event that could be added to the ledger is the stuffing of a container. The event should contain at least the following data elements (with example values):
-
event type: container stuffed
-
event time: 2017-04-14 09:22:00
-
event object: KZDU3401208.
Additional data elements that could be associated with this event are, for instance, descriptions of the goods the container was stuffed with and the weight of the container. These additional data elements can be added to the event as well.
Metadata of the data elements are added to enable context-based access control. Furthermore, certain data elements will be encrypted to keep them confidential. When they are encrypted, metadata are needed to know what the data elements are and whether it would be interesting for parties to try and get access to them.
The metadata that could be stored together with the data element of the weight of the container in our example is the owner of this information, the method of measuring and the type of data. The content of the metadata stored with the data elements is further discussed in Section 4.4. In the following subsection, we discuss the format in which the data elements and their metadata are stored in the events.
The data elements in events and their Merkle trees
Events consist of a header and a body. The header contains information required to link the event to the chain and information required for the consensus mechanism. The body contains the data elements associated with the event. To add a new event to the ledger in step 1, first the data to be shared should be in the appropriate format. Each data element has metadata associated with it. The metadata of each data element could be stored together with it in a structure similar to that of a JSON object (Crockford 2006). To protect confidentiality, each data element associated with the event and elements of its metadata could be encrypted within the structure. We discuss the encryption and decryption of data elements in Section 4.5.
In the case of Bitcoin, transactions are hashed in a Merkle tree and then the Merkle root is stored in the header of a block to allow efficient and secure verification (Nakamoto 2008). A Merkle tree in our case allows all hashes of all data elements in an event to be stored in a single hash value (the Merkle root) (Luu et al. 2015). Furthermore, it allows for a simple proof of the existence of a data element in the tree (Luu et al. 2015; Merkle 1987). This makes it possible to check whether all data elements in a Merkle root are in an event, or whether they have been tampered with.
The Merkle tree based on the hashes is built as described by Merkle (1987) and Massias et al. (1999). The exact hash-function to be used in our architecture is outside of the scope of this paper. However, the avoidance of collisions is important to be able to check whether a data element is in the tree.
Figure 2 provides an example of what the Merkle tree containing the elements could look like. The data elements (in a structure together with their metadata), here denoted by d1,...,d4, are hashed in to the hashes H(d1),...,H(d4), respectively. These are the leaves of the Merkle tree. The leaves are concatenated by two, denoted by H(d1)|H(d2) and H(d3)|H(d4). These concatenations are then hashed to a single values, viz. H(H(d1)|H(d2)) and H(H(d3)|H(d4)). The parent hashes obtained in that manner are then again concatenated by two and hashed again. This goes on until there is only a single hash left, the Merkle root.
In the case of Bitcoin, the Merkle tree is pruned to save disk space (Nakamoto 2008). In our case, we do not see the need for pruning parts of the tree. If disk space is a concern, the complete tree containing the data elements can be deleted to free disk space, while the header of the event is still stored. This can be done when the data on an event is no longer relevant, for instance when the goods have arrived at their destination. The Merkle root stored in the header is enough to be able to check whether a data element is part of an event.
The headers of events
In addition to data elements, events have a header. The header has seven fields:
- Field 1.:
-
The Merkle root of the Merkle tree of the data elements associated with the event
- Field 2.:
-
A hash of the header of the previous event in the blockchain
- Field 3.:
-
A timestamp for when the event was added
- Field 4.:
-
A unique ID for the party adding the event
- Field 5.:
-
The Merkle root encrypted using the private key of the party adding the event
- Field 6.:
-
A unique ID for the party confirming the event
- Field 7.:
-
The Merkle root encrypted using the private key of the confirming party.
The inclusion of a hash of the header of the previous event links the events together in the blockchain, just as in the case of Bitcoin (Nakamoto 2008). The events are ordered in the chain chronologically; therefore each header should also contain a field with a timestamp for when it was created. When a party wants to add a new event, it adds the hash of the header of the event in the chain that it accepts with the most recent time stamp.
When there is a fork in the chain, the chain with the block with the lowest time stamp directly after the fork that should be accepted according to the consensus mechanism should be considered the actual blockchain. The party that added the other event should try again and add its event after that. In the rare case when time stamps are exactly the same, it should be possible to order the events in another way, for instance based on the value of the Merkle root.
Fields 1, 2 and 3 can be used to add a new event to the chain and broadcast it, completing steps 1 and 2. Since we do not need proof of work in our architecture, events can now be simply added and broadcast. However, we do need a consensus mechanism for the acceptance of events that are added to the blockchain (step 4). Fields 4, 5, 6 and 7 are needed for this consensus mechanism.
The consensus mechanism
Since we are concerned with sharing information that will be used to ensure safety and security, the correctness of the information is of vital importance. The consensus mechanism should help to ensure such correctness. To do so, for all events two parties must confirm that the data are correct. To fulfil step 3, only events for which such confirmation has been provided should be accepted by nodes.
Consider again the example of an event for the stuffing of a container. There could be a party that arranged the transport, such as a freight forwarder, which knows when the container was stuffed and also has a description of the goods that should be in the container. In that case, there is also a party that actually stuffed the container, such as the consolidator. When the event is added to the ledger by the freight forwarder, the forwarder can ask the consolidator for confirmation that the container was in fact stuffed and that the data elements in the event are correct.
To get consensus, there should be an easy way for nodes to check whether two parties in the network have confirmed the correctness of the information in the event. Businesses and government agencies in the network should be assigned unique IDs. For a party to confirm the information in an event, a link should be made between the party and the data elements in the event. Such a link is made when a party uses its private key to encrypt the Merkle root of a Merkle tree of the data elements in the event. Both the IDs of the parties that confirmed the information (fields 4 and 6) and the Merkle root that they encrypted (fields 5 and 7) should then be added to the header of the event.
Nodes can now easily check whether the information in the event was confirmed by two parties. For each confirming party, they first look up their public key using the ID of the party in the header. Next, they use this public key to decrypt the Merkle root. If the decryption succeeds, they know that the confirmation did in fact come from this specific party, since they used their private key to encrypt the Merkle root. This also makes it possible to hold them accountable for incorrect information. In addition, they know that the information in the event was in fact the information that they confirmed if the Merkle root is a Merkle root of a Merkle tree of the data elements in the event. When the nodes in the network accept the new event, we can continue to step 4, in which a party adds a new event to the chain on top of the accepted event.
Procedural overview
Based on the discussion above, we can add details to the steps mentioned in the introduction of this subsection. Step 1 (node adds a new event to the ledger as a new block) is fulfilled when the following steps are performed by the party that wants to add a new event:
- Step 1.1:
-
Gather (possibly encrypted) data elements associated with the event
- Step 1.2:
-
Build the Merkle tree of the data elements and add the Merkle root to the header
- Step 1.3:
-
Encrypt the Merkle root using private key
- Step 1.4:
-
Add the encrypted Merkle root and own ID to the header
- Step 1.5:
-
Send data elements and the Merkle tree to confirming party
- Step 1.6:
-
Receive back the Merkle root encrypted with the private key of the confirming party
- Step 1.7:
-
Add the encrypted Merkle root and the ID of confirming party to header
- Step 1.8:
-
Add hash of previous event in the chain to header
- Step 1.9:
-
Add timestamp to header.
The next step (step 2) is broadcasting the new event to other nodes. This step does not need to be divided into smaller steps. However, the third step in which the nodes accept the event according to a consensus mechanism, can be divided into smaller steps. To check whether a new event is an acceptable addition to the chain, nodes perform the following steps:
- Step 3.1:
-
Check whether the Merkle root in the header conforms with the data elements of the event
- Step 3.2:
-
Check whether the hash is a hash of the header of the previous event
- Step 3.3:
-
Decrypt encrypted Merkle roots using the public keys of the adding party and confirming party
- Step 3.4:
-
Check whether these Merkle roots are the same as the Merkle root in the header that was not encrypted.
In the fourth step, parties express acceptance by adding new events to the chain on top of the accepted event. This step thus refers back to the first one in which a new event is added. The following subsections concern obtaining access to the information that is distributed in the manner described in this subsection.
Business rules
Business rules in the architecture are used to specify who should have access to information. A business rule can be defined in various ways. Graham (2006, p. 7) defines business rules with an emphasis on the form and expressive power as follows: “A business rule is a compact, atomic, well-formed, declarative statement about an aspect of a business that can be expressed in terms that can be directly related to the business and its collaborators, using simple unambiguous language that is accessible to all interested parties: business owner, business analyst, technical architect, customer, and so on.” While the form of business rules is of course important, here we are more concerned with their function. Work that focuses more on the function of the rules exists as well. For instance, Lee et al. (1999) view workflows as sets of business rules. However, the definition of Ross (2003) fits our purposes best, as he defines business rules as a directive intended to influence or guide business process behaviour. This conforms with the use of business rules in our research as an input for decision making on which parties get access to data. In this way, they influence and guide the information sharing process.
In the proposed architecture, the business rules are used as input for the decision made by the decision component. The specific business rules are provided and specified by the owners of the data and by the parties that own any data that the owners’ data are based upon. By specifying these rules, they have control over who gets access to their data and they can keep information confidential according to their company’s policy on access control. Each company might have different policies and therefore a company should be able to specify these rules itself. Since the business rules are requested each time a decision needs to be made, the owners of the data can change their business rules and thereby influence new decisions when their needs change.
Business rules can be used to specify precisely who does and who does not get access to a data element or even its metadata. For example, a business could specify that only a client that pays them extra gets access to the estimated arrival time of a container that contains their goods. Businesses could also use business rules to express more general policies on access. They could, for example, specify that in the case of an emergency, all data elements should be accessible to customs.
Generic businesses rules are not specific to a certain part of the data. They can be used to incorporate some general common sense in the decision making process. Furthermore, they could capture legal knowledge and be used to ensure that access to data is lawful. Capturing legal knowledge using business rules is not new; for instance, it is discussed in the work of Gong and Janssen (2014) and Palmirani et al. (2011).
Specifying exactly the way in which access to data is controlled and what the form of the business rules should be, is outside of the scope of this paper. Our focus is on the design of the architecture. However, to be able to provide some examples of business rules that could be used, we need a form to express them in.
Access control is discussed extensively in the literature. Karp et al. (2010) provide an overview of the different methods of access control, such as role-based access control (RBAC) and attribute-based access control (ABAC). According to Lee et al. (1999), first-order logic (FOL) is often proposed in the literature as a general framework that is suitable to formalise access control policies. It thus makes sense to use FOL to express the business rules in our examples as well. We emphasise, however, that further research is needed to determine whether FOL is in fact the appropriate format for the business rules in the architecture.
The format of the business rules used in the proposed architecture is highly dependent on the reasoning mechanism used in its decision component. There might be different kinds of possibly complex business rules, considering the large variety of businesses, the large variety of information to be shared, and the complexity of laws and legislation. Furthermore, the business rules of several businesses might be involved in making a decision on a specific part of data. It is therefore to be expected that contradictions will arise during the reasoning process. Moreover, it might be easier and more natural to express rules as being an exception to other rules, especially for generic rules based on the law. It is therefore highly likely that in the end there will be a need for a defeasible logic that is able to solve contradictions in a sensible manner. One could, for instance, think of some kind of argumentation logic, especially since such logics are quite often used in legal reasoning (Prakken & Vreeswijk 2002).
As discussed in Section 3.2.1, parties might want to keep information confidential for various reasons. Consider a scenario in which high-value goods are shipped. The freight forwarder might want to keep the goods description confidential from parties other than customs for fear of theft. They could encrypt the goods description before adding it to an event and then specify a specific business rule to control access to this information. The FOL sentence below shows what such a business rule might look like. The symbols have their usual meaning and the capitalised letters denote variables.
$$ dataType(Data,goods\_description) \land \neg hasRole(Req, customs) \rightarrow \neg access(Req,Data) $$
(1)
When a party wants access to this information, the freight forwarder can send the rule to the decision component and thereby control access to the goods description.
As mentioned in Section 3.2.3, taking into account the goal-binding of information can be important for ensuring the lawfulness of information sharing. A generic business rule that takes into account the goal-binding principle could look as shown in example 2.
$$ goalGathered(Data,G1) \land goalUse(Req,Data,G2) \land G1 \neq G2 \rightarrow \neg access(Req,Data) $$
(2)
When access to information is requested, the requester will be denied access according to this rule in cases in which the goal for gathering the information is not the same as the goal for its intended use by a party. Of course, this depends on the other rules that play a role as well.
The architecture components for access control
The architecture has two components that are necessary for controlling access, viz. a decision component and a component that allows access to data elements according to the decision. The decision component can be used by businesses or government agencies that want access to request a key. Based on the decision of the decision component, the second component provides the requester with a key that can be used to decrypt the data elements if the requester is allowed to access according to the decision.
The decision made in the decision component is based on several types of input from different information sources. There are two types of business rules (see Section 4.2) and two types of information (see Section 4.4). The first type of business rules are specific to the data to which access is requested. Each time the decision component needs to make a decision, it sends a request for specific business rules to the owners of the data that it needs to make a decision on and to the owners of the data that their data are based upon. The other type of business rules are generic business rules. They are the same for all decisions and are stored in the decision component itself.
The first type of information required by the decision component is context information on the requesters themselves and their intention to use the data. This information is send by the requester together with their request for access. The other type is metadata on the data elements they request access to. The metadata provides information about who is the owner of the data element and the party that is the owner of any data that the data element is based upon. Using this metadata the specific business rules can be requested from the appropriate parties. The decision component has access to its dedicated copy of the ledger to obtain metadata.
There are two possible outcomes of the decision process by the decision component, leading to two kinds of output of the component. The first is that the requester is not allowed access, in which case the requester is informed of this. The second possibility is that the requester is allowed access, in which case the decision and other information needed is sent to the other necessary component. This component generates a decryption key that can be used only by the requester of the information to decrypt the data elements that the requester is allowed to access according to the decision. This key is then sent to the requester. Figure 3 gives an overview of the components and their interfaces.
Metadata and context information
Decisions made by the decision component are based on metadata and context information. Metadata are often defined in the literature as data about data (Schuurman et al. 2008; Greenberg 2005). This simple definition is sufficient for this paper.
The data elements in events are all associated with the event. In some cases they are clearly data about the event, such as the event type. In other cases, such as the data element of container weight in a ‘container stuffed’ event, this association is more loose. All the data elements in the event themselves can also have metadata, such as the owner of the data element or when it was created.
In our case, the metadata will have to be rich enough for the decision component to be able to make a decision. It would make sense for the parties that add the data elements to an event, to generate all metadata as well. They will usually, if not always, be the same parties that control access to the data and deliver the specific business rules to the decision system. They will thus know what metadata are needed in order to make a decision. Furthermore, some metadata should always be provided, such as metadata containing information on the owners of data elements and the parties that are the owners of any data that the metadata are based upon, since otherwise it will not be possible to specify the parties the specific business rules should be requested from. Furthermore, metadata might be needed to decide whether a party should be allowed access according to the generic rules as well.
An additional function of the metadata is to let parties that want to access data elements in an event know what information is in there. They might already have some idea in some cases because of the events mentioned, but since the data elements themselves can be encrypted, there is no other way for them to know this directly and to determine whether or not they would like to have access. In the events, data elements are stored together with their metadata in the same structure. It might often be the case within this structure that the data element itself (e.g. goods description) is encrypted, while its metadata (e.g. the type of data element) are not.
To have access to the metadata, the decision component needs access to a copy of the distributed ledger. There might be cases in which metadata should be kept confidential, for instance because otherwise the volumes of goods transported by a business could be derived, which is competitively sensitive information. There is no clear reason in such cases not to allow the encryption of metadata.
In the scenario in which business rule (1) was specified, the metadata of data shared by the freight forwarder should include the data type of the goods description and the metadata identifying them as a party whose business rules have to be requested by the decision component. For example, for business rule (2) the metadata should include the goal for gathering the data elements.
In addition to the metadata, the decision component also bases its decision on context information. Context information is data generated by the requester of access to the information and concerns the context in which access to information is requested. The requester can send this context information together with the request for access to the decision component.
In the scenario of business rule (1), the context information required to make a decision would be the role of the requester. If this is anybody but customs, access to the information might be denied. In the scenario of business rule (2), the context information that is required is the goal for which the requester wants to use the information. If this is not the same as the goal for which the data were gathered, access might be denied by the decision component.
Regulating access via encryption and decryption of parts of data
Access to data is usually regulated by sending or not sending data to others or by allowing or not allowing others access to a database. This is different for the architecture we propose. In this architecture, access is regulated by encrypting and decrypting parts of data. This means that it is possible for businesses to encrypt data elements or their metadata and distribute them to others, without automatically granting them access. As a result, the access to data and the location where the data are saved are not linked. In other words, physical access to information does not imply logical access.
The fact that access and location are no longer linked allows organisations to enrich data or combine data in the ledger in useful ways that they might not have even known about otherwise. In order for this to work, the enriched data or combined data should also be encrypted before adding it to events, and the rules of the owners of the original data should also be applicable to the new data that are based on them. An example of the enrichment of data is a company adding the data element of the weight of containers, based on information received about the weight of goods and its own information about in which containers goods are. If they share this data element, the business rules of the owner of the data elements containing the weight of the goods, and those of the owner of the information that this data element is based upon, would be applicable, as would of course the business rules of the business itself.