storage Registerdaten-Transferfeedback
Dieser Funktionsbaustein wurde als strategisch notwendig identifiziert und befindet sich in der Konzeptionsphase.
Status: Vorgeschlagen | Erstellt am: 15. März 2026 | Autor: BMDS-Architekturteam
lightbulb Motivationfeedback
Registerdaten sind besonders schutzwürdig und unterliegen klaren Zweckbindungen. Ohne standardisierte Transfermechanismen entstehen Insellösungen, die schwer skalierbar, kaum auditierbar und mit erhöhten Compliance-Risiken verbunden sind. Ein konsistenter, auditierbarer Datenaustausch zwischen Behördenregistern erfordert daher einen eigenen Baustein, der sowohl europäische als auch nationale Anforderungen adressiert.
lightbulb Lösungsansätzefeedback
Für registerbasierte Datenaustausche existieren zwei dominante Architekturansätze, die je nach Kontext und Interoperabilitätsanforderung auch parallel genutzt werden können.
A) Dataspaces: DSP, DCP und DPSfeedback
Dieser Ansatz setzt auf Dataspace-Standards für souveränen Datenaustausch mit klaren Nutzungsbedingungen. Er eignet sich insbesondere für föderierte Datenflüsse mit Vertrags- und Policy-Logik.
Standards und Protokollefeedback
- Eclipse Dataspace Working Group: Standardisierung und Governance der Dataspace-Protokolle.
- DSP - Dataspace Protocol: Standard für Connector-zu-Connector-Kommunikation und Vertragsverhandlung.
- DCP - Decentralized Claims Protocol: Claims- und Identitätsnachweise für Dataspace-Interaktionen.
- DPS - Eclipse Data Plane Signaling: Steuerung und Signalisierung für Data-Plane-Flows.
Wer setzt es bereits einfeedback
Folgende Programme und Plattformen setzen Dataspace-Standards bereits produktiv oder in Pilotierungen ein:
- SIMPL (EU): Gemeinsame Basis für europäische Dataspace-Infrastrukturen.
- X-Road 8: Interoperabilitätsplattform für registerbasierte Austausche.
- MyData: Datenportabilität und Governance für personenbezogene Datenflüsse.
- Catena-X: Industrieller Dataspace mit Governance- und Connector-Modellen.
- Manufacturing-X: Referenzprogramm für sektorübergreifende Datenräume.
B) NOOTS / OOTS (Once-Only Technical System)feedback
Dieser Ansatz folgt dem EU-Once-Only-Prinzip und fokussiert auf registerbasierte Datenaustausche in Verwaltungsprozessen. Er ist besonders relevant für grenzüberschreitende Verwaltungsdienste und die SDG-Interoperabilität.
Standard und Rahmenwerkfeedback
- OOTS / NOOTS – High Level Architectur: EU-Standard für den Once-Only-Datenaustausch im Verwaltungsumfeld.
compare Vergleich und Empfehlungfeedback
Gegenüberstellungfeedback
| Kriterium | Dataspaces (DSP/DCP/DPS) | NOOTS / OOTS |
|---|---|---|
| Einsatzbereich | Föderierte, sektorübergreifende Datenaustausche | Registerbasierte Verwaltungsprozesse im EU-Binnenmarkt (SDG) |
| Konkrete Implementierungen | SIMPL (EU-Infrastruktur), X-Road 8 (Behördenregister), MyData (personenbezogene Daten) | Nationale OOTS-Knoten je EU-Mitgliedstaat |
| Zugrundeliegende Protokolle | Eclipse DSP, DCP, DPS (IDSA-Standards, offenes Ökosystem) | OOTS-Spezifikation (EU-Kommission, eIDAS) |
| Governance-Modell | Dezentral, vertragsbasiert; Policy-Enforcement je Connector | Zentral koordiniert durch EU-Kommission / OOTS-Governance |
| Datensouveränität | Hoch; Nutzungsbedingungen und Consent je Datenaustausch explizit | Mittel; durch EU-Recht geregelt, zentrale Vertrauensinfrastruktur |
| Reifegrad | Pilotbetrieb bis Produktion (SIMPL 2024–2026, X-Road produktiv, Catena-X produktiv) | Produktivbetrieb in mehreren EU-Mitgliedstaaten |
| Implementierungsaufwand | Höher; Connector-Setup, Policy-Modellierung, Betrieb | Geringer für SDG-pflichtige Dienste (vorgegebene Spezifikation) |
| Grenzüberschreitend | Möglich, Governance-Abstimmung zwischen Teilnehmern erforderlich | Nativ grenzüberschreitend (EU-weit definiert) |
| Nationale Anpassung | Sehr flexibel; nationale Profile, Sektorerweiterungen möglich | Begrenzt; EU-Vorgaben dominieren |
| Typischer Anwendungsfall | Register-zu-Register mit Policy-Anforderungen, sektorübergreifende Datenräume, Industriedaten | Studiennachweise, Geburtsurkunden, Unternehmensregister (SDG-Pflicht) |
Empfehlungfeedback
Für grenzüberschreitende Verwaltungsdienste und SDG-pflichtige Prozesse (z. B. Studiennachweise, Geburtsurkunden, Unternehmensregisterdaten) ist OOTS/NOOTS die erste Wahl es ist rechtlich verbindlich, EU-weit erprobt und reduziert den Implementierungsaufwand erheblich.
Für nationale und föderierte Register-zu-Register-Transfers mit komplexen Nutzungsbedingungen, Audit-Anforderungen oder sektorübergreifenden Datenflüssen (z. B. Sozialdaten, Gesundheitsdaten, Infrastrukturdaten) empfehlen sich Dataspace-Protokolle (DSP/DCP/DPS). Sie bieten maximale Datensouveränität und sind langfristig auf europäische Datenräume (SIMPL, Gaia-X) ausgerichtet.
Beide Ansätze schließen sich nicht aus. Eine hybride Architektur, bei der OOTS für EU-Pflichtaustausche und Dataspace-Connectoren für nationale Datenflüsse genutzt werden, ist der strategisch sinnvollste Pfad für den D-Stack.
engineering Technische Einordnungfeedback
| Eigenschaft | Wert |
|---|---|
| Kategorie | Daten, Register & Governance |
| GovStack-Mapping | ○ - |
| Referenzstandards | Eclipse DSP/DCP/DPS, OOTS/NOOTS |
| Open-Source-Referenz | Eclipse Dataspace Components (EDC) |
share Abhängigkeitenfeedback
- Registrierung & Stammdaten (Registerdaten, Datenqualität)
- API-Management (Schnittstellen-Governance und Zugriff)
- Einwilligungsmanagement (Zweckbindung und Consent)
- Souveräner Datenaustausch (Dataspace-Connector-Integration)
- Zero Trust (Vertrauensmodell und Policy-Enforcement)
- Audit Trail / Compliance Log (Nachvollziehbarkeit aller Transfers)
arrow_forward Nächste Schrittefeedback
- Abgrenzung von Dataspace-Transfers vs. OOTS-Transfers für Registerfälle
- Referenzarchitektur für DSP/DCP/DPS im Behördenkontext definieren
- Pilotierung mit mindestens zwei Registern und Audit-Trail
- Integration in den D-Stack