flag Souveräner Datenaustausch zwischen Registernfeedback
Dieser Funktionsbaustein wurde umbenannt (ehemals „Datenraum-Konnektor") und um eine kritische Analyse der vier zentralen Initiativen für föderalen und europäischen Datenaustausch erweitert: NOOTS, OOTS, SIMPL und Eclipse Dataspace.
Status: In Erarbeitung | Erstellt am: 13. März 2026 | Zuletzt geändert: 13. Mai 2026 | Autor: BMDS-Architekturteam
lightbulb 1. Motivationfeedback
Souveräner Datenaustausch zwischen Behörden, Registern, Unternehmen und europäischen Partnern ist das Fundament des Once-Only-Prinzips. Aktuell existieren fünf parallele Initiativen mit unterschiedlichen Ansätzen, Reifegraden und Zielgruppen, ohne klare Konvergenzstrategie. Dieser Baustein ordnet die Initiativen ein und leitet eine Empfehlung für den D-Stack ab.
Das Grundproblemfeedback
Fünf Initiativen, zwei Welten: FIT-Connect und NOOTS/OOTS adressieren den hoheitlichen Datenaustausch (Antragstransport, Register, Nachweise, Once-Only). Eclipse Dataspace/SIMPL adressieren Datenräume für Wirtschaft und Forschung (Mobility, Health, Agriculture). FIT-Connect deckt dabei den sicheren Antragstransport (G2C, G2G) ab, NOOTS den Registerdatenabruf. Beide Welten verwenden unterschiedliche Protokolle, Identitätsmodelle und Governance-Strukturen, obwohl langfristig maximale Interoperabilität das Ziel sein muss.
2. Die fünf Initiativen im Detailfeedback
2.1 FIT-Connect – Föderale Zustellinfrastruktur (FITKO)feedback
| Eigenschaft | Detail |
|---|---|
| Träger | FITKO (Föderale IT-Kooperation), Produkt des IT-Planungsrats seit 01.01.2023 |
| Rechtsgrundlage | OZG (Anbindung von Online-Diensten an Fachverfahren) |
| Architektur | Zentraler Zustelldienst mit 1:n-Verbindung. Sender und Empfänger binden sich jeweils einmalig an. Produktboard: Bund, Baden-Württemberg, Hamburg, Sachsen-Anhalt, Thüringen |
| Verschlüsselung | Ende-zu-Ende (JWE, RSA-OAEP-256 + A256GCM), Verwaltungs-PKI-Zertifikate (BSI TR-03107-1, TR-03116-4) |
| Nachrichtenformat | Submission: Metadatensatz + Fachdatensatz + Anlagen, FIM-Schemata für Leistungs- und Datenfeldbeschreibungen |
| Statusprotokollierung | Security Event Tokens (SET, RFC 8417), kryptographisch nachweisbar |
| Version | Produktiv seit April 2022 |
| Reife | Produktiv. Einheitliche Schnittstelle für die Anbindung von Online-Antragsdiensten an Fachverfahren auf allen föderalen Ebenen |
| Open Source | git.fitko.de/fit-connect, offene Lizenz |
Domäne: Hoheitlicher Antragstransport (G2C, G2G). FIT-Connect löst das Problem der sicheren Übermittlung von Antragsdaten zwischen Online-Diensten und Fachverfahren im Portalverbund.
DSP/DCP-Unterstützung: Nein. FIT-Connect ist kein Datenraum-Connector, sondern eine Zustellinfrastruktur mit eigenem Protokoll (Submission API, Routing API).
eIDAS 2.0: Die kryptographische Basis (JWE, JWS, JWK, X.509) ist kompatibel mit den DCP-1.0- und SD-JWT-VC-Formaten. Eine Wallet-Integration ist perspektivisch möglich, aber nicht spezifiziert.
Verzahnte Basisdienste: FIT-Connect ist kein isoliertes Produkt, sondern mit PVOG (Zuständigkeitsfindung), DVDV (Verbindungsparameter), FIM (standardisierte Datenfelder) und FIT-Store (nachnutzbare Onlinedienste) verzahnt.
Technische Dokumentation: docs.fitko.de/fit-connect
2.2 NOOTS – National Once-Only Technical System (FITKO)feedback
| Eigenschaft | Detail |
|---|---|
| Träger | FITKO (Föderale IT-Kooperation), im Auftrag des IT-Planungsrats |
| Rechtsgrundlage | Registermodernisierungsgesetz (RegMoG), SDG-Verordnung (EU) 2018/1724 |
| Architektur | Föderiert, Data-Mesh-orientiert. Kernkomponenten: Datenmanagementsystem (DAMAS), Vermittlungsstelle (VS), Registerdatennavigation (RDN), IAM |
| Nachrichtenformat | XNachweis (Request/Response) für strukturierten Nachweis-Austausch |
| Version | Datenmanagementkonzept v1.0 (Dezember 2025, Konsultation abgeschlossen Januar 2026) |
| Reife | Konzeptdokument (fortgeschrittener Arbeitsstand), kein produktives System |
| EU-Anbindung | Intermediäre Plattform verbindet NOOTS mit EU-OOTS Common Services |
| Interoperabilitätsansatz | Semantische Interoperabilität über Nachweistypen, Codelisten, XNachweis; konform zum European Interoperability Framework (EIF) |
DSP/DCP-Unterstützung: Nein. NOOTS ist kein Datenraum im IDSA/Eclipse-Sinne, sondern ein registerbasiertes Nachweisaustauschsystem.
eIDAS 2.0: EUDI-Wallet-Integration als Zukunftsausblick (Kapitel 8.4) gelistet, aber nicht implementiert und nicht spezifiziert.
OOTS-Version: Konzept verweist auf EU-OOTS über die Intermediäre Plattform, spezifiziert aber nicht, welche OOTS-TDD-Version unterstützt wird. Bei Erstellungszeitpunkt (Dezember 2025) war OOTS TDD 1.x aktuell; OOTS 2.0 wurde erst im Februar 2026 verabschiedet.
2.3 OOTS 2.0 – Once-Only Technical System (EU-Kommission)feedback
| Eigenschaft | Detail |
|---|---|
| Träger | Europäische Kommission, Gateway Coordination Group |
| Rechtsgrundlage | SDG-Verordnung (EU) 2018/1724, Durchführungsverordnung (EU) 2022/1463 |
| Architektur | EU-weites System für grenzüberschreitenden Nachweisaustausch (Evidence Exchange) |
| Version | TDD v2.0 (verabschiedet 19. Februar 2026); Maintenance-Patch v1.2.4 parallel |
| Reife | Produktionsspezifikation, formal verabschiedet |
| eIDAS 2.0 | Ja, explizit. v2.0-Ziele: „Enable EUDI synergies and prepare for eIDAS-2" |
| Rückwärtskompatibilität | Nicht rückwärtskompatibel zu v1.x (neue Inhalte, Revisionen, Korrekturen) |
Kernaussage: OOTS 2.0 ist die verbindliche EU-Spezifikation für den grenzüberschreitenden Nachweisaustausch. Alle Mitgliedsstaaten müssen sie umsetzen. Die eIDAS-2.0-Vorbereitung ist ein primärer Treiber der v2.0.
2.4 SIMPL – Smart Middleware Platform (EU-Kommission)feedback
| Eigenschaft | Detail |
|---|---|
| Träger | Europäische Kommission (DG CNECT) |
| Zweck | Gemeinsame Middleware-Schicht für EU Common European Data Spaces (Health, Mobility, Agriculture, Energy, …) |
| Repository | code.europa.eu/simpl/simpl-open/architecture |
| Version | Spezifikation in Entwicklung; Repository existiert, Inhalte größtenteils zugangsbeschränkt |
| Reife | Früh / in Entwicklung. Funktionale und technische Architekturspezifikation vorhanden, aber nicht öffentlich lesbar ohne code.europa.eu-Zugang |
DSP/DCP-Unterstützung: Architektonisch zu erwarten (SIMPL soll als Middleware für EU-Datenräume dienen), aber nicht bestätigt. Die aktuell zugänglichen Informationen deuten darauf hin, dass SIMPL veraltete Versionen der Dataspace-Protokolle referenziert und DSP/DCP in ihren aktuellen Fassungen noch nicht vollständig unterstützt.
eIDAS 2.0: Nicht bestätigt aus öffentlich verfügbaren Quellen.
Verhältnis zu OOTS: Kein direkter Bezug. SIMPL adressiert EU-Datenräume (Wirtschaft/Forschung), nicht den hoheitlichen Nachweisaustausch.
2.5 Eclipse Dataspace Working Groupfeedback
| Eigenschaft | Detail |
|---|---|
| Träger | Eclipse Foundation |
| Projekte | Eclipse Dataspace Components (EDC), Eclipse Dataspace Protocol (DSP), Eclipse Dataspace DCP, Eclipse Tractus-X, Data Plane Core, Data Plane Signaling |
| Governance | IDSA Dataspace Protocol + Gaia-X Trust Framework |
| Reife | EDC und Tractus-X aktiv/produktionsnah; DSP und DCP als Spezifikationen in Entwicklung |
DSP: Ja, Eclipse Dataspace definiert DSP. Das Dataspace Protocol ist die verbindliche Connector-zu-Connector-Kommunikation für alle IDSA-konformen Datenräume.
DCP: Ja, Eclipse Dataspace definiert DCP. Das Decentralized Claims Protocol löst die Frage der organisatorischen Identität und Vertrauensbildung in dezentralen Datenräumen.
eIDAS 2.0: Nicht explizit, aber DCP nutzt Verifiable Credentials und DIDs, die konzeptionell an eIDAS 2.0 anschlussfähig sind.
3. Wer baut auf wem auf?feedback
Abhängigkeitskette:
- Eclipse DSP/DCP sind die Basisprotokolle für alle Datenraum-Konnektoren.
- Eclipse EDC implementiert DSP/DCP und dient als Referenzimplementierung.
- Tractus-X ist eine branchenspezifische Ausprägung auf Basis von EDC.
- SIMPL soll die EU-Datenraum-Middleware werden, müsste dafür DSP/DCP verwenden, tut dies nachweislich noch nicht vollständig.
- OOTS 2.0 ist eine eigenständige Spezifikation ohne Bezug zu DSP/DCP; sie adressiert einen anderen Use Case (hoheitlicher Nachweisaustausch).
- NOOTS verbindet sich über die Intermediäre Plattform mit OOTS, hat aber keinen Bezug zum Eclipse-Dataspace-Ökosystem.
- FIT-Connect ist die produktive Zustellinfrastruktur für den Antragstransport zwischen Online-Diensten und Fachverfahren. Es ergänzt NOOTS auf der Transportschicht und nutzt die gleiche V-PKI-Vertrauensbasis.
warning 4. Kritische Fragen, beantwortetfeedback
Verwendet SIMPL noch veraltete Versionen und unterstützt noch nicht DSP/DCP?feedback
Ja, nach aktuellem Kenntnisstand. Die SIMPL-Architekturspezifikation ist größtenteils zugangsbeschränkt, aber die verfügbaren Informationen deuten darauf hin, dass SIMPL die aktuellen Fassungen von DSP und DCP noch nicht vollständig implementiert. SIMPL wurde als Smart Middleware für EU Common European Data Spaces konzipiert und referenziert zwar IDSA-Konzepte, aber die protokolltechnische Umsetzung hinkt den Eclipse-Dataspace-Spezifikationen hinterher.
Risiko für den D-Stack: Wenn SIMPL als EU-Middleware verbindlich wird, aber veraltete Protokollversionen verwendet, entsteht eine Interoperabilitätslücke zu Implementierungen, die aktuelle DSP/DCP-Versionen nutzen (z. B. Tractus-X, EDC). Dies muss im DSSC (Data Space Support Centre) adressiert werden.
Verwendet NOOTS schon OOTS 2.0 und eIDAS 2.0 Support?feedback
Nein zu beidem.
- OOTS: NOOTS wurde gegen OOTS TDD 1.x konzipiert (Datenmanagementkonzept v1.0 vom Dezember 2025). OOTS 2.0 wurde erst im Februar 2026 verabschiedet und ist nicht rückwärtskompatibel zu v1.x. NOOTS muss seine Intermediäre Plattform auf OOTS 2.0 aktualisieren; dies ist noch nicht erfolgt.
- eIDAS 2.0: Die EUDI-Wallet-Integration ist im NOOTS-Konzept als „Zukunftsausblick" (Kapitel 8.4) gelistet, aber weder spezifiziert noch implementiert. Es gibt keinen konkreten Umsetzungsplan oder Zeitrahmen.
Bewertung: NOOTS hat eine Doppel-Nachhollücke, sowohl bei OOTS 2.0 als auch bei eIDAS 2.0. Angesichts der Tatsache, dass OOTS 2.0 explizit eIDAS-2.0-Synergien als primäres Ziel nennt, droht NOOTS ins Hintertreffen zu geraten, wenn nicht zeitnah nachgesteuert wird.
Wie kann maximale Interoperabilität in Zukunft erreicht werden?feedback
Maximale Interoperabilität erfordert Konvergenz auf drei Ebenen:
| Ebene | Maßnahme | Verantwortlich |
|---|---|---|
| Identität | eIDAS 2.0 / EUDI Wallet als gemeinsamer Vertrauensanker für NOOTS, OOTS, SIMPL und Eclipse Dataspace | EU-Kommission (eIDAS-Implementierung), FITKO (NOOTS), Eclipse Foundation (DCP-eIDAS-Mapping) |
| Protokolle | OOTS 2.0 als Standard für hoheitlichen Nachweisaustausch; DSP/DCP als Standard für Datenräume. Dazwischen ein Brückenprotokoll (OOTS ↔ DSP Mapping), das beide Welten verbindet | DSSC (Data Space Support Centre), Gateway Coordination Group |
| Semantik | Harmonisierung der Datenmodelle: XNachweis (NOOTS) ↔ OOTS Evidence Types ↔ Dataspace Data Models. SEMIC und EIF als gemeinsamer Bezugsrahmen | FITKO, EU-Kommission (SEMIC), IDSA |
Konkreter Vorschlag: Ein OOTS-DSP-Gateway als Brückenkomponente, das den hoheitlichen Nachweisaustausch (OOTS-Protokoll) für Datenräume zugänglich macht und umgekehrt. Dieses Gateway nutzt eIDAS 2.0 als gemeinsame Identitätsschicht.
Welcher Ansatz ist empfehlenswert?feedback
Empfehlung: Zweigleisiger Ansatz mit Konvergenzpfad.
Kurzfristig: Zweigleisig
- Hoheitlicher Datenaustausch: NOOTS + OOTS 2.0 als verbindliche Grundlage. NOOTS muss dringend auf OOTS 2.0 TDD aktualisiert werden.
- Datenräume (Wirtschaft/Forschung): Eclipse EDC + DSP/DCP als Referenzimplementierung. SIMPL beobachten, aber nicht als alleinige Grundlage verwenden, solange DSP/DCP-Konformität nicht nachgewiesen ist.
- Identität: eIDAS 2.0 / EUDI Wallet als gemeinsame Klammer beider Schienen vorantreiben.
Mittelfristig: Konvergenz
- OOTS-DSP-Bridge: Brückenkomponente entwickeln, die OOTS-Evidence-Exchange über DSP-Konnektoren zugänglich macht.
- SIMPL auf DSP/DCP aktualisieren: In EU-Gremien (DSSC, Digital Europe Programme) darauf hinwirken, dass SIMPL aktuelle Eclipse-Dataspace-Protokolle übernimmt.
- NOOTS eIDAS-2.0-ready machen: EUDI-Wallet-Integration aus dem Zukunftsausblick in einen konkreten Umsetzungsplan überführen.
compare 5. Vergleichsmatrixfeedback
Legende: ● vorhanden · ◔ teilweise · ○ fehlend
| Kriterium | FIT-Connect | NOOTS | OOTS 2.0 | SIMPL | Eclipse Dataspace |
|---|---|---|---|---|---|
| DSP (Dataspace Protocol) | ○ | ○ | ○ | ○ (erwartet, nicht bestätigt) | ● (definiert DSP) |
| DCP (Decentralized Claims) | ○ | ○ | ○ | ○ | ● (definiert DCP) |
| IDSA-Konformität | ○ | ○ | ○ | ◔ (unklar) | ● |
| OOTS-Anbindung | ○ | ◔ (via Intermediäre Plattform, v1.x) | ● (ist OOTS) | ○ | ○ |
| eIDAS 2.0 / EUDI Wallet | ◔ (kryptographisch kompatibel) | ○ (Zukunftsausblick) | ● (explizites v2.0-Ziel) | ○ (unklar) | ◔ (DCP ↔ VC anschlussfähig) |
| Gaia-X Trust Framework | ○ | ○ | ○ | ◔ | ● |
| Produktionsreife | ● (produktiv seit 04/2022) | ○ (Konzept v1.0) | ● (TDD v2.0 verabschiedet) | ○ (frühe Entwicklung) | ◔ (EDC produktionsnah) |
| Open Source | ● (git.fitko.de) | ● (openCode) | ◔ (Spec öffentlich, Code EU) | ◔ (code.europa.eu) | ● (Eclipse Foundation) |
| Hoheitlicher Datenaustausch | ● (Antragstransport) | ● (Registerdaten) | ● | ○ | ○ |
| Datenräume (Wirtschaft) | ○ | ○ | ○ | ● | ● |
| Ende-zu-Ende-Verschlüsselung | ● (JWE, V-PKI) | ◔ (transportbasiert) | ◔ (eDelivery AS4) | ○ (unklar) | ◔ (Data-Plane-spezifisch) |
6. Wie müssen die einzelnen Initiativen weiterentwickelt werden?feedback
| Initiative | Kritischer Handlungsbedarf | Priorität |
|---|---|---|
| FIT-Connect | (1) Bidirektionale Kommunikation innerhalb einer Submission umsetzen (aktuell primär Einbahn-Zustellkanal). (2) EUDI-Wallet-Integration als Zustellschiene für wallet-signierte Anträge spezifizieren. (3) Brücke zu Datenraum-Konnektoren (EDC) für G2B-Szenarien evaluieren. | Mittel |
| NOOTS | (1) Aktualisierung auf OOTS 2.0 TDD, aktuell fehlt die Konformität zur verbindlichen EU-Spezifikation. (2) EUDI-Wallet-Integration von Zukunftsausblick zu konkretem Umsetzungsplan. (3) Prüfung, ob XNachweis-Format langfristig OOTS-2.0-Evidence-Types abbilden kann oder Anpassung nötig ist. | Kritisch |
| OOTS 2.0 | (1) Umsetzungsunterstützung für Mitgliedsstaaten bereitstellen (Referenzimplementierungen, Testsuite). (2) Langfristiger Konvergenzpfad mit Dataspace-Protokollen (DSP) definieren; aktuell existieren zwei parallele Welten ohne Brücke. | Hoch |
| SIMPL | (1) Transparenz schaffen: Spezifikation öffentlich zugänglich machen. (2) Aktualisierung auf aktuelle DSP/DCP-Versionen; ohne dies fehlt SIMPL die Grundlage für Interoperabilität mit dem Eclipse-Dataspace-Ökosystem. (3) eIDAS-2.0-Integration klären. | Hoch |
| Eclipse Dataspace | (1) DCP-eIDAS-2.0-Mapping formalisieren; DIDs/VCs müssen mit EUDI-Wallet-Credentials kompatibel sein. (2) Brücke zu OOTS für hoheitliche Daten definieren (OOTS-DSP-Gateway-Spezifikation). (3) Onboarding-Hürde für Behörden senken (EDC ist für Industrieunternehmen konzipiert). | Mittel |
settings 7. Kernfunktionalitäten des Bausteinsfeedback
Unabhängig von der gewählten Initiative muss der D-Stack-Funktionsbaustein folgende Fähigkeiten abdecken:
| Funktion | Beschreibung | Standard/Protokoll |
|---|---|---|
| Registerbasierter Nachweisaustausch | Strukturierter Austausch von Nachweisen zwischen Registern nach Once-Only-Prinzip | OOTS 2.0 TDD, XNachweis |
| Datenraum-Connector | Connector-zu-Connector-Kommunikation für souveräne Datenräume | Eclipse DSP, IDSA RAM 4.0 |
| Usage Policy Enforcement | Automatische Durchsetzung von Nutzungsbedingungen | ODRL (W3C) |
| Katalog-Service | Veröffentlichung und Suche von Datenangeboten und Nachweistypen | DSP Catalog Protocol, OOTS Evidence Types |
| Organisatorische Identität und Vertrauen | Vertrauensnachweise für Organisationen | Eclipse DCP, eIDAS 2.0, Gaia-X Trust Framework |
| Transfer-Typen | HTTP Pull, HTTP Push, S3-basierte Transfers | DSP Transfer Protocol |
| EU-Brücke | Gateway zwischen hoheitlichem Nachweisaustausch und Datenräumen | OOTS-DSP-Bridge (zu entwickeln) |
engineering 8. Technische Einordnungfeedback
| Eigenschaft | Wert |
|---|---|
| Kategorie | Daten, Register & Governance |
| GovStack-Mapping | Information Mediator BB (erweitert) |
| Referenzstandards | OOTS 2.0 TDD, Eclipse DSP, Eclipse DCP, IDSA RAM 4.0, Gaia-X Trust Framework, ODRL, XNachweis |
| Open-Source-Referenz | Eclipse Dataspace Components (EDC), Tractus-X |
share 9. Abhängigkeitenfeedback
- Machine Identity (Workload-Identity-Härtung der Connector-Laufzeitumgebung)
- API-Management (Gateway für externe Datenraum-/OOTS-APIs)
- Föderale API-Autorisierungsinfrastruktur (OAuth 2.0 + FAPI 2.0 für API-Absicherung der Konnektoren)
- Einwilligungsmanagement (Consent als Input für Usage Policies)
- Registerdaten-Transfer (Datentransport-Schicht)
- EUDI Wallet (eIDAS-2.0-Identitätsnachweis für Organisationen und Personen)
- Identität & Zugang (IAM) (BundID, MUK als Identitätsquellen)
arrow_forward 10. Nächste Schrittefeedback
- NOOTS-Konzept auf OOTS 2.0 TDD-Konformität prüfen und Gap-Analyse erstellen
- Eclipse EDC PoC: Souveräner Datenaustausch zwischen zwei D-Stack-Instanzen über DSP
- SIMPL-Architekturspezifikation beschaffen und auf DSP/DCP-Konformität bewerten
- OOTS-DSP-Bridge-Konzept als Architekturentscheidung (ADR) vorbereiten
- eIDAS 2.0 / EUDI Wallet als gemeinsamen Identitätslayer für beide Schienen pilotieren
- FITKO-Abstimmung: NOOTS-Roadmap für OOTS 2.0 und eIDAS 2.0 einfordern
arrow_forward 11. Weiterführende Quellenfeedback
- FIT-Connect Technische Dokumentation: docs.fitko.de/fit-connect
- FIT-Connect Source Code: git.fitko.de/fit-connect
- FIT-Connect Produktseite: fitko.de/produktmanagement/fit-connect
- NOOTS Datenmanagementkonzept: gitlab.opencode.de/noots/public/dm-noots
- OOTS 2.0 TDD: EU Digital Building Blocks / OOTS
- SIMPL Architecture: code.europa.eu/simpl/simpl-open/architecture
- Eclipse Dataspace Working Group: projects.eclipse.org/working-group/eclipse-dataspace
- Eclipse Dataspace Protocol (DSP): Eclipse Foundation
- IDSA Reference Architecture Model (RAM): IDSA