1 Introduction

Today’s data-intensive business is driven forward by continuously exchanging critical and sensitive data between business partners. Data is typically secured by access control mechanisms, which means that data can be used (e.g., altered, copied, disseminated) without further restrictions after access to the data has been granted. However, controlling only access to data is not sufficient to establish a trustworthy and secure data economy and to realize innovative business models.

Therefore, the International Data Spaces (IDS) establish a virtual data space, where businesses can exchange and exploit the potential of data in a trustworthy and secure manner. Data sovereignty is a key success factor to establish trust between all involved business partners for implementing data-driven business. Data sovereignty provides data owners full control over their data, which includes the (restricted) usage of their data by data consumers [1]. Hence, access control is extended by mechanisms to control the usage of data (i.e., data usage control) after access is granted.

We differentiate between intrinsic and extrinsic motivations to implement data sovereignty. On the one hand, organizations realized that more and more businesses are spurred by data. Hence, their own data gets more valuable and must be protected to prevent misuse. This also includes the protection of their intellectual property. Protecting their data by completely locking it is not a solution as it disables business performance. Therefore, organizations have an intrinsic motivation to implement data sovereignty to benefit from data-driven business while keeping control over their own data. On the other hand, domain requirements, standards, rules, and legal obligations constrain organizations in their possibilities to use their data. Above all, data protection regulations such as the European Union General Data Protection Regulation (EU-GDPR) [2] must be mentioned here as its implementation is often difficult and data protection incidents can be very costly. We call this extrinsic motivation, because it is induced by external factors.

We structure the remainder of the document as follows. Section 8.2 presents the general concept of data usage control and explains the difference to access control and its relation to other concepts. We address policy specification, i.e., the specification of usage control rules, in Sect. 8.3, followed by technologies to implement data sovereignty. In Sect. 8.4, we briefly conclude with a discussion about future expansion stages for data sovereignty.

2 Usage Control

Usage control is an extension to traditional access control (see Fig. 8.1). It is about the specification and enforcement of restrictions regulating what must (not) happen to data. Thus, usage control is concerned with requirements that pertain to data processing (obligations), rather than data access (provisions). Usage control is relevant in the context of intellectual property protection, compliance with regulations, and digital rights management.

Fig. 8.1
figure 1

Usage control extends access control

Full size image

In this section, we describe access control (as the basis) and usage control, followed by subsections describing the different building blocks to implement data usage control.

2.1 Access Control

In general, access control restricts access to resources. The term authorization is the process of granting permission to resources. Several access control models exist, such as Discretionary Access Control (DAC), Mandatory Access Control (MAC) [3], Role-Based Access Control (RBAC) [4], Attribute-Based Access Control (ABAC) [5], etc. Although such a plethora of access control models exists, RBAC and ABAC are most commonly used.

We use the XACML (eXtensible Access Control Markup Language) Standard [6] to introduce commonly used terms in the field of access control. XACML is a policy language to express ABAC rules. The main building blocks of the language are subject, action, resource, and environment. The subject describes who is accessing a data asset (e.g., a user). The action describes what the subject wants to perform on the data asset (e.g., read or write). The resource describes the data asset. Finally, the environment specifies the context (e.g., time, location).

Figure 8.2 illustrates the data-flow model of XACML and the main actors or components to implement it: Policy Enforcement Point (PEP), Policy Decision Point (PDP), Policy Information Point (PIP), and Policy Administration Point (PAP).

Fig. 8.2
figure 2

XACML data flow illustration [6], © 2013, OASIS Standard

Full size image

Access control in the IDS is a resource-centric regulation of access requests from subjects (i.e., IDS participants) to resources (i.e., data services). Resource owners define attribute-based access control policies for their endpoints and define the attribute values a subject must attest in order to grant access to the resource. These attributes may include:

  • Specific identity of a connector (only access requests from a specific connector will be granted)

  • Connector attributes (only access requests from a connector that possesses specific attributes will be granted)

  • Security profile requirements (only access requests from a connector that fulfills specific security feature requirements will be granted, e.g., having a TPM ≥ 1.2 and doing application isolation)

The IDS security architecture does not dictate a specific access control enforcement language or implementation.

2.2 Usage Control

In contrast to access control, where access to specific resources (e.g., a data service) is restricted, the IDS architecture additionally supports data-centric usage control. The overall goal is to enforce usage restrictions for data after access has been granted. Therefore, the purpose of usage control is to attach policies to data that specify their usage restrictions and to continuously control the way how data is processed, aggregated, or disseminated within the IDS. This data-centric perspective allows data owners to specify how their data is used, rather than only controlling access to the data services.

At runtime, the usage control enforcement prevents IDS connectors from treating data in an undesired way, for example, by disseminating personal data to public endpoints. Thus, usage control empowers IDS participants to ensure they are not building an architecture that violates data sovereignty. In addition, usage control mechanisms monitor data flows, which can be used as an audit mechanism to create evidence of a compliant data usage.

In the following examples, we illustrate data sovereignty requirements that cannot be achieved using traditional access control, but rather require data-centric usage control:

  • Data Secrecy: Classified data can only be forwarded to nodes and services with the respective clearance or security level.

  • Data Integrity: Critical data can only be modified by trusted nodes or services.

  • Time to Live: Data must be deleted or altered after a given period of time.

  • Anonymization: (Personal) Data has to be anonymized before use, for instance by aggregation or replacement.

  • Separation of Duty: Data sets, for instance from competitive organizations, must be kept separated (e.g., no joining operation or processing within the same service).

  • Usage Scope and Purpose: Data can only be used within trusted nodes or services. In addition, data can only be used for specific usage purposes.

  • Context Awareness: Data can only be used by meeting specific contextual conditions (e.g., only within company premises or only within a specific geolocation).

It is important to note that the purpose of usage control is to allow the specification of such constraints and enforcing them in the running system. It is a prerequisite to usage control that the enforcement mechanism itself is trusted, i.e., usage control itself does not establish trust in an endpoint. It rather builds upon an existing trust relationship and facilitates the enforcement of legal or technical requirements as well as data privacy regulations.

2.3 Usage Control Components and Communication Flow

For enforcing usage restrictions, data flows are monitored and intercepted by control points (i.e., Policy Enforcement Point, PEP), as illustrated in Fig. 8.3. Information about the intercepted data flows is sent from the PEP component to the decision engine (i.e., Policy Decision Point, PDP) for allowing or denying the data flow. The decision from the PDP may include instructions to modify the data of an allowed data flow.

Fig. 8.3
figure 3

Usage control communication flow (simple)

Full size image

The PDP takes the responsibility to answer incoming permission requests for data flows from a PEP. The decision from the PDP is based on the evaluation of the deployed usage restrictions (i.e., policy evaluation). The PDP decisions are received by the PEP component, which also encapsulates the enforcement of a PDP decision.

Figure 8.3 depicts the communication flow between PEP and PDP.

The policy evaluation may depend on information that is not directly present in the intercepted data flow. Such information may be contextual information such as the geolocation of the organization or membership information from a directory service. A Policy Information Point (PIP) takes responsibility to provide missing information for the policy evaluation during the policy evaluation phase in the PDP. It offers a standardized interface to the PDP and encapsulates the necessary logic to perform information retrieval.

Finally, there is the concept of Policy Execution Point (PXP). A PXP is used to perform additional actions based on the deployed policies. Examples for such additional actions are the sending of an email when data is used or sending a log message to a third-party logging system. Figure 8.4 illustrates an exemplary sequence of all processing steps (incl. optional PIP and PXP steps) to enforce usage control restrictions on a data flow.

Fig. 8.4
figure 4

Usage control communication flow (extended)

Full size image

In the following, we describe all processing steps in more detail: The PEP intercepts the data flow in the target system (1). Data is extracted from the data flow and prepared as a decision request for the PDP. The PEP requests a decision from the PDP (2). By receiving the decision request, the PDP starts its internal policy evaluation. In doing so, the PDP processes all deployed policies to draw a decision. Depending on the policy evaluation, the PDP may need additional information and invokes a PIP (3). The PIP processes the evaluation request, which may result in an interaction with further external systems. After information retrieval, the PIP responds with a data object to the PDP including the requested information (4). The PDP further processes the policy evaluation. If it includes the execution of additional actions, the PDP invokes a PXP (5) including parameters to execute the action. The PXP processes the action and returns to the PDP whether the action succeeded or not (6). The steps to retrieve additional information from a PIP (i.e., (3) and (4)) or to perform an additional action with a PXP (i.e., (5) and (6)) can be done several times, depending on the policy. The final step of policy evaluation is the preparation of the authorization decision and sending it back to the PEP (7). The PEP receives the decision and denies or allows the data flow (8). For the allow case, the authorization decision may include additional information to modify the data in transit, which is then performed by the PEP. Detailed information about policy specification and the resulting behavior during runtime can be found for the MY DATA Control Technologies at their developer website [7].

2.4 Specification, Management, and Negotiation

Another important aspect of usage control is the specification and management of usage restrictions. Data providers express the usage restrictions for their data in a more or less formal way. For a technical enforcement, the result of a policy specification must produce a machine-readable output. In order to simplify the specification process for the end-user, a Policy Administration Point (PAP) is used as an entry point for specification of usage policies, usually providing a user-friendly graphical interface.

A Policy Management Point (PMP) administers the usage restrictions. Hence, the component is concerned with the policy life cycle. This includes the instantiation, negotiation, deployment, and revocation of usage restrictions, as well as conflict detection between policies and, if necessary, the resolution of the conflicts. PAP and PMP completes the usage control communication flow as presented in Fig. 8.5.

Fig. 8.5
figure 5

Usage control communication flow (complete)

Full size image

We differentiate two ways to locate and transfer usage restrictions. First, usage restrictions can be attached to the data, which is also called sticky policy [8]. Sticky policies are one way to cope with the distribution of usage restrictions. In this approach, machine-readable usage restrictions (policies) stick to data when they are exchanged. There are different realization possibilities. Usually, data is encrypted and can only be decrypted when adherence to usage restrictions is guaranteed. The main advantage, the distribution of usage restriction, comes free of charge as it is transferred with the data. However, it is also the main disadvantage as data and policy are transferred before adherence to the policy can be guaranteed. Moreover, usage restrictions cannot be altered without revoking all instances of the data/policy tuple.

Second, policies can be stored independently from the data in a central component. For instance, policies are directly stored in the PMP or in a dedicated storage such as a Policy Retrieval/Repository Point (PRP). In this case, the management component is responsible to exchange the usage restrictions between different systems. Hence, we have the disadvantage to cope with the distribution of usage restriction, but the advantage to transfer data only, if the usage restrictions are fulfilled by the target system.

The management of usage policies becomes especially important when exchanging data across system boundaries. Every time data crosses system boundaries, the target system must be prepared for the protection of incoming data. Therefore, the corresponding policies need to be negotiated, instantiated, and deployed. Hence, policy negotiation is also part of policy management. As enforcement mechanisms may work differently in various technical environments, policies must also be instantiated on the target system. And finally, before establishing data exchange, the policies have to be deployed, i.e., activated, on the PDP.

2.5 Related Concepts

In addition to access control, there are more related concepts to cope with data sovereignty challenges. In order to make the concept of usage control more clear, we present related concepts to usage control such as Data Leak or Loss Prevention (DLP), Digital Rights Management (DRM), User Managed Access (UAM), and Windows Information Protection (WIP). These concepts are no replacement for usage control, but rather supplementary technologies to support data sovereignty.

2.5.1 Data Leak/Loss Prevention

Data Leak/Loss Prevention (DLP) technologies detect and prevent potential data breaches by monitoring sensitive data. Commonly used are Endpoint DLP solutions that run on the client’s operating system (e.g., as extension or feature of a security suite). In addition, there are also DLP solutions available that are monitoring the network or access to central storage devices.

Hence, the solutions are rather preventing unintended data leakages, but do not control the adherence to usage restrictions during data usage.

2.5.2 Digital Rights Management

The term Digital Rights Management (DRM) is frequently used in the area of protecting digital content from unintended use, modification, and distribution. Different DRM technologies exist to protect multimedia content such as movies (e.g., DVD, Blu-ray), music (e.g., audio CDs, Internet music), television, or E-books. In addition, there are DRM technologies to protect digital documents (e.g., MS Word, PDF) within enterprises. This kind of DRM is also known as enterprise rights management (ERM) or information rights management (IRM) and aims to control access and use of corporate documents.

DRM is closely related to data usage control, especially when focusing on enforcing usage restrictions on clients. However, usage control can be implemented at the client as well as at infrastructure components such as the IDS Connector. Hence, it is more flexible and extensible.

2.5.3 User Managed Access

The purpose of User Managed Access (UMA) is to empower the resource owner to control the authorization of data sharing. It is often used to protect resources between online services on behalf of the owner. OAuth-based access management systems are representations of UMA [9]. Several open-source implementations exist that follow the UMA core protocol [10].

UMA and related solutions such as OAuth focus on the authorization and the access, but rather neglect the usage. Usage control explicitly focuses on the usage, rather than access.

2.5.4 Windows Information Protection

Microsoft introduced several technologies to establish a comprehensive information protection in their operating system and software such as Microsoft Office (e.g., BitLocker, Windows Information Protection (WIP), Office 365, and Azure Information Protection (AIP)) [11]. WIP, for instance, is an integral part of Windows 10. The goals of the WIP are to protect data on its own devices, to separate private and business data (data separation), to prevent unauthorized access and use (data leakage protection), and to protect data when shared. WIP-protected documents can only be used in WIP-compliant apps. For example, WIP prevents pasting sensitive information (e.g., by using ctrl+c and ctrl+v) to non-WIP-compliant apps.

WIP and AIP are very closely related to usage control concepts, but with the disadvantage of a technology and vendor lock-in. However, it can complement existing usage control solutions. Moreover, usage control is more flexible and extensible.

3 Usage Control in the IDS

We have two activity streams within the IDS to implement data usage control: First, a policy language to express data usage restrictions. The policy language is descriptive and technology independent and initially based on the Open Digital Rights Language (ODRL). To express usage restrictions within the IDS, we developed several predefined policy classes that express the most common data usage restrictions from our IDS use cases. Second, we developed different usage control technologies to enforce these usage restrictions at a technical level. We differentiate between proactive and retrospective technologies. The proactive technologies enforce provisions and obligations across system boundaries during runtime. These technologies control the data usages during runtime and ensure compliant usage with respect to usage restrictions (i.e., prevent data misuse). The retrospective technologies are rather monitoring and recording technologies, but do not prevent or actively control any data usages. Therefore, it does not prevent undesired data usages and is called detective enforcement.

In the following section, we first address the usage control policies, the IDS policy classes, and necessary steps from the specification of usage restrictions to their negotiation between data provider and data consumer. Second, we present the different technologies to enforce usage control (preventive and detective enforcement).

3.1 Usage Control Policies

The IDS include several use cases such as IDS Connector, Digital Supply Chain, Smart Urban Mobility, Intelligent Sensor, Interconnected ESN, and many more [12, 13]. These use cases lead to a variety of usage restrictions and finally to a set of formal policies. The policies were categorized into a set of classes in order to define the previously mentioned templates. They are building blocks for expressing data sovereignty requirements with a common understanding such as duration-restricted or purpose-restricted data usage. Hence, data provider and data consumer have a common understanding of usage restriction that applies to the exchanged data. In addition, the policy classes are expressed in the IDS contract as IDS policy (an ODRL-like language) as part of the IDS Information Model and can be transformed to machine-readable policies that can be technically enforced by usage control technologies such as the MY DATA Control Technologies [7]. We call the technology-independent policies “Specification Level Policies” (SLP) and the technology-dependent policies “Implementation Level Policies” (ILP) [14]. SLPs directly refer to the aforementioned policy classes. ILPs have a direct mapping to the individual usage control technologies for technical enforcement.

As a starting point, the data providers of the IDS need to specify their data usage restrictions as policies. A policy editor or PAP can support the data provider in the policy specification process. It offers various pre-filled templates that refer to classes of data usage control policies. The data providers can choose a template, fill it with the required information, and receive the corresponding IDS policy, which they can use for a usage control technology to enforce the policy in the target system and respectively protect their data.

The policy transformation can be a part of the policy editor (i.e., PAP) or part of the policy instantiation process, usually supported by a PMP. The latter is the most common case as the target system and environment of the data consumer are usually not known during the specification of usage restriction by the data provider.

We will have a look at the policy classes in the next subsection, followed by a subsection presenting the policy negotiation. Finally, we will present the entire process from policy specification by the data provider, negotiation between data provider and data consumer, the transformation of the SLP to ILP, and finally the deployment of ILPs at the data consumer.

3.1.1 Policy Classes

A data usage control policy, in general, may provide permission to an IDS data consumer to operate specified action(s) over a data asset or prohibit the operation of that specified action(s). As well, a policy may require the operation of a specified action under specific circumstances. Providing permission or prohibition of an operation is extended to a variety of actions. A policy can be specified to provide permission to use the data. The action of using the data can cover various operations over that piece of data such as displaying it, printing it, making calculations over it, and so on. In addition, a policy may address only a particular fine-grained action. For example, a policy that permits reading data allows the act of obtaining the data asset from the data source without further restrictions; however, the action of printing data is not permitted.

The usage control technologies offer whitelisting, blacklisting, or both approaches to support data sovereignty and to protect the data. In a whitelisting approach, any data usage is denied unless there is a policy allowing the usage. Contrary to a blacklisting approach, any data usage is allowed unless there is a policy denying the usage.

Thus, it is possible to specify policies that either allow or deny the data usage. Obviously, there might be conflicts among the specified policies. Regardless of the whitelisting or blacklisting approach, a conflict detection and resolution strategy are needed. For example, while a policy provides permission to use the data, another policy might deny the data consumer to print the data. A conflict detection method must realize that the action of printing the data has been permitted once; likewise, it has been prohibited. A conflict resolution method in the context of IDS might always decide to prohibit the action in a case of a conflict; however, the exact definitions of the data usage actions and the concepts of conflict detection and resolution are still evolving.

The IDS supports 21 predefined policy classes such as purpose or role-restricted data usage policies. IDS association members can access the policy classes via the IDSA JIVE [15]. In addition, the IDS Lab offers a PAP to create IDS policies following the aforementioned IDS policy classes. In addition, it includes the transformation from an IDS policy to technology-dependent MY DATA policy.

3.1.2 Policy Negotiation

Now that we explained the basics of policy classes, we would like to introduce the concept of policy negotiation. It is a common activity in business to negotiate a (nontechnical) contract between provider and consumer. The same holds for data-driven business in the IDS, but in the end the policy shall be enforced technically. Hence, data provider and data consumer have to negotiate a data usage contract to establish their data economy.

A negotiation process takes care of two aspects: the technical mapping of usage restrictions toward the internal system landscape and the potential bargaining of the usage conditions. The mapping itself targets the challenge of instantiating the stated requirements to decidable features according to the deployed systems. For instance, the data provider is usually not supposed to know the types and variants of the IT architecture of the data consumer. Furthermore, neither the data provider nor the data consumer is willing to reveal more information about their local settings than necessary. However, any automatically enforceable restriction must state the exact parameters which, through a binary decision process, deterministically conclude whether any possible action is allowed or not.

The second aspect of a negotiation step is the bargaining of the actual conditions. When the usage restrictions are specified, the requirements and preferences of data consumers are usually unknown. Following a simple accept or reject pattern drastically reduces the number of potential data consumers and thereby reduces business opportunities. In addition, fixing obligations without knowing the context and implementation details of the potential usage is not reasonable as the information gap between specification and implementation time leads to unforeseen mismatches and conflicts. Therefore, an interested data consumer should be enabled to respond to a usage offering with a slightly adjusted counter offer. Still, it must be always in the authority of the data sovereign to accept or reject the request, or even make an additional offer regarding the details of the received counter-offer.

In Fig. 8.6, we depict the entire negotiation process. We start with the specification of the IDS policy by the data provider using a PAP equipped with the templates. The output of the first processing step is an IDS policy offer. After the specification, we have to negotiate between data provider and data consumer. As part of the negotiation, the data consumer also uses a PAP to specify his or her IDS policy request. If offer and request match, the negotiation terminates, and we will have an IDS policy agreement. The IDS policy agreement is still a technology-independent policy (i.e., SLP) that has to be transformed and instantiated at the data consumer. The transformation and instantiation are usually supported by a PAP or PMP. The result is a technology-dependent policy (i.e., ILP) such as a MY DATA policy (see the next section). The technology-dependent policy can then directly be deployed on a target system at the data consumer to enforce data usage control restrictions.

Fig. 8.6
figure 6

Policy specification, negotiation, and transformation

Full size image

For more details, we refer the interested reader to the position paper “Usage Control in the International Data Spaces” [16].

3.2 Usage Control Technologies

In this section, we briefly present the integration concept for usage control in the IDS and the different technologies.

3.2.1 Integration Concept

In the IDS, all communication between data provider and data consumer is handled by connectors. A data provider connects a data source with the connector that delivers the data to the data consumer connector that in turn connects to a data sink. Data source and data sink can be any kind of system or application. In order to add usage control to this data flow, we integrate control points (i.e., PEPs) to intercept the data flow. At the data provider, we are using a routing pattern, and at the data consumer, we are using an interceptor pattern. In doing so, we ensure to hook into every data flow at the data consumer and apply our data usage control policies. Figure 8.7 illustrates the entire communication flow.

Fig. 8.7
figure 7

Usage control integration

Full size image

3.2.2 MY DATA Control Technologies

MY DATA Control Technologies (MY DATA for short) is a technical implementation of data sovereignty, which represents an essential component for informational self-determination. It is a technical implementation of the conceptual IND2UCE framework for data usage control developed by Fraunhofer IESE.

In general, MY DATA implements data sovereignty by monitoring or intercepting security-relevant data flows. This enables fine-grained masking and filtering of data flows in order to make them anonymous, for example. Compared to classical access control systems, MY DATA can additionally enforce partial filtering and masking of data, context and situation restrictions, as well as restrictions on the purpose of use.

MY DATA offers a decision service (PDP), a management service including a policy editor (PMP and PDP), and an Open Source Software Development Kit for creating control points (PEPs), execution points (PXPs), and information points (PIPs).

MY DATA is integrated in the IDS Connector as part of the Usage Control Container (as illustrated in Fig. 8.7). However, the MY DATA Open Source Software Development Kit allows easy integration in any system.

3.3 Logic-Based Usage Control (LUCON)

LUCON (Logic-Based Usage Control) is a policy language for controlling data flows between endpoints. The IDS Trusted Connector uses Apache Camel to route messages between services. LUCON controls how these messages are processed and passed around between services. The LUCON policy language comes with an Eclipse plugin for syntax highlighting, code completion, and compilation into a format that is understood by the LUCON PDP within the Connector.

3.3.1 Degree (D°)

While LUCON and MY DATA aim at providing usage control for existing applications and workflows, D° takes another approach. D° is a domain-specific language (DSL) for the development of data processing applications (so-called Data Apps) and takes usage control into account from the beginning of the development. D° uses Java as host language. Through the use of Model-Driven Software Development (MDSD), Data Apps which are developed with D° are transformed into Java applications which are finally compiled into executable applications.

D° is a programming language and runtime environment that orchestrates, isolates, and controls all running data apps. The fulfillment of the IDS policies is ensured by directly integrating them during app compilation into executables.

3.3.2 Data Provenance Tracking

While distributed data usage control is concerned with the enforcement of provisions and obligations when exchanging data across system boundaries, the focus of data provenance tracking is on transparency and accountability. Hence, data provenance tracking is closely related, but also complementary to distributed data usage control.

Instead of using PEPs in a proactive manner such as MY DATA, data provenance tracking uses PEPs to passively monitor the data flow. More precisely, it observes, interprets, and logs data transactions and usages for retrospective examination. A data provenance tracking infrastructure can be built upon the same PEPs as distributed data usage control. Furthermore, data provenance tracking does not require a policy specification language, but rather a specification of how observed actions are to be interpreted in terms of data transactions or data usage.

From a technical perspective, data provenance tracking introduces local components to store data flow tracking information (i.e., a provenance storage) offered by PEPs. The provenance storage regularly updates central components (i.e., the provenance collection). The central component can then be equipped with a provenance dashboard to illustrate data flows in human-understandable manner. In addition, we can perform queries on the provenance data for auditing or reporting purposes.

4 Conclusion

Data-driven business models are based on sharing and exchanging data. Data sovereignty is a key success factor for data-driven business. In this chapter, we presented how the IDS use usage control concepts and technologies to tackle data sovereignty challenges. The main building blocks are the specification of usage restrictions as IDS policies and their adherence to technical enforcement. Although a lot of work has already been done, it will take a while until digital ecosystems will fully exploit the power of data usage control in order to realize a comprehensive and complete data sovereignty. It is rather a transition process that includes organizational, technical, and legal issues.

In addition, data usage control has to be integrated into and implemented for different positions of the entire digital ecosystem systems to ultimately enable a comprehensive control of all data usages. We call this the usage control onion, illustrated in Fig. 8.8. The inner part of the onion represents the starting point for usage control; it is the IDS Connector at the data provider. Every additional onion shell represents an expansion stage for the implementation of data usage control such as integrating usage control technologies into applications or client systems to enable a comprehensive control. There are different architecture options to integrate and implement data usage control [17], resulting in a tradeoff between costs and control capabilities.

Fig. 8.8
figure 8

Illustration of the usage control onion

Full size image