Introduction

In today's connected world, data sharing between enterprises and among organizations is commonplace. Both providing and consuming businesses benefit from sharing data in collaboration. In their data-sharing processes, today's businesses often rely on centralized platforms or ad-hoc solutions like email attachments. As the requirements of data sovereignty, security, and separation of data and application [1] become more pressing, endeavors like the International Dataspaces (IDS) 1 or Solid Dataspaces (SDS) [2] are gaining momentum.

Building on the SDS approach, we present a system for sovereign data sharing along a chain of enterprises. We implement a use case for credit requests, where an enterprise requests a credit from a bank and is required to provide data made available by the enterprise's tax advisor. Only the directly communicating actors know each other, so the origin of data passed on must remain hidden while data is still processed along the business chain. In our solution, the data is not stored as a hard copy for each participant. Instead, data from the original source is passed along to involved parties on-demand if access is granted. The party owning the data source is in control of data access and -we assume here -has permitted re-distribution according to contractually defined purposes. We thus present an implementation of a data value chain [3]. In this paper, we highlight the core components of our demonstrator: a Rights Delegation Proxy (RDP) [4] to handle the actions of natural persons on behalf of legal entities, and a Data Provision Proxy (DPP) [3] to requests to concealed locations along the chain. Our contribution is the demonstration of a Solid-based system for sovereign B2B data sharing.

Use Case

Fig. 1 illustrates our use case where the banking institution BigBank, the tax advisory office TAO, and the company SME create a data value chain for a credit offer scenario. As a representative of BigBank, the bank employee Lisa acts as a natural person.

Upon a credit request, BigBank is to create a credit offer for the requesting organization SME. The bank's employee Lisa is responsible for this task. To assess the financial situation of SME, Lisa needs to access accounting data and a business report of SME. This data is prepared and provided to SME by TAO. To get the credit, SME must provide that data to BigBank. In this data value chain, two requirements exist regarding business relationships and data sovereignty [3]:

A: The relation between SME and TAO must remain secret until SME is to disclose it.

B:

The TAO is required to keep control over the aggregated business report data.

Related Work

The Solid Protocol is a bundle of specifications for read/write Linked Data under access control.

The protocol builds on the RESTful HTTP specification of a Linked Data Platform (LDP) 2 for interacting with Web resources, and extends it with authentication and authorization using an extended version of OpenID Connect3 and Web Access Control 4 .

For handling the delegation of rights by real-world businesses, government-managed registers of commerce are used. Companies publicly and lawfully declare which individuals may act and negotiate on their behalf; see the German Commercial Register5 for example. In cyberspace, the long-standing vision of dataspaces aims to integrate different data sources [1]: Top-down approaches like the International Data Space (IDS) 6 or GAIA-X7 aim for sovereign data exchange using governance models and standardized data exchange components. From a bottom-up perspective, Meckler et al. [2] identifies the Solid Protocol8 as one technological foundation for decentralized yet interoperable dataspaces, named Solid Dataspaces (SDS).

For data exchange between collaborating enterprises, Henselmann et al. [5] present a Solidbased solution in a credit request scenario similar to ours. While their solution passes data along a chain of participants, their system relies on hard copies of data to be stored at each participant and does not include natural persons as actors for legal entities. In a machine-to-machine interaction use case, Wang et al. [6] present rule-based agents that negotiate a trade contract under German law using the Solid Protocol. In contrast to our approach, decision-making is automated and all participants, their needs, and data are known.

Demonstrator

Our demonstrator 910 is composed of the following components for each company (see Fig. 2):

Solid Business Web Apps enable the employees to carry out their business activities. For the example of SME, the initiation of a credit inquiry, the provision of the business reports requested by the bank to prepare a credit offer, and the approval of the Bank's credit offer. In addition, an authorization application, as described in [7], is used to manage incoming, existing, rejected, and revoked requests for data sharing. A Company's Solid Pod stores the company's business data and makes it available under access control. Notably, it also contains rights delegation policies, i.e., rules that define which specific employees are allowed to interact internally and externally on behalf of the company. Further, it contains definitions for resources that are made available via proxied data provision. A Rights Delegation Proxy (RDP), as described in [4], receives and logs requests made by the company's employee (e.g., Tom). It authenticates the employee using their WebId and checks if they were delegated the required rights to proceed with their request. To this end, the RDP retrieves and validates corresponding policies defined by the delegator (SME) from their Pod. If all requirements are fulfilled, the RDP proceeds with the delegatee's request but updates the authentication headers with the delegator's credentials. Any received response is logged and forwarded to the delegatee. A Data Provision Proxy (DPP), as envisioned in [3], receives all data requests (e.g., from Lisa on behalf of BigBank) and checks on the Pod whether the requested resource is an actual Pod-stored resource or to be retrieved and passed along from an external data source. That is, it validates if the company's own data (SME) or data from a third party (TAO shared with SME) is requested. If the requested data originate from a third party, the DPP checks the sharing policy of the third party. If allowed, the DPP retrieves the resource (authenticated as SME) and provides it as if originating from the company (SME), masking the original data source (TAO).

A walk-through of our demonstrator:

1. Lisa logs in to the business Web App using her own WebID. To retrieve the accounting data on the SME's Pod, she sends an authenticated request to the RDP of BigBank. 2. The BigBank RDP authenticates Lisa and checks if she is authorized by the bank's policies to interact with SME. Then it requests the resource from SME, authenticated as BigBank. 3. The SME DPP receives the authenticated request coming from BigBank to access the accounting data. It checks whether the requested resource is an actual Pod-stored resource or an external one to be forwarded. Additionally, it checks if re-distribution is allowed. 4. On pass, the SME DPP performs an authenticated request as SME for the TAO's data. 5. The TAO DPP receives an authenticated request from SME to the resource containing the accounting data. As this resource is an actual Pod-stored resource, the request is forwarded. The Pod checks access control rules and returns the data via the proxy. 6. The SME DPP receives the response, logs it, and responds to the request of BigBank. 7. The BigBank RDP receives the response from SME and forwards it to Lisa's app. A screencast of our demonstrator is available online11 .

Fulfillment of requirements:

Our system demonstrates how the requirements defined in Sec. 2 can be met:

A: BigBank and TAO are not disclosed to each other while Lisa (i.e., BigBank) still receives the desired data. SME and its RDP are acting as a broker facilitating the data sharing. B: The accounting data remains stored on TAO's Pod and in its control, without hard copies being necessary at the SME's Pod. Additionally, we highlight the following features of our approach:

• The data value chain could also continue further by the TAO without the SME knowing the additional upstream participants. • The existence of participants is secret and only revealed on a "need to know"-basis.

The existence of upstream or downstream business participants is obfuscated. Acting employees also remain private as their actions are attributed to the respective company.

• Policies for data access and re-use specify relations between two agents, e.g., the internal relation of Lisa and BigBank or the external relation of SME and TAO. The policies and thus the existence of these bilateral relations remain only known to the involved agents.

Conclusions and Future Work

In this paper, we presented a Solid-based system for sovereign data sharing between enterprises. Our main contribution is the demonstration of a data value chain that respects the privacy and data sovereignty of its participants. We emphasize that our demonstrator is comprised of reusable components based on Web standards and the Solid Protocol to build a Solid Dataspace. We highlighted the Rights Delegation Proxy (RDP), to let natural persons acting on behalf of their companies, and the Data Provision Proxy (DPP), to retrieve data from upstream data sources. We re-iterate that both of these components are built using the same Semantic Web standards and specifications as the rest our demonstrator.

In future work, we plan to address the process of interactively initiating a B2B collaboration while also protecting the currently often publicly accessible metadata of the involved enterprises.