We demonstrate a system architecture for seamless and sovereign business-to-business (B2B) data sharing using the Solid Protocol. We highlight two core system components: The Rights Delegation Proxy allows organizations to internally manage and enforce access policies on requests from their employees to external data providers. The Data Provision Proxy allows organizations to share data from an external data provider in a privacy-preserving manner. Organizations define and enforce the policies for internal and external data sharing themselves, thereby maintaining sovereignty in enterprise collaboration.
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 [
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 [
Lisa (Bank Clerk) Acts on behalf of the bank
Processes credit requests
SME requests credit offer
Bank requests business BigBank prreopvoidrtefsoorffcerrebdaitsoefdfeor,n SME report
Tom (Employee) Acts on behalf of SME
Applies for a credit for the compamy
SME mandates TAO TAO prepares business reports
TAO
Max (Tax advisor) Acts on behalf of TAO prepares tax returns, bookkeeping, business reports
In this paper, we highlight the core components of our demonstrator: a Rights Delegation
Proxy (RDP) [
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 Control4.
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 diferent data sources [
3https://solidproject.org/TR/oidc 4https://solid.github.io/web-access-control-spec/ 5https://www.handelsregister.de/ 6https://github.com/International-Data-Spaces-Association/IDS-RAM_4_0 7https://docs.gaia-x.eu/technical-committee/architecture-document/22.04/ forward RDP forward DPP
Frontend
Backend
perspective, Meckler et al. [
For data exchange between collaborating enterprises, Henselmann et al. [
Our demonstrator910 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 ofer, and the approval of the Bank’s credit ofer. In addition, an
authorization application, as described in [
9https://github.com/mandat-project/hackathon-demo
10https://github.com/mandat-project/delegation-proxy
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 [
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. 11https://purl.archive.org/mandatb2b/Semantics2024 • 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.
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. Acknowledgments This work has been supported in part by the German ministry BMBF under grant 16DTM107B (MANDAT ).