REFERENCE

ARCHITECTURE
MODEL

Version 3.0 April 2019

REFERENCE
ARCHITECTURE
MODEL

Version 3.0 April 2019

 AUTHORS & CONTRIBUTORS //

AUTHORS & CONTRIBUTORS

Prof. Dr.-Ing. Boris Otto, Fraunhofer ISST
Sebastian Steinbuß, International Data Spaces Association
Andreas Teuscher, SICK
Dr.-Ing. Steffen Lohmann, Fraunhofer IAIS

Prof. Dr. Sören Auer, L3S Research Center Jacob Köhler, Deloitte
Sebastian Bader, Fraunhofer IAIS Dr. Christoph Lange, Fraunhofer IAIS
Dr. Harrie Bastiaansen, TNO Dorothea Langer, Deloitte
Hannes Bauer, orbiter Jörg Langkau, nicos
Dr.-Ing. Pascal Birnstil, Fraunhofer IOSB Dominik Lis, Fraunhofer ISST
Martin Böhmer, Fraunhofer IML Sven Löffler, T-Systems
Dr. Jürgen Bohn, Schaeffler Dr. Ulrich Löwen, Siemens
Gernot Böge, FIWARE Foundation Dr. Christian Mader, Fraunhofer IAIS
Uwe Brettner, nicos AG Bernhard Müller, SICK
Gerd Brost, Fraunhofer AISEC Nadja Menz, Fraunhofer FOKUS
Juan Ceballos, Deutsche Telekom Christoph Mertens, International Data Spaces Association
Dr.-Ing. Jan Cirullies, Fraunhofer ISST Andreas Müller, Schaeffler
Constantin Ciureanu, T-Systems Lars Nagel, International Data Spaces Association
Eva Corsi, Boehringer Ingelheim Dr. Ralf Nagel, Fraunhofer ISST
Simon Dalmolen, TNO Harri Nieminen, Fastems
Søren Danielsen, GateHouse Logistics Thomas Reitelbach, Bosch
Alexander Duisberg, Bird & Bird Aleksei Resetko, PricewaterhouseCoopers
Andreas Eitel, Fraunhofer IESE Daniel Pakkala, VTT Technical Research Centre of Finland
Thilo Ernst, Fraunhofer FOKUS Florian Patzer, Fraunhofer IOSB
Fabiana Fournier, IBM Heinrich Pettenpohl, Fraunhofer ISST
Marquart Franz, Siemens AG René Pietzsch, eccenca
Dr. Sandra Geisler, Fraunhofer FIT Jaroslav Pullmann, Fraunhofer FIT
Joshua Gelhaar, Fraunhofer ISST Matthijs Punter, TNO
Roland Gude, Fraunhofer IAIS Dr. Christoph Quix, Fraunhofer FIT
Dr.-Ing. Christian Haas, Fraunhofer IOSB Aleksei Resetko, PwC
Jürgen Heiles, Siemens Dr. Dominik Rohrmus, Siemens
Burkhard Heisen, cybus Lena Romer, Boehringer Ingelheim
Juanjo Hierro, FIWARE Jörg Sandlöhken, REWE Systems
Joachim Hoernle, ATOS Patrick Schöwe, agma data
Manuel Huber, Fraunhofer AISEC Daniel Schulz, Fraunhofer IAIS
Christian Jung, Fraunhofer IESE Dr. Julian Schütte, Fraunhofer AISEC
Prof. Dr. Jan Jürjens, Fraunhofer ISST Dr. Karsten Schweichhart, Deutsche Telekom
Dr. Anna Kasprzik, L3S Research Center Inna Skarbowski, IBM
Dr. Markus Ketterl, msg systems Prof. Egbert-Jan Sol, TNO
Judith Koetzsch, Rittal

004 //
 IMPRINT & CONTRIBUTING RESEARCH PROJECTS //

Peter Sorowka, Cybus PUBLISHER

Prof. Dr.-Ing. Gernot Spiegelberg, Siemens International Data Spaces Association
Markus Spiekermann, Fraunhofer ISST Anna-Louisa-Karsch-Str. 2
Christian Spohn, ATOS 10178 Berlin
Gerrit Stöhr, GESIS Germany
Erwin Tanger, ATOS
Dr. Michael Theß, Signal Cruncher EDITOR
Dr. Sebastian Tramp, eccenca Sebastian Steinbuss, International Data Spaces Association
Dr. Mona Wappler, thyssenkrupp
Ann-Christin Weiergräber, Uniklinik RWTH Aachen COPYRIGHT
Dr. Sven Wenzel, Fraunhofer ISST International Data Spaces Association,
Oliver Wolff, Advaneo Dortmund 2019
Heike Wörner, DB Schenker

CONTRIBUTING RESEARCH PROJECTS

Industrial Data Space, Industrial Data Space + BOOST4.0 AMable

https://www.fraunhofer.de/en/research/ www.boost40.eu www.amable.eu
lighthouse-projects-fraunhofer-initiatives/
industrial-data-space.html

MIDIH Fraunhofer-Gesellschaft DEMAND

www.midih.eu www.fraunhofer.de www.demand-projekt.de

005 //
TABLE OF CONTENTS

1 INTRODUCTION 008

1.1 GOALS OF THE INTERNATIONAL DATA SPACES ................................................................................... 009
1.2 PURPOSE AND STRUCTURE OF THE REFERENCE ARCHITECTURE MODEL .......................................... 011

2 CONTEXT OF THE INTERNATIONAL DATA SPACES 012

2.1 DATA-DRIVEN BUSINESS ECOSYSTEMS AND THE SMART SERVICE WELT ............................................ 013
2.2 DATA SOVEREIGNTY AS A KEY CAPABILITY .......................................................................................... 014
2.3 DATA AS AN ECONOMIC GOOD............................................................................................................. 014
2.4 DATA EXCHANGE AND DATA SHARING ................................................................................................. 015
2.5 INDUSTRIAL CLOUD PLATFORMS ......................................................................................................... 016
2.6 BIG DATA AND ARTIFICIAL INTELLIGENCE .......................................................................................... 016
2.7 THE INTERNET OF THINGS AND THE INDUSTRIAL INTERNET OF THINGS ........................................ 016
2.8 BLOCKCHAIN ......................................................................................................................................... 017
2.9 CONTRIBUTION OF THE INTERNATIONAL DATA SPACES TO INDUSTRY 4.0
AND THE DATA ECONOMY .................................................................................................................... 018

3 LAYERS OF THE REFERENCE ARCHITECTURE MODEL 020

3.1 BUSINESS LAYER .................................................................................................................................... 021
3.1.1  Roles in the International Data Spaces .................................................................................................. 021
3.1.2  Interaction of Roles ................................................................................................................................ 025
3.1.3  Digital Identities ..................................................................................................................................... 026
3.1.4  Usage Contracts ..................................................................................................................................... 028

3.2 FUNCTIONAL LAYER .............................................................................................................................. 029

3.2.1  Trust ....................................................................................................................................................... 029
3.2.2  Security and Data Sovereignty ............................................................................................................... 030
3.2.3  Ecosystem of Data .................................................................................................................................. 031
3.2.4  Standardized Interoperability ................................................................................................................ 031
3.2.5  Value Adding Apps ................................................................................................................................. 032
3.2.6  Data Markets .......................................................................................................................................... 032

3.3 PROCESS LAYER ..................................................................................................................................... 033

3.3.1  Onboarding ............................................................................................................................................ 033
3.3.2  Exchanging Data ..................................................................................................................................... 036
3.3.3  Publishing and Using Data Apps ............................................................................................................ 038

006 //
 TABLE OF CONTENTS //

3.4 INFORMATION LAYER ........................................................................................................................... 040

3.4.1  Scope ...................................................................................................................................................... 040
3.4.2  Model Representations .......................................................................................................................... 040
3.4.3  Conceptual Representation of a Digital Resource in the IDS .................................................................. 042
3.4.4  Vocabularies ........................................................................................................................................... 059
3.4.5  Data App Interfaces ............................................................................................................................... 060

3.5 SYSTEM LAYER ....................................................................................................................................... 061

3.5.1  Connector Architecture .......................................................................................................................... 062
3.5.2  Broker .................................................................................................................................................... 067
3.5.3  Data Apps and App Store ....................................................................................................................... 067

4 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL 068

4.1 SECURITY PERSPECTIVE ........................................................................................................................ 069
4.1.1  Security Aspects Addressed by the Different Layers of the IDS-RAM ..................................................... 069
4.1.2  General Security Principles .................................................................................................................... 070
4.1.3  Key Security Concepts ............................................................................................................................ 070

4.2 CERTIFICATION PERSPECTIVE .............................................................................................................. 094

4.2.1  Certification Aspects Addressed by the Different Layers of the IDS-RAM .............................................. 094
4.2.2  Certification Process .............................................................................................................................. 095
4.2.3  Certification of Participants and Core Components ............................................................................... 097

4.3 GOVERNANCE PERSPECTIVE ................................................................................................................. 098

4.3.1  Governance Aspects Addressed by the Different Layers of the IDS-RAM ............................................... 099
4.3.2  Data Governance .................................................................................................................................... 100
4.3.3  Data as an Economic Good .................................................................................................................... 104
4.3.4  Data Ownership ..................................................................................................................................... 104
4.3.5  Data Sovereignty .................................................................................................................................... 105
4.3.6  Data Quality ........................................................................................................................................... 105
4.3.7  Data Provenance..................................................................................................................................... 105

APPENDIX 106

A GLOSSARY .............................................................................................................................................. 107
B SECURITY PROFILES .............................................................................................................................. 111
C LIST OF FIGURES ................................................................................................................................... 116
D LIST OF TABLES ...................................................................................................................................... 118

007 //
KAPITEL // UNTERKAPITEL

INTRODUCTION 1

8 //
 INTRODUCTION // 1.1

THE INTERNATIONAL DATA SPACES (IDS) IS A VIRTUAL DATA SPACE LEVERAGING EXISTING STANDARDS AND
TECHNOLOGIES, AS WELL AS GOVERNANCE MODELS WELL-ACCEPTED IN THE DATA ECONOMY, TO FACILITATE SECURE
AND STANDARDIZED DATA EXCHANGE AND DATA LINKAGE IN A TRUSTED BUSINESS ECOSYSTEM. IT THEREBY
PROVIDES A BASIS FOR CREATING SMART-SERVICE SCENARIOS AND FACILITATING INNOVATIVE CROSS-COMPANY
BUSINESS PROCESSES, WHILE AT THE SAME TIME GUARANTEEING DATA SOVEREIGNTY FOR DATA OWNERS.

1.1 GOALS OF THE

INTERNATIONAL
DATA SPACES

Data sovereignty is a central aspect of the International Data form the operational IDS ecosystem. As each offering
Spaces. It can be defined as a natural person’s or corporate must comply with the International Data Spaces standard,
entity’s capability of being entirely self-determined with re- it must undergo a certification process. Therefore, the
gard to its data. The International Data Spaces initiative pro- market requires offerings from evaluation and certifica-
poses a Reference Architecture Model for this particular capa- tion facilities.
bility and related aspects, including requirements for secure
and trusted data exchange in business ecosystems. THE INTERNATIONAL DATA SPACES AIMS AT MEETING
Overall, there are three types of activities in which the work of THE FOLLOWING STRATEGIC REQUIREMENTS:
the International Data Spaces initiative can be grouped: 1) re-
search activities, 2) standardization activities, and 3) activities »» TRUST: Trust is the basis of the International Data Spac-
for the development of products and solutions for the market es. Each participant is evaluated and certified before being
(see Figure 1.1): granted access to the trusted business ecosystem.

1. Fraunhofer runs the Strategic Initiative Data Spaces as a »» SECURITY AND DATA SOVEREIGNTY: All components of
large internal research program aiming at the design and the International Data Spaces rely on state-of-the-art se-
continuous development of the core principles of the IDS curity measures. Apart from architectural specifications,
Reference Architecture Model (IDS-RAM). An increasing security is mainly ensured by the evaluation and certifi-
number of further research projects conducted by various cation of each technical component used in the Interna-
partners complement these activities. tional Data Spaces. In line with the central aspect of en-
suring data sovereignty, a data owner in the International
2. The International Data Spaces Association (IDSA), a Data Spaces attaches usage restriction information to their
non-profit organization, aims at promoting the IDS-RAM in data before it is transferred to a data consumer. To use the
order to establish an international standard. To achieve data, the data consumer must fully accept the data own-
this goal, the Association pools the requirements from var- er’s usage policy.
ious industries and provides use cases to test the results
gained from the model’s implementation. The standard is »» ECOSYSTEM OF DATA: The architecture of the Internation-
intended to materialize in the IDS-RAM itself, but also in al Data Spaces does not require central data storage ca-
defined methods for secure data exchange and data shar- pabilities. Instead, it pursues the idea of decentralization
ing facilitated by the IDS Connector, the central technical of data storage, which means that data physically remains
component of the International Data Spaces. To ensure with the respective data owner until it is transferred to a
the international ambition of the initiative, Regional Hubs trusted party. This approach requires a comprehensive de-
have been established in different countries. In addition, scription of each data source and the value and usability
the activities of the IDSA aim at supporting the adoption of of data for other companies, combined with the ability to
IDS concepts and technologies in the market. integrate domain-specific data vocabularies. In addition,
brokers in the ecosystem provide services for real-time
3. Actors in the market can make use of the International data search.
Data Spaces standard for providing software services and
technology to the market. These products and solutions

009 //
 INTRODUCTION // 1.1

Industrial Data Space – Reference Architecture Model


Industrial Data Space Activities

Commercial Software ⋅ Data Markets ⋅ Technology Development ⋅ Central

Market Service Offerings (e.g. Certification) ⋅ Roll-out and Scale-up Activities ⋅
Professional Services ⋅ Domain-specific (vertical) Implementations …

Reference Architecture Model Maintenance ⋅ Requirements Management ⋅

Non-Profit-Organization
 Standardization Activities ⋅ Specification and RfQ with regard to Central 

(IDSA) Services ⋅ Knowledge Transfer ⋅ Internationalization ⋅ Platform for 

Domain-Specific Activities …

Reference Architecture Model (initial version) ⋅ Prototype Implementation 


in Use-Cases ⋅ Basic Versions of IDS Components ⋅ Knowledge Transfer
Research (Research Delivery and Support Center) ⋅ Technology Innovation (Usage
Control, Trusted Connector etc.) ⋅ Support of Standardization Activities …

Figure 1.1: Three types of activities of the International Data Spaces

© Fraunhofer !1

»» STANDARDIZED INTEROPERABILITY: The International software implementations, and thus for a variety of com-
Data Spaces Connector, being a central component of the mercial software and service offerings.
architecture, is implemented in different variants and can
be acquired from different vendors. Nevertheless, each All research and development activities, as well as all ac-
Connector is able to communicate with any other Connec- tivities with regard to standardization, are driven by the
tor (or other technical component) in the ecosystem of the following guidelines:
International Data Space.
»» OPEN DEVELOPMENT PROCESS: The International Data
»» VALUE ADDING APPS: The International Data Spaces al- Spaces Association is a non-profit organization institution-
lows to inject apps into the IDS Connectors in order to alized under the German law of associations. Every organi-
provide services on top of data exchange processes. This zation is invited to participate, as long as it adheres to the
includes services for data processing, data format align- common principles of work.
ment, and data exchange protocols, for example. Further-
more, data analytics services can be provided by remote »» RE-USE OF EXISTING TECHNOLOGIES: Inter-organization-
execution of algorithms. al information systems, data interoperability, and infor-
mation security are well-established fields of research and
»» DATA MARKETS: The International Data Space enables the development, with plenty of technologies available in the
creation of novel, data-driven services that make use of market. The work of the International Data Spaces initia-
data apps. It also fosters new business models for these tive is guided by the idea not to “reinvent the wheel”, but to
services by providing clearing mechanisms and billing use existing technologies (e.g., from the open-source do-
functions, and by creating domain-specific broker solu- main) and standards (e.g., semantic standards of the W3C)
tions and marketplaces. In addition, the International Data to the extent possible.
Spaces provides templates and other methodological sup-
port for participants to use when specifying usage restric- »» CONTRIBUTION TO STANDARDIZATION: Aiming at estab-
tion information and requesting legal information. lishing an international standard itself, the International
Data Spaces initiative supports the idea of standardized ar-
Being the central deliverable of the research project, the chitecture stacks.
Reference Architecture Model of the International Data
Spaces (IDS-RAM) constitutes the basis for a variety of

010 //
 INTRODUCTION // 1.2

1.2 PURPOSE AND STRUCTURE

OF THE REFERENCE
ARCHITECTURE MODEL

Focusing on the generalization of concepts, functionality, and place between the different components of the Internation-
overall processes involved in the creation of a secure “net- al Data Spaces; using the BPMN notation, it provides a dy-
work of trusted data”, the IDS-RAM resides at a higher ab- namic view of the Reference Architecture Model. The Infor-
straction level than common architecture models of concrete mation Layer defines a conceptual model which makes use
software solutions do. The document provides an overview of linked-data principles for describing both the static and the
supplemented by dedicated architecture specifications defin- dynamic aspects of the International Data Space’s constitu-
ing the individual components of the International Data Spac- ents. The System Layer is concerned with the decomposition
es (Connector, Broker, App Store, etc.) in detail. of the logical software components, considering aspects such
as integration, configuration, deployment, and extensibility of
In compliance with common system architecture models and these components.
standards (e.g., ISO 42010, 4+1 view model), the Reference
Architecture Model uses a five-layer structure expressing var- In addition, the Reference Architecture Model comprises
ious stakeholders’ concerns and viewpoints at different levels three perspectives that need to be implemented across all
of granularity. five layers: Security, Certification, and Governance.

The general structure of the Reference Architecture Model is

illustrated in Figure 1.2 The model is made up of five layers: International Data Spaces
The Business Layer specifies and categorizes the different
roles which the participants of the International Data Spaces Layers Perspectives
can assume, and it specifies the main activities and interac-
Business
tions connected with each of these roles. The Functional Lay-

Certification

Governance
er defines the functional requirements of the International Functional
Security

Data Spaces, plus the concrete features to be derived from Process

these. The Process Layer specifies the interactions taking
Information
System

Figure 1.2: General structure of Reference Architecture Model

011 //
KAPITEL // UNTERKAPITEL

CONTEXT OF
2
THE INTERNATIONAL
DATA SPACES

012 //
 CONTEXT OF THE INTERNATIONAL DATA SPACES // 2.1

2.1 DATA-DRIVEN BUSINESS

ECOSYSTEMS AND
THE SMART SERVICE WELT

Novel digital
Examples of business
products ecosystems
and servicesare often
numerous
emerge and
in business
can be Examples of business ecosystems are numerous and can be
found across which
ecosystems, all industries.
organizations
Many ofenter
them to have
jointly
beenfulfill
analyzedthe found across all industries. Many of them have been analyzed
and documented
needs of customers by the
better
Smartthan
Service
they Welt
can do
working
on their
group.own.1
and documented by the Smart Service Welt working group.1
In such ecosystems, which emerge and dissolve much faster
A data-driven
than traditionalbusiness ecosystem
value creating is an ecosystem
networks, in which
the partners have A data-driven business ecosystem is an ecosystem in which
data
a is the
clear strategic
focus resourcecustomer
on end-to-end used by the members
processes in to jointly
order to data is the strategic resource used by the members to jointly
create innovative
jointly value offerings.
develop innovative productsKeyand to success
services.isActors
to share in create innovative value offerings. Key to success is to share
and jointly
such maintain
ecosystems can data within such
be businesses an direct
(also ecosystem, as end- and jointly maintain data within such an ecosystem, as end-
competitors),
to-end customer
research process intermediaries
organizations, support can only be achieved
(electronic if the to-end customer process support can only be achieved if the
market-
partners
places, forteam up and
example), jointly utilizeagencies,
governmental their data
andresource
customers. (as partners team up and jointly utilize their data resource (as
shown by a number of examples in Figure 21). shown by a number of examples in Figure 2.1).
Ecosystems are characterized by the fact that no member is
capable of creating innovation on its own. Instead, the eco-
system as a whole needs to team up. In other words: Every
member has to contribute something for the benefit of all.
Ideally,Industrial Data inSpace
ecosystems function – Reference
an equilibrium Architecture Model
state of mutual
Data Sharing in Ecosystems
benefits for all members.

Sharing of material information along

Material Sciences
the entire product life cycle

Shared use of process data for

Energy
predictive asset maintenance
Data Sharing Manufacturing and Exchange of master and event data
Ecosystems Logistics along the entire supply chain

Anonymized, shared data pool for

Health Care
better drug development

Shared use of data for end-to-end

»Smart Cities«
consumer services

Figure 2.1: Data Sharing in Ecosystems

© Fraunhofer
1
1

¹ https://www.digitale-technologien.de/DT/
¹Redaktion/DE/Downloads/Publikation/
https://www.digitale-technologien.de/DT/Redaktion/DE/Downloads/
¹ https://www.digitale-technologien.de/DT/Redaktion/DE/
Publikation/SSWII_Programmbroschuere.html
SSWII_Programmbroschuere.html Downloads/Publikation/SSWII_Programmbroschuere.pdf

013 //
 CONTEXT OF THE INTERNATIONAL DATA SPACES // 2.2 // 2.3

2.2 DATA SOVEREIGNTY 2.3 DATA AS AN ECONOMIC GOOD

AS A KEY CAPABILITY

From these two developments – 1) data turning into a strate- It is indisputable that data has a value, and that data manage-
gic resource, and 2) companies increasingly collaborating in ment generates costs. Today, data is traded in the market like
business ecosystems – results a fundamental conflict of goals a commodity; it has a price, and many companies monitor the
as a main characteristic of the digital economy: on the one costs incurred for data management. However, data, being
hand, companies increasingly need to exchange data in busi- an intangible good, differs from tangible goods with regard
ness ecosystems; on the other hand, they feel they need to to a number of properties, among which the fact that data is
protect their data more than ever before, since the impor- non-rival is considered the most important one. The value of
tance of data has grown so much. This conflict of goals is all data increases as it is being used (and, in many cases, as the
the more intensified, the more a company is engaged in one number of user increases). While these differences hinder the
or more business ecosystems, and the higher the value con- adoption and application of legal provisions to the manage-
tributed by data to the overall success of the collaborative ef- ment and use of data, they do not dispute the fact that data
fort. is an economic good.

Data sovereignty is about finding a balance between the Depending on what type data is of, or what category it can be
need for protecting one’s data and the need for sharing subsumed under, the value it contributes to the development
one’s data with others. It can be considered a key capa- of innovative products and services can vary. Therefore, the
bility for companies to develop in order to be successful need for protection of data is not the same across all data
in the data economy. types and data categories. Public data, for example, which
can be accessed by anyone, requires a lower level of protec-
To find that balance, it is important to take a close look at the tion than private data or club data.
data itself, as not all data requires the same level of protec-
tion, and as the value contribution of data varies, depending Because of these differences and distinctions made with re-
on what class or category it can be subsumed under. gard to data, a generally accepted understanding of the value
of data has not been established so far. Nevertheless, there
Industrial Data Space – Reference Architecture Model
is a growing need to determine the value of data, given the
Data Exchange Standards rapid developments taking place in the Smart Service Welt.

Added value, criticality Example: automotive logistics

of the exchanged data

Inventory levels ·
Industrial
manufacturing steps ·
Data Space
Supply network structures

Event data from the supply chain … RFID · IoT

Electronic
Master data · change requests · safety data sheets …
Business

Requests · shipping notifications · invoices ... EDI

1990 2000 2010 today Time

Figure 2.2: Evolution of technical standards for data exchange

© Fraunhofer
1

014 //
 CONTEXT OF THE INTERNATIONAL DATA SPACES // 2.4

2.4 DATA EXCHANGE AND

DATA SHARING

Cross-company data exchange with the help of inter-organi- This does not mean that existing standards will become ob-
zational information systems is not a new topic; it has been solete. Instead, the overall set of standards companies need
around for decades. With the proliferation of Electronic Data to comply with when exchanging and sharing data needs to
Interchange (EDI) in the 1980s, many different data exchange be extended. It is therefore necessary to distinguish between
scenarios have emerged over time, which were accompanied data exchange and data sharing:
by the development of certain technical standards.
»» Data exchange takes place in the vertical cooperation be-
Figure 2.2 shows the evolution of technical standards for data tween companies to support, enable or optimize value
exchange since the 1980s, using the example of automotive chains and supply chains (e.g. EDI messages in logistics or
logistics. Data sovereignty, which is one of the main goals HL7 in medical scenarios).
of the International Data Spaces, materializes in “terms and
conditions” that are linked to data before it is exchanged and »» Data sharing takes place in the vertical and horizontal col-
shared. However, these terms and conditions (such as time to laboration between companies to achieve a common goal
live, forwarding rights, pricing information etc.) have not been (e.g. predictive maintenance scenarios in manufacturing)
standardized yet. In order to foster the establishment of data or to enable new business models by generating addition-
sovereignty in the exchange of data within business ecosys- al value out of data (e.g. in data marketplaces). Further-
tems, more standardization activities are needed. more, data sharing implies a mode of collaboration to-
wards coopetition.

Figure 2.3: Data exchange vs. data sharing

015 //
 CONTEXT OF THE INTERNATIONAL DATA SPACES // 2.5 // 2.6 // 2.7

2.5 INDUSTRIAL why the need for data sharing with regard to using AI will rise.
A standardized architecture for data exchange and data
CLOUD PLATFORMS
sharing would support the development and acceptance of
both Big Data and AI applications in industry. At the same
The growing number of industrial cloud platforms will also time, it is necessary to define usage policies for data sharing
drive the need for a standard for data sovereignty. With a lot and retaining data sovereignty for data providers.
of different platforms emerging – driven by technology pro-
viders, software companies, system integrators, but also ex-
isting intermediaries – it is very likely that the platform land-
scape will be very heterogeneous, at least for some time. 2.7 THE INTERNET OF THINGS
Platform providers will increasingly have to provide capabil- AND THE INDUSTRIAL
ities for secure and trusted data exchange and data sharing INTERNET OF THINGS
between their own platform and other platforms in the eco-
system.
The Internet of Things (IoT) and the Industrial Internet
Furthermore, the cloud platform landscape is likely to be of Things (IIoT), respectively, comprises an ever-growing
characterized by a plurality of architectural patterns, ranging number of devices generating more and more data. While
from approaches characterized by a high level of centraliza- there is mostly a clear focus on the primary use of that
tion (e.g. data lakes) to concepts promoting utmost decentral- data, it may be of interest for additional stakeholders as
ization (e.g. distributed applications using blockchain technol- well. This requires standardization with regard to the (I)
ogy). IoT architecture, but also standardization regarding data
exchange and data sharing – in order to enable the data
Which platform a data owner or data provider will choose to economy and facilitate the establishment of data market-
take advantage of will depend on the business criticality and places. The wide use of data generated within the (I)IoT will
the economic value of the data goods they want to exchange lead to new, smart and data centric services in conjunction
and share. As the data resource of a company consists of data with new business models.
of different criticality and value, it can be expected that many
companies will use different platforms for different purposes.

2.6 BIG DATA AND ARTIFICIAL

INTELLIGENCE

Today companies make a wide use of Big Data applications.

The common use case is to complement data available with-
in the company by additional data (e.g. open data, data from
other companies or data from data marketplaces). With the
data portfolio extended this way, companies can benefit from
significantly improved analytics results or from entirely new
usage scenarios.

Alongside with Big Data applications, also Artificial Intelligence

(AI) applications have become more and more mature and
powerful. Companies are increasingly using AI, which has led,
and will continue to lead, to an even greater demand for exter-
nal data (e.g. for training of AI models). However, companies
often do not have sufficient data available in-house, which is

016 //
 CONTEXT OF THE INTERNATIONAL DATA SPACES // 2.8

2.8 BLOCKCHAIN Two examples:

»» As perishable goods were exposed to improper ambient
temperatures, the company ordering the goods refuses
The core purpose of the International Data Spaces is to en- acceptance. The temperature data thereby becomes a
able controlled exchange and sharing of data between or- shared data asset that can be stored in a shared environ-
ganizations – regardless of the type of data. In many use ment which acts as a trusted record keeper of such quality
cases of the International Data Spaces, this is some form data.
of structured data (e.g. measurement data, product data,
or logistics data). But also other types of (streaming) data »» Several companies want to share their capabilities in order
are supported. The IDS Connector allows data owners and to produce a certain type of good. In this case, the capabil-
data providers to exchange and share their data with other ity of each company becomes a shared data asset to be
participants in the IDS ecosystem, while data sovereignty is stored in shared ‘yellow pages’ accessible for all partici-
ensured at any time. pants in the ecosystem.

In the use cases of the International Data Spaces, two basic From a functional perspective, it is expected that blockchain
patterns of data sharing can be found: technology will play an important role in maintaining these
‘shared data assets’ in an IDS environment. This would
»» Data is shared to feed new, data-driven services, such as complement the existing capabilities of the IDS architec-
using the data in a new app, smart algorithm, or other dig- ture to share (potentially large) datasets with the help of
ital service in which data of different sources/providers is IDS Connectors. For instance, a shared data asset might en-
combined. compass a hash code (‘fingerprint’ of a piece of data) which
can be used to verify a larger file (e.g. a complex product
»» Data is shared for some form of business process synchro- design for which an order was sent) being shared with the
nization, such as using the data to execute transactions help of an IDS Connector. In terms of the IDS-RAM, block-
(e.g. exchange orders), enable production (e.g. exchange chain technology could be used for the Clearing House or
product data), check quality (e.g. monitor the temperature the Broker, for example (see Business Layer).
of perishable goods), or synchronize processes (e.g. ex-
change status data). In general, the use of Blockchain technology can ensure
data consistency and transparency in combination with the
In many of these cases, this sharing of data enables trans- general IDS approach for data sovereignty and secure data
actions with the data itself becoming what one could call a exchange and sharing. In contrast, typical Data Lakes focus
‘shared data asset’, resulting in liability/responsibility for on the integration of data for the purpose of knowledge
the participating organizations. extraction.

Figure 2.4: General architectural patterns for data exchange and data sharing

017 //
 CONTEXT OF THE INTERNATIONAL DATA SPACES // 2.9

2.9 CONTRIBUTION OF THE

INTERNATIONAL DATA SPACES
TO INDUSTRY 4.0
AND THE DATA ECONOMY

By proposing an architecture for secure data exchange and In broadening the perspective from an individual use case
trusted data sharing, the International Data Spaces con- scenario to a platform landscape view, the International
tributes to the design of enterprise architectures in com- Data Spaces positions itself as an architecture that links dif-
mercial and industrial digitization scenarios. It does so by ferent cloud platforms through policies and mechanisms
bridging the gaps between research, industrial stakehold- for secure data exchange and trusted data sharing (or, in
ers, political stakeholders, and standards bodies. The ar- other words, through the principle of data sovereignty).
chitecture is designed with the objective to overcome the Over the IDS Connector, the International Data Space’s
differences between top-down approaches and bottom-up central component, industrial data clouds, as well as indi-
approaches. Figure 2.5 shows a typical architecture stack vidual enterprise clouds, on-premises applications and in-
of the digital industrial enterprise. The International Data dividual, connected devices can be connected to the Inter-
Spaces connects the lower-level architectures for commu- national Data Spaces (see Figure 2.6).
nication and basic data services with more abstract ar-
chitectures for smart data services. It therefore supports With this integrating ambition, the International Data Spac-
the establishment of secure data supply chains from data es initiative positions itself in the context of cognate ini-
source to data use, while at the same time making sure tiatives on both national and international level. Founded
data sovereignty is guaranteed for data owners. in Germany, the activities of the International Data Spac-
es are closely aligned with Plattform Industrie 4.0, in par-
ticular the Reference Architectures, Standards and Norms
working group.

Smart Service Scenarios

Production … (other
Mobility Healthcare Logistics Energy
Services Industries)

Service and Product Innovations

Architecture Level

»Smart Data Services« (alerting, monitoring, data quality, etc.)

INTERNATIONAL DATA SPACE
»Basic Data Services« (information, fusion, mapping, aggregation, etc.)

Internet of Things – Broadband Infrastructure – 5G

Real-time Area – Sensors and Actuators – Devices

Figure 2.5: Typical enterprise architecture stack

018 //
 CONTEXT OF THE INTERNATIONAL DATA SPACES // 2.9

Legend: IDS IDS Connector Data Usage Constraints Non-IDS Data Communication

Data
Marketplace
Industrial
Data Internet of
IDS
Cloud Things Cloud
IDS
IDS

Open Data
Source
IDS

IDS
Enterprise
Cloud

IDS IDS IDS IDS IDS

Company 1 Company 2 Company n Company n+1 Company n+2

Figure 2.6: International Data Spaces connecting different cloud platforms

The International Data Spaces initiative has established, Furthermore, the International Data Spaces initiative seeks
and will continue to establish, liaisons with other initia- collaboration and exchange of ideas with existing research
tives, among them and standardization initiatives. By functioning as a mediator
between top-down and bottom-up approaches, bridging the
»» Alliance for Internet of Things Innovation, gaps between research, industry, politics, and standards bod-
»» Big Data Value Association, ies, aligning the requirements of the economy and society,
»» Data Market Austria, and fostering ties with other initiatives, the International Data
»» Data Trading Alliance, Spaces can be considered a unique initiative in the landscape
»» eCl@ss, of Industry 4.0.
»» FIWARE Foundation,
»» Industrial Internet Consortium,
»» iSHARE,
»» Industrial Valuechain Initative,
»» OPC Foundation,
»» Plattform Industrie 4.0,
»» Standardization Council Industrie 4.0, and
»» World Wide Web Consortium.

019 //
LAYERS OF THE
3
REFERENCE
ARCHITECTURE MODEL

020 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.1

THE FIVE LAYERS OF THE REFERENCE ARCHITECTURE MODEL

ARE PRESENTED IN DETAIL
IN THE FOLLOWING SUBSECTIONS.

sure to establish trust among all participants (especially with

3.1 BUSINESS LAYER
regard to roles that are crucial for the overall functioning of
the International Data Spaces, such as the Broker Service Pro-
The Business Layer of the Reference Architecture Model de- vider, the App Store, the Identity Provider, or the Clearing
fines and categorizes the different roles the participants in House). The Certification Scheme applied in the participant
the International Data Spaces may assume. Furthermore, it evaluation process is described in detail in Section 4.2.
specifies basic patterns of interaction taking place between
these roles. It thereby contributes to the development of in- There are four categories of roles:
novative business models and digital, data-driven services to
be used by the participants in the International Data Spaces. »» Category 1: Core Participant
»» Category 2: Intermediary
While the Business Layer provides an abstract description »» Category 3: Software / Service Provider
of the roles in the International Data Spaces, it can be con- »» Category 4: Governance Body
sidered a blueprint for the other, more technical layers. The
Business Layer can therefore be used to verify the technical
architecture of the International Data Spaces. In this sense, CATEGORY 1: CORE PARTICIPANT
the Business Layer specifies the requirements to be ad- Core Participants are involved and required every time data is
dressed by the Functional Layer (see section 3.2). exchanged in the International Data Spaces. Roles assigned to
this category are Data Owner, Data Provider, Data Consumer,
Data User, and App Provider. The role of a Core Participant
can be assumed by any organization that owns, wants to pro-
3.1.1 ROLES IN THE vide, and/or wants to consume or use data.
INTERNATIONAL
DATA SPACES Benefit for participants in the International Data Spaces is
created by these roles as they make data available (Data Own-
er), provide data (Data Provider), or consume/use data (Data
In the following, each role a participant can assume in the In- Consumer, Data User, App Provider). In addition, Data Provid-
ternational Data Spaces is described in detail, together with ers and Data Consumers may apply business models (includ-
the basic tasks assigned to it. The majority of roles require ing pricing models) as deemed appropriate.
certification of the organization that wants to assume that
role, including certification of the technical, physical, and or- DATA OWNER
ganizational security mechanisms the organization employs. As the legal situation regarding data ownership is very com-
Certification of organizations that want to participate in the plicated (as discussed in section 4.3.4), the term ‘Data Own-
International Data Spaces is considered a fundamental mea- er’ is not used in a legal understanding in this document.

021 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.1

The Reference Architecture Model takes an operational data Exchanging data with a Data Consumer needs not necessarily
management perspective, defining a Data Owner as a legal be the only activity of the Data Provider. At the end of a data
entity or natural person creating data and/or executing con- exchange transaction completely or partially executed, for ex-
trol over it. This enables the Data Owner to define Data Us- ample, the Data Provider may log the details of the success-
age Policies and provide access to its data. Data Ownership ful (or unsuccessful) completion of the transaction at a Clear-
includes at least two major concepts: ing House (see below) to facilitate billing or resolve a conflict.
Furthermore, the Data Provider can use Data Apps to enrich
»» having the (technical) means and the responsibility to de- or transform the data in some way, or to improve its quali-
fine Usage Contracts and Usage Policies, and to provide ty. (Data Apps are specific applications that can be integrated
access to data; and into the data exchange workflow between two or more partic-
ipants in the International Data Spaces.)
»» having the (technical) means and the responsibility to de-
fine the Payment Model, including the model for reuse of If the technical infrastructure for participating in the Interna-
data by third parties. tional Data Spaces is not deployed by the Data Consumer, a
Data Provider may use a Service Provider (see below) to con-
Usually, a participant acting as Data Owner automatically as- nect to the International Data Spaces.
sumes the role of the Data Provider as well. However, there
may be cases in which the Data Provider is not the Data Own- DATA CONSUMER
er (e.g., if the data is technically managed by a different entity The Data Consumer receives data from a Data Provider. From
than the Data Owner, such as in the case of a company using a business process modeling perspective, the Data Consum-
an external IT service provider for data management, or if data er is the mirror entity of the Data Provider; the activities per-
management activities are handed over to a data trustee). formed by the Data Consumer are therefore similar to the
activities performed by the Data Provider.
In cases in which the Data Owner does not act as the Data
Provider at the same time, the only activity of the Data Own- Before the connection to a Data Provider can be established,
er is to authorize a Data Provider to make its data available to the Data Consumer can search for existing datasets by mak-
be used by a Data Consumer. Any such authorization should ing an inquiry at a Broker Service Provider. The Broker Ser-
be documented by a contract, which should include data us- vice Provider then provides the required metadata for the
age policy information for the data provided (see. Section Data Consumer to connect to a Data Provider. Alternatively,
4.1.3.6). The contract needs not necessarily be a paper docu- the Data Consumer can establish a connection with a Data
ment, but may be an electronic file as well. Provider directly (i.e., without involving a Broker Service Pro-
vider). In cases in which the information to connect with the
DATA PROVIDER Data Provider is already known to the Data Consumer, the
TThe Data Provider makes data available for being ex- Data Consumer may request the data (and the corresponding
changed between a Data Owner and a Data Consumer. As metadata) directly from the Data Provider.
already mentioned above, the Data Provider is in most cases
identical with the Data Owner, but not necessarily. To sub- Like a Data Provider, the Data Consumer may log the details
mit metadata to a Broker, or exchange data with a Data Con- of a successful (or unsuccessful) data exchange transaction
sumer, the Data Provider uses software components that are at a Clearing House, use Data Apps to enrich, transform, etc.
compliant with the Reference Architecture Model of the In- the data received, or use a Service Provider to connect to the
ternational Data Spaces. International Data Spaces (if it does not deploy the technical
infrastructure for participation itself).
Providing a Data Consumer with data from a Data Owner is
the main activity of the Data Provider. To facilitate a data re- DATA USER
quest from a Data Consumer, the Data Provider should pro- Similar to the Data Owner being the legal entity that has the
vide a Broker Service Provider (see below) with proper meta- legal control over its data, the Data User is the legal entity that
data about the data. However, a Broker Service Provider is has the legal right to use the data of a Data Owner as specified
not necessarily required for a Data Consumer and a Data by the usage policy. In most cases, the Data User is identical
Provider to establish a connection. with the Data Consumer. However, there may be scenarios in

022 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.1

which these roles are assumed by different participants. For The activities of the Broker Service Provider mainly focus on
example, a patient could use a web-based software system receiving and providing metadata. The Broker Service Provid-
to manage their personal health data and grant access to this er must provide an interface for Data Providers to send their
data to a health coach. The data could be received from a hos- metadata. The metadata should be stored in an internal re-
pital. In this case, the health coach would be the Data User pository for being queried by Data Consumers in a structured
and the provider of the web-based software system would be manner. While the core of the metadata model must be spec-
the Data Consumer. ified by the International Data Spaces (i.e., by the Informa-
tion Model, see Section 3.4), a Broker Service Provider may
APP PROVIDER extend the metadata model to manage additional metadata
App Providers develop Data Apps to be used in the Interna- elements.
tional Data Spaces. To be deployable, a Data App has to be
compliant with the system architecture of the International After the Broker Service Provider has provided the Data Con-
Data Spaces (see Section 3.5). In addition, Data Apps can be sumer with the metadata about a certain Data Provider, its
certified by a Certification Body in order to increase trust in job is done (i.e., it is not involved in the subsequent data ex-
these applications (especially with regard to Data Apps pro- change process).
cessing sensitive information). Each Data App must be pub-
lished in the App Store for being accessed and used by Data CLEARING HOUSE
Consumers and Data Providers. App Providers should de- The Clearing House is an intermediary that provides clearing
scribe each Data App using metadata (in compliance with a and settlement services for all financial and data exchange
metadata model) with regard to its semantics, functionality, transactions. In the International Data Spaces, clearing activi-
interfaces, etc.). ties are separated from broker services, since these activities
are technically different from maintaining a metadata reposi-
tory. As already stated above, it might still be possible that the
CATEGORY 2: INTERMEDIARY two roles “Clearing House” and “Broker Service Provider” are
Intermediaries act as trusted entities. Roles assigned to this assumed by the same organization, as both roles require act-
category are Broker Service Provider, Clearing House, Identi- ing as a trusted intermediary between the Data Provider and
ty Provider, App Store, and Vocabulary Provider. These roles the Data Consumer.
may be assumed only by trusted organizations.
The Clearing House logs all activities performed in the course
Benefit for participants in the International Data Spaces is of a data exchange. After a data exchange, or parts of it, has
created by these roles by establishing trust, providing meta- been completed, both the Data Provider and the Data Consum-
data, and creating a business model around their services. er confirm the data transfer by logging the details of the trans-
action at the Clearing House. Based on this logging informa-
BROKER SERVICE PROVIDER tion, the transaction can then be billed. The logging information
The Broker Service Provider is an intermediary that stores can also be used to resolve conflicts (e.g., to clarify whether a
and manages information about the data sources available data package has been received by the Data Consumer or not).
in the International Data Spaces. As the role of the Bro- The Clearing House also provides reports on the performed
ker Service Provider is central but non-exclusive, multiple (logged) transactions for billing, conflict resolution, etc.
Broker Service Providers may be around at the same time
(e.g., for different application domains). An organization IDENTITY PROVIDER
offering broker services in the International Data Spaces The Identity Provider should offer a service to create, main-
may assume other intermediary roles at the same time tain, manage, monitor, and validate identity information of
(e.g., Clearing House or Identity Provider, see below). Nev- and for participants in the International Data Spaces. This
ertheless, it is important to distinguish organizations and is imperative for secure operation of the International Data
roles (e.g., assuming the role of a Broker Service Provider Spaces and to avoid unauthorized access to data.
means that an organization deals only with metadata man-
agement; at the same time, the same organization may as- The Identity Provider consist of a Certification Authority (man-
sume the role of a Clearing House, for which completely aging digital certificates for the participants of the Interna-
different tasks are defined). tional Data Spaces), a Dynamic Attribute Provisioning Service

023 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.1

(DAPS, managing the dynamic attributes of the participants), International Data Spaces to a Service Provider hosting the
and a service named Dynamic Trust Monitoring (DTM, for con- required infrastructure for other organizations.
tinuous monitoring of the security and behavior of the net-
work. More details about identity management can be found This role includes also providers offering additional data ser-
in section 4.1. vices (e.g., for data analysis, data integration, data cleansing,
or semantic enrichment) to improve the quality of the data
APP STORE PROVIDER exchanged in the International Data Spaces. From a techni-
The App Store provides Data Apps. These are applications cal point of view, such a Service Provider can be considered a
that can be deployed inside the Connector, the core technical Data Provider and a Data Consumer at the same time (e.g., as
component required for a participant to join the International a Data Consumer, it receives data from a Data Provider, then
Data Spaces. Data Apps facilitate data processing workflows. provides its specific service, and then turns into a Data Provid-
They may be certified by a Certification Body, following the er itself and offers the data in the International Data Spaces).
certification procedures defined in Section 4.2.
Unlike the services provided by a Service Provider, Data Apps
The App Store is responsible for managing information about can be installed in the IT environment of a Data Consumer
Data Apps offered by App Providers (see below). The App or Data Provider for implementing additional data processing
Store should provide interfaces for publishing and retrieving functionality. To use the functionality of a Data App, the data
Data Apps plus corresponding metadata. therefore does not have to be transferred to an external Ser-
vice Provider.
VOCABULARY PROVIDER
The Vocabulary Provider manages and offers vocabularies SOFTWARE PROVIDER
(i.e., ontologies, reference data models, or metadata ele- A Software Provider provides software for implementing the
ments) that can be used to annotate and describe datasets. In functionality required by the International Data Spaces (i.e.,
particular, the Vocabulary Provider provides the Information through software components, as described in Section 3.5).
Model of the International Data Spaces, which is the basis for Unlike Data Apps, software is not provided by the App Store,
the description of data sources (see Section 3.4). In addition, but delivered over the Software Providers’ usual distribution
other domain specific vocabularies can be provided. channels, and used on the basis of individual agreements be-
tween the Software Provider and the user (e.g., a Data Con-
sumer, a Data Provider, or a Broker Service Provider). This
CATEGORY 3: SOFTWARE / SERVICE PROVIDER procedure implies that the agreements between Software
This category comprises IT companies providing software Providers and Data Consumers, Data Providers, etc. remain
and/or services (e.g., based on a software-as-a-service mod- outside the scope of the International Data Spaces.
el) to the participants of the International Data Spaces. Roles
subsumed under this category are Service Provider and Soft-
ware Provider. CATEGORY 4: GOVERNANCE BODY
The Certification Body, Evaluation Facilities, and the Interna-
Benefit is created by these roles by providing software and tional Data Spaces Association are the Governance Bodies of
services to the participants of the International Data Spaces. the International Data Spaces.

It should be noted that the process of providing software to Benefit for participants in the International Data Spaces is cre-
be used for establishing the endpoints of a data exchange ated by the Certification Body and the Evaluation Facilities by
transaction (e.g. Enterprise Systems like ERP or MES, or other taking care of the certification process and issuing certificates
platforms) is not part of the International Data Spaces, as it (both with regard to organizations that want to participate and
takes place before an organization joins the IDS. with regard to software components that are to be used).

SERVICE PROVIDER CERTIFICATION BODY AND EVALUATION FACILITIES

If a participant does not deploy the technical infrastructure The Certification Body, together with selected Evaluation Fa-
required for participation in the International Data Spaces cilities, is in charge of the certification of the participants and
itself, it may transfer the data to be made available in the the core technical components in the International Data Spac-

024 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.1

es. These Governance Bodies make sure that only compliant 3.1.2 INTERACTION OF ROLES
organizations are granted access to the trusted business eco-
system. In this process, the Certification Body supervises the
actions and decisions of the Evaluation Facilities. BASIC INTERACTIONS FOR DATA EXCHANGE AND DATA
SHARING IN THE INTERNATIONAL DATA SPACES
The Certification Scheme applied in the process is described Figure 31 gives an overview of the roles and the interactions
in Section 4.2 taking place between them. As some of the roles (Certification
Body and Evaluation Facilities) are not actively involved in the
INTERNATIONAL DATA SPACES ASSOCIATION (IDSA) everyday operations of the International Data Spaces, they
The International Data Spaces Association (IDSA) is a non-prof- are omitted from the illustration. Also, the figure does not in-
it organization promoting the continuous development of the clude Software Providers and Identity Providers, because of
International Data Spaces. More specifically, it supports and the necessary connection of those roles with all other roles.
governs the continuous development of the Reference Archi- The Software Provider would be connected to all other roles
tecture Model and the participant certification process. The with the relation “provides software”. Likewise, the Identity
International Data Spaces Association is currently organized Provider would be connected to all other roles with the rela-
across several working groups, each one addressing a spe- tion “provides identity”.
cific topic (e.g., architecture, use cases and requirements, or
certification). Members of the Association are primarily large Figure 31 shows only the basic interactions taking place be-
industrial enterprises, IT companies, SMEs, research institu- tween the different roles in the International Data Spaces. For
tions, and industry associations. data exchange, additional, more specific interactions are nec-
  essary. These interactions are described in the Process Layer
As the International Data Spaces Association is not directly section of the Reference Architecture Model (see section 3.3).
involved in the data exchange activities of the International
Data Spaces, its role will not be further addressed in the sec- Table 3.1 gives an overview of possible (mandatory or option-
tions on the other Layers. al) interactions taking place in the IDS.

Certification
Vocabulary

Evaluation
Consumer

Data User

App Store
Provider

Provider

Provider

Provider
Provider
Clearing

Identity

Service

Facility
Broker
Owner

House

Body
Data

Data

Data

App

Data Owner - X - - - (X) - (X) (X) (X) (X) - (X)

Data Provider X - X X (X) X (X) (X) (X) (X) - X
Data Consumer - X - X (X) (X) X (X) (X) (X) (X) - X
Data User - - X - - (X) - (X) (X) (X) (X) - (X)
Broker - (X) (X) - - - X (X) - - ? - X
Clearing House - (X) (X) - - - (X) - (X) (X) (X) - X
Identity Provider - X X - X (X) Federation - (X)? (X)? - - X
Service Provider (X) (X) (X) (X) (X) - - - (X) (X) (X) - X
App Provider (X) (X) (X) (X) - (X) (X) (X) - (X) - - (X)
App Store (X) (X) (X) (X) - (X) (X)? (X) (X) - (X) - (X)
Vocabulary Provider (X) (X) (X) (X) ? (X) - (X) (X) (X) - - X
Certification Body - - - - - - - - - - - - X
Evaluation Facility (X) X X (X) X X X X (X) X X X -

Table 3.1: Interactions between roles in the IDS – X --> mandatory interaction, (X) --> optional interaction

025 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.1

Figure 3.1: Roles and interactions in the Industrial Data Space

3.1.3 DIGITAL IDENTITIES

Establishing trust for data sharing and data exchange is a fun- CERTIFICATION
damental requirement. The IDS-RAM defines two basic types Certification of a participant or core component involves the
of trust: 1) Static Trust, based on the certification of partici- Certification Body and an Evaluation Facility (see section 4.2).
pants and core technical components, and 2) Dynamic Trust, Evaluation of a participant or a core component is executed
based on active monitoring of participants and core technical upon request of the participant and relies on the contract be-
components. For data sharing and data exchange in the IDS, tween the participant and the Evaluation Facility. In the same
some preliminary actions and interactions are required. These way, a Service Provider can request evaluation of a compo-
are necessary for every participant, and involve the Certifica- nent. In this process, the Certification Body is responsible for
tion Body, Evaluation Facilities, and the Dynamic Attribute Pro- supervision of the Evaluation Facility involved.
visioning Service (DAPS). Figure 3.2 illustrates the roles and in-
teractions required for issuing a digital identity in the IDS. CERTIFICATION AUTHORITY
The Certification Authority is responsible for issuing, validat-
PARTICIPANT ing and revoking digital certificates (see section 4.1). A digi-
Certification is required for every participant and the majority tal certificate is provided for a participant if both a valid cer-
of roles in the IDS, as defined above. Certification refers both tification for the participant and a valid certification for the
to the organizational capabilities of the participant and the core component is available. This means that the Certifica-
technical capabilities of the core technical components. tion Authority provides an IDS-ID for a combination of par-

026 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.1

Figure 3.2: Interactions required for issuing a digital identity in the IDS

ticipant and core component. The digital certificate is valid 1. Certification request: This is a direct interaction between
not exceeding the validity of both certifications, participant a participant and an evaluation facility to trigger an evalu-
certification and the certification of core component used by ation process based on IDS certification criteria.
the participant. The Certification Authority provides the digi-
tal certificate to the participant upon request. 2. Notification of successful certification: The Certifica-
tion Body notifies the Certification Authority of the suc-
DYNAMIC ATTRIBUTE PROVISIONING SERVICE (DAPS) cessful certification of the participant and the core compo-
The information resulting from the certification process is nent. Validity of both certifications must be provided.
passed on to the Dynamic Attribute Provisioning Service
(DAPS). This includes master data and information on secu- 3. Generating the IDS-ID: The CA generates a unique ID for
rity profiles (see section 4.1.3.3.6 and Appendix B).  The CA the pair (participant and component) and issues a digital
provides the details on the digital certificate (public key and certificate (X.509).
IDS-ID). The participant registers at the DAPS after successful-
ly deploying the digital certificate inside the component. 4. Provisioning of X.509 Certificate: The Certification Au-
thority sends a digital certificate (X.509) to the participant
DYNAMIC ATTRIBUTE PROVISIONING SERVICE (DAPS) in a secure and trustworthy way and notifies the DAPS.
Continuous monitoring of participants is necessary for clas-
sification of the trustworthiness of all participants in the eco- 5. Register: After the digital certificate (X.509) is deployed in-
system. Dynamic Trust Monitoring (DTM) implements a mon- side the component, the component registers at the DAPS.
itoring function for every IDS Component. The DTM shares
information with the DAPS to notify each of the two partic- 6. DTM Interaction: The DTM and the DAPS exchange infor-
ipant in a data exchange transaction of the current level of mation on the behavior of the component, e.g. about secu-
trustworthiness of the other participant. rity issues (vulnerabilities) or attempted attacks.

INTERACTIONS
The roles described above interact with each other in a struc-
tured way, as described in Figure 3.2. In the following, a brief
description of these interactions is given (they are described
in more detail in subsequent sections of the document):

027 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.1

3.1.4 USAGE CONTRACTS always be regarded as an extension of an existing legal agree-

ment between two IDS participants, which can be overruled
by them. As neither the IDS nor any other known technology
A legally valid contract is the foundation of any business trans- stack can sufficiently interpret legal texts, any Usage Contract
action. The IDS cannot, and does not intend to, replace legal must always be in line with the concluded agreements.
contracts or licensing agreements. Instead, the IDS provides
a technical framework for technically enforced agreements in Each contract between IDS participants consists of a technical
addition to existing, legally binding contracts. part and a non-technical part. The technical part focuses on
the description of technical interfaces (Application Program-
Many details of a business relationship cannot be modeled ming Interfaces) and the Usage Policy. Negotiation of the
in machine-readable form. Nevertheless, the IDS specifies technical part of a contract must be supported by the Infor-
methods to define categories of applicable contracts, and it mation Layer of the IDS-RAM. The non-technical part focuses
presents patterns to observe their usage and report valida- on legal aspects of the intended data exchange. For automat-
tions. For this purpose, the IDS makes use of the Information ic negotiation of contracts and conditions standard contracts
Layer (see section 3.4). are necessary (but not yet available today).

A Usage Contract comprises a set of Usage Policies. Each pol-

icy describes a certain permission or obligation of an IDS Re-
source (see section 3.4.3.2). Usage Contracts are written in a
machine-readable format (according to the IDS Usage Policy
Language, see section 3.4.4.1.1) and must be interpreted as
defined in section 4.1.3.6. In any case, a Usage Contract must

Figure 3.3: Technical Enforcement and Organizational Enforcement of Usage Policies

028 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.2

3.2 FUNCTIONAL LAYER ROLES

Each role in the International Data Spaces has certain rights
and duties. For example, the Identity Provider is responsible
The Functional Layer defines – irrespective of existing tech- for offering services to create, maintain, manage, monitor,
nologies and applications – the functional requirements of and validate identity information of and for participants in the
the International Data Spaces, and the features to be imple- International Data Spaces. More information about the roles
mented resulting thereof. is given in Section 3.1.

Figure 3.4 shows the functional architecture of the Interna- IDENTITY MANAGEMENT
tional Data Spaces, subdividing the requirements into six Every Connector participating in the International Data Spac-
groups of software functionality to be provided by the IDS. es must have a unique identifier and a valid certificate. In ad-
These six groups comply with the strategic requirements out- dition, each Connector must be able to verify the identity of
lined in Section 1.1. other Connectors (with special conditions being applied here;
e.g., security profiles).
The following subsections give a brief summary of these func-
tional requirements. The full list of functional requirements USER CERTIFICATION
can be found in a separate document entitled “Functional Each participant in the International Data Spaces must un-
Overview”. dergo certification in order to establish trust among all par-
ticipants. More information about the certification process is
given in Section 4.2.
3.2.1 TRUST

Although requirements related to trust are usually non-func-

tional, they are addressed by the Functional Layer, since they
represent fundamental features of the International Data
Spaces. The “Trust” group comprises three main aspects
(roles, identity management, and user certification), which
are complemented by governance aspects (see Section 4.3).

Figure 3.4: Functional architecture of the International Data Spaces

029 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.2

3.2.2 SECURITY AND DATA TRUSTWORTHY COMMUNICATION & SECURITY

BY DESIGN
SOVEREIGNTY Connectors, App Stores, and Brokers can check if the Connec-
tor of the connecting party is running a trusted (i.e. certified)
Like requirements related to trust, requirements related to software stack. Any communication between (external) Con-
security and data sovereignty are also usually non-functional, nectors can be encrypted and integrity protected. Each Data
but are still addressed by the Functional Layer, since they rep- Owner and Data Provider must be able to ensure that their
resent fundamental features of the International Data Spac- data is handled by the Connector of the Data Consumer ac-
es. The “Security and data sovereignty” group contains four cording to the usage policies specified: otherwise the data will
major aspects: authentication & authorization; usage policies not be sent. To reduce the impact of compromised applica-
& usage enforcement; trustworthy communication & security tions, appropriate technical measures must be applied (e.g.
by design; and technical certification. isolating Data Apps from each other and from the Connector).
Data Providers and Data Consumers can decide about the lev-
AUTHENTICATION & AUTHORIZATION el of security to be applied for their respective Connectors by
Each Connector must have a valid X.509 certificate. With the deploying Connectors supporting the selected security pro-
help of this certificate, each participant in the International file. More information about trustworthy communication and
Data Spaces that operates an endpoint is able to verify the security by design is given in Section 4.1.
identity of any other participant. Certain conditions (e.g. se-
curity profiles) may also apply here. More information about TECHNICAL CERTIFICATION
authentication is given in Section 4.1. The core components of the International Data Spaces, and
especially the Connectors, require certification from the Cer-
The Connector serving as the data source must be able to ver- tification Body in order to establish trust among all partici-
ify the receiving Connector’s capabilities and security features pants. More information about technical certification is given
as well as its identity. More information about authorization in Section 4.2.
is given in Section 4.1.

USAGE POLICIES & USAGE ENFORCEMENT

In the IDS, Data Owners and Data Providers can always be
sure their data is handled by a Data Consumer according to
the usage policies specified. Each participant can define us-
age policies and attach them to outbound data. Policies might
include restrictions, such as disallowing persistence of data,
or disallowing transfer of data to other parties, for example.
More information about usage policies and usage enforce-
ment is given in Section 4.1.

030 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.2

3.2.3 ECOSYSTEM OF DATA 3.2.4 STANDARDIZED

INTEROPERABILITY
Being able to describe, find and correctly interpret data is
another key aspect of the International Data Spaces. There- Standardized data exchange between participants is the fun-
fore, every data source in the International Data Spaces is de- damental aspect of the International Data Spaces. The IDS
scribed on the Information Layer (see section 3.4). Connector is the main technical component for this purpose.

The “Ecosystem of Data” group comprises three major as- OPERATION

pects: data source description, brokering, and vocabularies. Participants should be able to run the Connector software
in their own IT environment. Alternatively, they can run a
DATA SOURCE DESCRIPTION Connector on mobile or embedded devices. The operator of
Participants must have the opportunity to describe, publish, the Connector must be able to define the data workflow in-
maintain and manage different versions of metadata. Meta- side the Connector. Users of the Connector must be identi-
data should describe the syntax and serialization as well fiable and manageable. Passwords and key storage must be
as the semantics of data sources. Furthermore, metadata protected. Every action, data access, data transmission, inci-
should describe the application domain of the data source. dent, etc. should be logged. Using this logging data, it should
The operator of a Connector must be able to define the price, be possible to draw up statistical evaluations on data usage
the pricing model, and the usage policies regarding certain etc. Notifications about incidents should be sent automat-
data. More information about data source description is giv- ically.
en in Section 3.4.
DATA EXCHANGE
BROKERING The Connector must receive data from an enterprise backend
The operator of a Connector must be able to provide an inter- system, either through a push-mechanism or a pull-mecha-
face for data and metadata access. Each Connector must be nism. The data can be provided via an interface or pushed
able to transmit metadata of its data sources to one or more directly to other participants. To do so, each Connector must
brokers. Each participant must be able to browse and search be uniquely identifiable. Other Connectors can subscribe to
metadata in the metadata repository, provided the partici- data sources or pull data from these sources. Data can be
pant has the right to access the metadata. Furthermore, each written into the backend system of other participants.
participant must be able to browse the list of participants reg-
istered at a broker. More information about brokering is giv-
en in Section 3.5.2.

VOCABULARIES
To create and structure metadata, the operator of a Connector
may use vocabularies. In doing so, an operator of a Connector
can use existing vocabularies, create own vocabularies, or work
with other operators on new vocabularies provided by vocabu-
lary hubs. Vocabulary hubs are central servers that store vocab-
ularies and enable collaboration. Collaboration may comprise
search, selection, matching, updating, requests for changes,
version management, deletion, duplicate identification, and
unused vocabularies. Vocabulary hubs need to be managed.
More information about vocabularies is given in Section 3.4.

031 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.2

3.2.5 VALUE ADDING APPS 3.2.6 DATA MARKETS

Before or after the actual data exchange, data may need to be Data to be exchanged in the International Data Spaces may
processed or transformed. For this purpose, the Internation- have monetary value. Therefore, the International Data Spac-
al Data Spaces offers Data Apps. Each Data App has a lifecy- es has to integrate data market concepts, like clearing and
cle, spanning its implementation, provision in the App Store, billing, but also governance.
installation, and support. The App Store should therefore be
clearly visible and recognizable to every participant. CLEARING & BILLING
The Data Owner can define the pricing model (e.g. pay per
DATA PROCESSING AND TRANSFORMATION transfer, pay per access, pay per day/month/year), and the
A data processing app (which is a subtype of a Data App) price of data. Any transaction of any participant can be
should provide a single, clearly defined processing function logged. The clearing and billing process must be simple and
to be applied on input data for producing an expected out- standardized.
put. A data transformation app (also a subtype of a Data App)
should be able to transform data from an input format into a USAGE RESTRICTIONS, AND GOVERNANCE
different output format in order to comply with the require- Governance in the International Data Spaces comprises five
ments of the Data Consumer (without any substantial change aspects: data as an economic good, data ownership, data sov-
made to the information contained in the data; i.e., loss-less ereignty, data quality, and data provenance. More informa-
transformation). tion about governance is given in Section 4.3.

DATA APP IMPLEMENTATION LEGAL ASPECTS

The developers of Data Apps should be able to annotate the Trading data on a data marketplace requires legal contracts
software with metadata (about functions and interfaces, pric- and conditions that can be negotiated in an automated way.
ing models, licenses, etc.). Data Apps must explicitly define Therefore, standard contracts for typical data exchange trans-
their interfaces, dependencies, and access requirements. actions are necessary.

PROVIDING DATA APPS

Any authorized Data App developer can initiate a software pro-
vision process (App Store publication). Prior to publication in
the App Store, Data Apps must pass an optional evaluation and
certification process controlled by the Certification Body. The
App Store should support authorized users in their search for
a suitable application in an adequate fashion. Access of privi-
leged users (e.g., administrators or operators) should require
strong authentication (e.g., 2-factor authentication).

INSTALLING AND SUPPORTING DATA APPS

A dedicated Connector service should support authorized us-
ers in (un-)installing Data Apps not originating from an official
App Store. In addition, it should support authorized users in
searching, installing, and managing (e.g., removal or automat-
ed updates) Data Apps retrieved from an App Store.

032 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.3

3.3 PROCESS LAYER 3.3.1 ONBOARDING

The Process Layer specifies the interactions taking place be- The overall “Onboarding” process consists of several sub pro-
tween the different components of the International Data cesses. The first step for an organization to join the Interna-
Spaces. It thereby provides a dynamic view of the Reference tional Data Spaces as a Data Provider or Data User is to acquire
Architecture Model. an identity to be used in the IDS. This identity, which forms
the basis for establishing trusted communication in the IDS,
In the following, three major processes and their sub process- is provided by the Certification Body and an Evaluation Facili-
es are described: ty in the form of a certificate issued by an Identity Provider. In
a second step, the organization needs to request a Connector
1. Onboarding,  i.e. what to do to be granted access to the from a Software Provider. The Connector, being the core tech-
International Data Spaces as a Data Provider or Data User; nical component for becoming part of the IDS, must then be
installed. After that, it receives a digital certificate (X.509 cer-
2. Exchanging data, i.e. searching for a suitable Data Provid- tificate) to make sure it complies with IDS specifications and
er and invoking the actual data operation; and requirements. The digital certificate is based on the certifica-
tion of the participant and the certification of the Connector
3. Publishing and using Data Apps, i.e. interacting with the (see section 3.1 and section 4.2).  In a third step, the Connector
IDS as an App Provider and user of a Data App, respectively. needs to be configured for internal use and prepared for se-
cure communication (“Security Setup”, see below). In the final
These three processes are related to the International Data step, the Connector needs to be made available for other par-
Space’s key value propositions and involve most of the roles in- ticipants in the IDS so that it can finally enter live operation.
troduced in the Business Layer section. The processes are illus-
trated using the Business Process Modeling Notation (BPMN). The overall “Onboarding” process is illustrated in Figure 3.5.

The following paragraphs describe each step of the onboard-

ing process in more detail.

ACQUIRE IDENTITY
Any organization that wants to operate a connector in order
to exchange data in the International Data Spaces as a Data
provider or Data Consumer needs to acquire a unique identi-
ty in the form of a certificate. This certificate enables them to
establish secure and trusted connections to other IDS partici-
pants (see section 3.1).

033 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.3

Figure 3.5: “Onboarding” overall process

Figure 3.6: “Connector Configuration and Provisioning” sub process

034 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.3

Figure 3.7: “Security Setup” sub process

CONNECTOR CONFIGURATION AND PROVISIONING SECURITY SETUP

Each Connector that participates in the IDS ecosystem must To enable secure communication, a Certification Authority is-
provide a self-description for other IDS participants to read. sues a certificate to the Data Provider or Data Consumer. This
The respective organization needs to create this description certificate is deployed locally to enable Transport Layer Secu-
at the beginning of the connector configuration and provi- rity (TLS) and identification of the respective IDS participant.
sioning sub process. The Connector self-description must On top of that, the Connector self-description must be correct
contain information about the respective organization, about and valid, which is ensured by requesting a Dynamic Attribute
who maintains the Connector (i.e. the Service Provider), and Token from the Identity Provider (section 4.1). The token is a
about the content and type of the data offered or requested. signed attestation that the information the Connector states
about itself has been verified and is actually true. The token
Another mandatory step for the organization to take is to is presented by each subsequent outgoing communication
orchestrate data flows for (future) data retrieval and data message of the Connector, so that also the communicating
provisioning, respectively, and to set up system adapters Connectors have a means to verify the trustfulness of their
and communication interfaces (“endpoints”). (Details on the communication partners at any time.
configuration of the IDS Connector are described in section Furthermore, any organization that wants to assume the role
3.5.1.1). of Data Provider or Data Consumer has the option to config-
ure custom access restrictions for bilateral communications.
If needed, the organization can install and configure Data For instance, a Data Provider may want to block certain Con-
Apps acquired from the App Store Provider. nectors or participants from accessing their services, or it
may require specific access credentials. These configurations
may be set up in the last step of the Security Setup sub pro-
cess (see section 4.1).

035 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.3

AVAILABILITY SETUP 3.3.2 EXCHANGING DATA

After local Connector deployment and Security Setup, a Con-
nector must be made available for other participants in the
International Data Spaces. This is done by the provisioning The overall process of exchanging data consists of two sub
of an “External Connector”, which runs in a so-called “De- processes, as illustrated in Figure 3.9. The first sub process is
militarized Zone (DMZ)” and forwards or filters requests to about a Data Consumer searching for a suitable Data Provider.
the “Internal Connector”. Alternatively, proper adjustment If the search was successful, the Data Consumer and the Data
of firewall rules may be sufficient (in less sensitive environ- Provider can start to exchange data with one another. This
ments). Each Data Provider and Data Consumer can decide is done after Connector configuration, either starting “from
whether or not they want to announce their Connector (or scratch” (see IDS onboarding process described above) or by
the data resources accessible through their Connector) pub- reconfiguring an existing Connector. The second sub process
licly on the IDS. If they do so, they can select a Broker from a is the invocation of the actual data operation (e.g. data upload
set of available Broker services (i.e., a registry for Connector or download, data transformation, or data query).
self-descriptions) to publish the self-description of their Con-
nector (see above). The Broker provides functions for search-
ing for and retrieving registered Connector self-descriptions
(see section 3.5.2), including data sources, interfaces, security
profiles, and current levels of trustworthiness.

Figure 3.8: “Availability Setup” sub process

036 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.3

Figure 3.9: “Exchanging Data” overall process

FIND DATA PROVIDER

To find a Data Provider, the Data Consumer must send a que- Alternatively, the Data Consumer may already know a suit-
ry to a Broker Service Provider. Before that, however, the able Data Provider. In this case, the Data Consumer can con-
Data Consumer needs to select a suitable Broker (e.g. based tact the Data Provider directly (i.e. without invoking a broker).
on thematic coverage) and determine the query capabilities
(e.g. a graphical search interface or a domain-specific que- INVOKE DATA OPERATION
ry language). The Broker then returns the query result to the Data usage policy information is an important element of le-
Data Consumer, who needs to interpret the result to find out gal agreements and is therefore modeled as first-class objects
about the different data sources available in the Internation- on the Information Layer (see Section 3.4). The handling of
al Data Spaces for providing the data specified in the query. data usage policy information is shown in detail in the “In-
Each query result must provide information about each IDS voke Data Operation” sub process (Figure 3.11). While a Con-
Connector capable of providing the desired data, so that the nector self-description basically contains information about
Data Consumer can retrieve each Connector’s self-descrip- the datasets available, also usage policy information can be
tion to learn more about how to receive the desired dataset extracted from this description. In a (semi-)automated nego-
from a technical point of view (e.g., endpoint addresses, pro- tiation process performed by the usage control frameworks
tocol). The Data Provider may serve the same data using dif- of the participating Connectors, the Data Consumer and the
ferent representations or pricing options, so the Data Con- Data Provider need to agree on a data usage policy. If an
sumer may select a suitable offer from the Data Provider’s agreement has been reached, this policy is instantiated and
Connector description.

Figure 3.10: “Find Data Provider” sub process

037 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.3

deployed inside both Connectors. The policy both parties 3.3.3 PUBLISHING AND USING
agree upon needs to be persisted in an immutable way by
DATA APPS
both sides. After the data usage policy has been established,
the consuming Connector can be configured to deal with fur-
ther data coming in from the Data Provider in the future as Data Apps can be used by Connectors for specific data pro-
specified by the policy. The retrieval of the self-description cessing or data transformation tasks. They can perform tasks
and the negotiation of policies must make use of HTTPS or of different complexity, ranging from simple data transforma-
mqtt protocols. If this has been done, the Data Operation call tion to complex data analytics. An example of data transfor-
can be invoked – this is usually done by a request using a mation may be a Data App parsing a single string field with
common protocol (e.g., HTTP) to retrieve a data artifact from address information and producing a data structure consist-
the Data Provider. ing of street name and number, zip code, name of the city,
and name of the country.
The Data Provider then sends the result of the data operation
to the Data Consumer. Usage control on both sides signals the On a conceptual level, Data Apps can be treated the same way
data operation to the data provenance tracking infrastructure as data offerings in the International Data Spaces. Therefore,
(accessible via the Clearing House), so that provenance infor- just as data is provided by a Data Provider using a Connector
mation about the data transferred is kept up to date. Usage and registering this Connector at a Broker, Data Apps are cre-
control on the Data Consumer side also signals receipt of the ated by an App Provider and registered at an App Store (us-
data operation result to the data provenance tracking infra- ing the App Provider’s Connector as a means to communicate
structure, in order to confirm that the transaction has been with the App Store). As a consequence, App Providers also
completed successfully (see sections 4.1.3.6 and 4.1.3.7). 

Figure 3.11: “Invoke Data Operation” sub process

038 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.3

need to undergo the Onboarding process. However, instead For each Data App that was successfully certified, the cor-
of registering their Connector at a Broker, App Providers reg- responding metadata is stored in the App Store for being
ister their Data Apps at an App Store. retrieved by users (e.g., Data Consumers or Data Providers)
via a search interface. Searching for a Data App is part of the
In order to be published, certain Data Apps require certifica- “Find App” sub process depicted in Figure 313. If a user finds
tion from the Certification Body (see section 3.5.1) (see first a suitable Data App (i.e., matching in functionality and com-
step of the process shown in Figure 3.12). patible with the user’s Connector packaging format) in the
App Store, the App can be requested. This is indicated in the
When it comes to using a Data App that is offered by an App “Retrieve App” sub process, which is conceptually identical
Store, App Users (Data Provider or Data Consumer) need to with the “Invoke Data Operation” process outlined in section
execute a process that is very similar to the “Exchange Data” 3.3.2, which is why a detailed discussion is omitted here.
process described above.

Figure 3.12: “Data App Certification” process

Figure 3.13: “Use Data App” process

039 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.4

3.4
1 INFORMATION LAYER 3.4.2 MODEL REPRESENTATIONS

The Information Layer specifies the Information Model, the The Information Model has been specified at three levels of
domain-agnostic, common language of the International formalization. Each level corresponds to a digital representa-
Data Spaces. The Information Model is an essential agree- tion, ranging from this high-level, conceptual document down
ment shared by the participants and components of the IDS, to the level of operational code, as depicted in Figure 314.
facilitating compatibility and interoperability. The primary Every representation depicts the complete Information Mod-
purpose of this formal model is to enable (semi-)automated el in its particular way. Among the different representations,
exchange of digital resources within a trusted ecosystem of the Declarative Representation (IDS Ontology) is the only nor-
distributed parties, while preserving data sovereignty of Data mative specification of the Information Model. As such, it is
Owners. The Information Model therefore supports the de- accompanied by a set of auxiliary resources (e.g. guidance
scription, publication and identification of data products and documents, reference examples, validation tools, and editing
reusable data processing software (both referred to herein- tools intended to support a competent, appropriate, and con-
after as “Digital Resources”, or simply “Resources”). Once the sistent usage of the IDS Ontology).
relevant Resources are identified, they can be exchanged and
consumed via semantically annotated, easily discoverable 3.4.2.1 CONCEPTUAL REPRESENTATION
services. Apart from those core commodities, the Informa- The Conceptual Representation of the Information Model
tion Model describes essential constituents of the Interna- presents a high-level overview of the main, largely invariant
tional Data Spaces, its participants, its infrastructure compo- concepts, with no commitment to a particular technology or
nents, and its processes. domain. It targets a general audience, management boards,
and media, as it provides basic information and promotes
a shared understanding of the concepts by means of a tex-
3.4.1 SCOPE tual document and a plausible visual notation. If available,
references to related elements of the Declarative Represen-
tation4 and a Programmatic Representation5 are provided,
The Information Model is a generic model, with no commit- encouraging the reader to take a look at these alternative
ment to any particular domain. Domain modeling is dele- implementations.
gated to shared vocabularies and data schemata, as provid-
ed e.g. by domain-specific communities of the International 3.4.2.2 DECLARATIVE REPRESENTATION
Data Spaces. The Information Model does not provide a me- The Declarative Representation (IDS Ontology) provides a
ta-model for defining custom datatypes comparable to stan- normative view of the Information Model of the Internation-
dards such as OData2 or OPC-UA3. Concerns beyond the scope al Data Spaces. It has been developed along the analysis,
of modeling Digital Resources and their interchange are con- findings, and requirements of the Conceptual Representa-
sidered out of scope. The Information Model therefore does tion. Based on a stack of W3C Semantic Web technology stan-
not deal with the side effects of data exchange (e.g. in scenar- dards6 and standard modeling vocabularies (DCAT7, ODRL8,
ios in which data is used for time-critical machine operations). etc.), it provides a formal, machine-interpretable specifica-
tion of concepts envisaged by the Conceptual Representa-
tion. Furthermore, it details and formally defines entities of
the International Data Spaces in order to be able to share,
search for, and reason upon the structured metadata de-
scribing these entities. As such, it comprises a complete ref-

2
https://www.odata.org/
3
https://opcfoundation.org/
4
https://github.com/IndustrialDataSpace/InformationModel
5
https://maven.iais.fraunhofer.de/artifactory/eis-ids-snapshot/

040 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.4

erential model allowing the derivation of a number of Pro- 3.4.2.3 PROGRAMMATIC REPRESENTATION
grammatic Representations. The IDS Ontology is typically The Programmatic Representation of the Information Mod-
used and instantiated by knowledge engineers, ontology el targets Software Providers by supporting seamless inte-
experts, or information architects. It defines a fairly mini- gration of the Information Model with a development infra-
mal, domain-agnostic “core model” and relies on third-party structure software developers are familiar with. It comprises
standard and custom vocabularies in order to express do- a programming language data model (e.g., Java, Python, C++)
main-specific facts. According to the common practice, ex- shipped as a set of documented software libraries (e.g., JAR
isting domain vocabularies and standards are reused where files). The Programmatic Representation provides best-ef-
possible, fostering acceptance and interoperability. fort mapping of the IDS Ontology onto native structures of a
target programming language. This approach supports type-
safe development, well-established unit testing, and quality
assurance processes. It allows developers to easily create
instances of the Information Model that are compliant with
the IDS Ontology, relieving them from the intricacies of on-
tology processing.

Programmatic Representation
specific
transformation IDS Information
Integration, tooling, processing
Model Library
Java, Python, C++ shared library

Declarative Representation feedback

constraints
Specification, definition, reasoning IDS Ontology
RDF/OWL, SPARQL, SHACL files etc.

feedback
Conceptual Representation
IDS Reference
Analysis, overview, explanation
Architecture
generic Document, visual notation (UML)

descriptive executable

Figure 3.14: Representations of the Information Model

6
https://www.w3.org/standards/semanticweb/
7
https://www.w3.org/TR/vocab-dcat-2/
8
https://www.w3.org/TR/odrl-model/

041 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.4

3.4.3 CONCEPTUAL 3.4.3.3 SEPARATION OF CONCERNS (SOC)

REPRESENTATION OF A Following the “separation of concerns” design principle, only

one dimension of a subject matter is considered at a time, for
DIGITAL RESOURCE IN THE IDS the sake of clarity and consistency. Similar to the principle a
microscope works, each concern follows a particular, analyti-
In the following, the pivotal concept of a Digital Resource is cal point of view, while other concerns can temporarily be dis-
introduced, segregated into modules in accordance with the regarded. This principle can be applied to information mod-
“separation of concerns” principle (SoC principle). To do so, eling, aiming at a thorough understanding of the domain and
a basic concern hexagon is gradually augmented by individ- fostering modularity and re-usability of the resulting (sub-)
ual modeling aspects, resulting in a detailed version of the models. Accordingly designed, these models may evolve in-
hexagon at the end of this section. To motivate acceptance dependently of each other and can be updated by different
and demonstrate the adequacy of the concern hexagon, a agents at different times. As any modification of a single ele-
set of illustrative examples is introduced for each concern. ment of the overall model does not require a change in other,
The examples are motivated by a fictional scenario of observ- logically unrelated parts, the development and maintenance
ing traffic conditions at defined locations along the Europe- of models can be substantially simplified.
an highways for purposes of traffic control, predictive road
maintenance, toll fee optimization, and so on.

3.4.3.1 VERSION NOTE

Since version 2.0 of the IDS-RAM, this section of the docu-
ment has undergone major changes. It now has a consistent
structure (following the SoC principle), includes numerous il-
lustrative examples, and provides more informative figures
and simplified UML diagrams. The document thereby ad-
dresses the request from readers to emphasize the introduc-
tory nature of this work.

3.4.3.2 (DIGITAL) RESOURCE

A (Digital) Resource in the context of the International
Data Spaces is a uniquely identifiable, valuable, digital (i.e.
non-physical) commodity that can be traded and exchanged
between remote participants using the IDS infrastructure.
Following the web resource paradigm9, the abstract content Figure 3.15: Outline of the Concern-Basic concern hexagon
of a Resource is provided in a variety of representations. Ex-
amples of Resources are documents, time series of sensor
values, messages, image file archives, or media streams. Re-
sources are subject to forwarding, processing, and/or con-
sumption, with a particular demand for modeling related,
complementary aspects (i.e., content, provenance, provision-
ing etc.). These are analyzed and specified here by applying
the “separation of concerns” (SoC) paradigm10.

9
https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#tab_5_1
10
http://www.cs.utexas.edu/users/EWD/ewd04xx/EWD447.PDF

042 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.4

3.4.3.4 CONCERN HEXAGON 3.4.3.5 CONTENT

To illustrate the main modeling concerns of Digital Resources The Content concern deals with the description of a Resource’s
in an easy memorize way, the mnemonic hexagonal arrange- inherent substance, i.e. its “content” available in any ma-
ment of carbon atoms can be used (C-Hexagon), as shown in chine-interpretable, binary format. It addresses questions like:
Figure 315. As a Resource’s content is its most essential as-
pect, Content is located at the top of the hexagon. This con- »» What type of content does a Resource provide
tent is interpretable by references to a shared, formally de- (e.g. text or an image)?
fined Concept, whereas links to a particular Context (in terms
of time, place, or real-world entities) make the content poten- »» What does the content look like (i.e. what is its
tially relevant for certain Data Consumer. So the upper part of structure, format etc.)?
the C-Hexagon deals with the “what” aspects, independently
of Data Exchange, Data Sharing or Data Utilization. The low- »» Is a content sample provided?
er part relates to the “how” aspects; i.e. how the content is
exchanged (Communication) and under which conditions »» What is the size and creation date of a particular file?
(Commodity). The Community of Trust concern refers to the
distinctive feature of the International Data Spaces being an At the abstract Resource level, content is described inde-
ecosystem of certified participants and components that ex- pendently of its physical manifestation. It is made concrete by
change and share Digital Resources in accordance with usage augmenting structural information, i.e. details of how content
policies ensuring data sovereignty. is serialized into one of the supported Representations. At a
certain point in time, a Representation materializes in one or
The level of detail differs across the individual concerns. The several Instances (e.g. values or files).
selection of their constituting aspects may change in light of
new requirements and insights. Modeling concerns may in-
form, but do not necessarily correspond to any physical orga-
nization of the model (e.g., modules or directories). Some of
the models listed below directly map to the above mentioned
concerns, while others take a more detailed perspective on
particular aspects.

3.4.3.5.1 RESOURCE
Digital content at the Resource level of description abstracts
away from a particular physical manifestation and deals with
aspects that are shared equally by any of the content’s em-
bodiments.

Example: A report (i.e. Text, see below) containing figures re-

garding the utilization of European highways since 2000.

043 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.4

RESOURCE TYPE There are various types of Digital Resourc- Audio refers to media content primarily intended for aural
es11,12. Resources may differ with regard to the intended pur- perception; consumption of such content normally requires
pose, the level of structuring, or the (sensory) requirements for an audio output device (i.e. a loudspeaker). Image is static (i.e.
its consumption and interpretation. Distinguished sets of prop- time invariant) media content intended for visual perception,
erties are expected to evolve per Resource type, depending on normally requiring a display device (i.e. a screen). Video is dy-
their (future) use and relevance. namic (i.e. time variant) media content intended for visual
and aural perception, combining the rendering requirements
Regarding the IDS-RAM, Data is defined in alignment with ISO/ of Image and Audio as well as further requirements on pro-
IEC 2382:201513 (Information technology – Vocabulary) as a cessing (decoding etc.). Software is a collection of machine-in-
statement of facts provided in a formalized, structured format terpretable instructions, such as executable software (binary),
intended primarily for machine processing (i.e. atomic values program code (source), or fragments thereof; after option-
or arrangements of data fields, optionally defined by a sche- al preprocessing (compilation, installation etc.) its intended
ma). Text represents a meaningful sequence of characters writ- purpose is a subsequent execution exposing functionality.
ten in human language, which is intended for being read and Opaque is another, unspecified type of custom, binary con-
interpreted by humans (or other intelligent agents) regardless tent. The Container is a collection of multiple (implicit) con-
of its Representation (e.g. document or screenshot image). tent elements that are distributed as a single unit (archive).

Figure 3.16: Taxonomy of the Resource concept

11
https://tools.ietf.org/html/rfc2046
12
http://dublincore.org/documents/dcmi-terms/#section-7
13
https://www.iso.org/standard/63598.html

044 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.4

HIERARCHY Individual, physically or logically “included” parts 3.4.3.5.2 REPRESENTATION

of the Container (e.g. an archive file), as well as any other Abstract Resource content can be made “concrete” by add-
structured Resource (e.g. software re-using 3rd party librar- ing serialization details, i.e. by specifying alternative, physi-
ies), may explicitly be referred to by the content-part rela- cal Representations of the content. For example, Image con-
tion14, allowing the modeling of part-whole hierarchies. tent might be exposed via raster (JPEG, PNG, GIF) or vector
graphics Representations (SVG). Developers of a „software
CONTEXT Temporal, spatial and real-world entities linked to for image anonymization” might provide alternative software
the Resource content are covered by the Context concern Representations (Windows EXE, Debian DEB, or Java JAR) sup-
(see section 3.4.3.6). porting different software environments and operating sys-
tems.
CONCEPT Semantic annotation of the Resource content is
covered by the Concept concern (see section 3.4.6). Example: The above mentioned report made available in a
PDF or MS Word formats.

TYPE The general physical arrangement of the content is indi-

cated by the Internet Media Type (MIME-Type) and, if appro-
priate, more specifically by its specific data type.

SCHEMA Schema documents provide a formal structure defi-

nition of a Data Resource type. Profiles may add additional,
selective constraints that apply to a subset of the considered
data (e.g. geospatial data)15.

PACKAGING Packaging refers to means for archiving, com-

pressing, and encrypting a Representation in a transparent,
generic way.

Figure 3.17: Resource concept (outline)

1 Figure 3.18: Representation concept (outline)

14
http://dublincore.org/documents/dcmi-terms/#terms-hasPart
15
https://joinup.ec.europa.eu/release/statdcat-ap-v100

045 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.4

3.4.3.5.3 INSTANCE Accurate context modeling helps a client in searching for and
At a certain point in time, a Representation materializes into assessing the relevance of a Resource with respect to her in-
instances, which are either transient values or persisted files formational needs, for example, by looking at most recent
(Artifacts). Going beyond the prototypical level of Representa- data (Time) available for water pipelines (Entity) within a par-
tion, an Instance captures properties that are unique to this ticular area of interest (Space)
materialization of the Resource’s content or particular ele-
ments thereof. 3.4.3.6.1 TIME AND SPACE
Time and space are quantifiable context dimensions usually
Example: Version 3.1 of the above mentioned report; date of expressed by coordinates with regard to a shared reference
creation: 2018/01/17; file size: 1,73 MB (PDF) and 1,81 MB system, such as Coordinated Universal Time (UTC16) or World
(MS Word), respectively. Geodetic System 1984 (WGS 8417), allowing for unambiguous
interpretation. One-dimensional temporal context is limited
IDENTITY A rendered artifact may be provided with (par- to either a single point in time (instant) or an interval with
tial) identity features, such as a file name or hash sum. It be- a non-empty duration. Thanks to the linear nature of time,
comes identifiable and distinguishable from other artifacts, open-end intervals may express a continuous period with
and is suited for file-oriented provision. (Representations, in only an endpoint defined18. In contrast to temporal context,
contrast, are suited for interactive, service-oriented provision, spatial context is capable of expressing two-dimensional and
due their nature of being prototypical „blueprints“.) three-dimensional shapes as bounding boxes defined by a set
of coordinates.
SIZE The Size (specified e.g. in bytes) is another inherent char-
acteristic of an artifact. Example: Time period covered by the report, starting at
01/01/2000 UTC (end time is undefined here, as the report is
3.4.3.6 CONTEXT continuously updated).
The Context concern deals with temporal and spatial aspects
as well as with real-world entities a Resource’s content relates 3.4.3.6.2 REAL-WORLD ENTITIES
to (intrinsic context). It addresses questions like: This type of qualitative context refers to identifiable tempo-
ral and spatial entities, i.e. which are (implicitly) defined by
»» What time period does the content cover? spatio-temporal coordinates. These are conventionalized
named entities, such as time periods19 (“Renaissance”), coun-
»» When and where was it gathered? try codes (according to ISO 316620), national21 and interna-
tional road names (ECE/TRANS/SC.1/2016/3/Rev.122) etc. Be-
»» Which sub-entity of a larger entity does a certain dataset ing based upon an established reference system, standard,
relate to? or convention, such entities are considered universally valid.
In addition, within restricted domains (e.g. a building), cus-
tom context entities may be defined (e.g. individually num-
bered rooms), serving the purposes of contextualizing data
(e.g. for sensor observations). The usability of custom context
entities is limited by the characteristics of the defining model,
i.e. being a machine-interpretable, widely accepted one (ISO
1673923), and the context entities themselves. These should
have a (semantic) type or concept information attached in or-
der to support general, categorical queries for data (e.g. tem-
perature sensed in all “laboratories”). This type of annotation
is, among others, supplied by the Concept concern.

Example: “A 555”, Germany’s first highway ever built, con-

necting the cities of Bonn and Cologne, which is mentioned
in the report.

046 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.4

3.4.3.7 CONCEPT (formally) defined and reusable Terms, which can be shared
The Concept concern deals with the modeling of the “mean- across different scenarios and domains. In addition, concep-
ing”, annotation, and interpretation of entities introduced by tual schemas and ontologies define Types of entities, if these
the orthogonal Resource concerns (Content, Context, Com- are to be individually modeled as custom instances.
munication etc.). It addresses questions like:
KEYWORD Keywords are natural language annotations (tags)
»» What type of observation does the data refer to “tempera- arbitrarily chosen by the Data Provider to accurately charac-
ture” ? terize the Resource from their perspective. As such, they are
likely to be subjective and more domain specific than general
»» What kind of object does a context entity represent (facto- terms provided by controlled vocabularies. Consistency and
ry, building)? alignment of custom tag sets can be supported by means of
documentation (guidance), editing tools (tag suggestions), or
»» What is the meaning of a certain date parameter (begin- quality gates during the publication process, for example.
ning or end of a range)?
Examples: “statistics”, “highway”, “usage”, “traffic”, “Europe”.

TERM In contrast to (arbitrarily chosen) keywords, terms are

normally retrieved from an authoritative, curated source of
definition (controlled vocabulary) or defined as instances of
a conceptual type system. Identified by a normative literal
(code) or a unique identifier (URI), each term represents a re-
usable concept (“singelton”) that can be shared across differ-
ent usage scenarios and domains without variations.

Example: http://example.org/traffic_statistics.

TYPE Terms are not capable of expressing individual charac-

teristics of annotated entities. For this purpose, conceptual
schemas and ontologies define types of entities (e.g. classes,
concepts) along with properties and relations their instanc-
Keywords express the “meaning” of an entity via informal es may adopt. Unlike terms, instances of a type convey the
natural language tags. As keywords can be chosen freely by custom, particular semantics of the modeled entity. Concep-
a Data Provider, they are prone to inconsistencies and errors. tual types may be extended (specialized) to meet the require-
Using controlled vocabularies, it is possible to add curated, ments of other domains.

Example: http://example.org/TabularTrafficReport.

16
https://www.itu.int/dms_pubrec/itu-r/rec/tf/R-REC-TF.460-6-200202-I!!PDF-E.pdf
17
http://earth-info.nga.mil/GandG/publications/tr8350.2/wgs84fin.pdf
18
https://www.loc.gov/standards/datetime/edtf.html
19
https://en.wikipedia.org/wiki/List_of_time_periods
20
https://www.iso.org/iso-3166-country-codes.html
21
https://en.wikipedia.org/wiki/List_of_autobahns_in_Germany
22
https://www.unece.org/trans/main/sc1/sc1doc_2016.html
23
https://www.iso.org/standard/70303.html

047 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.4

3.4.3.8 COMMUNICATION into service interfaces (i.e., sets of a coherent functionality de-
The Communication concern deals with means to communi- fining an abstract “interaction contract”).
cate a Resource’s content in one of the Representations avail- Example: Read operation providing access to a parameter-
able. It addresses questions like: ized report (may expect a start year parameter, an end year
parameter, or both).
»» Is there any input required on client to retrieve the content?
PARAMETER Parameters are named slots of an operation’s
»» What communication protocols are supported? interface. They define the least level of content granularity an
operation may (optional) or must (mandatory) expect as an
»» What does a valid request look like? input or output. Each parameter mediates a particular kind of
digital content. This is defined by reusing the triadic content
»» What is the address of the endpoint handling the request? model from Section 3.4.3.5. Thereby abstract aspects (i.e. the
meaning) and concrete aspects (i.e. the shape) of the parame-
ter are covered. Optionally, the default value or lists of select-
able, enumerated values can be defined as instances of that
content model. Additional parameter types (e.g., an ID or the
start or end of a period) provide information for operation cli-
ents about the purpose and intended usage of the parameter
and may e.g. support a query generation process.

Example: Parameter indicating a year within the period be-

tween 2000 and 2018 (further categorized as the start of a
date range).

OPERATION TYPE The type conveys the semantics (i.e., the

functional capabilities) of an operation. Building upon con-
ventions established within technology related communities
(e.g., REST-architecture paradigm24), a taxonomy of operation
types (interaction primitives) has been defined for the purpose
Operations are the building blocks of interactive interfaces of Resource exchange, as depicted as depicted in figure 3.19.
for sharing and processing a Resource’s content. They model
an abstract functionality along with involved parameters and A client may read the digital content of a single, identified Re-
underlying interaction patterns. Through bindings to a com- source, or list a collection of resources. By providing an ap-
munication protocol, operations become “concrete” and can propriate expression (e.g., an XPath selector25), the client may
be invoked at networked Endpoints. A Connector’s interac- select a subset of matching resources or filter for relevant
tions at these Endpoints can be complemented by Message content fragments (e.g., via an LDAP filter26). The client may
metadata. subscribe for proactive content pushed by the Data Provider,
given the permission to write (or deliver) the content. Some
3.4.3.8.1 OPERATION
1
operation types may impose constraints on type and number
An operation models an atomic unit of functionality in the of parameters required, as demonstrated by the “select” and
exchange, processing, visualization, or persistence of digital “filter” parameters above.
content. Operations related to each other may be grouped

24
https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
25
https://www.w3.org/TR/xpath-31/
26
https://tools.ietf.org/search/rfc4511#section-4.5.1

048 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.4

Figure 3.19: Taxonomy of Operation types for Resource exchange

PATTERN The order of supplying the operation parameters

is governed by the operation’s interaction pattern, compara-
ble to web service Message Exchange Patterns27 (MEP). For
example, the “out-only” pattern indicates an unreliable (pos-
sibly asynchronous) server-side notification, extended in “ro-
bust-out-only” pattern by a mandatory confirmation. Such
a “reliable notification” may be implemented in a variety of
ways, depending on the communication protocol and the
programming paradigm used.

Example: In-out interaction pattern, since the result depends

Figure
1
3.20: Operation concept (outline) on (optional) input parameters.

27
https://www.w3.org/TR/wsdl20-adjuncts/#meps

049 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.4

3.4.3.8.2 ENDPOINT munication (e.g. addresses, transaction ID) and allows inter-
An Endpoint is a concrete point of content exchange (Re- pretation of the context (i.e. type of content, usage contract)
source Endpoint) and service interaction (Service Endpoint) within which an Instance of a Resource’s digital content is
that is uniquely identifiable via a specific communication pro- mediated. Depending on the implementation, this metada-
tocol. ta may be supplied as a standalone part of an initial session
negotiation or as an integral part of the content transfer (e.g.,
Example: https://stathub.org/report?start={year1}&end={- as header part of a compound multi-part message30). Thus,
year2}. the Message metadata may either complement interactions
of legacy application protocols or may be used independently
BINDING An individual operation or an entire interface can as a foundation for modeling the exchange of the Resource
be invoked at an Endpoint by bindings to communication in a generic, technology-agnostic manner. In the latter case,
protocols (such as HTTP/228) by means of established, ma- each state of the interaction is mapped onto an instance of an
chine-readable interface description languages (e.g., Open appropriate Message type (ArtifactRequestMessage).
API29).
Example: Message of the “ArtifactRequestMessage” type request-
HOST The address scheme type (e.g., HTTPS URL, MQTT topic) ing provision of the artifact named “Report_2000-2010.pdf”.
and communication protocol are defined by the implement-
ing host, which is a server node installed within a Connector. MESSAGE TYPE Figure 3.21 illustrates an excerpt of the Mes-
Within the address space of the host, each Endpoint is regis- sage taxonomy. Request-response interactions between the
tered at a particular path, topic, or queue. Connectors of interacting participants are reflected by the
dedicated subclasses of the RequestMessage and the Reques-
3.4.3.8.3 MESSAGE tResponse type. Event-like notifications are reflected by the
In contrast to the general communication capabilities de- NotificationMessage subclasses.
scribed above, the Message concept describes the content
payload being exchanged at runtime between Connectors.
Message metadata provides traceable evidence of the com-

Figure 3.21: Message taxonomy (excerpt)

28
https://tools.ietf.org/html/rfc7540
29
https://www.openapis.org/
30
https://tools.ietf.org/html/rfc7578

050 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.4

ADDRESSING The Message identifies the participants in- 3.4.3.9.1 PROVENANCE

volved in the interaction (e.g. a Data Provider and a Data Provenance is concerned with the origin of the digital con-
Consumer), as well as their Connectors, allowing for routing, tent,, the history of modifications it has undergone, and the
provenance tracking, and clearing, among other things. agents responsible for these activities. The main goal of prov-
enance tracking is to ensure reliability of the content, so that
SECURITY The Security aspect covers, among other things, the modifications are made explicit and comprehensible and
authorization features of the client (e.g., JSON Web token31) may be analyzed for defects. Furthermore, provenance infor-
and references to the contract underlying the interaction. mation should refer to the socio-economical context of the
content’s creation (the project the content was created in,
3.4.3.9 COMMODITY who the project was funded by etc.) in order to assess the un-
The Commodity concern helps assess the value and utility of derlying motivation, potential limitations, or bias.
a Resource as an obtainable asset with regard to a client’s
needs. It addresses questions like: Example: Report v3.1, derived from v3.0, including additional
tables and diagrams added by John Doe on 2018/01/17.
»» Does the Resource origin from a reliable source?
AGENT An Agent is any organization, person, or software
»» What level of quality does the Resource have? that has conducted or influenced an Activity. Agents are not
necessarily registered participants of the International Data
»» What are the restrictions regarding the use of the Resource? Spaces. Precautions should be taken to ensure a sufficient de-
scription of such external Agents is supplied.
»» How much does it cost to use the Resource?
ACTIVITY An Activity is a notable, temporarily limited opera-
tion applied by an Agent upon the content in question (such
as content creation, transformation, usage, or sharing). The
vocabulary of Provenance Activities should be controlled (i.e.
guidance should be provided to ensure homogeneous anno-
tation and evaluation/querying).

CONTENT Compared to generic provenance models, such

as the PROV Ontology32, the IDS provenance model focuses
on uniquely identifiable digital content as a subject to Activ-
ities along the Provenance tracking. Depending on the type
of Activity, this may link to abstract content (creation), con-
crete content (specification), or materialized content (modi-
fication).

Provenance explicates the context of the Resource’s creation

and its history of modification. The Quality of a Resource’s
content and provisioning services may be assessed by means
of tests, quality of service (QoS) parameters, and ratings from
previous users in the community. The Policy determines the
conditions for using the Resource, including Pricing, in a for-
mal way supporting contract negotiation and (automated)
1
contract enforcement. Figure 3.22: Provenance concept (outline)

31
https://jwt.io/
32
https://www.w3.org/TR/prov-o/

051 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.4

3.4.3.9.2 QUALITY MEASUREMENT Evaluation of a given dataset against a spe-

Quality is commonly interpreted as “fitness for use” (J. M. cific quality metric results in a measurement. Measurement
Juran33), emphasizing the contextual nature of quality. Data results, as well as individual, subjective assessments may be
Consumers can assess the fitness of a data offering for their annotated by means of metadata.
needs based on quality statements supplied alongside with
the Resource. These are, among other things, quality assess- METADATA Quality related metadata provides provenance
ments according to a multidimensional model (e.g. ISO/IEC information, information about the agent that performed
25012 data quality model34), a certificate of quality, or any the overall evaluation or an individual measurement (quality
form of community feedback. checker), information about the source it was originally de-
rived from (accumulative metrics), and the time of evaluation.
DIMENSION A quality Dimension is a qualitative character-
istic of a dataset relevant to the Data Consumer. It relates to CERTIFICATE A quality Certificate is a document that certifies
whether data is complete, valid, accurate, up to date, (techni- the quality of a Resource according to a set of quality assess-
cally) available, and so on. User-oriented quality dimensions ment rules, such as the ODI Quality Certificate35.
are measured by means of one or more quantifiable metrics.
FEEDBACK The Feedback comprises any kind of community
METRIC A quality Metric implements a particular approach to feedback regarding experiences made with certain data (such
assess a data quality dimension by observing a concrete indi- as star ratings, issue reports, or recommendations). Feedback
cator, such as the spatial resolution (accuracy) or the up-time considerably affects the credibility of data.
of the Resource’s server (availability). The value of a metric is
often numeric (percentage) or boolean.

Figure 3.23: Outline of the: Data Quality concept (outline)

33
Juran, J.M., Juran on Planning for Quality. 1988, New York: The Free Press.
34
https://iso25000.com/index.php/en/iso-25000-standards/iso-25012
35
https://certificates.theodi.org/

052 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.4

3.4.3.9.2 POLICY ASSET An Asset is the subject of a Rule, a Resource or a col-

A Policy defines rules for access to and usage of Resources. lection of Resources. Depending on the Policy’s specifications
Published as part of a Resource’s metadata, it constitutes a (e.g. do not redistribute), the Asset’s content needs to be iden-
contract offer to be further negotiated and agreed upon by tified in a persistent and unambiguous manner in order to
the prospective Data Consumer. be effectively enforceable, independently of the provisioning
type (e.g. download URL) or storage context (Data Provider or
Example: Permission for unrestricted usage of report data Data Consumer) (for example, by an identifier composed of
given the obligation the assignee John Doe will cite the source indicators such as artifact name and hash sum).
of data (Creative Commons Attribution, CC by).
CONSTRAINT A formal Constraint may restrict the applica-
RULE A Rule defines Actions that an involved Party is obliged bility of a Rule (e.g. by purpose of use), guide the selection
(Duty), permitted (Permission) or prohibited (Prohibition) to of collection items (e.g. according to the file format) and per-
do with respect to an Asset. missible Parties (e.g. by role), or refine the interpretation of
Actions (e.g. print at low resolution). The underlying Policy
PARTY The Parties involved in a data exchange transaction language has to define appropriate properties (e.g. purpose,
(i.e. the Data Owner/Provider and the Data Consumer, or file format, role, or resolution) along with conditions of their
their representative agents) are referred to by their respec- applicability and interpretation37. Reusing quality metrics (e.g.
tive roles, assigner and assignee. server uptime), as introduced above, allows specifying Poli-
cies on the required quality of service (QoS).
ACTION Alongside with operations on Assets (e.g. copy, print,
convert), an Action may comprise general obligations (e.g.
pay, attribute) or modify the interpretation of the policy (e.g.
ensure exclusiveness)36.

Figure 3.24: Policy concept (outline)

36
https://www.w3.org/TR/odrl-vocab/#actionConcepts
37
https://www.w3.org/TR/odrl-vocab/#term-LeftOperand

053 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.4

3.4.3.9.4 PRICING 3.4.3.10 COMMUNITY OF TRUST

Pricing models applied to Resources exchanged in the Inter- The Community of trust concern considers the fundamental
national Data Spaces may vary. Applying a Free Use model, requirement of the International Data Spaces for exchanging
the use of Resources is not charged (while other obligations and sharing digital content between a Data Provider and a
may still apply, e.g. attribution). The Freemium model expos- Data Consumer in a secure and trusted way, while preserving
es limited parts (or capabilities) of a Resource at no cost, while data sovereignty of the Data Owner. It addresses questions
for additional parts particular subtypes of Chargeable Use like:
apply. The Quantity-based Pricing model relies on particu-
lar quantitative metrics (e.g. volume, access count, download) »» What is known about the respective counterpart of the in-
to define a charged instance of usage (i.e. pay-per-use). The tended data exchange transaction?
Feature-based Pricing model depends on a selection of con-
tent features and quality parameters, such as map layers (ba- »» Is the respective system reliable with regard to technical
sic, mobility, crime), image or audio resolution (low, high) etc. guarantees?
The least restrictive Pricing model, the Flatrate model, allows
unconstrained use of a Resource at a fixed price, but can po- »» Is there a formal proof of the above, e.g. a valid certifica-
tentially be limited by quantitative boundaries (such as band- tion?
width, number of parallel requests, or data transfer speed).
»» What are the restrictions regarding the use of the acquired
Example: The European highway utilization report is provid- content?
ed free of charge.

Participants registered with the IDS provide or consume digi-

tal content by means of a dedicated software component: the
Connector. Participants and Connectors may undergo a for-
mal Certification process (depending on the role a Participant
wants to assume in the IDS), stating their trustworthiness ac-
Figure 3.25: Pricing concept (outline) cording to the criteria catalog and the extent of applied eval-
uation. Finally, the technical and legal terms of providing and
consuming digital content are laid down in a formal Contract.

054 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.4

3.4.3.10.1 PARTICIPANT SITE Each Participant is associated with at least one site that
A Participant is a legal or natural person assuming a role (or serves the purpose of addressing geo-spatial queries (for rea-
more than one role) in the International Data Spaces. Partici- sons of proximity) or finding out about the local law in force.
pants must undergo a formal certification process.
BUSINESS Participants may indicate the type of business and
Example: AAStat, a public agency maintaining an infrastruc- the domain in which they operate by making references to an
ture for monitoring, analysis, and prediction of highway sta- established business classification (such as NAICS39 or ISIC40).
tistics in Germany, has branches in Bonn and Berlin; since This information may support clients searching for digital
it provides open data that is available without any liability, content by business category.
it has refrained from undergoing an expensive certification
process. CERTIFICATION Depending on the role a Participant wants
to assume in the IDS, the Participant may choose (or be re-
IDENTITY Participants are registered at the International quired) to undergo an evaluation process resulting in a certi-
Data Spaces with a digital identity (X.509 certificate), along- fication that states its compliance with a criteria catalog based
side with other established, external identifiers (such asthe on an evaluation method.
D-U-N-S Number38). In accordance with linked-data princi-
ples, a Participant should always be unambiguously identifi-
able by a resolvable HTTPS URL, which links to a live metadata
document describing the Participant.

STRUCTURE Organizations may link to individual employees,

departments, or subsidiaries in order to allow for sharing au-
thorizations, corporate policies etc. across the International
Data Spaces.

Figure 3.26: Participant concept (outline)

38
https://www.dnb.com/duns-number/
39
https://www.census.gov/cgi-bin/sssd/naics/naicsrch?chart=2017
40
https://unstats.un.org/unsd/publication/seriesm/seriesm_4rev4e.pdf

055 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.4

3.4.3.10.2 CONNECTOR DEPLOYMENT CONTEXT The Deployment Context of a Con-

The Connector is the central technological building block of nector records, among other things, the Connector’s location
the International Data Spaces. It is a dedicated software com- (e.g. the data center, coordinates), the type of its deployment
ponent allowing Participants to exchange, share and process (on-premises or cloud-based), and the name of the Partici-
digital content. At the same time, the Connector ensures that pant it is operated by (i.e. the Service Provider). Depending on
the data sovereignty of the Data Owner is always guaranteed. the policy, this information may affect context-based routing
Depending on the type of configuration, the Connector’s tam- of content.
per-proof runtime hosts a variety of system services ensur-
ing, for example, secure bidirectional communication, en- SECURITY PROFILE The Security Profile indicates the capa-
forcement of content usage policies, system monitoring, and bilities of a Connector to maintain a controlled, secure and
logging of content transactions for clearing purposes. The trusted environment for exchanging, sharing and processing
functional range of a generic Connector may be extended by digital content in terms of properties (such as remote integ-
custom software (Data Apps), allowing data processing, visu- rity verification, application isolation, usage control support,
alization, persistence etc. etc.). A counterpart in the data exchange may evaluate this in-
formation, alongside with the level of Certification, in order to
Roles belonging to the Intermediary category are based on assess the Connector’s technical trustworthiness.
the Connector technology. For example, the Broker Service
Provider receives and provides metadata and maintains a CATALOG Connectors may expose an arbitrary number of Re-
metadata registry, the App Store provides Data Apps, and the sources that provide or consume digital content. The Catalog
Vocabulary Hub provides shared vocabularies and related comprises a metadata model of those Resources constructed
(schema) documents. in accordance with the IDS Ontology. Optionally, the Catalog,
or individual sets of Resource metadata, may be advertised
Example: A Base Connector operated by AAStat at WGS84; via intermediary nodes (such as the Broker Service provider
coordinates: 50°45’44.6”N 7°02’01.2”E. It provides a HTTPS or the App Store).
2.0 host serving traffic sensor data. The Connector has limit-
ed capabilities only (IoT device) and holds a base certification HOST Each Host represents an individual communication ca-
level. pability of the Connector, a server that exposes Resources via
Endpoints (HTTPS URLs, MQTT topics, etc.) according to the
communication protocol supported.

Figure 3.27: Connector concept (outline)

056 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.4

3.4.3.10.3 CERTIFICATION ternational Data Spaces Association, the Certification Body

Certification aims at determining and formally stating com- oversees the certification process, defines standardized eval-
pliance of a Participant or an infrastructure component (ba- uation procedures, and supervises all activities of the Evalu-
sically the Connector) with a predefined set of evaluation cri- ation Facilities.
teria.
CERTIFICATION LEVEL A successfully completed Certifica-
Example: Basic Component Certification based on a self-as- tion process results in the assignment of a predefined Cer-
sessment. tification Level, based on a combination of an underlying set
of criteria and the depth of the evaluation method chosen.
EVALUATION FACILITY An Evaluation Facility carries out the Here, a “higher” Certification Level transitively subsumes
evaluation part during a Participant Certification process, It “lower” levels allowing for queries based on a least required
issues the corresponding Certifications of compliance accord- level. Certification information is stored in the Participant’s
ing to the given Certification Scheme (i.e. the processes, roles, metadata description and attached to the attributes of the
evaluation methods, and target criteria). Appointed by the In- X.509 certificate, along with its Validity Period. Certification is
expected to be automatically revoked after that date, unless
it has been reasserted.

Figure 3.28: Certification facility (outline)

3.4.4.1.1 (USAGE) CONTRACT

A Usage Contract formalizes the expectations regarding the
behavior of Participants involved in a data exchange transac-
tion in a declarative, technology-agnostic way. It constitutes
a unique, binding agreement between the Parties on Re-
source usage conditions as a result of an (automated) nego-
tiation process. Digital Usage Contracts are to be maintained
in a safe, unforgeable manner (e.g. blockchain). They are the
foundation for clearing and configuring the Resource’s access
control policies, and for perpetual evaluation and enforce-
1
ment by Usage Control Frameworks, like MYDATA Control41.

41
https://www.mydata-control.de/

057 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.4

Example: Agreement between the Data Consumer YourCar- 3.4.4.2 SUMMARY

go and Data Provider AAStat valid from 2019/03/01 till The previous section introduced the Conceptual Representa-
2019/12/31 to provide push notifications about delays and tion of the Information Model with the help of the concern
traffic obstructions at some enumerated routes. First 5000 hexagon (C-hexagon). Each corner of the hexagon represents
messages are free of charge, the remaining are charged on a distinguished concern contributing to the concept of the Dig-
quantity base (5€/1000 messages). ital Resource in the context of the International Data Spaces:

RESOURCE Usage Policies originally published alongside with »» The Content concern deals with the description of a Re-
a Resource (Contract Offer) are the starting point of a Con- source’s inherent substance, i.e. its “content” available in
tract negotiation process. Over the course of this process, any any machine-interpretable, binary format.
incomplete or newly agreed details regarding Resource ex-
change are complemented, such as the identification of the »» The Context concern deals with temporal and spatial as-
Resource content in question, communication Endpoints, au- pects as well as with real-world entities a Resource’s con-
thorization token(s), or the provisioning period. tent relates to.

RULE Likewise, applicable Rules are selected and configured »» The Concept concern deals with the modeling of the mean-
in accordance with the Data Provider’s demand and the Data ing, annotation, and interpretation of entities introduced
Consumer’s economic, legal and technical options. By agree- by another Resource concerns such as Content and Con-
ing on a Usage Contract, the Data Consumer explicitly con- text.
firms its capability of implementing and enforcing the stipu-
lated rules. »» The Communication concern deals with means to commu-
nicate a Resource’s content in one of the Representations
available.

»» The Commodity concern helps to assess the value and util-

ity of a Resource.

»» The Community of trust concern considers the fundamen-

tal requirement of the International Data Spaces for ex-
changing and sharing Resources between a Data Provider
and a Data Consumer in a secure and trusted way, while
preserving the data sovereignty of the Data Owner.

The main aspects covered by the six concerns are summa-

Figure 3.29: Usage Contract concept (outline) rized in Figure 3.30.

058 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.4

Figure 3.30: Detailed concern hexagon

3.4.4 VOCABULARIES concepts of so called upper-level ontologies, provide further

explanations. As data exchange between different parties is
at the core of the IDS, only a fundamental core vocabulary for
The IDS expresses its Information Model as an RDF ontology data descriptions and data exchange invocations is required
in order to provide unambiguous identifiers and formalized for all IDS participants. Domain-specific vocabularies may be
definitions of its concepts and relations. To simplify the inte- used wherever necessary to extend the core concepts and to
gration of the IDS ontology, descriptions directly connected provide more information on data provided or requested.
to the respective concepts, as well as links to widely-known

059 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.4

3.4.5 DATA APP INTERFACES The description of Data Apps facilitates the discovery and
selection of a Data App in an IDS App Store. Consequently,
metadata must contain all necessary information to specify
Similar to an IDS Connector providing information on its iden- the value proposition and the applicability of the respective
tity, functional range, and interaction capabilities, an IDS Data Data App. Furthermore, metadata is a fundamental building
App provides information about itself according to the IDS block for the deployment and composition of several Data
Information Model. A description file contains details about Apps inside an IDS Connector. Therefore, all operations have
the intended usage and purpose of the Data App, the security to be defined in terms of input and output parameters, bound
level, and the licensing model applied. In addition, a Data Pro- protocols, and endpoints. Preconditions and postconditions
vider may describe a Data App with vocabularies outside the need to be made explicit, and effects on the environment
IDS core ontology (for instance, domain specific explanations must be outlined.
may require further terms and concepts).

Industrial Data Space – Reference Architecture Model

Reference Architecture of Connector
Meta
App
 App
Meta
App Broker Meta

Store App

Meta
Meta
App

Meta

Data Data
Connector Data Connector
Source Sink

Data Provider Data Consumer

Data
Dataset(s) transferred from
Provider to Consumer Data exchange (active)

Meta Data exchange (inactive)

Metadata Description of 
 Connector
Datasets/Provider/Consumer Metadata exchange

Application for specific data 
 App download

App …
manipulation

Figure 3.31: Interaction of technical components

© Fraunhofer !1

060 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.5

3.5 SYSTEM LAYER to the Broker as specified in the connector self-description,

e.g. technical interface description, authentication mech-
anism, exposed data sources, and associated data usage
On the System Layer, the roles specified on the Business Lay- policies. It is important to note that the data is transferred
er are mapped onto a concrete data and service architecture between the Connectors of the Data Provider and the Data
in order to meet the requirements specified on the Functional Consumer (peer-to-peer network concept).
Layer, resulting in what can be considered the technical core
of the International Data Spaces. There may be different types of implementations of the Con-
nector, based on different technologies and depending on
From the requirements identified on the Functional Layer, what specific functionality is required regarding the purpose
three major technical components result: of the Connector. Two fundamental variants are the Base Con-
nector and the Trusted Connector (see Section 4.1) as they dif-
»» the Connector, fer in the capabilities regarding security and data sovereignty.

»» the Broker, and Connectors can be further distinguished into External Con-
nectors and Internal Connectors:
»» the App Store.
»» An External Connector executes the exchange of data be-
How these components interact with each other is depicted tween participants of the International Data Spaces. The
in Figure 3.31. International Data Spaces network is constituted by the to-
tal of its External Connectors. Each External Connector
The Connector, the Broker, and the App Store are supported provides data via the Data Endpoints it exposes. Applying
by four additional components (which are not specific to the this principle, there is no need for a central instance for
International Data Spaces, but specified for the International data storage. An External Connector is typically operated
Data Spaces): behind a firewall in a specially secured network segment
of a participant (so-called “Demilitarized Zone”, DMZ).
»» the Identity Provider as defined in the Security From a DMZ, direct access to internal systems is not possi-
Perspective, ble. It should be possible to reach an External Connector
using the standard Internet Protocol (IP), and to operate it
»» the Vocabulary Hub currently as defined outside the IDS, in any appropriate environment. A participant may oper-
ate multiple External Connectors (e.g., to meet load bal-
»» the Update Repository (i.e. the source for updates of de- ancing or data partitioning requirements). External Con-
ployed Connectors) depending on the connectors technol- nectors can be operated on-premises or in a cloud
ogy, and environment.

»» the Trust Repository (i.e. the source for trustworthy soft- »» An Internal Connector is typically operated in an internal
ware stacks and fingerprints as well as remote attestation company network (i.e., a network which is not accessible
checks) as discussed in the Security Perspective. from outside). Implementations of Internal Connectors
and External Connectors may be identical, as only the pur-
pose and configuration differ. The main task of an Internal
A distributed network like the International Data Spaces re- Connector is to facilitate access to internal data sources in
lies on the connection of different member nodes where Con- order to provide data to External Connectors.
nectors or other core components are hosted (a Connector
comprising one or more Data Endpoints). The Connector is
responsible for the exchange of data or as a proxy in the ex-
change of data, as it executes the complete data exchange
process (see Section 3.3.2) from and to the internal data re-
sources and enterprise systems of the participating organiza-
tions and the International Data Spaces. It provides metadata

061 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.5

3.5.1 CONNECTOR ARCHITECTURE Data Apps are data services encapsulating data processing
and/or data transformation functionality bundled as con-
tainer images for simple installation by application container
The Connector Architecture uses application container man- management.
agement technology to ensure an isolated and secure envi-
ronment for individual data services. A data service matches Using an integrated index service, the Broker manages the
a system which offers an API to store, access or process data. data sources available in the International Data Spaces and
To ensure privacy of sensitive data, data processing should supports publication and maintenance of associated meta-
take place as close to the data source as possible. Any data data. Furthermore, the Broker Index Service supports the
preprocessing (e.g., filtering, anonymization, or analysis) search for data resources. Both the App Store and the Broker
should be performed by Internal Connectors. Only data in- are based on the Connector architecture (which is described
tended for being made available to other participants should in detail in the following paragraphs) in order to support se-
be made visible through External Connectors. cure and trusted data exchange with these services.

Industrial Data Space – Reference Architecture Model

Reference Architecture of Connector
Execution Configuration

Custom App Store Execution Configuration

Container Container Core Container Manager

API API Data Configuration

model
Validator
Router

Data
Bus
Network Workflow
Execution Execution
Data Data Execution Configurator Configurator …
App App Core

Runtime Runtime Runtime Configurator Management

Application Container Management Runtime

Operating System

Virtual Machine / Hardware

Figure 3.32: Connector Architecture

© Fraunhofer 1

062 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.5

Figure 332 illustrates the internal structure of the Connector. placed by alternative implementations in order to meet
A concrete installation of a Connector may differ from this the requirements of the operator. The selection of an
structure, as existing components can be modified and op- appropriate Data Bus may depend on various aspects
tional components added. The components shown in Figure (e.g., costs, level of support, throughput rate, quality of
332 can be assigned to two phases: Execution and Configu- documentation, or availability of accessories).
ration.
»» An App Store Container is a certified container download-
The Execution phase of a Connector involves the following ed from the App Store, providing a specific Data Service to
components: the Connector.

»» Application Container Management: In most cases, the »» A Custom Container provides a self-developed Data Ser-
deployment of an Execution Core Container and selected vice. Custom containers usually require no certification.
Data Services is based on application containers. Data Ser-
vices are isolated from each other by containers in order »» A Data Service defines a public API, which is invoked from
to prevent unintended interdependencies. Using Applica- a Data Router. This API is formally specified in a meta-de-
tion Container Management, extended control of Data Ser- scription that is imported into the configuration model.
vices and containers can be enforced. During develop- The tasks to be executed by Data Services may vary. Data
ment, and in case of systems with limited resources, Services can be implemented in any programming lan-
Application Container Management can be omitted. Diffi- guage and target different runtime environments. Existing
culties in container deployment can be handled by special components can be reused to simplify migration from oth-
Execution Configurators (see below). er integration platforms.

»» An Execution Core Container provides components for in- »» The Runtime of a Data Service depends on the selected
terfacing with Data Services and supporting communica- technology and programming language. The Runtime to-
tion (e.g., Data Router or Data Bus to a Connector). gether with the Data Service constitutes the main part of a
container. Different containers may use different run-
–– A Data Router handles communication with Data Ser- times. What runtimes are available depends only on the
vices to be invoked according to predefined configura- base operating system of the host computer. From the
tion parameters. In this respect, it is responsible of how runtimes available, a service architect may select the one
data is sent (and received) to (and from) the Data Bus deemed most suitable.
from (and to) Data Services. Participants have the op-
tion to replace the Data Router component by alterna- The Configuration phase of a Connector involves the follow-
tive implementations of various vendors. Differences in ing components:
configuration can be handled by specialized Execution
Configurator plug-ins. If a Connector in a limited or em- »» The Configuration Manager constitutes the administrative
bedded platform consists of a single Data Service or a part of a Connector. Its main task is the management and
fixed connection configuration (e.g., on a sensor de- validation of the Configuration Model, followed by deploy-
vice), the Data Router can be replaced by a hard-coded ment of the Connector. Deployment is delegated to a col-
software, or the Data Service can be exposed directly. lection of Execution Configurators by the Configurator
The Data Router invokes relevant components for the Management.
enforcement of Usage Policies, e.g. a Policy Enforce-
ment Point (see section 4.1.3.6), as configured in the »» The Configuration Model is an extendable domain model
connector or specified in the Usage Policy. for describing the configuration of a Connector. It consists
of technology-independent, inter-connected configuration
–– The Data Bus exchanges data with Data Services and aspects.
Data Bus components of other Connectors. It may also
store data within a Connector. Usually, the Data Bus »» Configurator Management loads and manages an ex-
provides the method to exchange data between Con- changeable set of Execution Configurators. When a Connec-
nectors. Like the Data Router, the Data Bus can be re-

063 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.5

tor is deployed, the Configurator Management delegates the Data Services and the Data Bus (for multiple
each task to a special Execution Configurator. data pipelines).

»» Execution Configurators are exchangeable plug-ins which • “Networking” relates to the definition of net-
execute or translate single aspects of the Configuration work parameters (ports, IPs, etc.) for being used
Model to a specific technology. The procedure of executing inside the Connector as well as for connections
a configuration depends on the technology used. Com- to External Connectors.
mon examples would be the generation of configuration
files or the usage of a configuration API. Using different • “Security” contains information about, for ex-
Execution Configurators, it is possible to adopt new or al- ample, which SSL certificates should be used for
ternative technologies and integrate them into a Connec- connections, or which public key infrastructure
tor. Therefore, every technology (operating system, appli- should be used.
cation container management, etc.) gets its own Execution
Configurator. • “Compliance / Data Sovereignty” specifies rules
to be checked by the Validator before Connector
»» The Validator checks if the Configuration Model complies deployment. If warnings or errors occur, deploy-
with self-defined rules and with general rules specified by ment may be canceled. This feature is used to
the International Data Spaces, respectively. Violation of prevent incorrect configuration of the Connec-
rules can be treated as warnings or errors. If such warn- tor.
ings or errors occur, deployment may fail or be rejected.
–– “Service Configuration” defines how configuration pa-
As the Configuration phase and the Execution phase are sep- rameters for Data Services or other Connector compo-
arated from each other, it is possible to develop, and later nents have to be set.
on operate, these components independently of each other.
Different Connector implementations may use various kinds • “Metadata” describes the data types for input and
of communication and encryption technologies, depending output used by different Connector components
on the requirements given. (see chapter 3.4.5 - App Interfaces). Data Services
can provide metadata descriptions, which can be
3.5.1.1 CONNECTOR CONFIGURATION MODEL imported to the Configuration Model. This infor-
The Connector Configuration Model describes the configura- mation is used to configure the Data Flow.
tion of a Connector, which is set-up during deployment. The
model is technology-independent. A Connector can be config- –– “Publishing” defines which Data Flows or Data Services
ured for different statuses (development, test, or live). are provided to external participants. This information
is submitted to a Broker.
The components of the Connector Configuration Model are
implemented with the help of special Execution Configurators: • “Identity Management” defines the Identity
Provider, which is closely integrated with the
»» “General Information” includes the configuration type, Connector. To be able to connect to an Identity
the Connector type (Base, Trusted, Mobile, Embedded, Provider, a Data Service may need additional li-
Developer), the Connector version, a timestamp of the braries.
last change made to the configuration, the configuration
status (development, test, live), and a name of a contact • For “Accounting” of a data exchange transaction
person. between participants, it is necessary to record
additional information, such as contract specifi-
»» “Lifecycle” contains information on the Data Flow, the cations, pricing models, or billing details.
Service Configuration, and Publishing.
• “Clearing” describes which Clearing House
–– “Data Flow” defines the configuration of tasks and should be informed regarding a certain data ex-
connections established by the Data Router between change transaction.

064 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.5

Figure 3.33: Connector Configuration Model

065 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.5

3.5.1.2 SPECIAL CONNECTOR IMPLEMENTATIONS EMBEDDED CONNECTOR

What type of Connector is to be implemented may depend on Another way of Connector miniaturization offers the Embed-
various aspects, such as the execution environment given or ded Connector. Embedded Connectors have the same design
the current developmental stage regarding Data Services or as Mobile Connectors, and do not necessarily require appli-
Data Flows used. In the following, three exemplary scenarios cation container management either. However, unlike Mo-
are outlined: bile or Developer Connectors, the Configuration Manager is
not part of the Connector hardware platform here, which is
DEVELOPER CONNECTOR why remote configuration capabilities of the platform are re-
As is the case for the development of any software, develop- quired (e.g., using an API or configuration files).
ing Data Services or configuring Data Flows comprises sever-
al phases (specification, implementation, debugging, testing, Additional steps for Connector miniaturization may include
profiling, etc.). For reasons of simplification, it may be use- the use of a common runtime for all components, or sim-
ful to run Connectors without application container manage- plified versions of the Data Router and the Data Bus. If data
ment. In doing so, the development process can be acceler- is to be sent to a fixed recipient only, a simple Data Bus cli-
ated, as packing and starting the container can be omitted, ent library may be sufficient. Similarly, it may be sufficient to
and debugging can be done in the development environment. hard-code a single, fixed connection to the Data Bus instead
After successfully passing all tests, the configuration model of using a configurable component. To save communication
used for the Developer Connector can be used to deploy a overhead, simple API calls inside the common runtime could
productive (live) Connector. Upon deployment in the live en- be used.
vironment, the Connector is ready for being used.

MOBILE CONNECTOR
Mobile operating systems (e.g., Android, iOS, or Windows
Mobile) use platforms with limited hardware resources. In
such environments, application container management is
not necessarily required. The same applies for operating sys-
tems which do not support application containers, or systems
without any operating system (e.g. microcontrollers). In such
environments, Data Services (and the execution core) can be
started directly on the host system, without requiring any vir-
tualization. The differences between Connectors with con-
tainers and Connectors without containers can be met by dif-
ferent Execution Configurator modules.

066 //
 LAYERS OF THE REFERENCE ARCHITECTURE MODEL // 3.5

3.5.2 BROKER »» Smart Data Apps (or Data Sink Connectors) are Data Apps
on the Data Consumer side, executing any kind of data
processing, transformation, or storage functionality. Nor-
The IDS Broker consists of an IDS Connector (see section mally, the data provided by, or sent to, a Smart Data App is
3.5.1), a service for data source registration, publication, already annotated with metadata (as described in the In-
maintenance, and query, based on an index. Therefore, for formation Layer section).
any interaction with the IDS Broker the processes defined
on the Process Layer, the descriptions defined on the Infor- »» Other Apps providing a certain use of the data on Data
mation Layer, and descriptions defined on the System Layer Consumer or Data Provider side. Usage Policies can en-
can be applied. The Information Layer describes the message force the processing of the data in a trusted environment,
types for Broker registration and query. An IDS Broker may i.e. a Trusted Connector.
provide additional services that must be described by the IDS
Information Model. The IDS App Store is a secure platform for distributing Data
Apps; features different search options (e.g. by functional or
non-functional properties, pricing model, certification status,
community ratings, etc.).An IDS App Store consists of a regis-
3.5.3 DATA APPS AND APP STORE try for available Data Apps in this App Store. Therefore an App
Store supports operations for Data App registration, publica-
tion, maintenance, and query, as well as operations for the
As described in section 3.5.1 Connectors can make use of provisioning of a Data App to a connector. These basic opera-
Apps for several purposes. Three types of Data Apps can be tions can be complemented by additional services, e.g. billing
distinguished: or support activities.

»» self-developed Data Apps, which are used by the Data Pro-

vider’s own Connector (usually requiring no certification
from the Certification Body),

»» third-party Data Apps, which are retrieved from the App

Store (and which may require certification), and

»» Data Apps provided by the Connector of the Data Consum-

er, which allow the Data Provider to use certain functions
before data is exchanged, e.g., filtering or aggregation of
data (which may also require certification).

In addition, Data Apps can be divided into three categories:

»» System Adapters are Data Apps on the Data Provider side,

establishing interfaces to external enterprise information
systems. The main tasks of a Data App belonging to this
category is providing access to enterprise information sys-
tems and, if necessary, transforming from an internal data
model to a data model recommended, or considered as a
standard, for a given application domain, as well as to add
metadata to the data.

067 //
PERSPECTIVES OF
4
THE REFERENCE
ARCHITECTURE MODEL

68 //
 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL // 4.1

DIRECTLY RELATED TO THE FIVE LAYERS OF THE IDS-RAM ARE THREE CROSS-SECTIONAL PERSPECTIVES:
SECURITY, CERTIFICATION, AND GOVERNANCE.
THESE ARE DESCRIBED IN DETAIL IN THE FOLLOWING SECTIONS.

4.1 SECURITY PERSPECTIVE

As stated in Section 1.1, one strategic requirement of the PROCESS LAYER

International Data Spaces is to provide secure data supply To take security aspects into account on the Process Layer, it
chains. This is critical for establishing and maintaining trust is important that existing processes are permanently moni-
among Participants that want to exchange and share data tored, validated, and redesigned, if need be. For example, to
and use Data Apps. The IDS Security Architecture provides allow trustworthy identification and authentication of Partic-
means to identify Participants,, protect communication and ipants using a central public key infrastructure (PKI), a Par-
data exchange transactions, and control the use of data after ticipant must apply for a public key certificate that is regis-
it has been exchanged. tered in a central PKI and deployed inside its Connector. For
dynamic attribute support, an identity management server
For these purposes, the International Data Spaces defines needs to verify attributes before issuing access tokens. The
a Trusted Connector as an extension of the Base Connector same is true for trustworthy operations of an App Store, for
(see Section 3.5). The IDS Connector ensures that the spec- which data must be verified and signed by a trusted entity be-
ifications and requirements of the Security Architecture ma- fore it can be uploaded.
terialize in everyday interactions and operations in the Inter-
national Data Spaces. The security aspects described in the INFORMATION LAYER
following constitute the basis of the IDS Connector. The dif- The Information Layer provides the means for Participants to
ferences between a Trusted Connecter and a Base Connector use a common vocabulary and common semantics to express
are detailed in the Security Profiles subsection 4.1.3.3.6. concepts and relationships between them. In doing so, it is
possible to specify access and usage control policies in a way
that these are understood by all Participants. The same is true
for access control requirements defining minimum security
4.1.1 SECURITY ASPECTS
profiles, which must be met before access is granted.
ADDRESSED BY THE
DIFFERENT SYSTEM LAYER
LAYERS OF THE IDS-RAM As the Connector is the central technical component on the
System Layer, it is predominantly the Connector where the
security features of the International Data Spaces are imple-
BUSINESS LAYER mented. Being an extension of the Base Connector, the Trust-
Security aspects are crucial for the definition of roles and ba- ed Connector takes up all relevant security specifications and
sic interaction patterns in the International Data Spaces. requirements, and serves as the technological basis for use
case implementations.
FUNCTIONAL LAYER
Security requirements may restrict certain transactions or
operations in the International Data Spaces, or even prevent
them. However, security is also an enabling factor. Without
security, many use cases would not be possible (e.g., offering
sensitive data to trusted business partners). The concept of
data usage control allows Data Providers to attach data usage
policy information to their data in order to define how a Data
Consumer may use the data.

069 //
 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL // 4.1

4.1.2 GENERAL SECURITY 4.1.3 KEY SECURITY CONCEPTS

PRINCIPLES
The Security Architecture addresses seven key security con-
The development of the Security Architecture follows two cepts: 1) secure communication, 2) identity management, 3)
general principles: trust management, 4) trusted platform, 5) data access con-
trol, 6) data usage control and 7) data provenance tracking.
USE OF EXISTING STANDARDS AND CONSIDERATION
OF BEST PRACTICES 4.1.3.1 SECURE COMMUNICATION
To the extent possible and reasonable, existing standards and To ensure confidentiality and authenticity of data transfers,
best practices are to be used and leveraged in the develop- communication between Connectors must be protected.
ment of the Security Architecture. The aim of the Security Ar- When using the IDS Connector, two layers of security are in
chitecture is not to offer new solutions for problems already place:
solved, but to combine existing, reliable approaches in a use-
ful and meaningful way, and bridge gaps where necessary. »» point-to-point encryption (between Connectors), using an
encrypted tunnel, and
SCALABILITY OF SECURITY LEVELS
The International Data Spaces does not enforce a single lev- »» end-to-end authorization (authenticity and authorization
el of security to be applied for all Participants. This way, also based on actual communication endpoints; i.e., Data
organizations with limited resources and technical means are Apps).
able to participate (at least as Data Consumers). However,
also the security level of these participants must be reliable Data from one External Connector to another is sent over the
and verifiable for others. Certain minimum security require- Internet or via a virtual private network (VPN), the specifica-
ments (e.g., encrypted communication) therefore need to be tion of which is beyond the scope of the IDS Security Archi-
met by all Participants. tecture. The Security Architecture defines the IDS Communi-
cation Protocol (IDSCP), which must be supported by Trusted
Provided a Participant is in line with general security require- Connectors, and can be supported by any other Connector
ments, it may decide about the level of security to be applied as well. The purpose of the IDSCP is to establish confidential,
for it itself. It should be noticed, however, that data sources authenticated communication, exchange data between the
may presuppose a certain minimum level of security to be Data Provider and the Data Consumer, and establish mutual
met by potential Data Consumers. This means for Data Con- remote attestation (if supported by the Connectors involved).
sumers: the higher the security level they choose for them-
selves to be applied, the better the access to high-quality data
Industrial Data Space – Reference Architecture
sources and high-value data services.
Model
IDS Communication Protocol

Custom Container Core Container Core Container Custom Container

Policy Set
Data Flow Control Data Flow Control

Data Service Message Queue Connection Mgmt. Message Queue Connection Mgmt. Target App

IDS Protocol
Trusted Container Management Layer Trusted Container Management Layer

Figure 4.1: IDS Communication

070 //
© Fraunhofer 1
 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL // 4.1

IDS Connectors must communicate with each other over an 4.1.3.2.1 MAPPING OF PARTICIPANT CERTIFICATION
encrypted tunnel (e.g., TLS), as depicted in Figure 41, and may AND CONNECTOR CERTIFICATION TO
use IDSCP or another appropriate protocol, like https or mqtt. IDENTITY MANAGEMENT
There are two targets of certification: Participants (receiving
The IDSCP is a high-level protocol established via WebSocket a Participant Certificate) and Core Components (receiving a
Secure (WSS). It contains several “conversations”, which can Core Component Certificate). If a Participant (e.g., a company)
be initiated by either side and must be confirmed by the other is successfully certified, it is allowed to participate in the In-
side to be entered. Currently, two conversations are provid- ternational Data Spaces. The Participant has to use a certified
ed: remote attestation and metadata exchange. The protocol IDS Connector. With both certificates, the Participant Certifi-
itself is performed inside a tunneled connection. The protocol cate and the Core Component Certificate, the Participant can
supports and enables several communication aspects: request a digital X.509 certificate for identification, authenti-
cation, and encryption.
»» identification and authentication,
A X.509 certificate contains only the most relevant, static in-
»» remote attestation, formation:

»» metadata exchange, and »» C (countryName): country of the organization (e.g. DE);

»» data exchange (together with usage policy information at- »» O (organizationName): name of the organization (e.g.
tached). Fraunhofer);

The last aspect, data exchange, provides the basic mechanism »» OU (organizationalUnitName): name of the organiza-
of data usage control, as it is possible to attach data usage tional unit (e.g. AISEC),
policy information in order to specify how the data may be
used by the Data Consumer. However, the specification of the »» CN (commonName): Universally Unique Identifier (UUID)
IDSCP is not part of this document. (e.g. 59C3BAE6-1C06-4723-802B-12C7DCF94E58);

4.1.3.2 IDENTITY MANAGEMENT » subjectAltName (X509v3 Subject Alternative Name): is

To be able to make access control related decisions that are filled with DNS entries / IP addresses of the Connector (e.g.
based on reliable identities and properties of Participants, a DNS.1 = localhost
concept for Identity and Access Management (IAM) is manda- DNS.2 = idsconnector.aisec.fraunhofer.de
tory. The following aspects are central for the concept: IP.1 = 0.0.0.0
IP.2 = 10.1.2.15
»» identification (i.e., claiming an identity), IP.3 = 10.1.2.16
IP.4 = 10.1.2.17
»» authentication (i.e., verifying an identity), and IP.5 = 10.1.2.18)

»» authorization (i.e., making access decisions based on an It is important to note that any modification of attributes leads
identity). to revocation and reissuing of the certificate. For this reason,
the number of attributes that are contained in a cer tificate
The Certificate Authority (CA) issues certificates for all en- needs to be kept at a minimum. Dynamic attributes are kept
tities. These certificates are used for authentication and en- by the Dynamic Attribute Provisioning Service (DAPS).
cryption between Connectors.

An identity may have several attributes, which are linked to

that identity. A Dynamic Attribute Provisioning Service (DAPS)
is used to provide dynamic, up-to-date attribute information
about Participants and Connectors.

071 //
 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL // 4.1

Industrial Data Space – Reference Architecture Model

Exemplary PKI structure

Trust Provider
IDS Certification Authority (CA)

Device / Connector Software Developer Software Authority

Sub CA Sub CA Sub CA

Figure 4.2: PKI structure (example)

© Fraunhofer 1

4.1.3.2.2 PROPOSED PKI STRUCTURE 4.1.3.2.3 CONNECTOR CERTIFICATE DEPLOYMENT

In general, a PKI can have several layers to achieve separation After obtaining the Participant Certificate and a Core Compo-
of duties (i.e., every Sub-CA is responsible for a specific topic). nent Certificate, an organization may apply for one or more
Depending on the business and deployment model applied, X.509 Certificates (the issuing of which may be triggered by
several Sub-CAs may exist. the International Data Spaces Association, for example).

This allows for specific parties to issue certificates for specif- The attributes for Connectors to be embedded in the X.509
ic purposes. It is also possible to support multiple instances certificate are defined above.
(e.g., multiple Connector Sub-CAs). The structure of the PKI is
not defined in this document. Once received, the Connector Certificate can be deployed
onto the Connector. The X.509 Certificate ensures that data is
always exchanged in an authenticated and encrypted manner.

Industrial Data Space – Reference Architecture Model

Embedding Certificate into Trust Infrastructure

IDS Infrastructure IDS Participant Domain

Request Dynamic
Dynamic Attribute Attribute Token
Provisioning Service
(DAPS)
IDS Connector
Assign attributes

Device Sub-CA X.509 Certificate

Request
Certificate

IDS Operating Company

Certificate issuance
notification

Confirm certification status

Certification Body

Figure 4.3:
© Fraunhofer
1 Embedding the Connector Certificate

072 //
 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL // 4.1

4.1.3.2.4 USING THE DYNAMIC ATTRIBUTE 4.1.3.2.5 USING AN AUTHORIZATION SERVICE FOR
PROVISIONING SERVICE (DAPS) FOR RESOURCE ACCESS CONTROL
IDENTITY MANAGEMENT Using an Authorization Service (featuring access tokens) al-
Using a service to hand out attributes in a dynamic fashion lows use case dependent modeling of access control deci-
reduces the need for certificate revocation and enables more sions. Delegation of access decisions is possible. In complex
flexible attribute handling for participants in the Internation- workflows, multiple Connectors can use a dedicated Autho-
al Data Spaces. This allows dynamic assignment of attributes rization Service to delegate resource access decisions. The
and status flags to Connector instances. Examples of status DAPS acts as the Authorization Service for the IDS.
flags are:
A workflow for accessing a resource (e.g., a Data Service) us-
»» Withdraw a security status if known vulnerabilities have ing dynamic attributes and access tokens is defined as follows:
not been fixed.
1. A Dynamic Attribute Token (DAT) is requested from the Dy-
»» Upgrade the certification status without reissuing a X.509 namic Attribute Provisioning Service, presenting the Con-
certificate. nector’s X.509 certificate. Depending on the verification
policy specified, the attribute can be verified at the CA.
»» Assign membership status to a workflow with contractors.
2. Before accessing a resource, a TLS tunnel is established
Notification of temporary changes of a Participant’s level of using the same X.509 certificate. Again, depending on the
trustworthiness. policy specified, the certificate can be verified at the CA.
Provisioning of mutable attributes (e.g. address of the orga-
nization). 3. (Optional) If using several Access Tokens (ATs), a token re-
quest is performed at a separate Authorization Service in
This concept avoids revocation of certificates in most cases, the domain of a use case operator or the domain of the
as it allows to include new attributes if need arises. Connector’s (or, more specifically, resource’s) owner.
not defined in this document.
4. The resource is requested by handing in either the Dynam-
ic Attribute Token (DAT) or the Access Token (AT).

Industrial Data Space – Reference Architecture Model

Resource Access Workflow
IDS Infrastructure

2b: Verify certificate Device Sub-CA (with ACME Server)

1b: Verify certificate

Dynamic Attribute Provisioning Service

(DAPS) 2b: Verify certificate
1: Present X.509 Certificate, request Identity Token

2: Present X.509 Certificate, establish TLS

IDS Connector IDS Connector
3: Request access token with Identity Token
Authorization Service
4: Access resource (multiple times)
Data Service

X.509 Certificate X.509 Certificate

IDS Participant 1 Domain IDS Participant 2 Domain

© Fraunhofer 1

Figure 4.4: Resource access workflow

073 //
 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL // 4.1

Due to the small size of access tokens, it is possible to incor- 4.1.3.3.1 PKI ROLLOUT
porate these tokens into any resource request and support To guarantee secure identity management, the International
stateless access management. Both DATs and ATs use the Data Spaces defines technical roles for implementing a PKI
JSON Web Token (IETF RFC 7519)42 standard. system that is flexible enough to support all roles defined on
the Business Layer. In particular, six entities with different
4.1.3.3 TRUST MANAGEMENT security levels are relevant for the Security Architecture. In
To establish trust across the entire business ecosystem (i.e., the following, these entities and the technical roles related to
to protect Participants from fraud and ensure they abide by them are described.
the designated rules), the International Data Spaces makes
use of cryptographic methods. One such method is the pub-
lic key infrastructure (PKI). A central principle of a PKI is that
every entity is allocated with secret keys, allowing each entity
to authenticate against other Participants. Thereby, a hierar-
chy is created, with the Identity Provider on top issuing certifi-
cates to the other entities, which in turn may issue certificates
to other entities, and so on. In the following, the PKI rollout is
described for mapping roles and entities required for the de-
ployment of the International Data Spaces.

Identity Provider

Figure 4.6: Mapping of technical roles and PKI layout

4.1.3.3.1.1 IDENTITY PROVIDER

The Identity Provider acts as an agent for the International
Data Spaces Association. It is responsible for issuing techni-
cal identities to parties that have been approved to become
Figure 4.5: Technical roles in the International Data Spaces Participants in the International Data Spaces. The Identity
Provider is instructed to issue identities based on approved
roles (e.g., App Store or App Provider). Only if equipped with
such an identity, an entity is allowed to participate in the In-
ternational Data Spaces (e.g., to provide data or publish Data
Apps). The Identity Provider may exclude Participants from
the International Data Spaces, if instructed to do so.
1

42
https://tools.ietf.org/html/rfc7519

074 //
 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL // 4.1

As a trusted entity, the Identity Provider manages the PKI CA is used by the App Store to ensure the validity of services
rollout. It takes care if certificates expire or must be revoked. downloaded by other Connectors. This means that if an App
There are two separate PKI hierarchies: one for software sig- Store signs a CSR (i.e., issues a certificate), a Connector re-
natures (Software Signing Root CA) and one for the Connec- ceives a certificate for a downloaded Data App.
tors (Service Root CA). An entity is assigned with either an end
certificate or a sub/root-CA certificate. The two hierarchies 4.1.3.3.1.5 APP PROVIDER
protect the interests of the six entities. App Providers must seek approval of Data Apps from the Cer-
tification Body. Upon successful certification of a Data App,
The Identity Provider also acts as an authorization service (as the App Provider may publish the Data App by uploading it to
described above) by incorporating the DAPS. the App Store. Each App Provider can be unambiguously iden-
tified by a certificate issued by the Identity Provider.
4.1.3.3.1.2 SOFTWARE PROVIDER
A Software Provider produces and distributes basic software 4.1.3.3.1.6 CERTIFICATION BODY
stacks for Connectors (for rollout and deployment). To ev- When an App Provider uploads a Data App, the App Store not
ery Software Provider seeking admission to the International only checks if the Data App comes from an approved App Pro-
Data Spaces, the Identity Provider issues a service sub-CA re- vider, but also if the software meets certain quality and secu-
quest. An approved Software Provider uses the service sub- rity standards. Therefore, App Providers must send the Data
CA during rollout and deployment of the Connector in order App to a Certification Body for inspection. The Certification
to provide it with an initial, valid and preconfigured system. Body checks the validity of the App Provider’s signature. If the
signature is valid, the source code of the respective Data App
4.1.3.3.1.3 CONNECTOR is inspected. If the Data App meets the quality and security
A Connector is allowed to communicate with other Connec- standards, the Certification Body signs the Data App with the
tors only if acquired from an approved Software Provider. certificate’s private key. To do so, it does not need a sub-CA,
Connectors download Data Apps from the App Store. For as it only signs the software, but does not create a certificate.
each Data App downloaded, the Connector creates a service
key pair and a Certificate Signing Request (CSR). While the 4.1.3.3.2 CONNECTOR MANIFESTATIONS
private key is used to identify the Data App and to protect A Connector can run different services and communicate
its data, the CSR is sent to the App Store, which uses it to is- with other Connectors. Using the PKI, a Connector protects
sue a certificate. This also allows entities to check whether the persistent storage of its services and the communication
the license of a certain Data App is still valid (see e.g. remote with other Connectors (in terms of authenticity, confidential-
attestation). Furthermore, the private key and the certificate ity, etc.). The following items characterize a Connector in the
are used for establishing a secure channel with other Connec- International Data Spaces from the security perspective:
tors. During rollout, the Software Provider deploys an initial
system onto the Connector and signs the Connector’s corre- 4.1.3.3.2.1 CONFIGURATION
sponding service CSRs for the initial system. Among other things, the configuration specifies from where
the Connector downloads new services, or which Brokers or
4.1.3.3.1.4 APP STORE Online Certificate Status Protocol (OCSP)43 servers it uses.
A Connector downloads the software it requires (i.e. Data Configuration is required in order to boot the system. It is ex-
Apps) from an App Store. Connectors can only connect with ecuted during the Connector’s deployment.
the App Store for requesting downloads and updates. As the
App Store is a Connector itself, it additionally stores its own 4.1.3.3.2.2 CA CERTIFICATES
sub-CA. When a new provider sets up an App Store, the Iden- In order to verify PKI signatures (e.g., for authentication or for
tity Provider signs a sub-CA request issued by the App Store Data Apps that were downloaded), the Connector stores the
provider. The App Store provider deploys this sub-CA inside trusted root certificates (Service Root CA and Software Sign-
the App Store (i.e., inside the respective Connector). This sub- ing Root CA) in a way their integrity is preserved (Figure 4.7).
1

43
https://tools.ietf.org/html/rfc6960

075 //
 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL // 4.1

4.1.3.3.3.3 APPS prove every new App Store. The CSR identifies the App Store
Apps offered in the International Data Spaces run inside iso- and makes it possible to sign the service CSRs from the Con-
lated containers (see section 3.5.1.2 for details). The Connec- nectors requesting apps.
tor creates a key pair for every App it downloads. The private
key protects the App’s persistent data. When downloading an 4.1.3.3.4 APP DEVELOPMENT AND DEPLOYMENT
App from the App Store, the Connector creates a CSR using The following steps describe the lifecycle of Data Apps used in
the public key. The App Store signs the CSR and issues a cer- the International Data Spaces, from an app’s development to
tificate. The Connector uses this certificate to make sure that its deployment onto a Connector (Figure 4.8):
the App it is running is valid (i.e., licensed, not expired, etc.).
1. The Identity Provider signs a key pair and a certificate for
An App is a generalization of the following types of software: each Software Provider on behalf of the International Data
Spaces Association. When the app is fully developed and
»» Core System: Every Connector runs exactly one Core Sys- ready for being offered, the Software Provider signs the
tem. The Core System, together with its certificate, is de- app using its private key, before the signed app is sent to a
ployed during the Connector’s deployment after being re- trusted Certification Body.
trieved from the Software Provider providing the Connector.
The Core System’s certificate identifies the underlying 2. If the Certification Body approves the app, a second signa-
hardware device. The Core System can connect to other ture is added to it.
Connectors (e.g., to communicate with the App Store for
app downloads). When a Connector establishes a commu- 3. The Software Provider uploads the app to an App Store;
nication channel with another Connector, it uses the Core the app thereby becomes an IDS Data App. The App Store
System’s private key and certificate for authentication. only accepts valid (i.e., correctly signed) Data Apps (since
the App Store is a Connector with corresponding root CAs,
»» Data App: A Data App is any data processing or data it is able to verify all signatures).
collecting app, or a System Adapter.
4. A Connector downloading the Data App connects with the
»» Broker: A Broker is a Connector providing a broker service. App Store. The Connector creates a service key pair and a
CSR, requests a service download, and sends the CSR to
»» OCSP Server: A Connector is considered an OCSP Server if the App Store. The App Store signs the CSR using the ser-
it runs the OCSP Server app. vice sub-CA and returns it to the Connector.

App Store: An App Store has a service sub CA. The Interna- 5. The Connector downloads the service and checks its signa-
tional Data Spaces Association signs this CSR in order to ap- tures. If the signatures are found to be valid, the Connec-
tor installs the service. From now on, the downloading
Connector can check the validity of the downloaded ser-
vice based on the certificate received.

4.1.3.3.5 DELIVERY OF CONNECTORS

After initial deployment, the Connector is delivered to the Op-
erator in a fully preconfigured state (Figure 49). For deploy-
ment of the Connector, every approved Software Provider
has a sub-CA key pair and CSR (similar to an App Store Provid-
er) to sign the initial system. When the Identity Provider signs
the CSR of the sub-CA, it confirms the requesting Software
Provider as being compliant with International Data Spaces
regulations and policies. The Operator of a Connector (e.g.,
a Data Provider) can change the configuration, the root cer-
Figure 4.7: Connector roles and manifestations tificates, and even the Core System as deemed appropriate.

076 //
 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL // 4.1

Figure 4.8 Software development, approval, and download process

Figure 4.9: Delivery of a Connector

077 //
 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL // 4.1

4.1.3.3.6 CONNECTOR SECURITY PROFILES To define a “common sense” for every IDS Participant and
Static security levels would make it necessary to anticipate all Connector, and to distinguish the different Security Profiles,
possible needs of every Participant, now and in the future. four dimensions are defined:
Since the IDS is designed to grow over time, and remain flex-  
ible with regard to the individual security needs of every par- »» Development, relating to the requirements and capabili-
ticipant, it offers the possibility to base access control deci- ties regarding the development of components;
sions on fully customized criteria. Access control policies can
be based on a set of attributes of the requesting Connector. »» IDS Roles supported, relating to the IDS Roles (as de-
Besides a unique identifier, these attributes include a set of scribed in section 3.1) supported by the respective Security
properties describing the security level of Data Apps as well Profile;
as the security properties of the technical setup of the Con-
nector and the organizational capabilities of the Participant. A »» Communication abilities supported, specifying the com-
set of security properties is called a Security Profile. munication features supported by the respective Security
Profile; and
A Security Profile comprises attributes of the Connector and
may be used in an attribute-based access control policy. Each »» Higher security features, specifying the security level pro-
Connector must provide its Security Profile upon request. The vided by the respective Security Profile.  
Security Profile must never be empty.
The attributes of the Security Profiles are listed in Appendix B
A Security Profile contains the following properties: of this document.

»» It describes the Connector’s current security configuration.

»» It allows Data Consumers to decide whether they are will-

ing to rely on data provided by a Data Provider’s endpoint.

»» It allows Data Providers to decide whether they are willing

to make sensitive data available to a Data Consumer.

The IDS-RAM defines four different Security Profiles: Base

Free, Base, Trust, and Trust+ (Managed Trust):

»» The “Base Free” Security Profile allows using IDS concepts

and technologies outside the trusted business ecosystem
(e.g. for research projects or for operation within a partic-
ular security domain like an internal company network).

»» The “Base” Security Profile defines the mechanisms re-

quired for a minimum level of trust, including the certifica-
tion process.

»» The “Trust” Security Profile allows definition of extended

security features.

»» The “Trust+” (Managed Trust) Security Profile relies on

trusted hardware based on TPM.

More profiles may be added in the future.

078 //
 Base Free Base Trust Trust+

Development Developed as Open Developed in the Developed in the Developed in the

Source IDSA Community IDSA Community IDSA Community
and bound to strong
SLA regarding securi-
ty updates.

IDS Roles supported Not certified, there- All IDS Roles (section All IDS Roles (section All IDS Roles (section
fore the public IDS 3.1.1) supported, but 3.1.1) supported, 3.1.1) supported,
infrastructure is not support for Clearing
available House is optional

Communication Cannot connect to Can connect to other Can connect to other Can connect to other
abilities supported public IDS services connectors and connectors and connectors and
or connectors. exchange data. exchange data. Can exchange data. Can
refuse a connection refuse a connection
with a Connector with a Connector
with Base Profile. with Base Profile.

Higher security Security level not Standard security Extended security High security level
features defined level level

Table 4.1: Overview of IDS Security Profiles and related dimensions

079 //
4.1.3.4 TRUSTED PLATFORM 4.1.3.4.1 ISOLATION AND REMOTE EXECUTION
The International Data Spaces consists of multiple GUARANTEE
manifestations of the Connector Architecture (as used by e.g. Isolation is a form of integrity enforcement for a Data App’s
the Broker or the App Store). This is why a trusted platform runtime environment. Data Apps can be isolated against each
is a central element of trustworthy data exchange. A trusted other by deploying each one inside a separate container (or
platform comprises certain key aspects: all Data Apps of a specific Software Provider into one contain-
er), as illustrated in Figure 410. This allows implementation
»» To be able to specify minimal requirements for Partici- of additional security features, such as time-to-live policy en-
pants that want to exchange data, a common understand- forcement for complete container instantiations.
ing of each other’s Security Profiles needs to be estab-
lished. The Connector supports mutual verification of The Connector should provide some mechanism to isolate
these profiles. Data Apps, system apps, and the core platform from each
other, in order to prevent applications from interfering with
»» To enable trustworthy execution of Data Apps and guaran- each other. Each Connector has a Security Profile attached to
tee system integrity, strong isolation of components is nec- it, describing its isolation capabilities. Users of Data Apps may
essary. The Connector’s application container manage- make data access control decisions based on the set of isola-
ment supports full isolation of Data Apps deployed, and tion capabilities stated in the Security Profile.
limitation of illegitimate communication channels. This
means that Data Apps have access only to data that is ex-
plicitly meant for them.

»» To establish a trustworthy relationship with another Partic-

ipant, and to verify Connector properties, remote integrity
verification is required. The Connector features a hard-
ware-based trust anchor and a trustworthy software stack.

Figure 4.10: Container isolation for Data Apps

080 //
 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL // 4.1

4.1.3.4.2 REMOTE INTEGRITY VERIFICATION To enable a Connector to get technically reliable informa-
During system setup, trust remains strictly limited to each tion about the integrity of the software stack and the runtime
party’s domain. Two levels of trust are supported in the Inter- configuration of another Connector, Connectors may sup-
national Data Spaces: port remote attestation for more secure Connector instantia-
tions. Trustworthy measurement is possible by using e.g. TPM
»» verification of each party’s identity by exchanging creden- 1.2/2.0 in a Connector, or equivalent security measures.
tials that originate from an entity both parties trust (e.g.,
credentials signed by a trusted PKI, or identity tokens is- 4.1.3.4.3 DYNAMIC TRUST MONITORING
sued by a trusted Identity Provider); As Remote Integrity Verification as described above can only
verify the current status and configuration of a Connector,
»» verification of the integrity of each Connector’s software Dynamic Trust Monitoring (DTM) is intended to verify the in-
stack by applying integrity measurement using trusted tegrity of a Connector for a longer period of time. In addition,
platform modules, and by remote attestation (for remote DTM is able to trigger certain actions, starting from simple no-
integrity verification, trust into the identity of a party is a tification of the Participant up to revocation of the X.509 cer-
mandatory requirement). tificate, depending on the severity of integrity violation.

Verifying the integrity of a Connector software stack (and its 4.1.3.5 DATA ACCESS CONTROL
configuration) is required for deploying trusted Data Apps. If In information security, access control restricts access to re-
platform integrity were not verified (either through certifica- sources. Authorization is the process of granting permission
tion or by technical measures), one or more of the following to resources. There are several models of access control,
problems would occur: such as Discretionary Access Control (DAC), Mandatory Ac-
cess Control (MAC), Role-Based Access Control (RBAC), Attri-
»» A Connector could pretend to run a certified and trusted bute-Based Access Control (ABAC), etc. RBAC and ABAC are
software stack in order to feign an unjustifyingly high level the most frequently used models.
of trust.
The XACML (eXtensible Access Control Markup Language)
»» A Connector might not run Data Apps as expected (i.e., the standard44 is used to introduce commonly used terms in the
Data Apps do not receive the desired amount of resources field of access control. XACML is a policy language to express
in terms of CPU and memory, and neither execution nor ABAC rules. The main building blocks of the language are sub-
communication is trustworthy); if that was the case, the ject, action, resource, and environment:
data consumed and provided by Data Apps running on an
untrusted and unattested Connector platform would not »» The subject describes who is accessing a data asset (e.g., a
be reliable. user).

»» Edge-computing use cases, where Data Consumers push »» The action describes what the subject wants to do with the
their Data Apps to the data source (i.e., onto a remote Con- data asset (e.g., read, write).
nector), would be difficult to implement, because correct
execution of these Data Apps could not be guaranteed. »» The resource describes the data asset.

»» The environment specifies the context of the action (e.g.,

time, location).

w
1

44
Standard OASIS and O. Standard, “eXtensible Access Control Markup Language (XACML) Version 3.0,” 22 January 2013. [On-
line]. Available: http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html

081 //
 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL // 4.1

Figure 4.11 illustrates the XACML data flow diagram and the In the IDS, access control is a resource-centric regulation of ac-
main actors or components to implement it: the Policy En- cess requests from subjects (i.e., IDS participants) to resourc-
forcement Point (PEP), the Policy Decision Point (PDP), the es (i.e., Data Services). Data Owners define attribute-based
Policy Information Point (PIP), and the Policy Administration access control policies for their endpoints. In addition, they
Point (PAP). define the attribute values a subject must attest in order to
grant access to the resource. These attributes may include:
»» In general, attributes can describe anything or anyone.
Nevertheless, they can be divided into four major catego- »» Specific identity of Connector(s) (only access requests
ries: from one or more specific Connectors will be granted);

»» Subject attributes, describing the user by e.g. their age, »» Connector attributes (only access requests from a Connec-
role, or clearance; tor that possesses specific attributes will be granted);

»» Action attributes, describing the intended action (e.g. read, »» Security profile requirements (only access requests from a
write, or delete); Connector that meets specific security requirements will
be granted; e.g., having a TPM >= 1.2 and doing application
»» Resource (or object) attributes, describing the resource it- isolation).
self (e.g. object type, location, or classification);

»» Context (or environment) attributes, addressing time, lo-

cation, or other dynamic aspects.

Figure 4.11: XACML data flow diagram [Source: eXtensible Access Control Markup Language (XACML) Version 3.0 ]

082 //
 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL // 4.1

The actual access control decision has to be made within the The following examples illustrate security requirements that
Connector and can be implemented using technologies such cannot be achieved by data access control, but require da-
as XACML or JAAS, depending on the implementation of the ta-centric usage control:
Connector. The IDS Security Architecture does not dictate a
specific access control enforcement language or implemen- »» SECRECY: Classified data must not be forwarded to nodes
tation. which do not have the respective clearance.

Alongside with data access control, regulating access to spe- »» INTEGRITY: Critical data must not be modified by untrust-
cific digital resources (e.g., a service or a file), the IDS Security ed nodes, as otherwise its integrity cannot be guaranteed
Architecture also supports data usage control. In general, the anymore.
overall goal is to enforce data usage restrictions on the Data
Consumer side after access to data has been granted. »» TIME TO LIVE: Data must be deleted from storage after a
certain period of time.
Usage control is an extension of access control (see figure
4.11). It is about the specification and enforcement of re- »» ANONYMIZATION BY DATA AGGREGATION: Personal
strictions regulating what may be done with a data asset, and data may be used only in an aggregated form by untrusted
what not. Thus, usage control is concerned with requirements parties. To do so, a sufficient number of distinct data re-
that pertain to data processing (obligations) rather than data cords must be aggregated in order to prevent deano-

Usage Control – An Extension to Traditional Access

access (provisions). Usage control is relevant in the context of
intellectual property protection, regulatory compliance, and
nymization of individual records.

Control digital rights management. »» ANONYMIZATION BY DATA SUBSTITUTION: Data allow-

ing personal identification (e.g., faces in video files) must
be replaced by an adequate substitute (e.g., pixelized) in
Usage order to guarantee that individuals cannot be deano-
Control
nymized.
Provisions Obligations
Access
Control »» SEPARATION OF DUTY: Two datasets from competitive
Past + Present Future Usages entities (e.g., two automotive OEMs) must never be aggre-
gated or processed by the same service.

Figure 4.12: Data usage control – an extension of

data access control »» USAGE SCOPE: Data may only serve as input for data pipes
within the Connector; it must never leave the Connector
and be sent to an external endpoint.
Data usage control in the IDS basically works by attaching
data usage policy information to data being exchanged and It is important to note that the purpose of data usage control
continuously controlling the way data is processed, aggregat- is to allow the specification of such constraints and enforcing
ed, or forwarded to other endpoints. This data-centric per- them in the respective system. A precondition of data usage
spective allows Data Providers to continuously control data control is that the enforcement mechanism itself is trusted;
flows, rather than accesses to services. At configuration time, i.e., data usage control itself does not establish trust in an
data usage policies support developers and administrators in endpoint, but rather builds upon an existing trust relation-
setting up correct data flows. ship and facilitates enforcement of legal or technical require-
ments, such as service level agreements (SLAs) or data privacy
At runtime, data usage control enforcement prevents IDS regulations. Thus, users must be aware that data usage con-
Connectors from handling data in an undesired way (for ex- trol will only provide certain enforcement guarantees if ap-
ample, by forwarding personal data to public endpoints). plied on highly trusted platforms, such as Trusted Connectors
Thus, data usage control is both a tool for system integrators in the International Data Spaces (see Section 3.2).
to ensure they are not building an architecture that violates
security requirements, and an audit mechanism providing ev-
idence of compliant data usage.

083 //
 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL // 4.1

4.1.3.6.1 TECHNICAL ENFORCEMENT, ORGANIZATIONAL 4.1.3.6.2 ENFORCEMENT

RULES, AND LEGAL CONTRACTS To enforce data usage restrictions, a system’s actions need to
Data usage control can be implemented by means of a ma- be monitored and potentially intercepted by control points
chine-readable contract, which is expected to be fulfilled by (i.e., Policy Enforcement Points, PEPs). These actions must
a party. It is a way to track and trace data as it is used within be judged by a decision engine (i.e., a Policy Decision Point,
different systems and to collect evidence of the violation of PDP) for requesting permission or denial. In addition to just
agreed usage constraints. With that in mind, solutions range allowing or denying an action, the decision engine may also
from organizational rules or legal contracts to completely require modification of the action. A PEP component encap-
technical ways of enforcing usage restrictions. For example, sulates the enforcement.
an organizational rule (e.g. a company policy) could state that
employees must not use removable storage devices, such as 4.1.3.6.2.1 DECISION AND INFORMATION
USB sticks. Similarly, a technical form of enforcement, such Enforcement relies on a decision. The PDP has the respon-
as group policies specified by the Windows operating system, sibility to answer incoming requests (e.g., system actions)
can prevent employees from using removable storage devic- from a PEP in the form of a decision (see Figure 4.14). De-
es. In some scenarios, organizational rules, legal contracts, cision-making based on usage restriction is also called (poli-
and technical rules can be used interchangeably. In other cy) evaluation. There are several types of evaluation, such as
scenarios, the three forms can be used to complement each event-based or flow-based approaches.
other. In the long run, it can be expected that organization-
al rules and legal contracts will increasingly be replaced by For event-based systems, data usage transactions are repre-
technical forms of enforcement (as illustrated in Figure 4.13). sented as events including attributes to characterize the data
usage. Event processing can be differentiated into simple pro-
Enforcement of data usage restrictions can be characterized cessing (e.g., event-condition-action paradigm) and stream

Technical Enforcement vs. Organizational / Legal

and implemented in different forms. Organizational rules or processing (e.g., sliding window) of events. The terms ”event
legal contracts can be substituted, or at least accompanied, stream processing” and “complex event processing” are often
by technical solutions, which introduce a new level of secu- used interchangeably.

Enforcement
rity. Vice versa, technical solutions can be accompanied by
organizational rules or legal contracts (e.g., to compensate
missing capabilities of the technical solution).

Although it is a commonly used solution to address data us-

age control restrictions by organizational rules, the IDS-RAM
focuses on technical enforcement.

Technical Enforcement
Organizational / Legal Enforcement
t
Figure 4.13: Technical enforcement vs. organizational/legal enforcement

084 //
 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL // 4.1

For example: It is possible to model the transition of data as The policy decision may also depend on additional informa-
an event with attributes about the data itself and the recipient. tion that is not present in the intercepted system action it-
The attributes contain metadata and information on the tar- self. This includes information about the context, such as data
get system (e.g., supplier management system). The decision flows or the geographical location of an entity. It is also possi-
engine makes a deny decision if the target system does not ble to specify pre- or post-conditions that have to hold before
correspond to the expected supplier management system. (e.g., integrity check of the environment) and after (e.g., data
item is deleted after usage) decision-making. In addition, it is
possible to define on-conditions that have to hold during us-
age (e.g., only during business hours). These conditions usual-
ly specify constraints and permissions that have to be fulfilled
before, during, and after using data (see Figure 4.15).

A Policy Information Point (PIP) provides missing information

for decision-making. In addition, such a component can be
used to get contextual information for or about the system
action intercepted (e.g., data flow information, geolocation of
the requesting device).

Figure 4.14: Communication Policy Enforcement Point and Policy Decision Point

Figure 4.15: Usage Control Pre-, On-, and Post-Conditions

085 //
 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL // 4.1

4.1.3.6.2.2 SPECIFICATION, MANAGEMENT, AND 4.1.3.6.3 USAGE CONTROL BUILDING BLOCKS

NEGOTIATION This section outlines which components the International
Another important aspect of data usage control is the specifi- Data Spaces uses to integrate data usage control technolo-
cation and management of usage restrictions. Data Providers gies. The first subsection deals with the IDS Information Mod-
have to express data usage restrictions in a more or less for- el and its modules addressing data usage control. The sub-
mal way. For technical enforcement, the specification must sequent sections are about the Trusted Connector and the
produce a machine-readable output. The Policy Administra- Apache Camel interceptor.
tion Point (PAP) is the entry point for specification of usage
policies, often via a user-friendly graphical interface. 4.1.3.6.3.1 INFORMATION MODEL
A Policy Management Point (PMP) is responsible for the man- The IDS Information Model is a modular meta-model (ontol-
agement of usage policies. Hence, the component is con- ogy) describing the capabilities of IDS infrastructure compo-
cerned with the policy’s lifecycle. This includes instantiation, nents, such as the Connector or the Data Endpoints. Descrip-
negotiation, deployment, and revocation of usage restric- tions of data provided by Data Endpoints are published at
tions, as well as conflict detection and resolution. dedicated Broker registries, allowing potential Data Consum-
There are two ways to make usage restriction information ers to search for and identify data that is relevant (semantics)
available: and applicable (quality) for their particular purpose, and to
assess in advance data’s affordability (price) and usability (re-
1. Usage restriction policy information can be attached to the strictions).
data that is about to be exchanged. This type of policy is
called sticky policy45. Following this approach, data is en- Extending the Open Digital Rights Language (ODRL)46, a W3C
crypted before it is sent to a Data Consumer, and it can standard, the Information Model’s Usage Control module
only be decrypted if the Data Consumer fully and explicitly provides machine-readable specifications of usage control
accepts the usage restrictions specified. policies (see section 3.4.4.1.1). These specify actions that a
party is prohibited or permitted to do with regard to given
2. A usage restriction policy can be stored independently of a data asset. In addition, they codify any potentially involved
the data it relates to (for instance, in a central component, duties. Despite a simple core model, which is depicted in Fig-
such as a PMP/PRP). In this case, the management compo- ure 416, ODRL policies are a formal way to declaratively ex-
nent has the responsibility to exchange usage restriction press usage contracts at a specification level. This way, the In-
information between different systems. formation Model provides a technology-agnostic, consistent
representation of usage control policies across the Interna-
The management of usage policies becomes especially im- tional Data Spaces.
portant when data is to be exchanged across system bound-
aries. Every time data crosses system boundaries, the target In order to implement and enforce usage policies at a specifi-
system must be prepared for the protection of incoming data cation level within individual target environments, it is neces-
(i.e. it has to deploy the corresponding policy). sary to map organizational and technical measures to the in-
dividual target environments. While organizational measures
Policy negotiation is also part of policy management. As en- are out of scope here, technical measures involve a variety
forcement mechanisms can work differently across different of additional information sources (PIPs) and tight integra-
systems or technologies, abstract policies may have different tion with the host environment (PEPs). Here, the Information
instantiations. Hence, usage policies must always be instanti- Model enhances ODRL constructs via predefined extension
ated on the target system. “hooks” to support mapping onto lower-level, implementa-
1.
1
tion-oriented policy languages (e.g., IND²UCE XML).

45
M. C. Mont and S. Pearson, “Sticky Policies: An Approach for Managing Privacy
across Multiple Parties,” Computer, pp. 60-68, 09 September 2011.
46
R. Iannella, S. Guth, D. Paehler and A. Kasten, “ODRL Version 2.1 Core Model,” 05 03 2015. [Online]. Available:
https://www.w3.org/community/odrl/model/2.1/.

086 //
 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL // 4.1

Figure 4.16: ODRL Core Model 2.1 (ODRL Version 2.1 Common Vocabulary Final Specification: 5 March 2015)

For example, the ODRL Constraint class expresses logical con-

ditions that govern the applicability of a Rule. Here, an Oper-
ator (eq) relates the Left Operand (a predicate like absolute-
Position) to a Right Operand (dynamic or predefined value).
On the one side, the Information Model extends the group of
predefined predicates47 in order to support decision-making
in particular scenarios of the IDS, such as data residency48; on
the other side, it defines a configuration overlay (b) to tie the
abstract predicates (a) to an operable programming logic sup-
plied by the respective target environment (c), as illustrated
Figure 4.17: Examples of mapping among policy language levels
by Figure 4.17.

47
R. Iannella, M. Steidl, S. Myles and V. Rodríguez-Doncel, “ODRL Vocabulary & Expression -
3.14.9 Left Operand,” 26 09 2017. [Online]. Available: https://www.w3.org/TR/odrl-vocab/#term-LeftOperand.
48
The Object Management Group, “Data Residency Working
Group,” [Online]. Available: http://www.omg.org/data-residency/.

087 //
 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL // 4.1

4.1.3.6.3.2 TRUSTED CONNECTOR wwThe Trusted Connector guarantees a controlled execution

Usage control only makes sense in an ecosystem where a environment for data services and supports the creation of
certain level of trust can be established and maintained for trusted relationships. A general constraint is one that remains
all participants. To enable the establishment of trusted rela- for all deployed IT systems: As long as physical or logical ac-
tionships, the central technological components used for data cess is granted to administrators, protection against data
processing and data exchange need to be trustworthy. The theft by malicious partners is almost impossible to prevent.
IDS Connector is the central component for data exchange The International Data Spaces is seen as a network of part-
and data processing in the International Data Spaces, and ners that are provided with the technical means to fulfill their
thus a central component that needs to be trusted. obligations and support in deciding what partners to trust
and to define reasonable access conditions.
The IDS Connector (see previous sections) focuses on security
and delivers a trusted platform, incorporating crucial build- 4.1.3.6.3.3 APACHE CAMEL INTERCEPTOR (EXAMPLE)
ing blocks: An IDS Connector may use Apache Camel to coordinate the
data flow between different systems and applications. From
»» identity & trust management for authenticating communi- a technical point of view, the developer does this by using
cating parties (e.g., other Connectors) and shaping trusted pipelining, which is a dominant paradigm of Apache Camel
relationships between partners; for connecting different nodes in a route definition. The ba-
sic idea of a pipeline is that Apache Camel uses the output
»» a trusted platform as a baseline for secure data process- of one node as input to the next node. Every node in such a
ing; route is a processor, except for the initial endpoint (as shown
in Figure 4.18).
»» trustworthy communication based on authenticated and
encrypted connections; and

»» access & usage control.

Instances of the Trusted Connector enable remote integrity

verification, so the integrity of the deployed software stack
can be guaranteed before granting access to data.

Figure 4.18: Apache Camel pipeline (example)

088 //
 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL // 4.1

In order to control the usage of data, one approach can be

to intercept the data flow between the services and applica-
tions. Figure 4.19 shows as example of how developers can
do this. Apache Camel offers the possibility to integrate inter-
ceptors that it executes every time before and after a proces-
sor is working.

As the International Data Spaces provides an Information

Model (see Section 3.1), additional metadata enhances the
data transferred via the route, thereby enabling better usage
control enforcement. The Connector attaches the metada-
ta to the data package, as explained in section 3.4. In addi-
tion, a PIP is able to resolve more metadata during the deci-
sion-making process if necessary.

Figure 4.19: Intercepting Apache Camel data flows

This paradigm also works across company borders, as data

always flows through the IDS Connector and the Apache Cam-
el interceptor, respectively (as shown in Figure 4.20). When
reaching the receiving Connector, the respective policy to
protect the data is automatically instantiated.

Depending on the policies available, this way of enforcement

is not enough to cover all possible use cases and full usage
control.

Figure 4.20: Data flow across company borders

089 //
 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL // 4.1

4.1.3.6.4 ROLES INVOLVED IN USAGE CONTROL This kind of traceability is similar to the data protection re-
Usage control is a cross-sectional concept and technology, quirements a data controller is confronted with, so as to be
which involves several IDS Roles. able to fulfill its data subjects’ right to access. It is also closely
related to the question of proving compliance with contracts,
BROKER agreements, or legal regulations. And data provenance track-
The IDS Broker manages connector self-descriptions that can ing can be used to facilitate clearing in decentralized data eco-
contain Usage Policies. Therefore the Broker must be able systems, since it is capable of aggregating information con-
to support Usage Policies. In addition the connector self-de- cerning data exchange transactions and data usage.
scription itself may be subject of Usage Policies.
However, while distributed data usage control is concerned
CONNECTOR with the enforcement of rights and duties when exchang-
The Connector is the main technical component for imple- ing data across system boundaries, the focus of data prove-
menting usage control. Hence, usage control enhanced Con- nance tracking is on transparency and accountability. In oth-
nectors, such as the Trusted Connector, contain relevant er words: While a Policy Enforcement Point (PEP) serving for
components to perform usage control enforcement as Data distributed data usage control in most cases needs to be able
Consumer (PEPs, such as the Apache Camel interceptor; PDPs, to proactively intercept data usage actions within the control
PMPs). However, PMPs and PDPs need not be part of the Con- flow (i.e. preventive enforcement), a PEP for data provenance
nector. In addition, Connectors as Data Providers should pro- tracking only needs to passively observe, interpret and log
vide the technology-dependent policies to the data they pro- data exchange transactions and data usage for retrospective
vide – for all kinds of systems and enforcement technologies examination (in terms of usage control, this kind of enforce-
that are part of the ecosystem. ment is denoted as “detective enforcement”). Despite this
fact, a data provenance tracking infrastructure can be built
CLEARING HOUSE upon the same PEPs as distributed data usage control. Fur-
By means of Data Provenance Tracking (as described in the thermore, data provenance tracking does not require a policy
next section), it is possible to track the usage of data and the specification language, but rather a specification of how ob-
enforcement of usage restrictions. The Clearing House is able served actions are to be interpreted in terms of data flow or
to use this data later on. data usage (i.e., a so-called data flow semantics specification).
By this, data provenance tracking maintains a data flow mod-
APP STORE el that keeps track of the particular representations of data
Data Apps can take advantage of usage control technology. items. This kind of information can also be leveraged for data
The IDS App Store needs to be able to provide information as usage control enforcement; i.e., the data flow model is imple-
to whether a Data App implements such technology. mented as a Policy Information Point (PIP).

APP PROVIDER 4.1.3.7.1 OPERATING PRINCIPLE

For Data Apps to take advantage of usage control technology, The operating principle of data provenance tracking is very
App Providers need to implement certain components, such similar to the operating principle of distributed data usage
as control points (i.e., PEPs), into their application. control. Data provenance tracking relies on passive mon-
itoring technology (e.g., PEPs), which deliver events indicat-
4.1.3.7 DATA PROVENANCE TRACKING ing data usage or data flows for being logged. For this, a PEP
Data provenance tracking is closely related, but also comple- needs to convey a semantic description of the data usage or
mentary to distributed data usage control. It has its origins in data flows its events indicate. The data provenance track-
the domain of scientific computing, where it was introduced ing infrastructure provides a data flow tracking component,
to trace the lineage of data. Data provenance tracking thereby which understands such semantics specifications. The PEP
allows finding out when, how and by whom data was modi- also needs to forward events together with metadata (includ-
fied, and which other data influenced the process of creating ing a unique identifier of the data’s content), so that logged
new data items. transactions can be attributed to data content when data
provenance is aggregated or queried.

090 //
 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL // 4.1

4.1.3.7.2 ARCHITECTURE
The PEP resides within the message routing component of the
Connector (or Data App). It is registered at the data flow track-
ing component via a registry component (i.e., a local Policy
Management Point, PMP). The same applies for the data flow
tracking component. Thereby a PEP can query the local PMP
for the communication interface of the local data flow track-
ing component, which is then used to deploy semantics spec-
ifications for its observed events and to forward actual events
during operation.

Figure 4.21: Architecture with centralized component for provenance information storage

Figure 4.22: Architecture with distributed component for provenance information storage

091 //
 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL // 4.1

Data provenance information is queried at a Privacy Dash- 4.1.3.7.4 INTEGRATION WITH DISTRIBUTED USAGE
board, which is accessible via a Clearing House. The Privacy CONTROL
Dashboard returns a provenance graph for the unique iden- In complex usage control scenarios, such as establishing data
tifier of data content. There are two options for storing data sovereignty for managing globally distributed supply chains,
provenance information: data is passed on from one Data Consumer to another. De-
pending on the usage control policy in place, data may be
»» Centralized architecture (see Figure 4.21): A Provenance forwarded in its original form, or it may be somehow pro-
Storage Point (ProSP) is attached to the Clearing House. cessed, aggregated, or anonymized before being forwarded.
After data usage or a data flow has been observed by the This indicates the relevance of establishing transparency con-
data flow tracking component inside the Connector, the cerning data flows and data usage in compliance with usage
transaction is logged at this ProSP. control policies, business contracts, or legal regulations. For
this purpose, distributed data usage control and data prove-
»» Distributed architecture (see Figure 4.22): Each Connector nance tracking complement each other. As explained before,
is equipped with a ProSP, which is directly connected to the the PEPs used for usage control (detective enforcement) can
data flow tracking component. The Clearing House accom- also serve as a basis for data provenance tracking, whereas in
modates only a stateless Provenance Collection Point turn data provenance information can be fed back into usage
(ProCP), which aggregates provenance information com- control enforcement (i.e., a usage control PDP can query for
ing in from the distributed ProSPs whenever a query oc- all locations of representations of some given data content
curs at the Privacy Dashboard. protected by a usage control policy).

4.1.3.7.3 COMMUNICATION Further synergies can be exploited by employing the same

The local data flow tracking component inside the Connec- communication infrastructure for distributed data usage
tor has to be able to communicate with the centralized data control and data provenance tracking. The hierarchical PMP
provenance infrastructure (i.e., ProSP or ProCP). For this, a so- structure (as described in the previous section) can also en-
called Root-PMP is attached to the Clearing House. Here, the able usage control components to interact across different
central components register their communication interfaces, IDS Connectors (e.g., for shipping policies to other Connec-
and so do the local PMPs of the Connectors. Using these in- tors, deploying and revoking policies, etc.).
terfaces, provenance information is passed on to the central
ProSP/ProCP.

Analogous to this hierarchical communication infrastructure,

the provenance information of each unit of data content is
a tree, a so-called provenance graph. It is either maintained
at a central ProSP or at the distributed ProSPs located inside
the Connectors. In the latter case, a centralized ProCP at the
Clearing House aggregates the various sub-trees for a unique
data content identifier from distributed ProSPs (i.e. it consol-
idates the provenance information by merging the subtrees).

092 //
 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL // 4.1

4.1.3.7.5 DATA PROVENANCE TRACKING ADDRESSED

BY THE DIFFERENT LAYERS OF THE IDS-RAM

4.1.3.7.5.1 BUSINESS LAYER

Data provenance tracking primarily supports the work of the
Clearing House. It provides the means to establish a central-
ized audit log aggregating tracking information concerning
data exchange transactions and data usage.

4.1.3.7.5.2 FUNCTIONAL LAYER

Data provenance tracking does not directly affect the core
functionality of the IDS, since it is typically implemented on
top of a usage control infrastructure, or based on passive
monitoring technology. However, data provenance tracking
may enhance the functionality of the IDS by offering func-
tions for clearing and accounting, provided tracking is suffi-
ciently accurate (e.g., in terms of delivering concrete numbers
of data users or a concrete duration of data use). Data Apps
might also be considered as content/data the usage of which
can be tracked by data provenance technology.

4.1.3.7.5.3 PROCESS LAYER

Data provenance tracking is integrated in the “Exchange Data”
process (or, to be more precise, in the “Query Data” sub-pro-
cess). Data provenance tracking components in the Connec-
tor of the Data Provider as well as in the Connector of the
Data Consumer signal to the data provenance storage com-
ponent at the Clearing House that data has been successfully
sent or received, respectively. This signaling is implemented
based on events intercepted by PEPs for distributed data us-
age control.

4.1.3.7.5.4 INFORMATION LAYER

Data provenance tracking can be orchestrated for different
purposes. Regarding the IDS, the most important goals are
establishing transparency and being able to prove compli-
ance to contracts, agreements, or legal regulations. Reliability
of content is a secondary goal of data provenance tracking
in the IDS. While making the lineage of data traceable is the
original purpose of data provenance tracking, this requires ei-
ther specific, data provenance enabled Data Apps or the use
of dedicated PEPs for these Data Apps.

4.1.3.7.5.5 SYSTEM LAYER

Reliability of data provenance information strongly depends
on trustworthy Connectors and Data Apps (including their
PEPs). It is recommended to integrate data provenance track-
ing into Trusted Connectors and to certify Data Apps that are
enabled for data provenance tracking and data usage control.

093 //
 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL // 4.2

4.2 CERTIFICATION PERSPECTIVE FUNCTIONAL LAYER

The functional requirements of the International Data Spac-
es are the core requirements expected to be implemented
Data security and data sovereignty are the fundamental val- by the technical core components (e.g., the Connector or the
ue propositions of the International Data Spaces. Data sov- Clearing House). Therefore, compatibility of each such imple-
ereignty can be defined as a natural person’s or legal entity’s mentation with these functional requirements forms the ba-
capability of being in full control of its data. Therefore, any or- sis of the compliance part of a core component’s certification.
ganization or individual seeking permission to access the In- The security part of the certification focuses on security spe-
ternational Data Spaces is certified, and so are the core soft- cific requirements. As for the Security Perspective (see Sec-
ware components (e.g., the IDS Connector) the participants tion 4.1), these security specific requirements are mainly re-
use to securely exchange data with one another While the cer- lated to the System Layer.
tification of organizations and individuals focuses on security
and trust, the certification of components also refers to com- PROCESS LAYER
pliance with technical requirements ensuring interoperability. Whenever relevant for the compliance part of a compo-
nent’s certification, a component is also evaluated in terms
To ensure a consistent process in the certification of par- of whether it fully supports all processes it is involved in, as
ticipants and core components, the IDS uses a Certification defined by the Reference Architecture Model.
Scheme comprising all processes, rules, and standards gov-
erning the certification process. The IDS Certification Scheme INFORMATION LAYER
follows best practices from other, internationally accredited Certification of a core component comprises also its compli-
certification concepts. ance with the Reference Architecture Model regarding func-
tionality, protocols, etc. Whenever relevant, evaluation of a
core component’s compliance also refers to its compatibility
with the Information Model defined at the Information Layer.
4.2.1 CERTIFICATION ASPECTS
ADDRESSED BY THE SYSTEM LAYER
DIFFERENT LAYERS OF The System Layer defines the possible interactions between

THE IDS-RAM the components, detailed requirements for the Connector,

and specific types of Connector implementations. The System
Layer is the predominant layer regarding the security part of
BUSINESS LAYER a component’s certification.
The Certification Body and the Evaluation Facility are in charge
of the certification process. Their interactions and responsibil-
ities in this process are described in section 4.2.2.

Organizations assuming a role under one of the three cate-

gories Core Participant, Intermediary, and Software/Service
Provider (see Section 3.1.1) are potential targets of certifica-
tion. The IDSA Whitepaper Certification49 describes for each
role what level of certification is required and what the focus
of the certification is.
1

49
IDSA White Paper Certification – Framework for the IDS Certification Scheme, Version 2.0
https://www.internationaldataspaces.org/publications/whitepaper-certification/

094 //
 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL // 4.2

4.2.2 CERTIFICATION PROCESS certification process are outlined in the following paragraphs.
An in-depth description of their responsibilities can be found
in Part 1 of the White Paper Certification50.
Figure 4.23 outlines the basic structure of the certification
process, together with the roles involved in this process. The It should be noted that all roles described in this section are
Certification Body and the Evaluation Facility belong to the specific to the International Data Spaces (i.e. terms such as
“Governance Body” category specified on the Business Layer “Certification Body” should not be misunderstood to refer to
(see section 3.1.1). The tasks of these roles with regard to the an existing organization already granting certificates).

Competence Monitoring

International Data
Spaces Association

Quality Assurance &

Framework Governance

Certification
Body

Evaluation
Fieldwork

Evaluation Evaluation Evaluation

Facility #1 Facility #2 Facility #n

Applicant #1 Applicant #2 Applicant #n

Figure 4.23: Certification process

Figure 1: Industrial Data Space Certification - Roles & Responsibilities

// 1

50
IDSA White Paper Certification – Framework for the IDS Certification Scheme, Version 2.0
https://www.internationaldataspaces.org/publications/whitepaper-certification/

095 //
 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL // 4.2

CERTIFICATION BODY CERTIFICATION PROCESS

The Certification Body oversees the certification process re- The certification process is divided into the following three
garding quality assurance and framework governance. It de- phases:
fines standard evaluation procedures and supervises the ac-
tions of the Evaluation Facilities. A certificate is granted only »» Application Phase: The main goal of this stage is the suc-
if both the Evaluation Facility and the Certification Body have cessful start of the IDS evaluation and certification process.
come to the conclusion that all preconditions for certification
are fulfilled. »» Evaluation Phase: The main goal of this stage is the evalu-
ation of an applicant or core component based on the de-
EVALUATION FACILITY fined evaluation criteria.
Contracted by an Applicant (see below), the Evaluation Facil-
ity is responsible for carrying out the detailed technical and/ »» Certification Phase: The main goal of this stage is the ex-
or organizational evaluation work during a certification pro- amination of the evaluation report by the certification
cess. The Evaluation Facility issues an evaluation report for body, which issues a certificate if the result of the evalua-
the respective organization/individual or core component, tion process is positive.
listing details regarding the evaluation process as well as in-
formation regarding the confirmed security level (the latter After a successfully completed evaluation process, the Certi-
determines the depth and scope of the evaluation activities fication Body awards an International Data Spaces certificate
performed). to the applicant. This certificate has a limited validity period.
In order to renew a certificate before it expires, re-certifica-
The term “Evaluation Facility” refers both to authorized audi- tion is required, taking into account any relevant external de-
tors for management system evaluations (i.e., for participant velopments that have happened in the meantime. Similarly,
certifications) as well as approved evaluators for product re-certification is required if changes are made to the target
evaluations (i.e., for core component certifications). Hence, of certification.
the Certification Body oversees and cooperates with multiple
Evaluation Facilities. However, in each evaluation of an orga- For authentication and authorization, each IDS component
nization/individual or core component only one Evaluation must have a valid X.509 certificate. These technical certifi-
Facility is involved. cates digitally represent the evaluation certificate and enable
automated trust checks between partners prior to data trans-
APPLICANT fer within the International Data Spaces.
The Applicant is not just the subject of the evaluation and cer-
tification process, but plays an active part in it. A more detailed description of the phases and the issuing of
digital certificates can be found in Part 1 and 4 of the White
An Applicant needs to actively submit an application to trig- Paper Certification51.
ger the certification process. This applies to organizations/in-
dividuals that develop software components intended to be
deployed within the International Data Spaces (i.e., prospec-
tive Software Providers) and to organizations that intend to
become IDS Participants

51
IDSA White Paper Certification – Framework for the IDS Certification Scheme, Version 2.0
https://www.internationaldataspaces.org/publications/whitepaper-certification/

096 //
 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL // 4.2

4.2.3 CERTIFICATION OF
PARTICIPANTS AND CORE
COMPONENTS

PARTICIPANT CERTIFICATION
Participants in the International Data Spaces collaborate by
exchanging and sharing valuable data. For this collaboration,
the IDS provides a trusted business ecosystem. Furthermore,
it is essential for the International Data Spaces and its reputa-
tion that the participants themselves are trustworthy. This is
achieved by evaluating each participant regarding fulfilment
of defined levels of security, including infrastructure reliabili-
ty and process compliance.

To build this trust in a structured way, the International Data

Spaces has established a well-defined process for participant
certification. An in-depth description of the certification pro-
cess (also with regard to each role) can be found in Part 2 of
the White Paper Certification52. The participant certification
criteria catalog is available for free to all IDSA members.

CORE COMPONENT CERTIFICATION

Core components to be used in the IDS must provide the re-
quired functionality and level of security. The certification
of core components focuses on interoperability and securi-
ty, while aiming to strengthen the development and mainte-
nance process of these components.

To build this trust in a structured way, the International Data

Spaces has established a well-defined process for core com-
ponent certification. An in-depth description of the certifica-
tion process, and how it applies to the key elements of the IDS
architecture, can be found in Part 3 of the White Paper Certifi-
cation. The core component certification criteria catalogue is
available for free to all IDSA members.

52
IDSA White Paper Certification – Framework for the IDS Certification Scheme, Version 2.0
https://www.internationaldataspaces.org/publications/whitepaper-certification/

097 //
 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL // 4.3

4.3 GOVERNANCE PERSPECTIVE data ecosystem. It supports collaborative governance mech-

anisms, so that the common service and value propositions
are achieved, while protecting the interests of all actors.
The Governance Perspective of the Reference Architecture
Model defines the roles, functions, and processes of the In- As innovative business models and digital, data-driven ser-
ternational Data Spaces from a governance and compliance vices require enhanced data management capabilities, the
point of view. It thereby defines the requirements to be met role of data governance is increasingly receiving attention.
by the business ecosystem to achieve secure and reliable cor- Therefore, the management of data related resources by
porate interoperability. This chapter provides an overview means of decision rights, accountabilities, roles, and owner-
of how central questions of governance are defined on each ship makes data governance a fundamental element in the
layer of the Reference Architecture Model (see section 3). In International Data Spaces ecosystem. To manage data under
particular, it describes how the International Data Spaces en- consideration of business needs and the existing digital in-
ables companies to define rules and agreements for compli- frastructure, data governance, being a leadership function of
ant collaboration. data management, acts as an enabler for successfully engag-
ing in a collaborative ecosystem. It is therefore necessary to
While the International Data Spaces enables all participants establish suitable organizational structures and procedures
to act in compliance with negotiated rules and processes, it that determine who makes what kind of decisions concerning
does not make any restrictions or enforce predefined reg- data assets, and which responsibilities and accountabilities
ulations. The architecture of the International Data Spaces are associated with these decisions.
should be seen as a functional framework providing mech-
anisms that can be customized by the participating organiza- In this context, organizations are confronted with new chal-
tions according to their individual requirements. lenges. Innovative, data-driven business solutions often
require that data is increasingly used outside of the orga-
The International Data Spaces supports governance issues by nization. This development transcends organizational bound-
aries, as internal data is used externally, and vice versa. At the
»» providing an infrastructure for data exchange, corporate in- same time, this creates new forms of collaboration in data
teroperability, and the use of new, digital business models; ecosystems. Various actors, such as original equipment man-
ufacturers (OEMs), suppliers, or third-party vendors interact
»» establishing trustworthy relationships between Data Own- with each other and contribute to fulfilling a common value
ers, Data Providers, and Data Consumers; proposition.

»» acting as a trustee for mediation between participants; From an internal perspective of one single organization, the
execution and allocation of decision rights for the manage-
»» facilitating negotiation of agreements and contracts; ment and use of data manifests itself within organizational
structures. They ensure that relevant guidelines and princi-
»» aiming at transparency and traceability of data exchange ples regarding data assets are in place and monitored. How-
and data use; ever, traditional instruments for assigning decision rights and
accountabilities in terms of data usually do not reach beyond
»» allowing private and public data exchange; an organization’s borders. Thus, the influence of authority for
the individual actor within a data ecosystem might be limited.
»» taking into account individual requirements of the partici- The IDS-RAM addresses this challenge in a federated manner
pants; and by distributing decision rights for data governance and man-
agement activities to the different roles in the International
»» offering a decentralized architecture that does not require Data Spaces ecosystem. It thereby supports the requirements
a central authority. to be met by the actors within the ecosystem to achieve se-
cure and reliable interoperability as well as desirable behav-
The Governance Perspective in the context of the IDS-RAM re- ior regarding the use of data. 
lates to concepts from an organizational and technical point
of view to establish the development of a healthy and trustful

098 //
 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL // 4.3

4.3.1 GOVERNANCE ASPECTS PROCESS LAYER

Providing a dynamic view of the architecture, the Process Lay-
ADDRESSED BY THE
er (see Chapter 3.3) describes the interactions taking place
DIFFERENT LAYERS OF between the different components of the International Data
THE IDS-RAM Spaces. The three major processes described in the Process
Layer section (onboarding, exchanging data, and publishing
BUSINESS LAYER and using Data Apps) are directly related to the Governance
The Business Layer (see Chapter 3.1) facilitates the develop- Perspective, as they define its scope regarding the technical
ment and use of new, digital business models to be applied architecture.
by the Participants in the International Data Spaces. It also
specifies the roles within the IDS. Thereby, it is directly relat- INFORMATION LAYER
ed to the Governance Perspective by considering the business The Information Layer (see Chapter 3.4) specifies the Infor-
point of view regarding data ownership, data provision, and mation Model, which provides a common vocabulary for
data consumption, and by describing core service concepts Participants to express their concepts. It thereby defines a
such as data brokerage. framework for standardized collaboration and for using the
infrastructure of the International Data Spaces for estab-
FUNCTIONAL LAYER lishing individual agreements and contracts. The vocabulary
The Functional Layer (see Chapter 3.2) defines the functional plays a key role in the Governance Perspective because of its
requirements of the International Data Spaces, and the con- relevance for describing data by metadata in the Internation-
crete features resulting from them, in a technology-indepen- al Data Spaces.
dent way. The IDS Connector represents the main interface
to enable participation in the ecosystem. From a governance SYSTEM LAYER
perspective, interoperability and connectivity must be en- The System Layer (see Chapter 3.5) relates to the Governance
sured to support trust, security, and data sovereignty. Beside Perspective due to its technical implementation of different
the Clearing House and the Identity Provider, which are enti- security levels for data exchange between the Data Endpoints
ties for which the relation to governance is obvious, also the in the International Data Spaces.
functionality of certain technical core components (e.g., the
App Store or the Connector) relates to the Governance Per-
spective.

099 //
 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL // 4.3

4.3.2 DATA GOVERNANCE

KEY ROLES AND CORRELATING DATA GOVERNANCE AND

MANAGEMENT ACTIVITIES
The following tables list what data governance / data manage-
ment activities central roles in the IDS ecosystem are occu-
pied with, and what IDS components are involved.

Data Owner / Data Provider

»» Define usage constraints for data resources

DG/DM activities »» Publish metadata including usage constraints to Broker
»» Transfer data with usage constraints linked to data
»» Receive information about data transaction from Clearing House
»» Bill data (if required)
»» Monitor policy enforcement
»» Manage data quality
»» Describe the data source
»» Authorize Data Provider, if Data Provider is not the Data Owner

Enabling/Supporting IDS »» IDS Connector

Component: –– Catalogue of rules allowing Data Owners to configure us-
age conditions related to their own requirements
–– Define pricing model and pricing (see section 3.4.3.9)

Table 4.2: Data governance and management activities of Data Owners and Data Providers

100 //
 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL // 4.3

Data Consumer

DG/DM activities »» Use data in compliance with usage constraints

»» Search for existing datasets by making an inquiry at a Broker Ser-
vice Provider
»» Nominate Data Users (if needed)
»» Receive information about data transaction from Clearing House
»» Monitor policy enforcement

Enabling/Supporting IDS »» IDS Connector

Component: –– Catalogue of rules to act in compliance with usage con-
straints specified by Data Owner

Table 4.3: Data governance and management activities of Data Consumer

Broker Service Provider

DG/DM activities »» Match demand and supply of data

»» Provide Data Consumer with metadata

Enabling/Supporting IDS »» Broker Service Provider component

Component: –– Core of the metadata model must be specified by the
International Data Spaces (by the Information Model)
–– Provide registration interface for Data Provider
–– Provide query interface for Data Consumer
–– Store metadata in internal repository for being queried
by Data Consumers

Table 4.4: Data governance and management activities of Broker Service Provider

101 //
 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL // 4.3

Clearing House

Data-related activities »» Monitor and log data transactions and data value chains
»» Monitor policy enforcement
»» Provide data accounting platform

Enabling/Supporting IDS »» Clearing House component

Component: –– Logging data

Table 4.5: Data governance and management activities of Clearing House

App Store Provider

»» Offer Data Services (e.g. for data visualization, data quality,

Data-related activities data transformation, data governance)
»» Provide Data Apps
»» Provide metadata and a contract based on the metadata for
app user

Enabling/Supporting IDS »» App Store Provider component

Component: »» Interfaces for publishing and retrieving Data Apps plus
corresponding data

Table 4.6: Data governance and management activities of App Store Provider

IDS DATA GOVERNANCE MODEL ments that do not rely on a central instance for data stor-
The IDS Data Governance Model defines a framework of de- age, but instead allow self-organization of different heteroge-
cision-making rights and processes with regard to the defini- neous databases. Additionally, data lifecycle management is
tion, creation, processing, and use of data. While governance concerned with the creation and capturing of data, including
activities set the overall directive of the decision-making sys- data processing, enrichment, storage, distribution, and use.
tem, data management comprises three groups of activities  
with regard to the creation, processing, and use of data. In The following responsibility assignment matrix (RACI matrix)
the IDS context, data governance comprises also usage rights supports the allocation of these activities to enable a gover-
of data shared and exchanged within the IDS ecosystem. The nance mechanism in the IDS ecosystem. RACI stands for “re-
management of metadata specifies data about data and com- sponsible”, “accountable”, “consulted” and “informed”. The
prises both syntactical, semantic and pragmatic information. focus lies on the „R“ and „A“ of the RACI matrix, supported by
This is of particular importance in distributed system environ- the notation „S“, which stands for „supported“.

102 //
 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL // 4.3

Data Owner / Data Data User / Data

Activity Broker Clearing House
Provider Consumer

Management

Determine data
usage restrictions
R, A - S -
(execute data ow-
nership rights)

Enforce data usage

- R, A - -
restrictions

Ensure data quality R, A - S -

Monitor and log

S S - R, A
data transactions

Enable data
S S - R, A
provenance

Provide clearing
S S - R, A
services

Metadata

Describe and
R, A - S -
publish metadata

Look up and
- R, A S -
retrieve metadata

Data Lifecycle

Capture
R, A - - -
and create data

Store data R, A S - -

Enrich and
S R, A S -
aggregate data

Distribute and
R, A - S -
provide data

Link data S S R, A -

Legend: R – Responsible; A – Accountable; S – Supporting.

Table 4.7: Roles responsible, accountable and supporting in data governance

103 //
 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL // 4.3

The following subsections describe five topics that are ad- From a legal perspective, there is no ownership regarding
dressed by the Governance Perspective. These topics play an data, as data is an intangible good. With the “Free Flow of
important role when it comes to the management of data as- Data” Regulation53, the European Commission supports data
sets. exchange and data sharing across borders in the means of
technical hurdles. The IDS approach supports the implemen-
tation of the regulation for non-personal data. At the same
4.3.3 DATA AS AN ECONOMIC GOOD time the democratization of data is not the aim of the IDS
concept, as data ownership is an important aspect when it
comes to offering data and negotiating contracts in digital
As data can be decoupled from specific hardware and soft- business ecosystems, especially because data can easily be
ware implementations, it turns into an independent econom- duplicated.
ic good. While this opens up new opportunities, it creates
challenges as well. To ensure competitiveness of organiza- The International Data Spaces makes sure the need of a Data
tions, a solution is required that facilitates new, digital busi- Provider or a Data Producer is comprehensively addressed
ness models. by providing a secure and trusted platform for authoriza-
tion and authentication within a decentralized architecture.
The International Data Spaces offers a platform for organiza- This allows Data Providers as well as Service Providers to be
tions to offer and exchange data and digital services. In doing identified and controlled by an Identity Provider (see Chapter
so, it offers a basic architecture for organizations that want 3.1.1). Decentralized data exchange by means of Connectors,
to optimize their data value chains. The main goal is to en- in contrast to other architectures of data networks (e.g., data
able participants to leverage the potential of their data within lakes or cloud services), ensures full data sovereignty. In addi-
a secure and trusted business ecosystem. The International tion to these self-control mechanisms, the architecture allows
Data Spaces thereby covers the information system perspec- logging of data transfer information at a Clearing House (see
tive and provides the components that enable participants to Chapter 3.2.5).
define individual business cases.
As the need for Data Sovereignty is obvious, but the term of
The International Data Spaces neither makes any statements ownership is not defined for data, the term “Data Sovereign”
on legal perspectives, nor does it restrict participants to any indicates the rights, duties, and responsibilities for this role.
predefined patterns. Instead, it offers the possibility to de- The term and the role of the Data Owner is defined for this
sign digital business models individually and as deemed ap- document in section 3.1.1 and does not cover a legal state-
propriate. ment on data ownership. This is indeed relevant on every lay-
er of the architecture.

4.3.4 DATA OWNERSHIP As the International Data Spaces intends to build upon and
apply existing law, it will not include any purely technolo-
gy-oriented solutions to prevent data duplication or misuse
In the material world, the difference between the terms “pos- of data assets. However, it supports these important aspects
session” and “property” is an abstract, yet necessary con- over the entire data lifecycle. Furthermore, it supports the ar-
struct. It is accepted that moving a good from one place to rangement of collaborative solutions by providing an appro-
another and changing possession of the good does not nec- priate technical infrastructure.
essarily have an impact on the property rights. Regarding the
specific concept of the International Data Spaces, it is neces-
sary to take into account that the Data Owner and Data Pro-
vider may not be identical (see Chapter 3.1.1).
1

53
Regulation (EU) 2018/1807 of the European Parliament and of the Council of 14 November 2018 on a framework for
the free flow of non-personal data in the European Union

104 //
 PERSPECTIVES OF THE REFERENCE ARCHITECTURE MODEL // 4.3

4.3.5 DATA SOVEREIGNTY 4.3.7 DATA PROVENANCE

Data sovereignty is a natural person’s or corporate entity’s By creating transparency and offering clearing functional-
capability of being entirely self-determined with regard to ity, the International Data Spaces provides a way to track
its data. The Reference Architecture Model presented in this the provenance and lineage of data. This is strongly linked
document particularly addresses this capability, as it specifies to the topics of data ownership and data sovereignty. Data
requirements for secure data exchange and restricted data provenance tracking can be implemented with local tracking
use in a trusted business ecosystem. components integrated into IDS Connectors and a central-
ized provenance storage component attached to the Clearing
The International Data Spaces promotes interoperability be- House (see Chapter 3.1.1), which receives all logs concerning
tween all participants based on the premise that full self-de- activities performed in the course of a data exchange transac-
termination with regard to one’s data goods is crucial in such tion, and requests confirmations of successful data exchange
a business ecosystem. Data exchange takes place by means of from the Data Provider and the Data Consumer. In doing so,
secured and encrypted data transfer including authorization data provenance is always recursively traceable. In, addition
and authentication. The Data Provider may attach metadata provenance information can be integrated into the IDS Vo-
to the data transferred using the IDS Vocabulary. In doing so, cabulary, so as to enable the participants to maintain data
the terms and conditions to ensure data sovereignty can be provenance as part of the metadata during the process of
defined unambiguously (e.g., data usage, pricing information, data exchange.
payment entitlement, or time of validity). The International
Data Spaces thereby supports the concrete implementation The International Data Spaces thereby provides the possibili-
of applicable law, without predefining conditions from a busi- ty to implement and use appropriate concepts and standards.
ness point of view, by providing a technical framework that However, it does not force participants to use these concepts
can be customized to the needs of individual participants. and standards. It is therefore up to the individual participant
to provide correct information (i.e., metadata) on the prove-
nance of data.

4.3.6 DATA QUALITY

Because of the correlation between good data quality and

maximizing the value of data as an economic good, the Inter-
national Data Spaces explicitly addresses the aspect of data
quality. Due to this premise, the International Data Spaces
enables its participants to assess the quality of data sourc-
es by means of publicly available information and the trans-
parency it provides with regard to the brokerage functionality
it offers. Especially in competitive environments, this trans-
parency may force Data Providers to take data maintenance
more seriously. By extending the functionality of the Connec-
tor with self-implemented Data Apps (see Chapter 3.2.4), the
International Data Spaces lays the foundation for automated
data (quality) management.

105 //
APPENDIX
A // GLOSSARY
B // SECURITY PROFILES
C // LIST OF FIGURES
D // LIST OF TABLES

106 //
 APPENDIX A // GLOSSARY

APPENDIX A // GLOSSARY

Term Definition

App Store Secure platform for distributing Data Apps; features different search options (e.g. by
functional or non-functional properties, pricing model, certification status, community
ratings, etc.)

Applicant Organization formally applying for being certified by the Certification Body

Broker Service Provider Intermediary managing a metadata repository that provides information about the
Data Sources available in the International Data Spaces; multiple Broker Service
Providers may be around at the same time, maintaining references to different, do-
main-specific subsets of Data Endpoints

Certification Authority Trusted third-party entity issuing digital certificates (e.g., x509 certificates); may host
services to validate certificates issued

Certification Body Governance body certifying components and entities seeking admission to the Interna-
tional Data Spaces; aside from having the final word on granting or denying a certifi-
cate, it is responsible for maintaining the Certification Scheme (including its catalog of
requirements), overseeing and approval of Evaluation Facilities, and ensuring compati-
bility of evaluation procedures carried out by Evaluation Facilities

Certification Scheme Scheme defining the processes, roles, targets, and criteria involved in the certification
of components and entities; maintained by the Certification Body

Clearing House Intermediary providing clearing and settlement services for all financial and data
exchange transactions within the International Data Spaces

Connector Dedicated communication server for sending and receiving data in compliance
with the general Connector specification; different types of Connectors can be
distinguished (Base Connector vs. Trusted Connector, or Internal Connector vs.
External Connector)

107 //
 APPENDIX A // GLOSSARY

Term Definition

Connector-Self- Description of a Connector participating in the IDS for being read by other IDS Parti-
description cipants; created by the Data Provider or Data User as the first step of the Connector
configuration process; contains information such as the name of the Connector provi-
der or the name of the maintainer, as well as information about the content and type
of the data offered or requested, about data communication interfaces, and about
usage policies and contracts

Data App Self-contained, self-descriptive software package that is distributed via the App Store
and deployed inside a Connector; provides access to data and data processing capabi-
lities; the interface of a Data App is semantically described by the IDS Vocabulary

Data Asset Content exposed for exchange via Data Endpoints according to a parametrized Data
Service interface; Data Assets are expected to be focused, homogeneous, and con-
sistent over time with regard to granularity, coverage, context, data structure, and
conceptual classification

Data Consumer Core Participant in the International Data Spaces requesting and using data provided
by a Data Provider

Data Endpoint Data interface for data publication (Data Source) and data consumption (Data Sink),
respectively

Data Exchange Contractual agreement between a Data Provider and a Data Consumer regarding the
Agreement exchange of data in the International Data Spaces

Data Operation Method or operation with defined functionality to be invoked on a Data Endpoint.

Data Owner Core Participant having complete control over the data it makes available in the Inter-
national Data Spaces; defines the terms and conditions of use of its data

108 //
 APPENDIX A // GLOSSARY

Term Definition

Data Provider Core Participant exposing Data Sources via a Connector; a Data Provider may be an
enterprise or other organization, a data marketplace, an individual, or a “smart thing”

Data Sink Data Endpoint consuming data uploaded and offered by a Data Provider

Data Source Data Endpoint exposing data for being retrieved or subscribed to by a Data Consumer

Data Sovereignty The capability of an entity (natural person or corporate) of being entirely self-deter-
mined with regard to its data

Demilitarized Zone (DMZ) A Demilitarized Zone is an IT system (or a part of an IT system) with controlled access.

Dynamic Attribute Issues Dynamic Attribute Tokens (DATs) to verify dynamic attributes of Participants or
Provisioning Service Connectors
(DAPS)

Dynamic Attribute Contains signed dynamic attributes for participants and Connectors
Token (DAT)

Evaluation Facility Governance body providing services related to the certification of components and
entities (certification targets) seeking admission to the International Data Spaces;
responsible for detailed technical evaluation of targets in consistence with the Certifi-
cation Scheme and its catalog of requirements; reports evaluation results to the
Certification Body

Governance Concept defining the rights and duties (“rules of the game”) for formal data manage-
ment, ensuring quality and trust throughout the International Data Spaces; mission
critical to the International Data Spaces, as a central supervisory authority is missing

109 //
 APPENDIX A // GLOSSARY

Term Definition

Identity Provider Intermediary offering services to create, maintain, manage and validate identity infor-
mation of and for Participants in the International Data Spaces

Information Model Set of vocabularies and related schema information for the semantic description of
International Data Spaces entities (e.g., Data Endpoints or Data Apps), data provenan-
ce, or licensing information; the core IDS Vocabulary is domain-independent; it can be
extended and/or reference third-party vocabularies to express domain-specific aspects

International Data Spaces Distributed network of Data Endpoints (i.e., instantiations of the International Data Spa-
ces Connector), allowing secure exchange of data and guaranteeing Data Sovereignty

Participant Stakeholder in the International Data Spaces, assuming one or more of the prede-
fined roles; every Participant is given a unique identity by the Identity Provider

Security Profile Defined set of a Connector’s security properties; specifies several security aspects
(e.g., isolation level, attestation, or authentication), expressing the minimum requi-
rements a Data Consumer must meet to be granted access to the Data Endpoints
exposed

System Adapter Data App used for integration of custom Data Sources and legacy systems with
a Connector

Usage Contract Set of rules and conditions regarding one or more transactions in the Internati-
onal Data Spaces.

Usage Policy Set of rules specified by the Data Owner restricting usage of its data; covers as-
pects like time-to-live or forwarding conditions (e.g., anonymization or scope of
usage); transmitted along with the respective data, and enforced while residing
on the Connector of the Data Consumer

Vocabulary Hub Server providing maintenance facilities for editing, browsing and downloading
vocabularies and related documents; mirrors a set of external third-party voca-
bularies ensuring seamless availability and resolution

110 //
 APPENDIX B // SECURITY PROFILES

APPENDIX B // SECURITY PROFILES

DIMENSION: DEVELOPMENT
The development dimension relates to the requirements and capabilities
regarding the development of components.

Base Free Base Trust Trust+

Lifecylce Community IDS community (indi- IDS community (via IDS community (via
Management vidual developments SW major release), SW major release),
from companies quality evaluation, quality evaluation,
possible), weaker contributions of the contributions of the
SLAs IDS Community, IDS Community,
fixed SLAs for patch fixed SLAs for patch
management management

Development Decentralized Decentralized Decentralized Centrally managed

Centrally managed Open Source IDS members only, IDS members only, IDS members only,
(preferred) Open Source not Open Source not Open Source not
excluded excluded excluded

DIMENSION: DEVELOPMENT
The IDS Roles supported dimension relates to the IDS Roles (as described in section 3.1) supported
by the respective Security Profile. Basically the Base Free Profile cannot make use of a
public IDS infrastructure (e.g. Identity Provider, Broker) as its components are not certified.

Base Free Base Trust Trust+

Broker (the Connector can Own security Mandatory Mandatory Mandatory

register and query a Broker) domain

Billing Provider / Clearing House Own security Optional Mandatory Mandatory

domain

Identity Provider Own security Decentralized Mandatory Mandatory

domain

App Store Own security Mandatory Mandatory Mandatory

domain

Dynamic Trust Monitoring Own security Optional Optional Mandatory

domain

111 //
 APPENDIX B // SECURITY PROFILES

DIMENSION: COMMUNICATION ABILITIES SUPPORTED

The Communication abilities dimension specifies the communication features supported by the
respective Security Profile to achieve interoperability between every IDS Connector.

Base Free Base Trust Trust+

Authorization (access control Mandatory Mandatory Mandatory Mandatory

with rights and roles) (fine-grained) (fine-grained)

Authenticatiacon Mandatory Optional Mandatory Mandatory, with

(own CA) hardware
anchor or similar

Support of IDS Mandatory Mandatory Mandatory Mandatory

Vocabularies

Profile classification Mandatory Mandatory Mandatory Mandatory

(provisioning of
own security level)

Profile evaluation Optional Optional Mandatory Mandatory

(evaluation of profile from
connecting party)

Communication security Mandatory Optional Mandatory Mandatory

(encrypted
transmission/channel)

Technical logging Local or Local or Distributed Distributed

distributed distributed

App execution Mandatory Mandatory Mandatory Mandatory

Assignment of OS resources Optional Optional Mandatory Mandatory

for apps (e.g. memory, CPU)

Interoperability Base Free Base Free Trust, Trust+, Base Trust, Trust+, Base

Initialization of HTTPS, MQTT HTTPS, MQTT HTTPS, MQTT, HTTPS, MQTT,

communication IDSCP IDSCP

Transmission protocols To be negotiated To be negotiated To be negotiated To be negotiated

between between between between
participants participants participants participants

Contract profiles, mapping of To be defined To be defined To be defined To be defined

electronic contract variants,
automated order processing

112 //
DIMENSION: SECURITY FEATURES SUPPORTED
The Higher security features dimension specifies the security level provided by the
respective Security Profile regarding Attacker Models and .detailed security and safety requirements.

1. Attacker Model: Protection of faulty operation through the local administrator.

[Trust is based on proper administration of all connectors in the IDS complete system]
 
Base Free Base Trust Trust+

Protection of accidental faulty Optional Optional Mandatory Mandatory

operation admin

Protection of faulty operation Optional Optional Optional Mandatory

and manipulation admin (refer to
IEC 62443 Security Level)

2. Safety requirements 

Base Free Base Trust Trust+

IEC 62443 security level None None SL2 (7 base SL2 or SL3 (7 base
requirements) requirements)

Hardware-related / hardware Optional Optional Optional Mandatory

anchor or similar

Downward compatibility Base Free Base Trust, Trust+, Base Trust, Trust+, Base

Maintaining data integrity Mandatory Mandatory Mandatory Mandatory

(data classes / usage classes)

Checking data integrity (data Optional Optional Mandatory Mandatory

classes / usage classes)

Operation monitoring Mandatory Mandatory  Mandatory Mandatory

(basic monitoring (average monito- (high monitoring
frequency) ring frequency) frequency)

Service isolation Limited Limited Strong Strong

Support for Usage policy Mandatory Mandatory Mandatory Mandatory

Usage control Not defined Mandatory Mandatory Mandatory

(based on Trust)

Technical usage enforcement Optional Optional Mandatory Mandatory

Audit function Local Local Remote Remote

113 //
 APPENDIX B // SECURITY PROFILES

Connector integrity Base Free Base Trust Trust+

Integrity protection Optional Optional Mandatory Mandatory

Integrity protection attestation Optional Optional Mandatory Mandatory

(local check and
enforcement)

ISA-OS and IDS stack No No Yes, if applicable Yes, if applicable

as aggregation as aggregation

ISA-OS, IDS stack and No No Yes, if applicable Yes, if applicable

configuration filtered filtered

Authenticated, integrity Mandatory Mandatory Mandatory Mandatory

protected and encrypted
communication

Both-sided certificate-based Mandatory Mandatory  Mandatory Mandatory

authentication

Protection of cryptographic Mandatory Mandatory Mandatory (with Mandatory (with

key material hardware anchor hardware anchor
or similar) or similar)

Connector isolation Base Free Base Trust Trust+

Isolation between IDS system Mandatory Mandatory Mandatory Mandatory

and apps

Isolation of the IDS services Mandatory Mandatory Mandatory Mandatory

(apps)

Isolation and full control over Optional Optional Mandatory Mandatory

I/O of an IDS service (app) 

114 //
 APPENDIX B // SECURITY PROFILES

Logging and monitoring

Base Free Base Trust Trust+
(audit logging)

System utilization

Local Optional Mandatory Mandatory Mandatory

Remote monitoring Optional Optional Mandatory Mandatory

Data usage

Local Optional Mandatory Mandatory Mandatory

Remote monitoring Optional Optional Mandatory Mandatory

(only against
faulty operation)

Data usage control

Definition of data usage rules Yes Yes Yes Yes

Monitoring of rules No No Yes Yes

Platform requirements (OS, No No Yes Yes

security level IEC 62443,
audit level of the certification)

Enforcement of data usage No No Yes (only against Yes

rules on the Connector faulty operation)
(internal criteria): deletion,
useful life, number of
usages, apps with data access

Enforcement of data usage No No Yes (only against Yes (no full pro-
rules on the connector faulty operation) tection against
(external criteria): position, manipulation)
time, legal requirements

Encrypted backups of No No Yes Yes

system data and payload
outside of the container

Enforcement of data No No No No
usage rules outside of the
connector

115 //
 APPENDIX C // LIST OF FIGURES

APPENDIX C // LIST OF FIGURES

FIGURE 1.1: THREE TYPES OF ACTIVITIES OF THE INTERNATIONAL DATA SPACES .................................................................010
FIGURE 1.2: GENERAL STRUCTURE OF REFERENCE ARCHITECTURE MODEL ......................................................................011
FIGURE 2.1: DATA-DRIVEN BUSINESS ECOSYSTEMS ..............................................................................................................013
FIGURE 2.2: EVOLUTION OF TECHNICAL STANDARDS FOR DATA EXCHANGE .....................................................................014
FIGURE 2.3: DATA EXCHANGE VS. DATA SHARING .................................................................................................................015
FIGURE 2.4: GENERAL ARCHITECTURAL PATTERNS FOR DATA EXCHANGE AND DATA SHARING ......................................017
FIGURE 2.5: TYPICAL ENTERPRISE ARCHITECTURE STACK ...................................................................................................018
FIGURE 2.6: INTERNATIONAL DATA SPACES CONNECTING DIFFERENT CLOUD PLATFORMS ............................................019
FIGURE 3.1: ROLES AND INTERACTIONS IN THE INDUSTRIAL DATA SPACE ........................................................................026
FIGURE 3.2: INTERACTIONS REQUIRED FOR ISSUING A DIGITAL IDENTITY IN THE IDS ....................................................027
FIGURE 3.3: TECHNICAL ENFORCEMENT AND ORGANIZATIONAL ENFORCEMENT OF USAGE POLICIES .........................028
FIGURE 3.4: FUNCTIONAL ARCHITECTURE OF THE INTERNATIONAL DATA SPACES ...........................................................029
FIGURE 3.5: “ONBOARDING” OVERALL PROCESS .................................................................................................................034
FIGURE 3.6: “CONNECTOR CONFIGURATION AND PROVISIONING” SUB PROCESS ...........................................................034
FIGURE 3.7: “SECURITY SETUP” SUB PROCESS ......................................................................................................................035
FIGURE 3.8: “AVAILABILITY SETUP” SUB PROCESS ................................................................................................................036
FIGURE 3.9: “EXCHANGING DATA” OVERALL PROCESS .........................................................................................................037
FIGURE 3.10: “FIND DATA PROVIDER” SUB PROCESS ............................................................................................................037
FIGURE 3.11: “INVOKE DATA OPERATION” SUB PROCESS.....................................................................................................038
FIGURE 3.12: “DATA APP CERTIFICATION” PROCESS .............................................................................................................039
FIGURE 3.13: “USE DATA APP” PROCESS ................................................................................................................................039
FIGURE 3.14: REPRESENTATIONS OF THE INFORMATION MODEL .......................................................................................041
FIGURE 3.15: OUTLINE OF THE CONCERN-BASIC CONCERN HEXAGON .............................................................................042
FIGURE 3.16: TAXONOMY OF THE RESOURCE CONCEPT ......................................................................................................044
FIGURE 3.17: RESOURCE CONCEPT (OUTLINE) ......................................................................................................................045
FIGURE 3.18: REPRESENTATION CONCEPT (OUTLINE) ..........................................................................................................045
FIGURE 3.19: TAXONOMY OF OPERATION TYPES FOR RESOURCE EXCHANGE ...................................................................049
FIGURE 3.20: OPERATION CONCEPT (OUTLINE)....................................................................................................................049
FIGURE 3:21: MESSAGE TAXONOMY (EXCERPT) ....................................................................................................................050
FIGURE 3:22: PROVENANCE CONCEPT (OUTLINE) ................................................................................................................051
FIGURE 3.23: OUTLINE OF THE: DATA QUALITY CONCEPT (OUTLINE) .................................................................................052
FIGURE 3.24: POLICY CONCEPT (OUTLINE) ...........................................................................................................................053
FIGURE 3.25: PRICING CONCEPT (OUTLINE) .........................................................................................................................054
FIGURE 3.26: PARTICIPANT CONCEPT (OUTLINE) .................................................................................................................055
FIGURE 3.27: CONNECTOR CONCEPT (OUTLINE) ..................................................................................................................056
FIGURE 3.28: CERTIFICATION CONCEPT (OUTLINE) .............................................................................................................057
FIGURE 3.29: USAGE CONTRACT CONCEPT (OUTLINE) .........................................................................................................058
FIGURE 3.30: DETAILED CONCERN HEXAGON .......................................................................................................................059

116 //
 APPENDIX C // LIST OF FIGURES

FIGURE 3.31: INTERACTION OF TECHNICAL COMPONENTS ................................................................................................060

FIGURE 3.32: CONNECTOR ARCHITECTURE ...........................................................................................................................062
FIGURE 3.33: CONNECTOR CONFIGURATION MODEL ..........................................................................................................065
FIGURE 4.1: IDS COMMUNICATION .......................................................................................................................................070
FIGURE 4.2: PKI STRUCTURE (EXAMPLE) ................................................................................................................................072
FIGURE 4.3: EMBEDDING THE CONNECTOR CERTIFICATE ...................................................................................................072
FIGURE 4.4: RESOURCE ACCESS WORKFLOW ........................................................................................................................073
FIGURE 4.5: TECHNICAL ROLES IN THE INTERNATIONAL DATA SPACES .............................................................................074
FIGURE 4.6: MAPPING OF TECHNICAL ROLES AND PKI LAYOUT .........................................................................................074
FIGURE 4.7: CONNECTOR ROLES AND MANIFESTATIONS.....................................................................................................076
FIGURE 4.8: SOFTWARE DEVELOPMENT, APPROVAL, AND DOWNLOAD PROCESS...............................................................077
FIGURE 4.9: DELIVERY OF A CONNECTOR..............................................................................................................................077
FIGURE 4.10: CONTAINER ISOLATION FOR DATA APPS.........................................................................................................080
FIGURE 4.11: XACML DATA FLOW DIAGRAM [SOURCE: EXTENSIBLE ACCESS CONTROL MARKUP LANGUAGE (XACML) .
VERSION 3.0 ].....................................................................................................................................................082
FIGURE 4.12: DATA USAGE CONTROL – AN EXTENSION OF DATA ACCESS CONTROL..........................................................083
FIGURE 4.13: TECHNICAL ENFORCEMENT VS. ORGANIZATIONAL/LEGAL ENFORCEMENT................................................084
FIGURE 4.14: COMMUNICATION POLICY ENFORCEMENT POINT AND POLICY DECISION POINT.....................................085
FIGURE 4.15: USAGE CONTROL PRE-, ON-, AND POST-CONDITIONS....................................................................................085
FIGURE 4.16: ODRL CORE MODEL 2.1 (ODRL VERSION 2.1 COMMON VOCABULARY
FINAL SPECIFICATION: 5 MARCH 2015)...........................................................................................................087
FIGURE 4.17: EXAMPLES OF MAPPING AMONG POLICY LANGUAGE LEVELS......................................................................087
FIGURE 4.18: APACHE CAMEL PIPELINE (EXAMPLE)..............................................................................................................088
FIGURE 4.19: INTERCEPTING APACHE CAMEL DATA FLOWS.................................................................................................089
FIGURE 4.20: DATA FLOW ACROSS COMPANY BORDERS.......................................................................................................089
FIGURE 4.21: ARCHITECTURE WITH CENTRALIZED COMPONENT FOR PROVENANCE INFORMATION STORAGE.............091
FIGURE 4.22: ARCHITECTURE WITH DISTRIBUTED COMPONENT FOR PROVENANCE INFORMATION STORAGE..............091
FIGURE 4.23: CERTIFICATION PROCESS..................................................................................................................................095

117 //
 APPENDIX C // LIST OF FIGURES

APPENDIX C // LIST OF TABLES

TABLE 3.1: INTERACTIONS BETWEEN ROLES IN THE IDS – X --> MANDATORY INTERACTION, (X) --> OPTIONAL ............
INTERACTION) ......................................................................................................................................................025
TABLE 4.1: OVERVIEW OF IDS SECURITY PROFILES AND RELATED DIMENSIONS ...............................................................079
TABLE 4.2: DATA GOVERNANCE AND MANAGEMENT ACTIVITIES OF DATA OWNERS AND DATA PROVIDERS ..................100
TABLE 4.3: DATA GOVERNANCE AND MANAGEMENT ACTIVITIES OF DATA CONSUMER ....................................................101
TABLE 4.4: DATA GOVERNANCE AND MANAGEMENT ACTIVITIES OF BROKER SERVICE PROVIDER ..................................101
TABLE 4.5: DATA GOVERNANCE AND MANAGEMENT ACTIVITIES OF CLEARING HOUSE ...................................................102
TABLE 4.6: DATA GOVERNANCE AND MANAGEMENT ACTIVITIES OF APP STORE PROVIDER .............................................102
TABLE 4.7: ROLES RESPONSIBLE, ACCOUNTABLE AND SUPPORTING IN DATA GOVERNANCE ..........................................103

118 //
HEAD OFFICE:

International Data Spaces Association

Joseph-von-Fraunhofer-Str. 2 – 4
44227 Dortmund

Phone: +49 (0) 231 9743 - 619

[email protected]
www.internationaldataspaces.org
@ids_association
international-data-spaces-association

LEGAL OFFICE:

International Data Spaces Association

Anna-Louisa-Karsch-Str. 2
10178 Berlin
Germany