1 Introduction

By reading previous chapters, you may have reached the conclusion that data spacesFootnote 1 can mean many things to many people. It is a vast idea, with many angles and incentives for various stakeholders, varying from business leaders, operational manager, policymakers, ethicist, citizens, and businesses to government, IT specialist, researchers, and scientists. This chapter will bring some practical approaches to data sharing.

In its most concrete appearance, a data space is functional to users. Users can control their data while sharing it with others. Control means that they can share the data for a certain purpose (e.g., “only for maintenance purpose”), time (“1 month”), and other conditions such as the nature of the receiver (“lawyer,” “doctor,” “government”). Data sovereignty is the term often used for this functionality of control, all in an easy-to-use fashion.

Functionality is what makes data spaces so powerful. The word “space” refers to the optionality for users, who want to engage in data sharing. Participants to the space have a lower threshold in engaging with each other (than people outside of the data space), leading to lower transaction cost. Sharing is not bilateral anymore but becomes multilateral. Sign up once, and reach many other who also did sign up. Very similar to GSM, email, and payments cards who all share a decentralized design, leading to vibrant ecosystems with low thresholds for participation.

The larger the number of participants, the larger the data space. There can be unlimited amount of data spaces. In fact, today, many data spaces exist already. Think of the many data-sharing activities happening in, e.g., pharming, banking, insurance, healthcare, energy, or social media for that matter. These can be seen as data space, as they have defined groups of participants who all have sharing and interaction optionality vis-à-vis each other. Most of them are also open to participants, as long as participants fit the requirement set up by the community.

This chapter is about possible ways to implement data spaces, the business considerations, and a practical approach through the trust scheme iSHARE.

2 Business Considerations for Data Sharing

Consider yourself as a decision-maker or influential in business, e.g., agriculture, finance, manufacturing, energy, or health, or government for that matter, because governments also engage in digital data sharing.

In today’s world of digital business, data sharing is often performed by commercial intermediaries, often referred to as platforms. They put their own capital at risk by offering a data exchange service to a defined set of actors while investing heavily in growth, because the more users they have, the more value they create for their customers and themselves. They invest in breaking the chicken and egg problem, by enlarging the optionality for all users. Examples of such platforms are freight and transport providers, b2b e-commerce platforms for supplies, and agriculture data for buying and selling crop, or social media platforms in the personal data spaces.

Data sharing via data spaces can be seen as 2.0 data sharing. The biggest difference with the platform business model is that the governance of the data spaces is not geared around profit maximization of a few owners, but the whole community of users can benefit. Multiple actors participating in the data spaces make profits. This is not such a new concept as in today’s world, already many of such cooperative structures exist to realize public goals. Current examples include data exchange in sea and airports, agriculture, energy, and healthcare, providing the ecosystem environment for actors to do their business.

Governance and profit distribution are the largest differentiators of data spaces, vis-à-vis commercial platforms. Data spaces allow actors to realize their own value add, based on the data space, while offering interoperability for the end customers. As such, data spaces should be seen as infrastructure, similar to electricity grids, roads, and telecommunications.

Having a clear business goal is paramount for any form of data sharing. It should lead to either more revenue, lower costs, or better services. In most situations, it is a combination of these factors as they are not fully independent from each other. However, the time horizon is also crucial.

We can apply the three horizons model here (by Baghai, Coley et al.Footnote 2). The short-term horizon will lead to continuation of data sharing, as we know it, including bilateral arrangements, data silo’s and platform providers. Horizon 2 is where we are with data spaces. Conceptually and technically, all is there, after many years of R & D. The biggest challenge now is the adoption and implementation. At its core, this is the change process within organizations. It will require a longer time horizon before the business results can be monetized. Horizon 3 is not applicable anymore when it comes to the conceptual development of decentralized data sharing. All is there to make it happen.

Leadership with a strategic mindset is needed to overcome this longer time span of horizon 2. The impact and competitive advantage of engaging in data spaces transcend the shorter horizon 1 of operational managers, charged with caring about the day-to-day problems. Amara’s law is applicable here as well: we tend to overestimate the effect of a technology in the short run and underestimate the effect in the end.

3 Data Sovereignty Spectrum: From the Technical and Legal Perspective

How to start in practice with data sharing? As mentioned, a business reason is paramount for engaging in data sharing. Business reasons vary from achieving higher revenues, lower costs, and higher quality of goods or services. In practice, this means combinations of these three elements. Figure 32.1 shows an overview of various data-sharing situations.

Fig. 32.1
figure 1

Data sovereignty in functionalities (Source: INNOPAY)

Full size image

Whatever the reason for data sharing, data sovereignty is the central functionality and design principle.

Control on data can be viewed from both a technical and a legal perspective. Technically, control is given through identity access management techniques, which are built into the APIs, which are actually sharing the data. Data right holders can authorize third parties (data consumers) to access the data source controlled by the data rights holders, by giving and recording the proper consent. Figure 32.2 shows the role-play between data consumer and data provider, from both a technical and legal perspective.

Fig. 32.2
figure 2

Basic roles in data sharing (Source: INNOPAY)

Full size image

The next technical question that arises is: how to control the data after the data has been shared. This is a hard problem, because data can easily be replicated and the data sharing party does not control the systems and users of the data-consuming party. One way to go about this is to apply edge computing, by doing the computations on the data at the source and only share the result to the data consumer. Then data control can be enforced in a technical fashion. However, this comes at a price in terms of complexity, cost, and manageability. This is one end of the data sovereignty spectrum.

In practice, decision-makers and engineers often think in terms of risk. For data sharing, this is not different. Edge computing solutions may be a technically sound solution; it may be often overkill (cost, effort) when it comes to many data-sharing practices. On the other end of the sovereignty spectrum is the procedural and legal approach.

Companies and people under verifiable consent then share data and the consumer has the legally binding obligation to only use the data for that purpose. The data provider has no technical means to control the data after it has been shared. He only has a technical and legal means to record a proper consent record, in which the terms of sharing are recorded in a digitally sound fashion and where the authenticity and the identity of the data consumer are secured. In this scenario, the data provider has strong legal recourse possibilities in case he detects that the data consumer is misusing the provided data.

Table 32.1 summarizes the main dimensions of the two ends of the spectrum.

Table 32.1 Trade-offs between functional data control and legal data control
Full size table

The data provider has the trade-off between functional data control and legal data control. The latter comes with a lighter implementation.

The heart of this decision is a risk, cost, and speed trade-off, and this depends on the specific use case. The consequence of a possible data breach or misuse of data determines which scenario will often be used as a determinate. E.g. health data pose a greater risk and therefore require a more stringent treatment because of privacy regulations than e.g. weather data or shipment information of a specific container. Confidentiality in both cases is paramount; and the way to enforce this is different. In the case of medical data, the edge-computing scenario may be used; on the other cases, the data is shared, and possible misuse is legally enforceable because the digital trail of consent, authentication, and authorization has a legal status.

Intuitively, the number of use cases for this technically lighter scenario is higher than the number of use cases for the edge computing solution. Both provide data sovereignty, but in a different fashion and against different cost and effort. The application area is large as there are many applications where actors prefer a lighter implementation as they can oversee the risk of misuse themselves, supported by the legal trail provided by the consent, authentication, and identification mechanism. Figure 32.3 summarizes the relation between risk and the number of use cases.

Fig. 32.3
figure 3

Incidence of use cases as a function of risk (Source: INNOPAY)

Full size image

The remainder of this contribution focusses on iSHARE as a solution for this “entry level” data sovereignty. In the following sections, we explain more and show iSHARE as a cornerstone of data sovereignty, because of its focus on consent, authentication, and identification.

4 The iSHARE Trust Mechanism for Data Spaces

First and foremost: iSHARE is not a platform nor a provider.

iSHARE is a trust standard, also referred to as “trust scheme.” The set of agreements describe how APIs for data sharing can implement the identity access management part, in a functional, operational, technical, and legal way. iSHARE participants implement the set of agreement in their data-sharing solutions and participate in the governance of iSHARE.

The things iSHARE provides are the governance, the set of agreements, and the vetting of the participants. It is run by a foundationFootnote 3 and governed by its participants. Participants can be everyone who uses data, provides data, and offers technical services to these groups. Often a data user also is a data provider.

4.1 Standards and Contract

The set of agreements come with an optional contract, which binds the user to the terms set by the foundation and its governance. This ensures that sharing among participants occurs on the same legal terms. A minimum is defined such that participants have less to negotiate and agree upon when engaging in data sharing. Therefore, the more participants there are, the more options to share data a participant will experience. Thresholds for data sharing are reduced, and costs for data providers and data consumers for engaging into data sharing are reduced.

Data consumers and data users are referred to as “adhering parties,” as they bind themselves to adhering to the iSHARE rules and regulations. The parties offering the technical services to actually run the network are referred to as “certified parties.” The iSHARE Foundation and its future satellites certify them.

iSHARE only becomes a solution when it is integrated in an IT system of a data consumer and data provider. That IT system can be self-built by data providers and data consumers, but often, this IT system will come from a specialized (cloud) provider. In addition, iSHARE can serve in complement with existing identity and access management solution, offering additional security and legal trust.

4.2 Connecting Legal Entities to Data

Next to providing an IAM protocol for data sharing APIs, iSHARE also binds the data point to a specific legal identity through its identifier. The identities used in iSHARE are grounded in eIDAS and linked to local, certified, and legal business registries, such as tax identifiers, legal entity identifiers, or Chamber of Commerce. This connection makes data sharing a legal transaction and therefore enforceable through legal means. The iSHARE digital trail in combination with the underlying contracts can serve as proof of data sharing in case of an incident or breach.

4.3 iSHARE Roles and the IDS Reference Architecture

iSHARE fits in the IDS RAM architecture as trust solution. The roles within iSHARE are similar to the ones in the IDS RAM as both revolve around data consumers, data providers, and their technical representation thereof. Figure 32.4 shows the role model of ISHARE.

Fig. 32.4
figure 4

iSHARE role model (Source: iSHARE Foundation)

Full size image

The roles are non-exclusive, except for the directory of participants. The distributed and federated directory, which is executed by the satellites of data spaces, holds the metadata of trust actors within the network. On a transaction basis, this list can be consulted via an API.

The non-exclusivity exclusivity of roles means that multiple parties can perform roles in competition with each other. This ensures the level playing field.

Next to the role of “data consumer” (represented by service consumer) and “data provider” (represented by service provider), we see the “identity provider” and the “authorization registry.” The legal identity of the actor comes through the identity provider, which is in practice existing provider of login credentials and certificates. The authorization registry stores the consent of every data transaction. Data providers have the option to provide for their own authorization registry or to outsource this to a specialized third-party provider conforming to the iSHARE rulebook.

The exclusive role of “directory” is to keep track of all actors in the network by storing their digital certificate credentials. Every data transaction can be checked against the validity of the actor in the registry. Noncompliant actors are not in the directory or can be taken out of the directory. In technical terms, the directory is a set of APIs, which actors use in their operations of data sharing. This role is comparable with the DAPS within the IDS RAM, although DAPS stores more attributes of actors than the iSHARE registry.

Figure 32.5 shows where iSHARE fits in the IDS RAM role model.

Fig. 32.5
figure 5

iSHARE within the IDS architecture (Source: iSHARE Foundation, International Data Spaces Association)

Full size image

iSHARE is drawn in as an option for trust provisioning and IAM (Identity Access Management). As such, it can be seen as “basic level data sovereignty,” where data sovereignty is mainly enforced via legal means, based on the digital trace of data sharing and consents. The decision of using a lighter data sovereignty solution or a more ruggedized one via edge computing in connectors depends fully in the risk analysis of the particular use case.

5 Practical Example: Data Sharing Along the Chain

In practice, iSHARE is a crucial component for data sovereignty, as it is now possible to grant access to information on a very granular level. Access to one or more data points can be given by the data rights holder (also referred to as “entitled party”), under very specific conditions such as time, event status, and identifiers, all linked to legal entities.

Data hubs are very common along all sorts of industrial, logistics, financial, and healthcare processes. These are collections of data about processes, which are under the control of the hub owner. The data rights holder has limited control over his data, e.g., for reuse further down the physical chain.

iSHARE enables data hubs to offer data sovereignty functionality to their customers, which typically are the data rights holders. With this additional service, data rights holders are able to grant access to third parties to this data, by generating and distributing API authorization keys to specific data with specific purpose and conditions attached to this. In this section, we describe three cases of data hubs.

5.1 Faster Inland Dispatch of Sea Freight

This data sovereignty can very well be illustrated with the case of European Container Terminal (ECT), part of the worldwide Hutchinson Ports company. In this use case, ECT was able to improve data security by using iSHARE for authorizing the pick-up of containers. This is an alternative for the standing practice using a PIN code, which is shared on a need-to-know basis. This is not very secure, as the ownership of such PIN code is very easy to change via messaging, calling, and post-it notes on computer screens.

The handling of inbound containers involves many actors. Think of customers, shippers, ship owners, forwarders, importers, inspections, and transporters. One large container vessel contains more than 15,000 40-foot containers. Unloading one ship leads to a lot of physical handling of containers by road freight, rail, and barge for transporting the container to the next handler in the physical chain, somewhere in Europe (hinterland).

By using iSHARE, the shipper (importing the goods) can receive data about the shipment earlier: instead of being notified once the container is unloaded, the shipper can receive the expected unloading moment in advance, because the sophisticated authorization mechanism of iSHARE facilitates legally sound consent. The carrier can then provide the information to the right shipper. Once this importing shipper has this information, his transporter is sent to pick up the container, also through a proper delegation of rights. So authorizations can also be delegated in iSHARE.

All the authorizations are temporarily, specific for the goal, limited to the need-know part of the information, and legally bound to a certain legal entity and its employees. Data is sovereign in the sense that the data rights holder is in control of granting the authorization. In logistics, the data rights holder (entitled party) may vary during the physical transport. Therefore, delegation of rights is a crucial functionality.

5.2 Faster Information for the Road Authority in Case of Truck Accidents

Another example is a data hub, which provides information about trucks and their loads at a certain moment in time. This information is important for the public road authority (in The Netherlands “Rijkswaterstaat”), who needs this information in case of a road accident where trucks containing hazardous information are involved.Footnote 4 In case of a road accident, cameras of road authority read out the license plates of the involved truck.

This identifier collects all relevant information from various sources, including the on-board trip computer and the e-CMR. The road authority has received the proper and standing authorization from the transporters and shippers, such that this information on the cargo is instantly available. With this information, the road authority can better request and coordinate help from police, fire department, and (road and air) medical support. All the authorizations and delegations thereof are achieved using iSHARE.

5.3 Inland Container Terminal Sharing Data Down Stream

The last example (depicted in Fig. 32.6) is about an inland container terminal. Often a container is composed of freight of several importers. The freight forwarder, in collaboration with the inland terminal, would be able to share data about specific freight directly from the inland terminal to the end receiver of a particular freight, even if there are other transporting parties still be involved later to move the goods to the end receiver. The advantage is a better supply chain visibility for the end receiver, allowing them to better anticipate their production or service process. The inland terminal can provide new data services to downstream actors who would benefit from this information.

Fig. 32.6
figure 6

iSHARE for inbound sea freight (Source: iSHARE Foundation)

Full size image

6 Conclusions

In the above, we have proposed practical approaches to data spaces. This starts with thinking in terms of functionality for users, in this case the data consumer and the data provider. In addition, the ease of doing business should be optimal, which means that the “data space” of data consumer and data provider needs to be covering most existing and potential data exchange situations for its users.

Contextual risk analysis for users is another essential approach when realizing data spaces. Each end of the risk spectrum requires different implementations. Data sharing use cases should be selected on this aspect. The data spaces architecture accommodates both ends of the spectrum. The use cases by iSHARE illustrate the possibilities in real-life situation.