Skip to main content
Skip table of contents

Technische Perspektive

Die International Data Spaces (Association) IDS(A) hat sich das Ziel gesetzt, einen Standard für einen vertrauenswürdigen und selbstbestimmten Austausch von Daten zu etabilieren [1]. Es ist vollständig konform zum Gaia-X Trustframework durch die Implementierung von Selbstbeschreibungen und den Notarisation Services.

Entstanden ist das Reference Architecture Model, akutell in der vierten Version, bestehend aus 6 miteinander interagierenden Bausteinen.

Das Schaubild zeigt einen Datenaustausch zwischen einem Data Owner und einem Data User unter Nutzung der Bausteine des RAM.

RAM-technischesModell.png

Die Komponenten

IDS-Connector-Components.png
Der Alleskönner

Der IDS-Connector

Die zentralen Funktionalitäten werden darin von IDS-Connectoren übernommen. Sie realisieren die Aushandlung von Verträgen zur Datennutzung (Usage Policys), ebenso wie den tatsächlichen Datentransfer. Jeder Connector verfügt über ein internes Containermanagement, sodass datenverarbeitende Apps darin laufen können.

Jeder Teilnehmer eines Datenraums muss über einen eigenen Connector verfügen.

Die weiteren Komponenten muss es pro Datenraum mindestens einmal geben, und werden von privaten Anbietern betrieben (es liegt in ihrem Ermessen dafür eine Nutzungsgebühr zu verlangen), damit der Datenraum föderiert bleibt.

Der Angebotskatalog

Der Metadata-Broker

Der Metadata-Broker verwaltet einen Angebotskatalog, mit allen Datensätzen, die im Datenraum öffentlich angeboten werden. Wer einen neuen Datensatz einstellt, registriert diesen mit seinen Metadaten, einer Beschreibung, und den dazugehörigen Nutzungsbedingungen beim Metadata-Broker. [3]

Dort können andere Nutzer die Angebote finden, und die Connectoren, die die Angebote erstellt haben, direkt kontaktieren wenn Sie an einem solchen interessiert sind. Daraufhin starten die Connectoren einen automatischen Vertragsverhandlungsprozess, auf den im Erfolgsfall ein Datentransfer folgt.

Metadata-Broker-Process.png
ClearingHouse-Architecture.png
Jetzt wird abgerechnet

Das Clearing-House

Das Clearing House ist im Kern ein IDS-Connector, dem alle wichigen Informationen zum loggen und Abrechnen der tatsächlichen Datennutzung zugeschickt werden. Die geloggten Informationen werden mit einer Attribut-basierenden Verschlüsselung geschützt, sodass nur jemand mit den passenden Attributen die Logging-Einträge entschlüsseln kann. [2, Seite 27f.]

Datenanalyse zum Download

Der App Store

Hier werden Apps zum Download in den Connector angeboten. Der App-Store unterstützt dabei den Installations- und Deinstallations-Prozess. Die Apps selbst können in drei Kategorien eingeteilt werden (siehe rechts).


Die Apps können hintereinander in einen Datenstrom gehängt, und somit beliebig kombiniert werden.

Je nach Typ und Funktionallität der App muss sie vor der Veröffentlichung im App Store geprüft und zertifiziert werden. Wer eine eigene Anwendung entwickeln möchte, ohne sie im App Store zu veröffentlichen, kann das in Form einer “Custom App” ebenfalls tun. [4]

  • Data Apps verarbeiten Daten, oder werten sie aus. Das beinhaltet alles vom Umformatieren der Daten, über eine explorative Datenanalyse, bis hin zum Training eines Neuronalen Netzes zur Erkennung von Anomalien oder zur Vorhersage zukünftiger Daten.

  • Adapter Apps helfen bestehende Datenhaltungs-Systeme an den Datenraum anzubinden, die vom Connector standardmäßig nicht unterstützt werden. Mit einer passenden Adapter App kann jede beliebige Datenquelle verbunden werden.

  • Control Apps ermöglichen die Nutzung/Steuerung eines Connectors aus anderen Anwendungen heraus. Wenn Ihre Firma also bereits über eine Shopfloor-Management Applikation verfügt, kann diese mit einem Connector verbunden, und die Datenraum-Interaktionen aus der Anwendung heraus gesteuert werden.

Foto von Kutan Ural auf Unsplash

Das Trustframework live und in Farbe

Der Identity Provider

Im Schaubild nicht gezeigt, und trotzdem absolut essentiell für einen dezentralen Datenraum ist der Identity Provider. Er erfüllt die von Gaia-X im Trustframework eingeforderten Funktionen, die für Sicherheit und Vertrauen im ganzen Datenraum sorgen sollen.

Mit drei Services kann die Identität eines Teilnehmers im Datenraum zuverlässig überprüft und bestätigt werden:

  • Certificate Authoritys (CAs) stellen Identitäts-Zertifikate aus, und prüfen ob ein Connector wirklich zu einer registrierten Organisation gehört, und die Angaben der Organisation über sich selbst stimmen.

  • der Dynamic Attribute Provisioning Service (DAPS) stellt Dynamic Attribute Tokens (DATs) aus, die in signierten Claims aktuelle Informationen über die Identität eines Teilnehmers beinhalten. Die DATs laufen nach kurzer Zeit aus, und müssen immer wieder neu beantragt werden. In diesem Prozess werden auch die Manifeste und Measurements geprüft, die eine Zertifizierung der benutzten Komponenten zulassen.

  • ein Participant Information Service (ParlS) liefert von Trust Anchors bestätigte Informationen mit Aussagekraft über die Vertrauenswürdigkeit eines Teilnehmers. Ähnlich wie Nutzer beim Metadata-Broker die verfügbaren Angebote erfragen können, können beim ParlS Informationen über andere Teilnehmer eingeholt werden. [6]

Alle sprechen die gleiche Sprache

Der Vocabulary-Hub

Der Vocabulary Hub beinhaltet standardisierte Syntax, die innerhalb des Datenraums verwendet wird, und dient als Lookup-Table für die anderen Komponenten. Die Vocabulary Hubs aller Datenräume haben als gemeinsame Basis das IDS Information Model, und ergänzen es um eigene, branchenspezifische Terme.

Ein solches Vocabulary folgt dem Resource-Description-Model Schema. Datenraum-Teilnehmer können ein Vocabulary Hub nutzen, um ihre Selbstbeschreibungen präziser zu gestalten, oder um andere Selbstbeschreibungen zu interpretieren. [5]

mick-haupt-IJrtDN2u220-unsplash.jpg

Foto von Mick Haupt auf Unsplash

Sicherheit im RAM

Abgesehen von der Identifizierung der Teilnehmer durch die Beglaubigung ihrer Selbstbeschreibungen von den Trust Anchors, ist der Connector als zentrale Komponente der Architektur verantwortlich für die Sicherheit der Daten.

Dabei wird unterschieden zwischen Usage- und Access-Control: Access-Control kontrolliert den Zugang zu den Daten. Für eine freie und präzise Definition der Nutzungsbedingungen ist darüber hinaus die Kontrolle der tatsächlichen Nutzung der Daten (Usage Control) unabdingbar.

Dazu wird jeder Datenstrom in jedem Connector vom sogenannten Policy Enforcement Point (PEP) unterbrochen, und eine Überprüfung der Richtigkeit dieser Aktivität veranlassen. Nur wenn die Aktivität mit den für die Daten festgelegten Nutzungsbedingungen übereinstimmt, können die Daten verarbeitet oder übertragen werden. [2]

Connector-Implementierungen werden von der IDSA zertifiziert, und die Integrität jeder Installation eines solchen Connectors mit einem Hash-Wert überprüft, sodass niemand den PEP in seiner lokalen Installation des Conncetors manipulieren, und die Daten entgegen ihrer Bestimmungen benutzen kann.

Selbiges gilt für Apps: auch sie müssen vor dem Verkauf durch den App Store vom Clearing House überprüft und zertifiziert werden, sodass der Käufer genau weiß, wie die App die Daten verwendet, und dass sie nicht nach draußen gelangen können.

Weitere Informationen

Die unbestritten beste Quelle zum RAM ist die Dokumentation des RAM selbst.
Die Selbstbeschreibungen und Teile der Funktionen des Identity Providers werden im Trustframework definiert.

Wem weniger nach lesen zumute ist, der findet auch auf Youtube_logo.png YouTube einige gute Erklärungen, zum Beispiel:

  • IDS Techtalk: the IDS Reference Architecture Model - the standard for sovereign data sharing hier

  • Webinar über Data Usage Control des Frauenhofer IESE hier

Quellen

  1. International Data Spaces - fact sheet und Kernaussagen, 2019 (Englisch): hier

  2. International Data Spaces - Position Paper: Usage Control in the International Data Spaces, 2021, (Englisch): hier

  3. IDS-RAM, Version 4.0: Layers of the Reference Architecture Model → System Layer → Metadata Broker (Englisch): hier

  4. IDS-RAM, Version 4.0: Layers of the Reference Architecture Model → System Layer → App Store und App Ecosystem (Englisch): hier

  5. IDS-RAM, Version 4.0: Layers of the Reference Architecture Model → System Layer → Vocabulary Hub (Englisch): hier

  6. IDS-RAM, Version 4.0: Layers of the Reference Architecture Model → System Layer → Identity Provider (Englisch): hier

Quellen der Bilder 1, 2 und 4 ebenfalls IDS-RAM, Version 4.0.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.