Logging mechanism for cross-organizational collaborations using Hyperledger Fabric

Abstract

Organizations nowadays are largely computerized, with a mixture of internal and external services providing them with on-demand functionality. In some situations (e.g. emergency situations), cross-organizational collaboration is needed, providing external users access to internal services. Trust between partners in such a collaboration can however be an issue. Although (federated) access control policies may be in place, it is unclear which data was requested and delivered after a collaboration has finished. This may lead to disputes between participating organizations. The open-source permissioned blockchain Hyperledger Fabric is utilized to create a logging mechanism for the actions performed by the participants in such a collaboration. This paper presents the architecture needed for such a logging mechanism and provides details on its operation. A prototype was designed in order to evaluate the performance of an asynchronous logging approach. Measurements show that the proposed logging mechanism enables organizations to create a log of service interactions with limited delay imposed on the data exchange process.

Trustful ad hoc cross‐organizational data exchanges based on the Hyperledger Fabric framework

“…This average TX size is a bit lower than the earlier reported 4.8 KiB. 19 The reason for this is that the transientMap field instead of the args field is now used when the sendTransactionProposal function (shown in Listing 9) is called. This prevents the arguments passed to each CC function to be logged in a TX, that is, it prevents the actual request and response data to be logged unintentionally.…”

“…It would instead be more useful to let connecting organizations, also called clients, couple to one or more reusable features. This feature-based vision, enabling automated clients, is extensively described by its founders F I G U R E 2 Recap of the components needed for the proposed logging mechanism 19 Verborgh and Dumontier. 21 It is important to note that their vision is aimed at the entire web API ecosystem and that the selection and granularity of the different features need to be agreed upon by the community.…”

“…On the other hand, the data exchange and logging process are separated in order to avoid latency for the exchange. 19 Conceptually, two layers can be identified, the application layer and the blockchain layer. Due to this, it is impossible to choose an alternative policy requiring the two organizations involved in a data exchange to endorse a single TX, as the actual data exchange can only be known by the EPs when it is communicated top-down, that is, from the application layer to the blockchain layer.…”

“…Two additional checks are required to be able to verify the correct operation of the entire collaboration setup. 19 • As each organization can store the logs it wants and as TXs can get lost, intentionally (e.g., malicious ordering service) or not (e.g., network failure), it is needed for each organization to verify the presence and integrity of all expected logs. It is important to note that the involved organizations should obtain complete logging cycles, that is, both for request and response, as external parties are not able to know what exactly happened during their private communication without those logs.…”

“…A specific case of this situation is when physical instead of digital goods are exchanged, as the sender and receiver need to meet in person and acknowledge the handover on‐chain before the actual package transfer happens 18 . The earlier proposed logging mechanism by the authors 19 is in a second category, as the data receiver can immediately consume the received data without having to wait for on‐chain information to be received. This is referred to as an asynchronous data exchange approach.…”