1. Anschlusskonzept Data Consumer (DC)
Redaktioneller Hinweis
Das Dokument stellt einen fortgeschrittenen und stabilen Arbeitsstand dar. Weitere Anpassungen sind in einer zukünftigen Veröffentlichung möglich.
Zielgruppe: relevant für betriebsverantwortliche Stellen und Softwarelieferanten
1.1 Abstract
Das Anschlusskonzept Data Consumer liefert notwendige Informationen für die Teilnahme von Data Consumern am NOOTS zum Zweck des Abrufs von Nachweisen. Es erklärt hierzu die notwendigen Schritte zum Anschluss eines Data Consumer an das NOOTS sowie zum Abruf von Nachweisen über das NOOTS. Nicht Teil dieses Dokuments sind u.a. Themen wie Bezahlfunktionen, Bündelung von Nachweisabrufen oder das geplante Fachdatenkonzept. Das Anschlusskonzept Data Consumer richtet sich an IT-Verantwortliche der öffentlichen Verwaltung mit Verantwortung für Onlinedienste und sonstige technische Verfahren, die zum Nachweisabruf befähigt werden sollen. Das Anschlusskonzept Data Consumer verweist auf weitere Dokumente des NOOTS, in denen sich zu jeweiligen Themen zusätzliche Informationen finden lassen.
1.2 Einführung und Ziele
1.2.1 Überblick
Das Dokument High-Level-Architecture (AD-NOOTS-03) betrachtet die Gesamtarchitektur des NOOTS, die NOOTS-Komponenten, ihr Zusammenwirken zum Nachweisabruf und die übergreifenden Querschnittsaspekte des NOOTS und EU-OOTS, die sich aus dem Architekturzielbild des NOOTS ergeben. Im Rahmen eines Nachweisabrufs fordern nationale Antrags- und Fachverfahren (nationale Data Consumer) Nachweise von nationalen Registern (Data Provider) oder Registern in EU-Mitgliedstaaten (Evidence Provider) mittels der Intermediären Plattform an. Die nationalen Data Consumer sind somit in den Prozess des Nachweisabrufs eingebunden und verantwortlich für den Abruf von Nachweisen für natürliche Personen oder Unternehmen anhand einer XNachweis-Anfrage gemäß XNachweis-Spezifikation (XS-01). Damit Data Consumer Nachweise abrufen können, ist eine technische Anbindung an das NOOTS erforderlich.
Abb. 1: Übersicht der Beteiligten beim Abruf von Nachweisen durch Data Consumer
Das Anschlusskonzept Data Consumer ist wie folgt aufgebaut:
- Das Kapitel Einführung und Ziele beschreibt grundlegende Begriffe und Zusammenhänge.
- Das Kapitel Randbedingungen beschreibt wesentliche technische, rechtliche und organisatorische Voraussetzungen, die für einen Anschluss an das NOOTS erfüllt sein müssen, sowie Abgrenzungen zu in diesem Dokument nicht betrachteten Themen.
- Das Kapitel Anforderungen beschreibt die von Data Consumern zu beachtenden Anforderungen.
- Das Kapitel Ablauf eines Nachweisabrufs beschreibt die einzelnen Schritte zum Nachweisabruf durch den Data Consumer.
- Das Kapitel Anschluss an das NOOTS beschreibt die Systemumgebung des Data Consumer im Überblick sowie die notwendigen organisatorischen und technischen Schritte zum Anschluss des Data Consumer.
- Das Kapitel Ausblick und weiterführende Aspekte liefert einen Ausblick auf angrenzende und zukünftige Inhalte.
- Das letzte Kapitel umfasst die Änderungsdokumentation mit den wesentlichen Änderungen des aktuellen Dokuments gegenüber vorherigen Versionen.
Zum besseren Verständnis wird empfohlen, zunächst die Konzepte der High-Level-Architecture (AD-NOOTS-03) und der Transportinfrastruktur (AD-NOOTS-19) zu lesen.
1.2.2 Ziele des Dokuments
Dieses Dokument legt neben den funktionalen Anforderungen auch die nicht-funktionalen Anforderungen für den technischen Anschluss von Data Consumern an das NOOTS fest. Die Zielgruppe des Dokuments sind IT-Verantwortliche der öffentlichen Verwaltung, IT-Dienstleister im Auftrag der öffentlichen Verwaltung sowie nachweisanfordernde Stellen, die gleichzeitig den Anschluss an das NOOTS verantworten.
1.2.3 Begriffsdefinitionen
Die Begriffsschärfung im Zusammenhang mit dem Data Consumer befindet sich derzeit in Abstimmung innerhalb der Gesamtsteuerung Registermodernisierung.
In diesem Kapitel sind Begriffe und deren Bedeutungen aufgeführt, die für dieses Konzept von besonderer Relevanz sind und darin verwendet werden. Für allgemeine Definitionen im Kontext der Registermodernisierung wird auf das zentrale Glossar der Gesamtsteuerung Registermodernisierung (SQ-14) verwiesen.
Data Consumer
Ein Data Consumer ist ein NOOTS-Teilnehmer zum Abruf von Nachweisen. Ein NOOTS-Teilnehmer ist eine im IAM für Behörden registrierte IT-Komponente zur Teilnahme in einer bestimmten Weise (Teilnahmeart).
Ein Data Consumer hat stets eine fachverantwortliche und eine betriebsverantwortliche Stelle (verantwortliche Stellen), die bei jedem Nachweisabruf ermittelt und protokolliert werden.
Die für den Data Consumer verantwortliche nachweisanfordernde Stelle ist die fachverantwortliche Stelle. Sie verantwortet
- die Rechtskonformität der veranlassten Nachweisabrufe,
- die Korrektheit der Daten eines Nachweisabrufs, insbesondere der Basisdaten des Nachweissubjekts und deren Vertrauensniveau,
- die Weiterleitung abgerufener Nachweise an die für die Entscheidung über den Antrag zuständige Behörde.
Die den Data Consumer im Auftrag der fachverantwortlichen Stelle betreibende Stelle ist die betriebsverantwortliche Stelle. Sie verantwortet
- den technisch korrekten Betrieb des Data Consumer und des Sicheren Anschlussknotens.
Betreibt die fachverantwortliche Stelle den Data Consumer selbst, ist sie zugleich dessen betriebsverantwortliche Stelle.
Data Consumer können nationale Onlinedienste, nationale Fachverfahren und die Intermediäre Plattform (als Data Consumer) sein.
Abb. 2: Übersicht Data Consumer
Ein Onlinedienst ist eine IT-Komponente, die ein eigenständiges elektronisches Angebot an die Nutzerinnen und Nutzer darstellt, welches die Abwicklung einer oder mehrerer elektronischer Verwaltungsleistungen von Bund oder Ländern ermöglicht. Ein Onlinedienst dient dem elektronischen Ausfüllen der Onlineformulare für Verwaltungsleistungen von Bund oder Ländern, der Offenlegung dieser Daten an die zuständige Fachbehörde sowie der Übermittlung elektronischer Dokumente und Informationen zu Verwaltungsvorgängen an die Nutzer, gegebenenfalls unter Einbindung von Nutzerkonten einschließlich deren Funktion zur Übermittlung von Daten aus einem Nutzerkonto an eine für die Verwaltungsleistung zuständige Behörde.
Fachverfahren sind fachrechtliche Verwaltungsverfahren, welche digital oder analog umgesetzt werden.
Die Intermediäre Plattform ermöglicht den Abruf von nationalen Nachweisen durch Evidence Requester aus EU-Mitgliedstaaten über das Europäische Once-Only-Technical-System (EU-OOTS). Die Intermediäre Plattform agiert hierbei als Mittler und ruft u.a. den nationalen Nachweis über das NOOTS ab.
Die Schritte einer Intermediären Plattform beim Nachweisabruf werden im Grobkonzept Intermediäre Plattform (AD-NOOTS-06) beschrieben. Daher wird die Intermediäre Plattform bei nachfolgenden Nennungen zu Data Consumern nicht betrachtet.
Nachweisanfordernde Stelle
Ein Data Consumer wird von einer nachweisanfordernden Stelle verantwortet. Gemäß §5 (2) S. 2 EGovG kann eine nachweisanfordernde Stelle eine für die Entscheidung über den Antrag zuständige Behörde oder auch eine andere öffentliche Stelle sein, die dafür zuständig ist, Nachweise einzuholen und an die für die Entscheidung über den Antrag zuständige Behörde weiterzuleiten. Die für den Nachweisabruf durch ein Fachverfahren verantwortliche Stelle benötigt für die Berechtigung zum Nachweisabruf eine eigene Rechtsgrundlage. Die hier verantwortliche Stelle wird nachfolgend zur einheitlichen Betrachtung ebenfalls als nachweisanfordernde Stelle bezeichnet.
Sicherer Anschlussknoten (SAK)
Der Begriff Sicherer Anschlussknoten (SAK) wird im zentralen Glossar der Gesamtsteuerung Registermodernisierung definiert (SQ-14).
Die Anbindung an das NOOTS ist ausschließlich über die verpflichtenden SAK gestattet. Der SAK ist mandantenfähig, was bedeutet, dass er mehrere Data Consumer verwalten kann. Die Verbindung zwischen dem Data Consumer und dem SAK erfolgt über die Consumer-API für Data Consumer des Anschlussprotokolls. Es handelt sich um eine REST-API. Weitere Informationen zum SAK finden sich in den Kapiteln "Baustein Sicherer Anschlussknoten (SAK)" und "Baustein Anschlussprotokoll" des Konzepts zur Transportinfrastruktur (AD-NOOTS-19). Eine aktuelle OpenAPI-Beschreibung der SAK-APIs kann im entsprechenden OpenCode-Projekt (SQ-31) gefunden werden.
1.3 Randbedingungen
Bevor die spezifischen Anforderungen und Schritte für den Anschluss eines Data Consumer an das NOOTS betrachtet werden können, müssen verschiedene Randbedingungen berücksichtigt werden. Dazu zählen verschiedene technische, rechtliche und organisatorische Randbedingungen für den Anschluss an das NOOTS.
1.3.1 Technische / Organisatorische / Rechtliche Randbedingungen
1.3.1.1 Rechtliche Randbedingungen
Rechtsgrundlage
Gem. § 5 Abs. 3 E-Government-Gesetz (EGovG) (RGR-10) darf die nachweisanfordernde Stelle, den Nachweis des Antragstellers bei der nachweisliefernden Stelle abrufen, wenn
- dies zur Erfüllung der Aufgabe der nachweisanfordernden Stelle erforderlich ist und
- die nachweisanfordernde Stelle den Nachweis auch aufgrund anderer Rechtsvorschriften beim Antragsteller erheben dürfte.
Dies gilt unter der Voraussetzung, dass sich der Antragsteller für den automatisierten Nachweisabruf entschieden hat.
Nach § 5 Absatz 4 des EGovG (RGR-10) darf die nachweisanfordernde Stelle die Identifikationsnummer nach § 1 des Identifikationsnummerngesetzes (IDNrG) (RGR-01) zur Zuordnung der Datensätze zum Antragsteller und zum Abruf des Nachweises sowie weitere Daten im Sinne von § 4 Absatz 2 und 3 IDNrG an die nachweisliefernde Stelle übermitteln.
Auch beim grenzüberschreitenden Nachweisabruf aus einem anderen EU-Mitgliedstaat darf die zuständige Behörde gem. § 5a Abs. 1 EGovG einen Nachweis nach Artikel 14 Absatz 2 SDG-VO (EU-03) automatisiert abrufen, wenn dies zur Erfüllung ihrer Aufgaben für eines der Verfahren nach Artikel 14 Absatz 1 SDG-VO (EU-03) erforderlich ist.
IT-Planungsrat Beschlüsse
In der High-Level-Architecture (AD-NOOTS-03) werden in dem Kapitel "Übergreifende Entwurfsentscheidungen" Beschlüsse und Vorschläge des IT-Planungsrates von übergreifender Relevanz für die NOOTS-Gesamtarchitektur aufgelistet. Die folgenden Beschlüsse und Vorschläge sind für dieses Anschlusskonzept Data Consumer von besonderer Relevanz.
Tab. 1: IT-Planungsrat Beschlüsse
| Beschlüsse | Erläuterungen |
|---|---|
| IT-PLR-Beschluss 2022/22 - Entscheidung asynchrone Prozesse ([IT-PLR-E-02](./AD-NOOTS-00_+Quellenverzeichnis.md)) |
_"TOP 3: Entscheidung zur Unterstützung asynchroner Prozesse in der Architektur der Registermodernisierung" _ Wenn der Data Consumer ein Onlinedienst ist, sollen nur fachlich synchrone Nachweisabrufe möglich sein. Für die Behörde-zu-Behörde-Kommunikation sollen auch fachlich asynchrone Nachweisabrufe möglich sein. |
Rechtliche Randbedingungen
Die nachfolgende Tabelle enthält beispielhaft eine Anforderung an nachweisanfordernde Stellen. Es ist sicherzustellen, dass sämtliche Änderungen seitens der nachweisliefernden Stelle im Einklang mit den geltenden rechtlichen Bestimmungen stehen.
Tab. 2: Rechtliche Randbedingungen
| Aufgaben | Beschreibung | |
|---|---|---|
| 1 | Prüfung der Rechtsgrundlage für den Abruf von Nachweisen | Die nachweisanfordernde Stelle hat sicherzustellen, dass die rechtlichen Grundlagen für den Abruf von Nachweisen und die Übermittlung von Daten an die nachweisliefernde Stelle vorhanden sind. |
1.3.1.2 Organisatorische Randbedingungen
Die nachfolgende Tabelle enthält Randbedingungen, die sich auf die Organisation der nachweisanfordernden Stelle beziehen.
Tab. 3: Organisatorische Randbedingungen
| Aufgaben | Beschreibung | |
|---|---|---|
| 1 | Anpassen bzw. Einrichten von betrieblichen Supportprozessen zur Erfüllung der NOOTS-SLAs | Die technischen Systeme eines Data Consumer müssen betrieben und gewartet werden. Zur Erfüllung der Service Level Agreements (SLAs) des NOOTS\* müssen betriebliche Support- und Wartungsprozesse mit zugehörigen Organisationsstrukturen angepasst bzw. neu eingeführt werden. |
*Die SLAs des NOOTS befinden sich derzeit in Ausarbeitung und werden zu einem späteren Zeitpunkt veröffentlicht.
1.3.1.3 Technische Randbedingungen
Die technischen Randbedingungen beziehen sich auf die technische Ertüchtigung von Data Consumern, die nicht Bestandteil des technischen Anschlusses an das NOOTS in diesem Konzept sind.
Tab. 4: Technische Randbedingungen
| Aufgaben | Beschreibungen | |
|---|---|---|
| 1 | Nutzeridentifzierung und -authentifzierung | Der Data Consumer muss die Nutzeridentifizierung- und authentifizierung sicherstellen. Dazu melden sich die Nutzerinnen und Nutzer über ein Nutzerkonto beim Data Consumer an. Es muss ein Identifizierungsmittel verwendet werden, dass das für die Verwaltungsleistung erforderliche Vertrauensniveau erfüllt. Im Rahmen der Nutzeridentifizierung und -authentifizierung erhält der Data Consumer die Basisdaten des Nachweissubjekts aus dem Identifizierungsmittel oder dem Ergebnis des Nutzerkontos. Zu beachten: Im NOOTS findet zudem eine Nachauthentifizierung der Nutzerinnen und Nutzer durch die Komponente "NOOTS-Nutzeridentifizierung" statt. Die Komponente dient der Nutzeridentifizierung und der Erstellung eines gesiegelten Authentifizierungstokens, welches vom Data Consumer und insbesondere Data Provider verwendet werden kann, um die Nutzerin bzw. den Nutzer zu authentisieren. Hierdurch wird der Data Provider in die Lage versetzt, die Nutzerauthentifizierung ohne zwingende Vertrauensbeziehung zum Data Consumer durchzuführen und ohne, dass eine erneute Nutzeridentifizierung (inkl. Vorlage des Identifizierungsmittels) beim Data Provider notwendig ist. Weiterführende Informationen finden sich im übergreifenden Konzept Nutzeridentifizierung, Nutzerauthentifizierung und Datensatzabgleich ([AD-NOOTS-14](./AD-NOOTS-00_+Quellenverzeichnis.md)). |
| 2 | Zuständigkeitswerte abfragen | Zuständigkeitsparameter werden ggf. beim Abruf des Nachweisangebots benötigt. Zuständigkeitsparameter definieren, welche Angaben zur Ermittlung des zuständigen Data Providers zu einem Nachweistyp notwendig sind (z.B. amtlicher Regionalschlüssel) (siehe [AD-NOOTS-07](./AD-NOOTS-07_+Grobkonzept+Registerdatennavigation+_RDN_.md)). Der Data Consumer muss die zu einem Nachweistyp gehörigen Zuständigkeitsparameter a priori kennen (z.B. dem Nachweiskatalog entnehmen) und deren Zuständigkeitswerte ggf. direkt vom Antragsteller erfragen oder von der antragbearbeitenden Person vor dem Nachweisabruf erfassen lassen. |
| 3 | Vertreter des Nachweissubjekts | Das EU-OOTS und das NOOTS bieten die technische Möglichkeit, in einem Nachweisabruf den Vertreter des Nachweissubjekts anzugeben. Bietet ein Data Consumer beim Nachweisabruf den Vertretungsfall an, muss die fachverantwortliche Stelle für geeignete Maßnahmen zur Missbrauchsverhinderung sorgen und die Korrektheit der Basisdaten von Vertreter und Vertretenem und deren jeweiligem Vertrauensniveau sicherstellen. Das NOOTS leistet keine Unterstützung bei der Prüfung von Vertretungsberechtigungen. |
| 4 | Vorschau (Preview) einrichten | Gem. § 5 Abs. 5 EGovG hat der Antragsteller bei einem elektronischen antragsgebundenen Antragsverfahren die Möglichkeit, den Nachweis vorab einzusehen, bevor der abgerufene Nachweis verwendet werden darf. Der Antragsteller kann in diesem Fall entscheiden, ob der Nachweis für das Antragsverfahren verwendet werden soll. Die Vorschau (Preview) bezeichnet die Menge aller Aktivitäten und Funktionen, durch die dieser geforderte Vorschaubereich ermöglicht werden soll. Für den nationalen Nachweisabruf wird die Preview im Bereich des Data Consumer betrieben. Im Programmbereich OZG-EU-OOTS wird aktuell ein Konzept erstellt, welches die Rahmenbedingungen und Anforderungen an die Preview beschreibt. |
1.3.2 Abgrenzungen
Um einen konsistenten Dokumentationsstand zu gewährleisten, verweist dieses Anschlusskonzept bewusst bei angrenzenden Themen auf weiterführende Konzepte des NOOTS, insbesondere auf die XNachweis-Spezifikation (XS-01), die Transportinfrastruktur (einschließlich SAK) (AD-NOOTS-19) oder IAM für Behörden (AD-NOOTS-05). Detaillierte Informationen sind diesen Konzepten zu entnehmen.
Das Anschlusskonzept Data Consumer beschreibt die technischen und organisatorischen Schritte zum elektronischen Abruf einzelner Nachweise. Es enthält keine Aussagen
- zu Bezahlfunktionen; die Abwicklung von Zahlungen für kostenpflichtige Nachweisabrufe liegt außerhalb des Regelungsumfangs von NOOTS und ist daher zusätzlich von dem Data Consumer abzudecken, der Nachweise über das NOOTS abruft,
- zur Bündelung von Nachweisabrufen; dies ist derzeit weder in der Konzeption noch im Standard XNachweis vorgesehen,
- zur Weiterleitung von durch Nachweisabrufvertreter abgerufenen Nachweisen an die antragbearbeitende Behörde; die Weiterleitungspflicht gemäß der §§ 5 und 5a EGovG ist unabhängig vom NOOTS zu erfüllen,
- zum geplanten Fachdatenkonzept des PB Registers, das sich noch in der Reviewphase befindet.
- zu Hilfsmitteln, die den eigentlichen Nachweisabruf für einen Data Consumer übernehmen; die Delegation des Nachweisabrufs an ein solches Hilfsmittel ist zulässig, aber nicht Bestandteil dieses Konzepts.
1.4 Anforderungen
Ein Data Consumer muss die nachfolgenden Anforderungen erfüllen, um Nachweise über das NOOTS abrufen zu können. Die Geltung für eine Art des Nachweisabrufs wird durch ein "x" in folgenden Spalten dargestellt:
- nationaler Nachweisabruf
- EU-Nachweisabruf
Die Anforderungen basieren auf Rechtsnormen, Beschlüssen des IT-PLR und/oder Entwurfsentscheidungen des Programmbereichs NOOTS. Die jeweilige Grundlage wird in der gleichnamigen Spalte angegeben. Die Hinweise zu mit Ziffern markierten Grundlagen sind unter der Tabelle aufgeführt.
Die Maßnahmen zur Umsetzung der Anforderungen werden in den nachfolgenden Kapiteln beschrieben (siehe Spalte Referenz).
1.4.1 Funktionale Anforderungen
Tab. 5: Übersicht funktionaler Anforderungen des NOOTS an den Data Consumer
| Nr | Anforderung | Grundlage | nationaler Nachweisabruf | EU-Nachweisabruf | Referenz im Anschlusskonzept Data Consumer |
|---|---|---|---|---|---|
| NOOTS-198 | Der Data Consumer MUSS die Berechtigung zur Teilnahme am NOOTS und zum Nachweisabruf nachweisen. | IT-PLR 2022/06 | x | x | * 6.1.1 Erstanbindung |
| NOOTS-302 | Der Data Consumer MUSS den Nachweisabrufstandard XNachweis implementieren. |
IT-PLR 2022/22, § 12 (2) IDNrG |
x | x | * 5\. Ablauf eines Nachweisabrufs |
| NOOTS-448 | Der Data Consumer MUSS für einen Nachweis aus Deutschland von der Registerdatennavigation das Nachweisangebot des Data Provider abfragen, der für Nachweistyp und Nachweissubjekt zuständig ist. | IT-PLR 2022/22 | x | * 5\. Ablauf eines Nachweisabrufs | |
| NOOTS-538 | Der Data Consumer MUSS bei einem Nachweisabruf im Dialog mit einer natürlichen Person aus Deutschland deren IDNr ermitteln und verwenden, wenn damit ein Nachweisabruf möglich ist.\*) | § 6 IDNrG | x | * 5\. Ablauf eines Nachweisabrufs | |
| NOOTS-539 | Der Data Consumer KANN bei einem Nachweisabruf zu einem Unternehmen aus Deutschland dessen bundeseinheitliche Wirtschaftsnummer ermitteln und verwenden, wenn damit ein Nachweisabruf möglich ist.\*) | § 2 UBRegG | x | * 5\. Ablauf eines Nachweisabrufs | |
| NOOTS-542 | Der Data Consumer MUSS einen Nachweis aus einem anderen EU-Mitgliedstaat über eine Intermediäre Plattform abrufen. | IT-PLR 2022/34 | x | * 5\. Ablauf eines Nachweisabrufs | |
| NOOTS-872 | Der Data Consumer MUSS sich über den Sicheren Anschlussknoten an das NOOTS anschließen. |
IT-PLR 2021/05, IT-PLR 2023/38, § 7 IDNrG |
x | x | * 6.2.1.2 Integration mit dem Sicheren Anschlussknoten |
| NOOTS-875 | Der Data Consumer MUSS für die Ermittlung des Data Provider für jeden abzurufenden Nachweis dessen Herkunft (national oder EU-Ausland) kennen - oder von der nutzenden Person erfragen. | PB NOOTS | x | x |
*) Es wird davon ausgegangen, dass bei Verfügbarkeit der IDNr als Ordnungsmerkmal bei der nachweisliefernden Stelle die Verpflichtung zur Nutzung selbiger bei Nachweisabruf in einem Staatsvertrag zum Themenbereich oder in einer Novellierung des IDNrG enthalten sein wird.
1.4.2 Nicht-funktionale Anforderungen
Tab. 6: Übersicht nicht-funktionaler Anforderungen des NOOTS an den Data Consumer
| Nr | Anforderung | Grundlage | nationaler Nachweisabruf | EU-Nachweisabruf | Referenz im Anschlusskonzept Data Consumer |
|---|---|---|---|---|---|
| NOOTS-842 | Der Data Consumer muss sicherstellen, dass ein Nachweisabruf vor Ablauf der maximal zulässigen Zeit nicht wegen Zeitablauf abgebrochen wird.\*) | PB NOOTS | x | x | |
| NOOTS-1089 | Der Data Consumer MUSS als IT-Komponente im IAM für Behörden mit der Teilnahmeart "Data Consumer" registriert sein.\*\*) | PB NOOTS | x | x | * 6.1.1 Erstanbindung |
| NOOTS-1234 | Der Data Consumer MUSS den Betrieb für den Sicheren Anschlussknoten des Data Consumer verantworten. | PB NOOTS | x | x | * 6.2.1.2 Integration mit dem Sicheren Anschlussknoten |
*) Siehe auch entsprechende Anforderung an das NOOTS zu Antwortzeiten bei Nachweisabrufen (NOOTS-628 in AD-NOOTS-03)).
**) Teilnahmeart "Data Consumer" umfasst mehrere unterschiedliche Teilnahmearten als Data Consumer, konkret z.B.: DC_ONLINEDIENST, DC_FACHVERFAHREN, DC_IP.
1.5 Ablauf eines Nachweisabrufs
In diesem Kapitel werden die Aktivitäten zum Ablauf eines Nachweisabrufs durch den Data Consumer über das NOOTS erläutert.
Die High-Level-Architektur (AD-NOOTS-03) beschreibt in dem Kapitel "Nachrichtenaustauschmuster" die unterstützten NOOTS-Nachrichtenaustauschmuster für die technische Abbildung sowohl fachlich synchroner als auch asynchroner Prozesse beim Nachweisabruf. Diese Nachrichtenaustauschmuster (Message Exchange Patterns) definieren die Interaktionen beim Austausch von Nachrichten zwischen dem Data Consumer und dem Data Provider. Weitere Details sind im Kapitel "Nachrichtenaustauschmuster" der High-Level-Architektur (AD-NOOTS-03) zu finden.
Abb. 3: Ablauf eines Nachweisabrufs
Im Folgenden werden die einzelnen Prozessschritte zum Ablauf eines Nachweisabrufs in tabellarischer Form beschrieben.
Tab. 7: Prozessschritte zum Ablauf eines Nachweisabrufs
| **Prozessschritt** | **Beschreibung** | **Anmerkung** |
|---|---|---|
| **\[DC-01\]** Berechtigung für NOOTS-Zugriffe beschaffen | * Beschaffung der notwendigen Berechtigung für die nachfolgenden NOOTS-Zugriffe * Aufruf der Methode _getZugriffsToken_ des Sicheren Anschlussknotens des Data Consumer | |
| _Prozessvariante nationaler Nachweisabruf_ | ||
| **\[DC-02a\]** Nachweisangebot des zuständigen Data Providers abrufen | * Abruf des Nachweisangebots des zuständigen Data Providers * Aufruf der Methode _getNachweisangebot_ des Sicheren Anschlussknotens des Data Consumer | Ein Nachweisangebot enthält Informationen für den Abruf eines Nachweises von einem Data Provider, der für den Nachweistyp und das Nachweissubjekt zuständig ist: * Zuständiger Data Provider samt dessen Dienstkennung (Service-ID). * Für die Ermittlung der Zuständigkeit genutzte Zuständigkeitswerte. * Für den Nachweisabruf nötiges Vertrauensniveau. Es bestimmt, wie hoch das Vertrauensniveau der Basisdaten des Nachweissubjekts oder dessen Vertreters mindestens sein muss, um einen Nachweis dieses Typs abrufen zu können. * Für den Nachweistyp angebotene Nachweisformate. Sie bestimmen, in welchen Formaten (z.B. Fachstandard-XML in Version x.y) der Data Consumer einen Nachweis beziehen kann. Der Data Consumer muss eines der angebotenen Nachweisformate im Nachweisabruf angeben. * Angabe, ob ein Nachweis dieses Typs mit IDNr (natürliche Person) bzw. beWiNr (Unternehmen) abgerufen werden kann. |
| **\[DC-03a\]** Identifikationsmerkmal für natürliche Person beschaffen | Wenn ein Identifikationsmerkmal im Register gespeichert und eine Rechtsgrundlage zu dessen Abruf vorhanden ist: * Beschaffung der IDNr einer natürlichen Person * Aufruf der Methode _getIDNr_ des Sicheren Anschlussknotens des Data Consumer | |
| **\[DC-04a\]** Daten für Nachweisabruf zusammenstellen | * Zusammenstellung der Daten für den Abruf eines nationalen Nachweises gemäß XNachweis: * Angaben zu den Beteiligten (Data Consumer, Data Provider, antragbearbeitende Behörde), * Angaben zum Nachweis (Typ, Format, Kommunikationszweck, ggf. Zuständigkeitswerte), * Protokollinformationen (Rechtsgrundlage, Verarbeitungszweck) für Datenschutzcockpit und * Angaben zum Nachweissubjekt und ggf. zum Vertreter | |
| **\[DC-05a\]** Nachweis von Data Provider abrufen | Der Data Consumer wertet die erhaltene Antwort des Data Providers aus. Enthält die Antwort * eine Fehlermeldung, soll der Data Consumer eine Fehlermeldung anzeigen und die Fehlerursache beheben, soweit sie ihm zuzurechnen ist. * eine Information, dass der Nachweis erst zu einem späteren Zeitpunkt ("ResponseAvailableDateTime") elektronisch abgerufen werden kann (siehe Nachrichtenaustauschmuster in [AD-NOOTS-03](./AD-NOOTS-03_+High-Level-Architecture+_HLA_.md)), soll der Data Consumer diesen Hinweis anzeigen. Der Data Consumer kann eine Zwischenspeicherung des laufenden Antrags anbieten und den Antragsteller zu dem Zeitpunkt informieren, wenn der Data Provider den Nachweis abrufbereit halten wollte. Der erneute Versuch eines Nachweisabruf muss vom Antragsteller angestoßen werden. | |
| **\[DC-06a\]** Nachweis in Preview freigeben | Wenn Preview vorgesehen und gewünscht ist: * Prüfung des Nachweises durch die Nutzerin oder den Nutzer sowie die anschließende Freigabe für die weitere Verwendung | * Der Data Consumer muss den Nachweis anzeigen und dem Antragsteller eine Entscheidung über die Verwendung des Nachweises ermöglichen: * Bei Zustimmung zur Verwendung darf der Data Consumer über den Nachweis im erlaubten Umfang verfügen. * Bei Ablehnung der Verwendung muss der Data Consumer den Nachweis verwerfen. |
| _Prozessvariante EU-Nachweisabruf_ | ||
| **\[DC-02b\]** Service ID der zuständigen Intermediären Plattform beschaffen | * Abruf der Service-ID der zuständigen Intermediären Plattform * Aufruf der Methode _getServiceIDzuIP_ des Sicheren Anschlussknotens des Data Consumer | |
| **\[DC-03b\]** Daten zum Aufruf der zuständigen Intermediären Plattform anfordern | * Initiierung der Beauftragung des EU-OOTS-Nachweisabrufs bei einer Intermediären Plattform (IP) und Abruf der Redirect-URL zur grafischen Oberfläche der IP * Aufruf der Methode _getIPAufrufdaten_ des Sicheren Anschlussknotens des Data Consumer | |
| **\[DC-04b\]** zuständige Intermediäre Plattform aufrufen | * Weiterleitung an die Intermediäre Plattform via erhaltener Redirect-URL * Durchführung der Preview auf der Nutzeroberfläche der Intermediären Plattform und Abruf des Nachweises aus dem EU-Mitgliedstaat | |
| **\[DC-05b\]** Nachweis von Intermediärer Plattform abholen | * Abruf der verfügbaren Nachweise von der IP unter Angabe der ConversationID aus den zuvor bezogenen Aufrufdaten * Aufruf der Methode _getNachweisVonIP_ des Sicheren Anschlussknotens des Data Consumer | |
| _Ende Prozessvarianten_ | ||
| **\[DC-07\]** Nachweis übernehmen | * Übernahme des Nachweises zur weiteren Verwendung | |
1.6 Anschluss an das NOOTS
Die Abbildung "Systemumgebung Data Consumer" zeigt die relevanten NOOTS-Komponenten für den technischen Anschluss eines Data Consumer an das NOOTS sowie die entsprechenden Kommunikationsstrecken zum Abruf von Nachweisen.
- Versand der XNachweis-Anfrage an den Data Provider und Empfang der XNachweis-Antwort
- Aufruf der Methode getNachweis des Sicheren Anschlussknotens des Data Consumer
Der Sichere Anschlussknoten (SAK) fungiert als grundlegende Komponente im NOOTS und vermittelt den Datentransport zwischen dem Data Consumer und den weiteren NOOTS-Komponenten. Er stellt den zentralen Zugangspunkt für den Data Consumer zum NOOTS dar, dessen Nutzung obligatorisch ist.
Es ist zu beachten, dass aufgrund von Vorbedingungen aus dem Kapitel "Randbedingungen" möglicherweise zusätzliche Maßnahmen erforderlich sind, um den Data Consumer zum Abruf von Nachweisen über das NOOTS zu ertüchtigen.
Abb. 4: Systemumgebung Data Consumer
Die zentralen Bausteine der Systemumgebung eines Data Consumer sind in der nachfolgenden Tabelle aufgeführt und nach Kategorien gegliedert. In der Spalte "Dokument-Referenzen" finden sich die Verweise zu den Konzepten, die die Funktionalität der einzelnen Bausteine im Detail beschreiben.
Tab. 8: Systemumgebung Data Consumer
| Kategorie | Beschreibuung | Dokument-Referenzen |
|---|---|---|
| Data Consumer | ist ein NOOTS-Teilnehmer zum Abruf von Nachweisen. | dieses Anschlusskonzept |
| NOOTS-Komponenten | 1. Sicherer Anschlussknoten für den sicheren Zugang eines Data Consumer an die NOOTS-Transportinfrastruktur. 2. Intermediäre Plattform (IP): Vermittelt zwischen dem NOOTS und dem EU-OOTS, indem Nachweisabfragen aus dem EU-Ausland in nationale Abfragen umgewandelt werden und umgekehrt. | 1. Übergreifendes Konzept Transportinfrastruktur ([AD-NOOTS-19](./AD-NOOTS-19_+Transportinfrastruktur.md)) 2. Grobkonzept Intermediäre Plattform (IP) ([AD-NOOTS-06](./AD-NOOTS-06_+Grobkonzept+Intermediaere+Plattform+_IP_.md)) |
| nationale Data Provider | sind NOOTS-Teilnehmer zur Lieferung von Nachweisen. Der Anschluss der nationalen Register an das NOOTS kann über verschiedene nachweisausstellende Registerstrukturen erfolgen: * Zentrale Register auf Bundesebene * Dezentrale Registerstrukturen: verteilte Register ohne zentralisierte Strukturen. * Dezentrale Registerstrukturen mit zentralisierten Strukturen (z.B. Abrufportale oder Spiegelregister). | Anschlusskonzept Data Provider (DP) ([AD-NOOTS-02](./AD-NOOTS-02_+Anschlusskonzept+Data+Provider+_DP_.md)) |
| Nutzerkonten | Systeme zur Nutzeridentifizierung und -authentifizierung (siehe Kapitel "Randbedingungen"). 1. Bürgerkonto für natürliche Personen 2. Organisationskonto für Unternehmen Sinne des § 3 Abs. 1 UBRegG | Übergreifendes Konzept Nutzeridentifizierung, Nutzerauthentifizierung und Datensatzabgleich ([AD-NOOTS-14](./AD-NOOTS-00_+Quellenverzeichnis.md)) |
1.6.1 Organisatorische Schritte
Neben dem technischen Anschluss eines Data Consumer an den Sicheren Anschlussknoten sind initiale und fortlaufende administrative Aufgaben in anderen NOOTS-Komponenten erforderlich. Dazu gehören die Bereitstellung des Sicheren Anschlussknotens, die Beschaffung der erforderlichen elektronischen Zertifikate sowie die Registrierung des Data Consumer im IAM für Behörden. Die initialen Schritte werden im folgenden Abschnitt "Erstanbindung" erläutert, während die fortlaufenden Aufgaben im Abschnitt "Fortlaufende Administration" behandelt werden.
1.6.1.1 Erstanbindung
Im Rahmen der Erstanbindung sind einmalige Schritte zur Einrichtung des technischen Anschlusses des Data Consumer an das NOOTS notwendig.
1.6.1.1.1 Beschaffung elektronische Zertifikate
Elektronische Zertifikate dienen verschiedenen Zwecken wie der Ende-zu-Ende-Verschlüsselung oder der Authentifizierung eines Data Consumer und können auf verschiedenen Ebenen verwendet werden:
Tab. 9: Zertifikate für verschiedene Ebenen
| Ebene | Beschreibung |
|---|---|
| Registrierung Data Consumer: IAM für Behörden | Die fach- und betriebsverantwortlichen Stellen des Data Consumer müssen sich einmalig im IAM für Behörden registrieren. Eine öffentliche Stelle nach § 2 BDSG registriert sich anhand ihres Zertifikats unter Angabe ihrer Behördenfunktion als fachverantwortliche Stelle. Ein IT-Dienstleister (z.B. eine AöR oder ein Unternehmen) registriert sich anhand seines Zertifikats als betriebsverantwortliche Stelle. Im Anschluss erfolgt durch die fach- und betriebsverantwortlichen Stellen die Registrierung des Data Consumer als IT-Komponente mit der Teilnahmeart "Data Consumer" im IAM für Behörden. Die jeweils andere Stelle wird vom IAM für Behörden zur Bestätigung der Registrierung aufgefordert. Weitere Informationen dazu finden sich im Grobkonzept IAM für Behörden ([AD-NOOTS-05](./AD-NOOTS-05_+Grobkonzept+IAM+für+Behoerden.md)). |
| Transport: Transportprotokoll | Die NOOTS-Transportinfrastruktur trägt die Verantwortung für die Sicherstellung von Qualitätsmerkmalen wie Vertraulichkeit, Authentizität und Integrität beim Abruf von Nachweisen innerhalb der Transportinfrastruktur. Die erforderlichen Zertifikate und ihre Verwendungszwecke werden im Grobkonzept Transportinfrastruktur ([AD-NOOTS-19](./AD-NOOTS-19_+Transportinfrastruktur.md)) festgelegt. |
| Transport: Anschlussprotokoll | Das Anschlussprotokoll zwischen einem Data Consumer und seinem Sicheren Anschlussknoten wird mittels einer zustandslosen REST-API implementiert. Je nachdem, welche Methode zur Authentifizierung der REST-API gewählt wird, können Client-Zertifikate erforderlich sein (siehe Grobkonzept Transportinfrastruktur ([AD-NOOTS-19](./AD-NOOTS-19_+Transportinfrastruktur.md))). Eine aktuelle OpenAPI-Beschreibung der Consumer-API ist im entsprechenden OpenCode-Projekt ([SQ-31](./AD-NOOTS-00_+Quellenverzeichnis.md)) zu finden. |
1.6.1.1.2 Registrierung der IT-Komponente als Data Consumer
Sind die fach- und betriebsverantwortlichen Stellen des Data Consumer im IAM für Behörden registriert, kann jede dieser Stellen eine IT-Komponente mit folgenden Angaben im IAM für Behörden (AD-NOOTS-05) als Data Consumer registrieren:
- Bezeichnung der IT-Komponente,
- Teilnahmeart "Data Consumer",
- Verweis auf fachverantwortliche Stelle (bei Registrierung durch die betriebsverantwortliche Stelle),
- Verweis auf betriebsverantwortliche Stelle (bei Registrierung durch die fachverantwortliche Stelle),
- eine der Behördenfunktionen der fachverantwortlichen Stelle.
Zur erfolgreichen Durchführung dieser Registrierung wird ein gültiges Zertifikat benötigt, welches den Anforderungen des IAM für Behörden entspricht. Das IAM für Behörden bestätigt die Registrierung unter Angabe der Komponenten-ID des Data Consumer, Die vom IAM vergebene Komponenten-ID dient zusammen mit dem Zertifikat der betriebsverantwortlichen Stelle des Data Consumer zur Identifizierung des selbigen beim IAM.
1.6.1.2 Fortlaufende Administration
Nach erfolgreicher Erstanbindung des Data Consumer an das NOOTS sind kontinuierliche organisatorische Tätigkeiten erforderlich.
Aktualisierung elektronische Zertifikate
Zertifikate verfügen über ein zeitliches Ablaufdatum. Rechtzeitig vor dem Ablaufdatum müssen die Zertifikate erneuert werden.
1.6.2 Technische Schritte
1.6.2.1 Erstanbindung
1.6.2.1.1 Implementierung der SAK-Consumer-API und der XNachweis-Spezifikation
Die XNachweis-Spezifikation (XS-01) beschreibt als XÖV-Standard die Nachrichtentypen, die für den Datenaustausch im NOOTS verwendet werden. Der Data Consumer muss XNachweis als allgemeinen Standard für den Nachweisabruf implementieren.
Die Consumer-API befähigt den Data Consumer dazu, Nachweise vom Data Provider oder von einem EU-Mitgliedstaat über die Intermediäre Plattform abzurufen. Dazu muss der Data Consumer die Operationen gem. der Consumer-API aufrufen. Weitere Informationen dazu sind im Kapitel "Baustein NOOTS-Anschlussprotokoll" des Grobkonzepts Transportinfrastruktur (AD-NOOTS-19) sowie im entsprechenden OpenCode-Projekt zur Open-API-Beschreibung der SAK-APIs (SQ-31) zu finden.
1.6.2.1.2 Integration mit dem Sicheren Anschlussknoten
Damit der Data Consumer die Schritte zum Nachweisabruf umsetzen kann, muss er an einen Sicheren Anschlussknoten angeschlossen werden (siehe AD-NOOTS-19).\ Dafür werden dem Data Consumer perspektivisch 3 Schritte angeboten, die im Folgenden beschrieben sind und unterschiedliche Zwecke erfüllen:
- SAK API-Mocking: Fokus auf lokale Entwicklungsumgebung und Erstellung von auf den Data Consumer zugeschnittenen Testszenarien.
- NOOTS-Referenzumgebung: Fokus auf einfache funktionale Tests und Test der Integration einer Testumgebung des Data Consumer mit einem zentralen "echten" SAK, solange noch keine SAK-Softwaredistribution bezogen werden kann.
- SAK-Softwaredistribution: Muss im Produktivbetrieb verwendet werden und kann, sobald verfügbar, beliebig für die lokale Entwicklungsumgebung sowie Testumgebungen verwendet werden.
Integration des SAK via API-Mocking
API-Mocking ist eine Technik zur Simulation des Verhaltens einer API durch Erstellung von Mock-Versionen, die echte API-Antworten nachahmen, auch wenn die tatsächliche SAK-Software noch nicht verfügbar oder fertiggestellt ist. Im OpenCode-Projekt der SAK-API (SQ-31) sind Beispieldaten enthalten, deren Beispiel-Requests und -Responses als Grundlage für die Erstellung eigener API-Mock-basierter Testfälle und Tests dienen können. Data Consumer können damit einen auf sie zugeschnittenen API-Mock der SAK-Consumer-API erstellen und in den Umgebungen ihrer Wahl (primär lokale Entwicklungsumgebung) die Integration mit dem SAK testen. NOOTS macht hierbei keinerlei Vorgaben zur Wahl des Tools, das zum API-Mocking verwendet werden soll.
Integration des SAK via NOOTS-Referenzumgebung
Ergänzend zum API-Mocking wird eine NOOTS-Referenzumgebung bereitgestellt, in welcher ein zentral gehosteter SAK bereitgestellt wird, an den sich Data Consumer anbinden können, um die Integration mit NOOTS zu testen. Der Fokus der Referenzumgebung liegt auf einfachen funktionalen Tests. Detailliertere fachliche Testfälle oder Tests von nicht-funktionalen Anforderungen wie Lasttests werden dort nicht unterstützt. Zunächst wird es dort möglich sein, den Anschluss an einen zentralen SAK zu testen. Hierbei ist wichtig zu verstehen, dass Data Consumer und Data Provider in der Referenzumgebung nicht direkt miteinander verbunden werden. Die Referenzumgebung versorgt beide Parteien jeweils getrennt mit Testdaten. Ab September wird es dann möglich sein, auf der NOOTS-Testumgebung funktionale Ende-zu-Ende-Tests durchzuführen.
Die NOOTS-Referenzumgebung steht ab sofort zur Verfügung. Weiterführende Informationen und Dokumente können beim Bundesverwaltungsamt noots.umsetzung@bva.bund.de angefragt werden. Für den technischen Support bitte an folgende Kontaktadresse wenden: noots-support@seitenbau.com
Integration des SAK via SAK-Softwaredistribution
Sobald eine Softwaredistribution des SAK zur Verfügung steht, kann diese vom Data Consumer verwendet werden, um sich an NOOTS anzuschließen.
Hierfür muss der Data Consumer:
- für alle Umgebungen, in denen der SAK betrieben wird, ein Server-Zertifikat für den SAK und ggf. ein Client-Zertifikat für den Data Consumer für die Absicherung des Anschlussprotokolls ausstellen oder ausstellen lassen
- für die Entwicklungs- und Testumgebungen, in denen der SAK betrieben wird, selbst Client-Zertifikate für die Absicherung des Transportprotokolls des SAK erzeugen
- einen idealerweise automatisierten Prozess einführen, um die aktuelle Version des SAKs in seiner Betriebsumgebung zu beziehen, zu konfigurieren und zu installieren
- für die Integration des SAKs mit den restlichen NOOTS-Komponenten und mit dem SAK des Data Providers die entsprechenden Netzfreischaltungen (z.B. Anpassung von Firewallregeln) veranlassen
- die Monitoring-Ausgaben des SAKs in die eigene Monitoring-Infrastruktur anbinden, damit auf Ausfall oder Überlastung des SAKs reagiert werden kann. Konkret sind dies:
- Technisches Logging zur Fehleranalyse
- Nachrichtenverfolgung via TraceID (traceparent)
- Monitoring z.B. via HealthChecks / Monitoring-API des SAK
1.6.2.1.3 Erweiterung der bestehenden Systemarchitektur
Um sich an das NOOTS anzuschließen, muss der Data Consumer seine bestehende Systemarchitektur anpassen.
Insbesondere müssen folgende Aspekte entschieden und dokumentiert werden:
- Welche Anpassungen an der bestehenden Systemarchitektur müssen vorgenommen werden, um die eigenen nicht-funktionalen Anforderungen insbesondere hinsichtlich Sicherheit und Verfügbarkeit zu erfüllen?
- Müssen neue Netzfreischaltungen beantragt, umgesetzt und dokumentiert werden?
- Soll der SAK Standalone oder redundant betrieben werden? (abhängig von eigenen Verfügbarkeits- und Effizienzanforderungen)
- In wie vielen Umgebungen soll der SAK installiert werden? (Entwicklungsumgebung, Testumgebungen, ...)
- Soll der SAK in einer klassischen Server-Plattform oder in einer DVC-konformen Containerumgebung betrieben werden? Installierbare Artefakte des SAK werden für beide Plattformen zur Verfügung gestellt.
- Soll der Data Consumer via TLS oder mTLS mit seinem SAK kommunizieren? Falls mTLS präferiert wird, muss der Data Consumer ein Client-Zertifikat erzeugen.
Weitere Details zu Bezug und Betrieb des SAK werden im Grobkonzept Transportinfrastruktur (AD-NOOTS-19) beschrieben.
1.6.2.2 Fortlaufende Administration
Nach erfolgreicher Erstanbindung des Data Consumer an das NOOTS sind kontinuierliche technische Tätigkeiten erforderlich.
Aktualisierung der SAK-Softwaredistribution
Die Softwaredistribution des SAK muss regelmäßig aktualisiert werden.
Aktualisierung XNachweis-Versionen
Die Spezifikation des Standards XNachweis wird regelmäßig in aktualisierter Version veröffentlicht (XS-01). Es muss sichergestellt werden, dass die jeweils aktuelle Version verwendet wird.
1.7 Ausblick und weiterführende Aspekte
Weitere Ausarbeitungen und Konkretisierungen sind geplant, um die Verständlichkeit für Verantwortliche weiter zu erhöhen. Hierzu gehören Anwendungsbeispiele für den Nachweisabruf von zentralen sowie dezentralen Data Providern. Dabei sollen ebenfalls die Aufrufe des Anschlussprotokolls mit exemplarischen Aufrufparametern und entsprechenden Antworten angegeben werden.
1.8 Änderungsdokumentation
Tab. 10: Änderungsdokumentation
| Release-Versionen | Kapitel | Beschreibung der Änderungen | Art der Änderung | Priorisierung/major changes | Quelle der Änderung | |
|---|---|---|---|---|---|---|
| 1 | Q4/2023 | Alle | * Vollständige Überarbeitung und Restrukturierung | neuer Inhalt | ⭐ | Interne Review-Anmerkungen |
| 2 | Q1/2024 | Einleitung - Data Consumer | * Definition NOOTS-Teilnehmer | Aktualisierung | ⭐ | Grobkonzept IAM für Behörden |
| 3 | Q1/2024 | Voraussetzungen für die Teilnahme am NOOTS erfüllen | * Anpassung an Vorgaben von IAM für Behörden * Anpassung an Vorgaben zur Transportinfrastruktur / Sichere Anschlussknoten | Aktualisierung | ⭐ |
Grobkonzept IAM für Behörden Grobkonzept Transportinfrastruktur |
| 4 | Q1/2024 | HLA-1: Nationalen Nachweis interaktiv abrufen | * Anpassung an Sicheren Anschlussknoten | Aktualisierung | ⭐ | Grobkonzept Transportinfrastruktur |
| 5 | Q2/2024 | Technische / Organisatorische / Rechtliche Randbedingungen | * Betrieb und Nutzung des Sicheren Anschlussknotens (SAK) neu erstellt * Tabelle mit Methoden benannt, Input/Output definiert | neuer Inhalt | ⭐ |
Grobkonzept Transportinfrastruktur Referenzumgebung |
| 6 | Q2/2024 | HLA-1: Nationalen Nachweis interaktiv abrufen / Ergebnis | * Umgang mit fachlich asynchronem Nachweisabruf neu definiert. | neuer Inhalt | ⭐ | Konsultationsprozess |
| 7 | Q2/2024 | HLA-4: Nachweis aus EU-Mitgliedstaat abrufen | * Vereinfachter Ablauf (→ Methode zum Abruf bei der IP) | Aktualisierung | ⭐ | PB NOOTS |
| 8 | Q2/2024 | Anschluss an das NOOTS | * Schaubild zu Kommunikationsbeziehungen überarbeitet (gemeinsame fachliche Verantwortung für SAKs angedeutet) | Aktualisierung | PB NOOTS | |
| 9 | Q2/2024 | Lesehilfe für Diagramme | * Lesehilfe für Diagramme entfernt | Aktualisierung | PB NOOTS | |
| 10 | Q2/2024 | Anforderungen | * Anforderungen NOOTS-872 & -1089 den fachlichen Anforderungen zugeordnet zwecks Konsistenz mit anderen NOOTS Konzeptdokumenten | Aktualisierung | PB NOOTS - Review Prozess Q2 | |
| 11 | Q2/2024 | Anschlussprotokoll des Sicheren Anschlussknoten | * Aktualisierung Nachrichtenbezeichnungen für HLA-UC1 | Aktualisierung | KoSIT-XNachweisteam | |
| 12 | Q2/2024 | Alle | * Umstrukturierung auf der Grundlage von Arc42 | Aktualisierung | PB NOOTS | |
| 13 | Q3/2024 | Technische Schritte | * Aufnahme weiterer Methodenaufruf für HLA-UC04 zur Abfrage der Service-ID der zuständigen IP | Aktualisierung | Grobkonzept Transportinfrastruktur | |
| 14 | Q3/2024 | Organisatorische Schritte | * Wegfall der Zuordnung von SAKs zu Verwaltungsbereichen | Aktualisierung | Grobkonzept Transportinfrastruktur | |
| 15 | Q4/2024 | HLA-1: Nationalen Nachweis interaktiv abrufen | * Ersetzen von Anlass durch Rechtsgrundlage bei den Protokollinformationen (Rechtsgrundlage, Verarbeitungszweck) für Datenschutzcockpit | Aktualisierung | PB NOOTS | |
| 16 | Q4/2024 |
Anhang A: Checkliste Data Consumer, Integration mit dem Sicheren Anschlussknoten |
* Checkliste Data Consumer als Anhang hinzugefügt * Kapitel 5.2.2 (Integration mit dem Sicheren Anschlussknoten) hinzugefügt | neuer Inhalt | PB NOOTS | |
| 17 | Sprint 2 (28.10 - 22.11.24) | Alle | Anpassungen im Rahmen der Konsolidierung der Anwendungsfälle in der High-Level-Architecture: * Verweise auf Anwendungsfälle 1, 2 und 4 in der High-Level-Architecture entfernt und durch übergreifenden Prozess zum Nachweisabruf ersetzt * Trennung zwischen interaktivem und nicht-interaktivem Nachweisabruf aufgehoben * Verweise auf Verfahren für Zensus und Wissenschaft als Data Consumer entfernt * Grafik und Beschreibung zu den technischen Schritten im Kapitel 5.2.1 Umsetzung des Nachweisabrufs angepasst * Kapitel 5.2.2 und 5.2.3 entfernt | Aktualisierung, Löschung | ⭐ | PB NOOTS |
| 18 | Sprint 2 (28.10 - 22.11.24) | Anschluss an das NOOTS | Abbildung 4 "Darstellung technischer Systeme zu Once-Only, ausgewählter Komponenten und Teilnehmer sowie Kommunikationsstecken" aktualisiert * IDM für Unternehmen als NOOTS-Komponente entfernt | Aktualisierung | PB NOOTS | |
| 19 | Sprint 3 (25.11.24 - 20.12.24) | Allgemein | Anpassungen im Rahmen der Harmonisierung der Anschlusskonzepte Data Consumer und Data Provider: * Kapitel 2.3 Begriffsdefinition: Definitionen zu Arten von Nachweisabrufen, Typen von Onlinediensten (autarker Onlinedienst, Onlinedienst-Plattform), antragbearbeitende Behörde und Nachweisabrufvertreter entfernt * Kapitel 3. Randbedingungen: Aufteilung in rechtliche, organisatorische und technische Randbedingungen * Kapitel 5. Ablauf eines Nachweisabrufs: neues Kapitel zur Darstellung und Beschreibung der Schritte des Nachweisabrufs ergänzt, vorheriger Bestandteil von Kapitel 6 * Kapitel 6. Anschluss and das NOOTS: Aktualisierung der Grafik zur Systemumgebung des NOOTS, Trennung von Schritten zur Erstanbindung und zur fortlaufenden Administration bei Anschluss an das NOOTS | Aktualisierung, neuer Inhalt, Löschung | ⭐ | PB NOOTS |
| 20 | Sprint 3 (25.11.24 - 20.12.24) | Anforderungen | Prüfung der funktionalen und nicht-funktionalen Anforderungen bzgl. Scope des NOOTS und Aktualität * entfernte Anforderungen: * NOOTS-462: Anforderung wurde entfernt, da sie nicht im Verantwortungsbereich des PB NOOTS liegt * NOOTS-599: Anforderung wurde entfernt, da sie nicht im Verantwortungsbereich des PB NOOTS liegt * NOOTS-835: Anforderung wurde entfernt, da sie für Funktionalität des NOOTS nicht erforderlich ist * NOOTS-873: Anforderung wurde entfernt, da sie nicht im Verantwortungsbereich des PB NOOTS liegt * NOOTS-600: Anforderung wurde entfernt, da sie nicht im Verantwortungsbereich des PB NOOTS liegt * NOOTS-864: Anforderung wurde entfernt, da sie nicht im Verantwortungsbereich des PB NOOTS liegt * aktualisierte Anforderungen: * NOOTS-539: Anforderung wurde von MUSS zu KANN-Anforderung geändert * NOOTS-1089: Anforderung wurde von funktional zu nicht-funktional geändert * neue Anforderungen: * NOOTS-1234: Anforderung wurde ergänzt, da sie sich aus den Anforderungen zur Integration des SAK beim Data Provider ergibt | Aktualisierung, Löschung | PB NOOTS | |
| 21 | Sprint 4 (06.01.25 - 31.01.25) | Technische Randbedingungen Punkt 2 Ablauf eines Nachweisabrufs Prozessschritt DC-02a Prozessschritt DC-04a | * Anlass der Änderung: In der Registerdatennavigation wurden die bei der Ermittlung der Zuständigkeit genutzten Zuständigkeitswerte mit in das Zuständigkeitstoken aufgenommen, um Fehler und Manipulationen (gesiegelte Information) auszuschließen. * Überarbeitung des Textes, begriffliche Unterscheidung zwischen Zuständigkeitsparametern und Zuständigkeitswerten * Entfernen der Angabe, ob Zuständigkeitswerte übermittelt werden müssen, Ergänzung um Zuständigkeitswerte * Aufnahme der Zuständigkeitswerte | Aktualisierung | PB NOOTS | |
| 22 | Sprint 4 (06.01.25 - 31.01.25) | Anforderungen NOOTS-538 NOOTS-842 NOOTS-875 | * Anlass der Änderung: Im Hinblick auf entsprechende Anpassungen in der HLA wurden die Anforderungen umformuliert. * Die Begriffe "interaktiv" und "nicht-interaktiv" entfallen und wurden durch andere Formulierungen ersetzt. | Aktualisierung | PB NOOTS |
1.9 Anhang A: Checkliste Data Consumer
Hinweise:
- Diese Checkliste setzt voraus, dass die Inhalte des Dokuments "AD-NOOTS-01: Anschlusskonzept Data Consumer" bekannt sind.
- Die NOOTS-Architekturdokumente werden an einigen Stellen noch nachgeschärft, daher können sich einzelne Angaben in dieser Checkliste noch ändern.
- Noch nicht alle Schritte sind bereits heute durchführbar. In der Spalte "Durchführung bereits möglich" ist daher pro Schritt angegeben, ob der Schritt bereits heute durchführbar ist.
- Diese Checkliste konzentriert sich auf den technischen Anschluss des Data Consumer an das NOOTS. Um einen Nachweisabruf Ende-zu-Ende durchzuführen sind weitere Schritte (z.B. Zustimmung des Bürgers, Anzeige der Preview und Weiterverarbeitung der Nachweise im Antragsprozess) erforderlich, die im "Anbindungsleitfaden für die naS" aufgeführt werden.
1.9.1 Checkliste fachverantwortliche Stelle
| Als fachverantwortliche Stelle muss ich ... | Welcher Schritt muss vorher ausgeführt worden sein? | Referenz auf Anschlusskonzept DC | Durchführung bereits möglich? | |
|---|---|---|---|---|
| 1 | * [ ] mir ein **Zertifikat** bei der zuständigen Zertifizierungs- oder Registrierungsstelle beschaffen. | \- | 6.1.1.1 | nein |
| 2 | * [ ] mich als fachverantwortliche Stelle **beim IAM für Behörden registrieren.** | 1 | 6.1.1.1 | nein |
| 3 | * [ ] die zur **Registrierung des Data Consumer** als IT-Komponente beim IAM für Behörden nötigen Schritte ausführen. | 2 | 6.1.1.2 | nein |
1.9.2 Checkliste betriebsverantwortliche Stelle
| Als betriebsverantwortliche Stelle muss ich ... | Welcher Schritt muss vorher ausgeführt worden sein? | Referenz auf Anschlusskonzept DC | Durchführung bereits möglich? | |
|---|---|---|---|---|
| 1 | * [ ] mir ein **Zertifikat der betriebsverantwortlichen Stelle** bei der zuständigen Zertifizierungs- oder Registrierungsstelle beschaffen. | \- | 6.1.1.1 | nein |
| 2 | * [ ] mich als betriebsverantwortliche Stelle **beim IAM für Behörden registrieren.** | 1 | 6.1.1.1 | nein |
| 3 | * [ ] die zur **Registrierung des Data Consumer** als IT-Komponente beim IAM für Behörden nötigen Schritte ausführen. | 2 | 6.1.1.2 | nein |
| 4 | * [ ] meine bestehende **Systemarchitektur** anpassen, um den Betrieb des SAK in meiner Betriebsumgebung abzubilden. | \- | 6.2.1.3 | ja |
| 5 | * [ ] für den SAK ein **Server-Zertifikat und ggf. für den Data Consumer ein Client-Zertifikat für das Anschlussprotokoll** bei der zuständigen Zertifizierungs- oder Registrierungsstelle beschaffen. | 4 | 6.2.1.2 | nein |
| 6 | * [ ] meine Testumgebungen an die **NOOTS-Referenzumgebung** anschließen. | 6.2.1.2 | geplant Q1/2025 | |
| 7 | * [ ] einen idealerweise automatisierten **Prozess einführen**, um die aktuelle Version des SAKs in meiner Betriebsumgebung zu beziehen, zu konfigurieren und zu installieren. | 6.2.1.2 | nein | |
| 8 | * [ ] für meine Entwicklungs- und Testumgebungen ein **Zertifikat** der betriebsverantwortlichen Stelle generieren. | 6.2.1.2 | ja | |
| 9 | * [ ] die **Monitoring**-Ausgaben des SAKs in meine eigenen Monitoring- (und Incident-)prozesse integrieren, um auf Ausfälle oder Überlastung des SAKs reagieren zu können. | 6.2.1.2 | nein | |
| 10 | * [ ] alle nötigen **Netzfreischaltungen** (z.B. Firewallfreischaltung) veranlassen, damit der SAK mit anderen NOOTS-Komponenten und dem SAK des DP kommunizieren kann. | 6.2.1.3 | nein |
1.9.3 Checkliste Softwarelieferant
| Als Softwarelieferant muss ich ... | Welcher Schritt muss vorher ausgeführt worden sein? | Referenz auf Anschlusskonzept DC | Durchführung bereits möglich? | |
|---|---|---|---|---|
| 1 | * [ ] den SAK in die lokale Entwicklungsumgebung integrieren (z.B. via API-Mocking basierend auf der OpenAPI-Beschreibung der SAK-API in [SQ-31](./AD-NOOTS-00_+Quellenverzeichnis.md)). | \- | 6.2.1.2 | ja |
| 2 | * [ ] im Data Consumer die **Anbindung an das** **Anschlussprotokoll** (Consumer-API) des SAK umsetzen. | \- | 6.1.1.1 | ja |
| 3 | * [ ] im Data Consumer die **Erzeugung von XNachweis-Nachrichten** umsetzen. | \- | 5. | ja |
| 4 | * [ ] einen idealerweise automatisierten **Prozess einführen**, um die aktuelle Version des SAKs in meinen Umgebungen zu beziehen, zu konfigurieren und zu installieren. | \- | 6.2.1.2 | nein |
| 5 | * [ ] für meine Entwicklungs- und Testumgebungen ein **Zertifikat der betriebsverantwortlichen Stelle** generieren. | \- | 6.2.1.2 | ja |
| 6 | * [ ] für den SAK ein **Server-Zertifikat und ggf. für den Data Consumer ein Client-Zertifikat für das Anschlussprotokoll** generieren. | \- | 6.2.1.2 | ja |