2. Anschlusskonzept Data Provider (DP)
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
2.1 Abstract
Eine nachweisliefernde Stelle ist diejenige öffentliche Stelle, die für die Ausstellung von nationalen Nachweisen zuständig ist. In Deutschland erfolgt die Ausstellung dieser Nachweise durch nationale Register (Data Provider), die für den Nachweisabruf an das nationale Once-Only-Technical-System (NOOTS) angeschlossen werden. Das Anschlusskonzept Data Provider definiert die notwendigen Schritte für den Anschluss von nationalen Registern an das NOOTS. Es richtet sich an IT-Verantwortliche der öffentlichen Verwaltung, IT-Dienstleister im Auftrag der öffentlichen Verwaltung/Fachverfahrenshersteller sowie nachweisliefernde Stellen, die den Anschluss von Data Providern an das NOOTS verantworten.
2.2 Einführung und Ziele
2.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) sowie Antragsverfahren im EU-Ausland (Evidence Requester) mittels der Intermediären Plattform Nachweise von nationalen Registern (Data Provider) an. Die nationalen Register sind somit in den Prozess des Nachweisabrufs eingebunden und verantwortlich für die Ausstellung von Nachweisen für natürliche Personen oder Unternehmen anhand einer XNachweis-Anfrage gemäß XNachweis-Spezifikation (XS-01). Um die Ausstellung dieser Nachweise durch die nationalen Register zu ermöglichen, ist eine technische Anbindung an das NOOTS erforderlich.
Abb. 1: Übersicht der Beteiligten bei der Lieferung von Nachweisen durch Data Provider
Gemäß dem Architekturzielbild der High-Level-Architektur (AD-NOOTS-03) sind die nationalen Register als Prozessbeteiligte in den Nachweisabruf eingebunden und liefern Nachweise an folgende Data Consumer:
- nationale Onlinedienste,
- nationale Fachverfahren,
- Intermediäre Plattform.
Das Anschlusskonzept Data Provider 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 Provider zu beachtenden Anforderungen.
- Das Kapitel Ablauf einer Nachweislieferung beschreibt die einzelnen Schritte zum Nachweislieferung durch den Data Provider.
- Das Kapitel Anschluss an das NOOTS beschreibt die Systemumgebung des Data Provider im Überblick sowie die notwendigen organisatorischen und technischen Schritte zum Anschluss des Data Provider.
- 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.
2.2.2 Ziele des Dokuments
Dieses Dokument legt neben den funktionalen Anforderungen auch die nicht-funktionalen Anforderungen für den technischen Anschluss von nationalen Registern an das NOOTS fest. Die Zielgruppe des Dokuments sind IT-Verantwortliche der öffentlichen Verwaltung, IT-Dienstleister im Auftrag der öffentlichen Verwaltung/Fachverfahrenshersteller sowie nachweisliefernde Stellen, die gleichzeitig den Anschluss an das NOOTS verantworten.
2.2.3 Begriffsdefinitionen
Die Begriffsschärfung im Zusammenhang mit dem Data Provider 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 Provider
Ein Data Provider ist ein NOOTS-Teilnehmer zur Lieferung von Nachweisen.
Folgende Merkmale gelten für Data Provider:
- registriertes technisches Verfahren mit der Teilnahmeart "Data Provider", wobei die Registrierung in der NOOTS-Komponente "IAM für Behörden" erfolgt,
- kann mehrere Nachweistypen pro Registertyp für natürliche Personen oder Unternehmen aus einem fachlichen Aufgabenbereich auf einer rechtlichen Grundlage (Behördenfunktion) ausstellen.
- bei dezentralen Registern können mehrere Data Provider pro Registertyp definiert werden.
- muss durch ein Zertifikat und eine Komponenten-ID in IAM für Behörden eindeutig identifizierbar sein (AD-NOOTS-05).
- verfügt über einen XNachweis-Endpunkt, über den die Lieferung von Nachweisen verschiedener Nachweistypen gemäß XNachweis (XS-01) erfolgt.
Fachliches Datenmodell
Abb. 2: Komponentendiagramm Fachliches Datenmodell Data Provider
Anschlussmodelle für Register
Register müssen befähigt werden, Nachweise zu erzeugen. Der Anschluss der nationalen Register an das nationale Once-Only Technical System (NOOTS) kann über verschiedene Anschlussmodelle (IT-PLR-B-09) - nachfolgend auch Registerstrukturen genannt - erfolgen:
- Zentrale Register auf Bundesebene
- Dezentrale Registerstrukturen: verteilte Register ohne zentralisierte Strukturen.
- Dezentrale Registerstrukturen mit zentralisierten Strukturen, zum Beispiel Abrufportale oder Spiegelregister:
- Bundesweite Register mit dezentralen Registern auf Landesebene
- Föderal verteilte Register mit dezentralen Registern auf kommunaler Ebene
Eine zentralisierte Struktur, wie ein Spiegelregister oder Abrufportal, kann im Rahmen eines Nachweisabrufs die Nachweise auf Basis eines dezentral gepflegten Datenbestandes bereitstellen, ist aber nicht zugleich für die Datenpflege verantwortlich. Registerstrukturen, die Nachweise gemäß Fachdatenkonzept ausstellen können, werden nachweisausstellende Registerstrukturen genannt.
XNachweis-Endpunkt
Ein XNachweis-Endpunkt implementiert die XNachweis-Spezifikation (XS-01) und ist integraler Bestandteil des Data Provider. Über diesen Endpunkt erfolgt die Anfrage und Lieferung von Nachweisen durch den Data Provider an das NOOTS.
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 Provider verwalten kann. Die Verbindung zwischen dem XNachweis-Endpunkt des Data Provider und dem SAK erfolgt über die Provider-API für Data Provider des Anschlussprotokolls. Diese REST-API bietet Data Providern zwei alternative Modelle für die Kommunikation mit dem SAK: den passiven und den aktiven Empfänger. Die Wahl des geeigneten Kommunikationsmodells hängt von den Anforderungen an Durchsatz und netzseitige Sicherheitsmechanismen seitens des Data Provider ab. 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.
2.3 Randbedingungen
Bevor die spezifischen Anforderungen für den Anschluss eines nationalen Registers an das NOOTS und deren Umsetzung betrachtet werden können, müssen verschiedene Randbedingungen berücksichtigt werden. Dazu zählen die Rechtsgrundlage, relevante Beschlüsse des IT-Planungsrats sowie verschiedene technische, rechtliche, fachliche und organisatorische Vorbedingungen für den Anschluss an das NOOTS.
2.3.1 Rechtliche / Organisatorische / Technische / Fachliche Randbedingungen
2.3.1.1 Rechtliche Randbedingungen
Rechtsgrundlage
Eine nachweisliefernde Stelle ist gem. § 5 Absatz 2 EGovG (RGR-10) für die Ausstellung von Nachweisen zuständig. Nach § 5 Absatz 3 des EGovG (RGR-10) darf die nachweisliefernde Stelle den Nachweis an die nachweisanfordernde Stelle übermitteln, wenn
- dies zur Erfüllung der Aufgabe der nachweisanfordernden Stelle erforderlich ist
- die nachweisanfordernde Stelle den Nachweis auch aufgrund anderer Rechtsvorschriften beim Antragsteller erheben dürfte.
Nach § 5 Absatz 4 des EGovG (RGR-10) darf die nachweisanfordernde Stelle die Identifikationsnummer nach § 1 des Identifikationsnummerngesetzes (IDNrG) (RGR-01) und zusätzlich weitere Daten im Sinne von § 4 Absatz 2 und 3 IDNrG an die nachweisliefernde Stelle übermitteln. Die nachweisliefernde Stelle darf diese Daten zum Zwecke der Zuordnung des Nachweisabrufs zum Antragsteller verarbeiten.
Auch beim grenzüberschreitenden Nachweisabruf ist gem. § 5a Abs. 2 EGovG (RGR-10) die automatisierte Übermittlung eines Nachweises nach Artikel 14 Absatz 2 SDG-VO (EU-03) an eine Behörde eines anderen EU-Mitgliedstaats zulässig, wenn diese Behörde zuständig ist und die Übermittlung zur Erfüllung ihrer Aufgaben für eines der Verfahren nach Artikel 14 Absatz 1 der 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 Provider von besonderer Relevanz.
Tab. 1: IT-Planungsrat Beschlüsse Data Provider
| Beschlüsse | Erläuterungen |
|---|---|
|
IT-PLR-Beschluss 2022/34 - NOOTS-Registeranbindung ([IT-PLR-B-09](./AD-NOOTS-00_+Quellenverzeichnis.md)) |
_"TOP 4: Anbindung der Register an das nationale Once-Only-Technical-System zum Nachweisabruf"_ Data Provider müssen für den technischen NOOTS-Anschluss eine Vielzahl an Anforderungen erfüllen. Während es zentralen Registern voraussichtlich mit akzeptablem Aufwand möglich sein wird, diese Anforderungen zu erfüllen, gestaltet sich die Situation bei dezentralen Registern deutlich komplexer. Insbesondere dann, wenn sich die Dezentralität bis auf kommunaler Ebene erstreckt, kann nicht davon ausgegangen werden, dass die notwendigen Ressourcen zur Anbindung an das NOOTS vorhanden sind. Aus technischer Sicht wird daher empfohlen datenschutzkonforme strukturelle Anpassungen zu prüfen. Bei der Entscheidung sind allerdings neben technischen und wirtschaftlichen Aspekten auch organisatorische sowie rechtliche Vorgaben der jeweiligen Fachlichkeit zu beachten. Die Entscheidung über die Notwendigkeit und Möglichkeiten struktureller Anpassungen liegt daher bei den Fachverantwortlichen, die sich über die zuständigen Fachministerkonferenzen abstimmen. |
| 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 nachweisliefernde 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 die Ausstellung von Nachweisen gemäß Fachrecht | Die nachweisliefernde Stelle hat gemäß ihrem Fachrecht sicherzustellen, dass die rechtlichen Grundlagen für die Ausstellung von Nachweisen vorhanden sind und, dass die Ausstellung für den anfragenden Data Consumer im entsprechenden Kontext und auf dem geeigneten Kommunikationsweg erfolgt. Hierbei sind insbesondere die Anschlussmodelle mit zentralisierten Strukturen zu berücksichtigen, in denen die registerführende Stelle nicht für die Ausstellung der Nachweise zuständig ist. |
2.3.1.2 Organisatorische Randbedingungen
Die nachfolgende Tabelle enthält Randbedingungen, die sich auf die Organisation der nachweisliefernden 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 Provider 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.
2.3.1.3 Technische Randbedingungen
Die technischen Randbedingungen beziehen sich auf die technische Ertüchtigung von Registerstrukturen, die nicht Bestandteil des technischen Anschlusses an das NOOTS in diesem Konzept sind.
Tab. 4: Technische Randbedingungen
| Aufgaben | Beschreibung | |
|---|---|---|
| 1 | Datenabgleich mit Identitätsdatenabruf [IDA (SQ-30)](./AD-NOOTS-00_+Quellenverzeichnis.md) | Die nachweisliefernden Stellen, deren Register im IDNrG genannt sind, sind gemäß § 6 Absatz 1 (IDNrG, [RGR-01](./AD-NOOTS-00_+Quellenverzeichnis.md)) verpflichtet, die Basisdaten einschließlich der IDNr aus dem Identitätsdatenabruf (IDA) in ihren Datenbestand zu übernehmen. Sollten Register nicht im IDNrG genannt sein, dürfen die Basisdaten aus IDA nicht in den Datenbestand übernommen werden. Die Integration der Basisdaten ist jedoch keine Voraussetzung für den technischen Anschluss an NOOTS, würde jedoch eine effiziente Teilnahme am NOOTS unterstützen. |
| 2 | Datenabgleich mit Unternehmensbasisregister | Die nachweisliefernden Stellen nach § 4 Absatz 1 und § 5 Absatz 1 in (UBRegG\*\*,\*\* [RGR-02](./AD-NOOTS-00_+Quellenverzeichnis.md)) dürfen die bundeseinheitliche Wirtschaftsnummer für Unternehmen (beWiNr) in ihren Registern oder sonstigen Datenbeständen speichern und verwenden, soweit dies für ihre Aufgabenerfüllung erforderlich ist. Die bundeseinheitliche Wirtschaftsnummer für Unternehmen ist bei jeder Übermittlung an das und aus dem Basisregister anzugeben, wenn sie vergeben und durch das Basisregister an die Quellregister übermittelt wurde (§2 (3) UBRegG\*\*,\*\* [RGR-02](./AD-NOOTS-00_+Quellenverzeichnis.md)). Als bundeseinheitliche Wirtschaftsnummer für Unternehmen dient die Wirtschafts-Identifikationsnummer nach § 139c der Abgabenordnung (§2 (1) UBRegG\*\*,\*\* [RGR-02](./AD-NOOTS-00_+Quellenverzeichnis.md)). |
| 3 | Bereitstellung von Protokolldaten zu Nachweisabrufen der natürlichen Personen | Die nachweisliefernden Stellen, die Nachweisabrufe mittels IDNr für natürliche Personen ermöglichen, sind verpflichtet, Protokollinformationen und Nachweisdaten zu den Nachweisabrufen über eine Datenschutzcockpit-Schnittstelle gemäß XDatenschutzcockpit-Standard ([XS-02](./AD-NOOTS-00_+Quellenverzeichnis.md)) zur Verfügung zu stellen (§2 (3), §9 (2) IDNrG\*\*,\*\* [RGR-01](./AD-NOOTS-00_+Quellenverzeichnis.md)). |
| 4 | Bewertung der Vorteile und Risiken von datenschutzkonformen strukturellen Anpassungen bei Nutzung von zentralen Strukturen | Die nachweisliefernden Stellen bewerten im Vorfeld die Vorteile und Risiken bei einer Anbindung an das NOOTS von dezentralen Registerstrukturen über vorhandene oder neue zentralisierte Registerstrukturen (IT-PLR-Beschluss2022/34 [IT-PLR-E-07](./AD-NOOTS-00_+Quellenverzeichnis.md)). |
| 5 | Bereitstellung der Zuständigkeits- und Konfigurationsparameter für die Registerdatennavigation | Die Zuständigkeitsparameter und das erforderliche Vertrauensniveau müssen einmalig pro Nachweistyp und unabhängig vom spezifischen Data Provider festgelegt werden. Die nachweisliefernde Stelle eines Data Provider ist verantwortlich für die Konfiguration der unterstützten Nachweisformate für jeden angebotenen Nachweistyp, der Methoden zur Abfrage über die IDNr bzw. beWiNr sowie der erforderlichen Verbindungsparameter für den sicheren Anschlussknoten im Once-Only-Diensteverzeichnis (OODV) und im Nachweiskatalog gemäß Fachdatenkonzept. |
2.3.1.4 Fachliche Randbedingungen
Die nachfolgende Tabelle listet Randbedingungen in der Fachdomäne auf.
Tab. 5: Fachliche Randbedingungen
| Aufgaben | Beschreibung | |
|---|---|---|
| 1 | Ausstellung der Nachweise gemäß Fachdatenkonzept | Die Nachweisdaten, die über XNachweis ausgetauscht werden, müssen semantisch und syntaktisch standardisiert sein, damit nachweisanfragende Stellen und nachweisliefernde Stellen die Informationen korrekt interpretieren können. Die Standardisierung muss der nachweisanfragenden Stelle und der nachweisliefernden Stelle bekannt sein. XNachweis ([XS-01](./AD-NOOTS-00_+Quellenverzeichnis.md#xs-01)) enthält **keine** Standardisierung der Fachinhalte. Als Grundlage der Bewertung der Register bzw. der Nachweise sollte der IT-Planungsrat-Beschluss 2024/15 ([IT-PLR-B-12](./AD-NOOTS-00_+Quellenverzeichnis.md)) herangezogen werden, der den notwendigen Reifegrad der Register und Nachweise zum Anschluss an das NOOTS darstellt. In dem Beschluss wird eine möglichst schnelle Erreichung des Reifegrads D1 auf nationaler Ebene angestrebt. Mit der Erreichung des Reifegrads C auf Seiten der nachweisanfragenden Stelle und nachweisliefernden Stelle gilt jedoch auf nationaler Ebene der Reifegrad 4 des OZG als erreicht. Im Übrigen wird festgestellt, dass nachweisanfragende Stellen und nachweisliefernde Stellen im Hinblick auf Nachweisabrufe in und aus EU-Mitgliedsstaaten mindestens Nachweise im Reifegrad B abrufen und übermitteln müssen. |
| 2 | Definition der Zugriffsberechtigungen | Neben der Standardisierung der Nachweisdaten muss auch das Berechtigungsmodell gemäß IAM für Behörden ([AD-NOOTS-05](./AD-NOOTS-05_+Grobkonzept+IAM+für+Behoerden.md)) definiert sein. |
2.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.
Ein umfassendes Verständnis für den technischen NOOTS-Anschluss eines Data Provider erfordert auch die Berücksichtigung aller fachlichen, rechtlichen und organisatorischen Vorbedingungen, die im Vorfeld des technischen Anschlusses sorgfältig geprüft werden müssen. In diesem Konzept werden nur Vorbedingungen benannt, die im direkten Zusammenhang mit dem technischen NOOTS-Anschluss eines Datenanbieters stehen. Eine vollständige Liste der Vorbedingungen mit einer detaillierten Beschreibung wird zukünftig in den Dokumenten zum Fachdatenkonzept und Leitfaden für Datenbestände des Programmbereichs (PB) Register zu finden sein.
Im Dokument "Leitfaden für Datenbestände (Register, Fachverfahren) zum Anschluss an das NOOTS" des PB Register werden rechtliche, organisatorische, fachliche und technische Besonderheiten beim Anschluss von nachweisliefernden Stellen an das NOOTS übersichtlich dargestellt. Der Leitfaden für Datenbestände bildet durch die darin beschriebene generische Vorgehensweise die Grundlage für die individuelle, eigenständige Projektplanung der Roll-Out Vorhaben, indem darin standardisierte Rollout-Phasen beschrieben und auf relevante Informationen für jede Rollout-Phase verwiesen wird.
Im Dokument "Fachdatenkonzept" des PB Register wird beschrieben, wie der automatisierte Nachweisaustausch von Daten zwischen Data Consumer und Data Provider in verschiedenen Reifegraden über das NOOTS fachlich gewährleistet werden kann. Die hierfür benötigten Bedingungen, wie bspw. ein semantischer Fachdatenstandard, werden entsprechend definiert. Somit bildet das Fachdatenkonzept die fachliche Grundlage für den automatisierten Datenaustausch. Die gemäß Fachdatenkonzept zu erhebenden Daten sollen im sogenannten Nachweiskatalog gepflegt werden. Die Verweise auf die entsprechenden Dokumente werden hier ergänzt, sobald diese verfügbar sind.
2.4 Anforderungen
Im Folgenden sind die Anforderungen an den Data Provider aufgeführt. Die Maßnahmen zur Umsetzung dieser Anforderungen sind im Kapitel "5. Anschluss an das NOOTS" beschrieben.
2.4.1 Funktionale Anforderungen
Funktionale Anforderungen definieren die geforderten Funktionalitäten oder Verhaltensweisen des technischen Anschlusses des Data Provider an das NOOTS und beschreiben, welche Aufgaben dieser ausführen oder welche Fähigkeiten er besitzen soll.
Tab. 6: Funktionale Anforderungen Data Provider
| **Nr.** | **Anforderung** | **Grundlage** | **Referenz im Anschlusskonzept Data Provider** |
|---|---|---|---|
| NOOTS-363 | Der Data Provider MUSS den Nachweisabrufstandard XNachweis ([XS-01](./AD-NOOTS-00_+Quellenverzeichnis.md#xs-01)) implementieren. | PB NOOTS | * 6.2.1.1 Implementierung der XNachweis-Spezifikation * 5\. Ablauf einer Nachweislieferung |
| NOOTS-880 | Der Data Provider MUSS die Identifizierung einer natürlichen Person anhand von Basisdaten ermöglichen, wenn das Register Daten von natürlichen Personen führt. | IT-PLR-Beschluss 2022/06 | |
| NOOTS-854 | Der Data Provider MUSS die Identifizierung einer natürlichen Person anhand der IDNr ermöglichen, wenn das Register Daten von natürlichen Personen führt und im IDNrG [(RGR-01)](./AD-NOOTS-00_+Quellenverzeichnis.md) aufgeführt ist. | IT-PLR-Beschluss 2022/06 | |
| NOOTS-855 | Der Data Provider MUSS die Identifizierung von Unternehmen im Sinne des § 3 Abs. 1 UBRegG anhand von Basisdaten ermöglichen, wenn das Register Daten von Unternehmen im Sinne des § 3 Abs. 1 UBRegG führt. | IT-PLR-Beschluss 2021/05 | |
| NOOTS-410 | Der Data Provider MUSS sich über den Sicheren Anschlussknoten an das NOOTS anschließen. | PB NOOTS | * 6.2.1.2 Integration mit dem Sicheren Anschlussknoten |
| NOOTS-881 | Der Data Provider SOLL Nachweisabrufe über das synchrone Request-Response-Nachrichtenaustauschmuster ermöglichen. | PB NOOTS | * 5\. Ablauf einer Nachweislieferung |
| NOOTS-882 | Der Data Provider KANN Nachweise fachlich asynchron bereitstellen, falls der Nachweis nicht innerhalb der geforderten Antwortzeit ausgestellt werden kann. In diesem Fall KANN der Abrufende den Nachweis durch eine erneute Anfrage abrufen. | PB NOOTS | * 5\. Ablauf einer Nachweislieferung |
2.4.2 Nicht-funktionale Anforderungen
Nicht-funktionale Anforderungen beziehen sich auf die Qualität, in der die geforderten Funktionalitäten erbracht werden sollen. Hierzu gehören Aspekte wie die Verfügbarkeit und Antwortzeiten.
Tab. 7: Nicht-funktionale Anforderungen Data Provider
| **Nr.** | **Anforderung** | **Grundlage** | **Referenz im Anschlusskonzept Data Provider** |
|---|---|---|---|
| NOOTS-859 | Der Data Provider MUSS innerhalb von 3 Sekunden der Nachweisabrufe eine Antwort liefern. | PB NOOTS | * 4.1 Funktionale Anforderungen, NOOTS-882 |
| NOOTS-836 | Das NOOTS MUSS eine effiziente Lokalisierung und Analyse von Fehlern wirksam unterstützen. | PB NOOTS | |
| NOOTS-355 | Der Data Provider MUSS als IT-Komponente im IAM für Behörden mit der Teilnahmeart "Data Provider" registriert sein. | PB NOOTS | * 6.1.12 Registrierung als NOOTS-Teilnehmer |
| NOOTS-1259 | Der Data Provider MUSS den Betrieb für den Sicheren Anschlussknoten des Data Provider verantworten. | PB NOOTS | * 6.2.1.2 Integration mit dem Sicheren Anschlussknoten |
| NOOTS-717 | Das NOOTS MUSS Mechanismen vorsehen, die den Parallelbetrieb unterschiedlicher Versionen einzelner Standards und Schnittstellen erlauben, so dass Umstellungen nicht zeitgleich in allen betroffenen Systemen erfolgen müssen. | PB NOOTS | |
| NOOTS-888 | Der Data Provider MUSS sicherstellen, dass personenbezogene Daten ausschließlich zum berechtigten Nachweissubjekt abgerufen werden können. | PB NOOTS | * 5\. Ablauf einer Nachweislieferung |
| NOOTS-992 | Der Data Provider KANN die Daten zur Siegelung der Nachweise an den Data Consumer übertragen, sofern die Integrität der Nachweise durch Siegelung sichergestellt wird. | PB NOOTS | |
| NOOTS-964 | Der Data Provider SOLL 98% der Zeit verfügbar sein. | PB NOOTS | |
| NOOTS-1026 | Der Data Provider SOLL 24/7 nutzbar sein. | PB NOOTS |
2.5 Ablauf einer Nachweislieferung
In diesem Kapitel werden die Aktivitäten zum Ablauf einer Nachweislieferung durch den Data Provider über das NOOTS erläutert. Die Rahmenbedingungen für die Erstellung von Nachweisdaten werden an dieser Stelle nicht behandelt. Hierfür wird auf das zukünftige Fachdatenkonzept verwiesen.
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 bei der Abfrage von Nachweisen. 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 einer Nachweislieferung
Im Folgenden werden die einzelnen Prozessschritte zum Ablauf einer Nachweislieferung in tabellarischer Form beschrieben.
Tab. 8: Prozessschritte zum Ablauf einer Nachweislieferung
| **Prozessschritt** | **Beschreibung** | **Anmerkung** |
|---|---|---|
| **\[DP-01\]** Nachweis-Anfrage empfangen | * Empfang der Nachweis-Anfrage * Aufruf der Methode _getNachweis_ des Sicheren Anschlussknotens des Data Provider * Authentifizierung zwischen dem Data Provider und dem Sicheren Anschlussknoten erfolgt gemäß den Anforderungen des Anschlussprotokolls | * Entscheidung des Data Provider für ein Kommunikationsmodell, entweder "aktiver Empfänger" oder "passiver Empfänger", der Provider-API des Anschlussprotokolls * SAK des DP hat das Abruftoken der Vermittlungsstelle erfolgreich geprüft |
| **\[DP-02\]** XNachweis-Anfrage lesen und validieren | * Schema-Validierung der XML-Struktur für XNachweis-Anfrage (DE.EvidenceRequest.0x01) * Prüfung folgender Daten der XNachweis-Anfrage * Version der unterstützten XNachweis-Version * Daten zum Data Provider * Daten zu Zuständigkeitsparametern * Daten zum Nachweissubjekt * Daten zum angefragten Nachweistyp wie zum Beispiel Identifier, Formate, Schema-Versionen und Anforderungselemente * Vertrauensniveau des Nachweissubjektes muss mindestens dem erforderlichen Vertrauensniveau für den Nachweistyp entsprechen oder dieses übertreffen | * DE.EvidenceRequest.0x01 in XRepository:XNachweis ([XS-01](./AD-NOOTS-00_+Quellenverzeichnis.md#xs-01)) * Falls der DP Zuständigkeitsparameter definiert, die für die Bestimmung der örtlichen Zuständigkeit notwendig sind, müssen die Zuständigkeitswerte für diese korrekt gegeben sein. |
| **\[DP-03a\]** Prüfung Basisdaten | Wenn Nachweisabruf ohne Identifikationsmerkmal erfolgt: * Prüfen anhand der Basisdaten aus der XNachweis-Anfrage, ob eine natürliche Person oder Unternehmen im Datenbestand des Registers eingespeichert ist Wenn die Prüfung fehlschlägt, dann wird eine XNachweis-Fehlerantwort (DE.EvidenceErrorResponse.0x03) erzeugt. | * Bei Nachweisabruf über die Intermediäre Plattform (IP) kann die Prüfung nur anhand Basisdaten erfolgen, da im EU-OOTS kein Identifikationsmerkmal bekannt ist |
| **\[DP-03b\]** Prüfung Identifikationsmerkmal | Wenn Nachweisabruf mit Identifikationsmerkmal erfolgt: * Prüfen, ob das Identifikationsmerkmal aus der XNachweis-Anfrage im Datenbestand des Registers eingespeichert ist: * bei einer natürlichen Person über die Identifikationsnummer IDNr und dem Geburtsdatum gemäß § 6 Absatz 3 Nr. 2 IDNrG * bei Unternehmen im Sinne des § 3 Abs. 1 UBRegG über die bundeseinheitliche Wirtschaftsnummer beWiNr. Wenn die Prüfung fehlschlägt, dann wird eine XNachweis-Fehlerantwort (DE.EvidenceErrorResponse.0x03) erzeugt. | * Vorbedingung für die eindeutige Identifizierung mit der IDNr bei einer natürlichen Person ist der Datenabgleich mit Identitätsdatenabruf (IDA) * Vorbedingung für die eindeutige Identifizierung mit der beWiNr. bei Unternehmen im Sinne des § 3 Abs. 1 UBRegG ist der Datenabgleich mit Unternehmensbasisdatenregister |
| _Prozessvariante Nachweis verfügbar_ | ||
| **\[DP-04a\]** Nachweis ausstellen | * Durchführung von Prüfungen, wie beispielsweise die Anwendung einer Auskunftssperre, erfolgt gemäß dem internen Berechtigungsmodell der Register zur Ausstellung von Nachweisen * Ausstellung der Nachweisdaten für das Nachweissubjekt auf Basis der Daten aus der XNachweis-Anfrage (Nachweistyp, Format, Datenfelder, …) durch die Registerstruktur * Nachweisdaten können gesiegelt werden, um die Integrität zu gewährleisten | * Erzeugung von Fachdaten für den Nachweis, siehe Fachdatenkonzept * Für den Abruf von nationalen Nachweisen aus EU-Mitgliedstaaten über das EU-OOTS soll die menschenlesbare Darstellung von strukturierten Nachweisdaten in der Preview durch die Intermediäre Plattform mithilfe von Templates erfolgen. * Für dezentrale Registerstrukturen muss die Nachweisausstellung durch die anhand der gegeben Zuständigkeitswerte identifizierte nachweisauststellende Registerstruktur erfolgen. |
| **\[DP-05a\]** Fachliche Protokollierung | Wenn Nachweisabruf mit Identifikationsmerkmal erfolgt: * Erzeugung eines Protokolleintrages mit Nachweisinhalten: * bei natürlichen Personen mit einer IDNr gemäß §9 IDNrG ([RGR-01](./AD-NOOTS-00_+Quellenverzeichnis.md)) und * bei Unternehmen im Sinne des § 3 Abs. 1 UBRegG gemäß §7 UBRegG ([RGR-02](./AD-NOOTS-00_+Quellenverzeichnis.md)) | * Die Aufbewahrungs- und Löschfristen der Protokolldaten sind gemäß §9 IDNrG und §7 UBRegG einzuhalten. * Bei natürlichen Personen müssen die Protokolleinträge so gespeichert werden, dass diese von der Datenschutzcockpit-Schnittstelle gemäß XDatenschutzcockpit-Standard ([XS-02](./AD-NOOTS-00_+Quellenverzeichnis.md)) ausgelesen werden kann. |
| **\[DP-06a\]** Technische Protokollierung | * Technische Protokollierung der Nachweisabrufe zur schnellen Identifizierung von Fehlersituationen | * Bei der technischen Protokollierung sind die Vorgaben der Datenschutzgrundverordnung (DSGVO) einzuhalten. Die technischen Protokolle müssen anhand von Suchparametern effizient durch berechtigte Personen analysiert werden können. |
| _Prozessvariante Nachweis nicht verfügbar_ | ||
| **\[DP-04b\]** Zeitpunkt der Verfügbarkeit des Nachweises festlegen | * Können die erforderlichen Nachweisdaten nicht innerhalb der vorgesehenen Antwortzeiten bereitgestellt werden und wird das Nachrichtenaustauschmuster "Request-Response/Sync mit erneutem Abruf (Retry)" unterstützt, so muss der Data Provider einen Zeitpunkt ("ResponseAvailableDateTime") festlegen, an dem der Nachweis erneut durch den Data Consumer abgerufen werden kann. * Der Data Provider sorgt dafür, dass der Nachweis zum angegebenen Zeitpunkt ("ResponseAvailableDateTime") verfügbar ist. * Erzeugen einer XNachweis-Antwort mit dem Zeitpunkt ("ResponseAvailableDateTime") (siehe \[DP-10\]) | * Details zu Nachrichtenaustauschmuster siehe Kapitel "Nachrichtenaustauschmuster" in High-Level-Architecture ([AD-NOOTS-03](./AD-NOOTS-03_+High-Level-Architecture+_HLA_.md)) |
| _Ende Prozessvarianten_ | ||
| **\[DP-07\]** XNachweis-Antwort oder Fehlermeldung erzeugen | * Erzeugen der XNachweis-Antwort: DE.EvidenceResponse.0x02 * mit Nachweisdaten (RegistryObjectList) \ ODER * mit Zeitpunkt ("ResponseAvailableDateTime") zu dem der Nachweis verfügbar sein wird ODER * Erzeugen einer XNachweis-Fehlermeldung: DE.EvidenceErrorResponse.0x03 | * XRepository:XNachweis ([XS-01](./AD-NOOTS-00_+Quellenverzeichnis.md#xs-01)) |
| **\[DP-08\]** XNachweis-Antwort oder Fehlermeldung zurücksenden | * Rücksenden der XNachweis-Antwort oder Fehlermeldung | |
2.6 Anschluss an das NOOTS
Die Abbildung "Systemumgebung Data Provider" zeigt die relevanten NOOTS-Komponenten für den technischen Anschluss eines Data Provider an das NOOTS sowie die entsprechende technische Schnittstelle zur Lieferung von Nachweisen.
Der Sichere Anschlussknoten (SAK) fungiert als grundlegende Komponente im NOOTS und vermittelt den Datentransport zwischen dem Data Provider und den weiteren NOOTS-Komponenten. Er stellt den zentralen Zugangspunkt für den Data Provider zum NOOTS dar, dessen Nutzung obligatorisch ist. Der Data Provider muss über seinen XNachweis-Endpunkt genau eine technische Schnittstelle gemäß der XNachweis-Spezifikation (XS-01) bereitstellen, um Nachweise zu liefern. Diese Schnittstelle ermöglicht auch die Bereitstellung von Nachweisen mit unterschiedlichen Nachweistypen. Die Anbindung des XNachweis-Endpunktes an den dezentralen SAK des Data Provider erfolgt über das REST-basierte Anschlussprotokoll (AD-NOOTS-19).
Es ist zu beachten, dass aufgrund von Vorbedingungen aus dem Kapitel "Randbedingungen" möglicherweise die Implementierung zusätzlicher technischer Schnittstellen erforderlich ist. Dazu gehören der Datenabgleich mit dem Identitätsdatenabruf (IDA) sowie die Integration mit dem Datenschutzcockpit gemäß dem IDNrG (RGR-01) oder der Datenabgleich mit dem Unternehmensbasisdatenregister gemäß dem UBRegG (RGR-02).
Abb. 4: Systemumgebung Data Provider
Die zentralen Bausteine der Systemumgebung eines Data Provider 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. 9: Systemumgebung Data Provider
| Kategorie | Beschreibung | Dokument-Referenzen |
|---|---|---|
| Data Provider | ist ein NOOTS-Teilnehmer zur Lieferung von Nachweisen. Die Funktionalität eines Data Provider unterteilt sich in: 1. Anschluss NOOTS: Anschluss zwischen dem XNachweis-Endpunkt und dem Sicheren Anschlussknoten 2. Anschluss Register: Anschluss nachweisausstellende Registerstrukturen zur Bereitstellung der Nachweise | 1. dieses Anschlusskonzept 2. Leitfaden für Datenbestände und Fachdatenkonzept PB Register |
| NOOTS-Komponenten | 1. Sicherer Anschlussknoten für den sicheren Zugang eines Data Provider 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. 3. Datenschutzcockpit (DSC) zur Anzeige von Datenübermittlungen unter Verwendung der Identifikationsnummer (IDNr). Die DSC-Anbindung ist eine Vorbedingung. | 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)) 3. XRepository: XDatenschutzcockpit ([XS-02](./AD-NOOTS-00_+Quellenverzeichnis.md)) |
| nationale Data Consumer | sind NOOTS-Teilnehmer zum Abruf von Nachweisen über das NOOTS: * Onlinedienste oder * Fachverfahren. | Anschlusskonzept Data Consumer (DC) ([AD-NOOTS-01](./AD-NOOTS-01_+Anschlusskonzept+Data+Consumer+_DC_.md)) |
| Datenabgleich Identifikator | Systeme zur Erfüllung technischer Vorbedingungen zum Datenabgleich (siehe Kapitel "Randbedingungen"). 1. Identitätsdatenabruf (IDA) zum Datenabgleich nach dem IDNrG ([RGR-01](./AD-NOOTS-00_+Quellenverzeichnis.md)) 2. Unternehmensbasisdatenregister zum Datenabgleich nach dem UBRegG ([RGR-02](./AD-NOOTS-00_+Quellenverzeichnis.md)) | 1. Identitätsdatenabruf (IDA): XRepository:XBasisdaten ([XS-03](./AD-NOOTS-00_+Quellenverzeichnis.md)) 2. Unternehmensbasisdatenregister: XUnternehmen.Basisregister ([XS-06](./AD-NOOTS-00_+Quellenverzeichnis.md)) |
2.6.1 Organisatorische Schritte
Neben dem technischen Anschluss eines Data Provider 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, die Bereitstellung von Daten für die Registerdatennavigation sowie die Registrierung des Data Provider 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.
2.6.1.1 Erstanbindung
Im Rahmen der Erstanbindung sind einmalige Schritte zur Einrichtung des technischen Anschlusses Data Provider an das NOOTS notwendig.
2.6.1.1.1 Beschaffung elektronische Zertifikate
Elektronische Zertifikate dienen verschiedenen Zwecken wie der Ende-zu-Ende-Verschlüsselung oder der Authentifizierung eines Data Provider und können auf verschiedenen Ebenen verwendet werden:
Tab. 10: Zertifikate für verschiedene Ebenen
| Ebene | Beschreibung |
|---|---|
| Registrierung Data Provider: IAM für Behörden | Die fach- und betriebsverantwortlichen Stellen des Data Provider 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 Provider als IT-Komponente mit der Teilnahmeart "Data Provider" 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 sind im Grobkonzept IAM für Behörden zu finden ([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ätsstandards 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 XNachweis-Endpunkt eines Data Provider und seinen Sicheren Anschlussknoten wird mittels einer zustandslosen REST-API implementiert. Der Data Provider muss sich zwischen zwei alternativen Kommunikationsmodellen entscheiden: * _"aktiver Empfänger"_: Der SAK stellt die Operationen der Provider-API zur Verfügung, die vom Data Provider aufgerufen werden, um Nachweis-Anfragen abzurufen. * _"passiver Empfänger"_: Der SAK spezifiziert eine API als Service Provider Interface (SPI), welches vom Data Provider zu implementieren ist. Der SAK des Data Provider leitet eine Nachweis-Anfragen an das SPI des passiven Data Provider weiter. 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 Provider-API ist im entsprechenden OpenCode-Projekt ([SQ-31](./AD-NOOTS-00_+Quellenverzeichnis.md)) zu finden. |
| Inhalt: Nachweis | Der Data Provider kann die Integrität und Authentizität der Nachweisdaten durch Siegelung mithilfe eines Zertifikats sicherstellen (siehe auch das Qualitätsmerkmal "[Integrität](./AD-NOOTS-02_+Anschlusskonzept+Data+Provider+_DP_.md)"). |
2.6.1.1.2 Registrierung der IT-Komponente als Data Provider
Sind die fach- und betriebsverantwortlichen Stellen des Data Provider 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 Provider registrieren:
- Bezeichnung der IT-Komponente,
- Teilnahmeart "Data Provider",
- 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, das 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 Provider. Die vom IAM vergebene Komponenten-ID dient zusammen mit dem Zertifikat der betriebsverantwortlichen Stelle des Data Provider zur Identifizierung des selbigen beim IAM.
2.6.1.1.3 Lieferung initiale Daten Once-Only-Diensteverzeichnis (OODV) und Nachweiskatalog
Die Konfigurationsdaten eines Data Provider für die Registerdatennavigation wie Verbindungs- und Zuständigkeitsparameter zur Lokalisierung müssen in den folgenden Pflegesystemen verwaltet werden:
- Once-Only-Diensteverzeichnis: Hier werden die technischen Daten für den OO-Dienst des Data Provider gepflegt. Dazu zählen die ServiceID, die den Data Provider und sein Nachweisangebot eindeutig identifiziert, sowie die Verbindungsparameter für eine sichere, verschlüsselte Kommunikationsverbindung zum SAK des Data Provider.
- Nachweiskatalog gemäß Fachdatenkonzept: Hier werden die fachlichen Daten, wie Nachweistypen, Zuständigkeiten und Nachweisangebote des Data Provider verwaltet.
2.6.1.2 Fortlaufende Administration
Nach erfolgreicher Erstanbindung des Data Provider 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.
Aktualisierung Once-Only-Diensteverzeichnis und Nachweiskatalog
Die Aktualisierung der Konfigurationsdaten für den Data Provider erfolgt durch die Pflegesysteme für das Once-Only-Diensteverzeichnis und den Nachweiskatalog gemäß Fachdatenkonzept.
2.6.2 Technische Schritte
2.6.2.1 Erstanbindung
2.6.2.1.1 Implementierung der SAK-Provider API und der XNachweis-Spezifikation
Die XNachweis-Spezifikation (XS-01) beschreibt als XÖV-Standard die Nachrichtentypen, die der Data Provider für den Datenaustausch im NOOTS verwendet.
Abb. 5: XNachweis-Endpunkt des Data Provider
Durch den Data Provider sind die nachstehenden Nachrichtentypen gemäß der XNachweis-Spezifikation zu implementieren.
Tab. 11: XNachweis-Nachrichtentypen
| Nachrichtentyp | Beschreibung | Nachricht | nationaler DC | IP als DC |
|---|---|---|---|---|
| XNachweis-Anfrage | Parameter, die für die Ausstellung von Nachweisen benötigt werden | DE.EvidenceRequest.0101 | x | |
| DE.EvidenceRequest.0301 | x | |||
| XNachweis-Antwort | Bereitstellung der Ergebnisse einer erfolgreich verarbeiteten Nachweis-Anfrage in Form von einem oder mehreren Nachweisen | DE.EvidenceResponse.0102 | x | |
| DE.EvidenceResponse.0302 | x | |||
| XNachweis-Fehlerantwort | Fehlermeldungen, die durch Fehler bei der syntaktischen und semantischen Validierung der Nachweis-Anfrage oder bei der Bereitstellung von Nachweisen gemeldet werden. Nachweise werden in diesem Fall nicht geliefert. | DE.EvidenceErrorResponse.0103 | x | |
| DE.EvidenceErrorResponse.0303 | x |
Die Provider-API befähigt den Data Provider dazu, Nachweise aus nationalen Registern bereitzustellen. Sie bietet dabei zwei alternative Kommunikationsmodelle für die Kommunikation mit dem SAK: den passiven und den aktiven Empfänger. Die Wahl des geeigneten Kommunikationsmodells richtet sich nach den Anforderungen des Data Provider an Durchsatz und netzseitige Sicherheitsmechanismen. 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.
2.6.2.1.2 Integration mit dem Sicheren Anschlussknoten
Damit der Data Provider die Schritte zum Nachweisabruf umsetzen kann, muss er an einen Sicheren Anschlussknoten angeschlossen werden.\ Dafür werden dem Data Provider perspektivisch 3 Möglichkeiten angeboten, die im Folgenden beschrieben sind und unterschiedliche Zwecke erfüllen:
- API-Mocking: Fokus auf lokale Entwicklungsumgebung und Erstellung von auf den Data Provider maßgeschneiderten Testszenarien.
- NOOTS-Referenzumgebung: Fokus auf einfache funktionale Tests und Test der Integration einer Testumgebung des Data Provider mit einem zentralen "echten" SAK, so lange 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 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 Provider können damit einen auf sie zugeschnittenen API-Mock der SAK-Provider-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 Provider 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 Provider verwendet werden, um sich an NOOTS anzuschließen.
Hierfür muss der Data Provider:
- 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 SAK des Data Provider (passiver Empfänger) oder ein Client-Zertifikat für den Data Provider (aktiver Empfänger) 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 Consumer 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
2.6.2.1.3 Erweiterung der bestehenden Systemarchitektur
Um sich an das NOOTS anzuschließen, muss der Data Provider 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?
- Welches Kommunikationsmodell wird für die Kommunikation zwischen SAK des Data Provider und Data Provider selbst gewählt (aktiver Empfänger, passiver Empfänger)?
- 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 SAK des Data Provider via TLS oder mTLS mit dem Data Provider kommunizieren? Falls mTLS präferiert wird, muss der Data Provider ein Client-Zertifikat erzeugen.
Weitere Details zu Bezug und Betrieb des SAK werden im Konzept zur Transportinfrastruktur von NOOTS (AD-NOOTS-19) beschrieben.
2.6.2.2 Fortlaufende Administration
Nach erfolgreicher Erstanbindung des Data Provider 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.
2.7 Ausblick und weiterführende Aspekte
Der technische NOOTS-Anschluss eines Data Provider ist insbesondere abhängig von den Konzepten der Transportinfrastruktur (AD-NOOTS-19) und anderer NOOTS-Komponenten, die in der Systemumgebung im Kapitel "Anschluss an das NOOTS" dargestellt werden. Diese Konzepte werden im Rahmen des NOOTS-Anforderungsmanagement angepasst oder erweitert. Diese Weiterentwicklung der Konzepte wird auch Einfluss auf die Inhalte dieses Konzeptes haben, was eine Aktualisierung in zukünftigen Releases zur Folge hat. Die Weiterentwicklung dieses Konzeptes hat aber nur geringe Auswirkungen auf die Vorbedingungen zum technischen Anschluss, wie beispielsweise die Ertüchtigung der Registerstrukturen oder die fachliche Spezifikation der Nachweise im Rahmen des Fachdatenkonzeptes bzw. Leitfadens für Datenbestände.
2.8 Änderungsdokumentation
Tab. 13: Änderungsdokumentation
| Release-Versionen | Kapitel | Beschreibung der Änderung | Art der Änderung | Priorisierung/major changes | Quelle der Änderung | |
|---|---|---|---|---|---|---|
| 1 | Q4/2023 | Begriff Data Provider | * Konkretisierung Begriff Data Provider unter Berücksichtigung der verschiedenen Anschlussmodelle für Register | Aktualisierung | :star: |
Komponententeam, NOOTS-Board |
| 2 | Q4/2023 | Randbedingungen | * Schärfung der Formulierungen in den Vorbedingungen an den technischen Anschluss | Aktualisierung |
Interne Review-Anmerkungen, externer Review anderer PBs |
|
| 3 | Q4/2023 | Anforderungen | Einführung eines Überblicks über alle funktionalen und nicht-funktionalen Anforderungen für den technischen Anschluss eines Data Provider unter Berücksichtigung der NOOTS-Gesamtanforderungen mit: * Zuweisung der Anforderung zu einem zeitlichen Architekturzielbild und * Verweis auf entsprechende Umsetzungshinweise zu einer Anforderung im Anschlusskonzept. | neuer Inhalt | :star: | Komponententeam |
| 4 | Q4/2023 | Anschluss an das NOOTS | Erweiterung der Beschreibung des technischen Anschlusses eines Data Provider an NOOTS: * graphische Darstellung der Systemumgebung eines Data Provider mit einer Beschreibung der technischen Schnittstellen * Initiale Beschreibung der Anforderungen an den technischen XNachweis-Endpunkt eines Data Provider unter Berücksichtigung der XNachweis-Spezifikation. * Prozessbeschreibung für den Ablauf einer interaktiven Nachweislieferung * Definition der Qualitätsmerkmale auf Basis der nicht-funktionalen Anforderungen an den technischen Anschluss. | neuer Inhalt | :star: | Komponententeam |
| 5 | Q1/2024 | Begriffsdefinition | * Definition NOOTS-Teilnehmer: * alt: "Ein Data Provider ist ein NOOTS-Teilnehmer zur Lieferung von Nachweisen für ein Nachweissubjekt. Ein Nachweissubjekt ist die natürliche Personen oder Unternehmen im Sinne des § 3 Abs. 1 UBRegG, für die ein Nachweis ausgestellt wird." * neu: "Ein Data Provider ist ein NOOTS-Teilnehmer zur Lieferung von Nachweisen." * Hinweise zu Zertifikaten für die Registrierung im IAM für Behörden ergänzt |
Korrektur, Aktualisierung |
Grobkonzept IAM für Behörden | |
| 6 | Q1/2024 | Anforderungen | Konsolidierung der Anforderungen Data Provider mit den Gesamt-NOOTS Anforderungen: * Neu: NOOTS-964, NOOTS-102 * Aktualisieren: NOOTS-355, NOOTS-881, NOOTS-882, NOOTS-859 * Löschen: NOOTS-351, NOOTS-362, NOOTS-503, NOOTS-541, NOOTS-886 |
neuer Inhalt, Korrektur, Aktualisierung |
:star: |
Grobkonzept IAM für Behörden, NOOTS-Board, Interne Review-Anmerkungen |
| 7 | Q1/2024 |
Anschluss an das NOOTS, Ablauf einer Nachweislieferung |
* Entfernen des Kapitels "Abrufarten". Stattdessen wurde ein neuer Abschnitt zu den technischen "Nachrichtenaustauschmustern" im Kapitel "Ablauf einer Nachweislieferung" hinzugefügt, der auf die detaillierte Beschreibung in der High-Level-Architektur (HLA) verweist. * Ersetzen der Begriffe "technischer Anschluss" und "fachlicher Anschluss" durch "Anschluss NOOTS"\ und "Anschluss Register" * Entfernen von redundanten Informationen im Kapitel "Technischer Anschluss eines NOOTS-Teilnehmers" |
Aktualisierung, Löschen |
Komponententeam, Interne Review-Anmerkungen, Konsultationsprozess |
|
| 8 | Q1/2024 | Technische Anbindung XNachweis-Endpunkt | * Aktualisierung der Nachweis-Spezifikation von der Version 1.0.1 auf Version 1.1.0 * Entfernen der Beschreibungen zu den Strukturen der XNachweis-Spezifikation. Stattdessen wird nur noch auf die relevanten Kapitel in der XNachweis-Spezifikation verwiesen, um die Konsistenz zwischen den Dokumenten sicherzustellen. * Korrektur des geplanten Veröffentlichungstermins für die Erweiterung der XNachweis-Spezifikation zur Abbildung der nationalen Anwendungsfälle 1 und 2 der High-Level-Architektur von Q1/2024 auf Q2/2024 |
Aktualisierung, Löschung |
Grobkonzept IAM für Behörden, Interne Review-Anmerkungen |
|
| 9 | Q1/2024 | Qualitätsmerkmale | * Verfügbarkeit: Aktualisierung der Angabe zur Verfügbarkeit eines Data Provider auf 98% * Vertraulichkeit: Gewährleistung durch Ende-zu-Ende-Verschlüsselung durch die Sicheren Anschlussknoten (SAK) * Integrität: Sicherstellung durch Sieglung der Nachweisdaten durch den Data Provider |
neuer Inhalt, Aktualisierung |
:star: |
NOOTS-Board, Konsultationsprozess |
| 10 | Q2/2024 | Anforderungen | * Konsolidierung der Anforderungen Data Provider mit den Gesamt-NOOTS Anforderungen: * Neu: NOOTS-649, NOOTS-860 * Entfernen der Zuordnung der HLA-Zielbilder zu einer Anforderung * Aufnahme der neuen funktionale Anforderung NOOTS-464 |
neuer Inhalt, Löschung |
NOOTS-Board, Konsultationsprozess |
|
| 11 | Q2/2024 | Randbedingungen | * Die Durchführung eines Datenabgleichs mittels Identitätsdatenabruf (IDA) ist nicht zwingend erforderlich für einen technischen Anschluss an das NOOTS. Jedoch würde ein solcher Abgleich die Effizienz einer Teilnahme am NOOTS unterstützen. | Korrektur | :star: | Konsultationsprozess |
| 12 | Q2/2024 | Allgemein | * Restrukturierung aufgrund der Standardisierung der Dokumentenstruktur für NOOTS-Anschlusskonzepte. | Aktualisierung | Komponententeam | |
| 13 | Q2/2024 |
Vorbedingungen, Organisatorische Schritte |
* Die Pflege der Konfigurationsdaten für den Data Provider, wie beispielsweise Verbindungs- und Zuständigkeitsparameter zur Lokalisierung des Data Provider, erfolgt durch den Data Provider im Once-Only-Diensteverzeichnis und im Nachweiskatalog gemäß Fachdatenkonzept. | Aktualisierung | Komponententeam | |
| 14 | Q2/2024 |
Fachliches Datenmodell, Technische Schritte |
* Die Beschreibung des Sicheren Anschlussknotens im Fachlichen Datenmodell wurde aktualisiert, und es wurden Verweise auf die neuen Kapitel "Baustein Sicherer Anschlussknoten (SAK)" und "Baustein Anschlussprotokoll" im Grobkonzept der Transportinfrastruktur hinzugefügt. | Aktualisierung | Komponententeam | |
| 15 | Q3/2024 | Allgemein | * Umbenennung "NOOTS-Diensteverzeichnis" nach "Once-Only-Diensteverzeichnis (OODV)" | Aktualisierung | Komponententeam | |
| 16 | Q3/2024 | Begriffsdefinitionen | * Verweis auf in OpenCode öffentlich gestellte SAK-APIs hinterlegt. | Aktualisierung | Komponententeam | |
| 17 | Q4/2024 | Qualitätsmerkmale | * Verwendung der neuen XNachweis-Attribute "Verarbeitungszweck" und Rechtsgrundlage zur DSC Protokollierung in "Tab. 14: Datenquellen aus Datenstrukturen des NOOTS" | Aktualisierung | Komponententeam | |
| 18 | Q4/2024 | Anhang A: Checkliste Data Provider | * Checkliste Data Provider als Anhang hinzugefügt | neuer Inhalt | :star: | PB NOOTS |
| 19 | Sprint 2 (28.10 - 22.11.24) | Anschluss an das NOOTS | * Ergänzung der Kapitel 5.2.2 Integration mit Sicheren Anschlussknoten und Kapitel 5.2.3 Erweiterung der bestehenden Systemarchitektur | neuer Inhalt | PB NOOTS | |
| 20 | Sprint 2 (28.10 - 22.11.24) | Anhang A: Checkliste Data Provider | * Vervollständigung der Referenzen auf Anschlusskonzept Data Provider in der Checkliste | Aktualisierung | PB NOOTS | |
| 21 | Sprint 3 (25.11.24 - 20.12.24) | Allgemein | Anpassungen im Rahmen der Harmonisierung der Anschlusskonzepte Data Consumer und Data Provider: * Kapitel 5. Ablauf eines Nachweisabrufs: neues Kapitel zur Darstellung und Beschreibung der Schritte des Nachweisabrufs ergänzt, vorheriger Bestandteil von Kapitel 6; Darstellung des Prozessidagramms angepasst * Kapitel 6.2 technische Schritte: Trennung von Schritten zur Erstanbindung und zur fortlaufenden Administration bei Anschluss an das NOOTS * Kapitel 6.2.4 Qualitätsmerkmale: Kapitel entfernt, da Qualitätsmerkmale bereits in nicht-funktionalen Anforderungen genannt werden | Aktualisierung, neuer Inhalt, Löschung | :star: | PB NOOTS |
| 22 | 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-649: Anforderung wurde wegen fehlender Rechtsgrundlage entfernt * NOOTS-860: Anforderung ist eine übergreifende Anforderung an das NOOTS und wurde in HLA aufgenommen * NOOTS-856: Anforderung wurde wegen fehlender Rechtsgrundlage entfernt * NOOTS-519: Anforderung wurde entfernt, da sie nicht im Verantwortungsbereich des PB NOOTS liegt * NOOTS-862: Anforderung wurde entfernt, da sie nicht im Verantwortungsbereich des PB NOOTS liegt * NOOTS-464: Anforderung wurde entfernt, da sie nicht im Verantwortungsbereich des PB NOOTS liegt * aktualisierte Anforderungen: * NOOTS-355: Anforderung wurde von funktional zu nicht-funktional geändert * neue Anforderungen: * NOOTS-1259: Anforderung wurde ergänzt, da sie sich aus den Anforderungen zur Integration des SAK beim Data Provider ergibt | Aktualisierung, Löschung | PB NOOTS | |
| 23 | Sprint 4 (06.01.25 - 31.01.25) | Ablauf einer Nachweislieferung DP-02 XNachweis-Anfrage lesen und validieren DP-04a Nachweis ausstellen | Ergänzung um Umgang mit Zuständigkeitsparametern | Aktualisierung | PB NOOTS |
2.9 Anhang A: Checkliste Data Provider
Hinweise:
- Diese Checkliste setzt voraus, dass die Inhalte des Dokuments "AD-NOOTS-02: Anschlusskonzept Data Provider" 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 Provider an das NOOTS. Um einen Nachweisabruf Ende-zu-Ende durchzuführen sind weitere Schritte erforderlich, die im "Grobkonzept Leitfaden für Datenbestände" aufgeführt sind.
2.9.1 Checkliste fachverantwortliche Stelle
| Als fachverantwortliche Stelle muss ich... | Welcher Schritt muss vorher ausgeführt worden sein? | Referenz auf Anschlusskonzept DP | 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 Provider** als IT-Komponente beim IAM für Behörden nötigen Schritte ausführen. | 2 | 6.1.1.2 | nein |
2.9.2 Checkliste betriebsverantwortliche Stelle
| Als betriebsverantwortliche Stelle muss ich... | Welcher Schritt muss vorher ausgeführt worden sein? | Referenz auf Anschlusskonzept DP | 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 Provider** als IT-Komponente beim IAM für Behörden nötigen Schritte ausführen. | 2 | 6.1.1.2 | nein |
| 4 | * [ ] mir ein **Zertifikat für die Siegelung von Nachweisen** bei der zuständigen Zertifizierungs- oder Registrierungsstelle beschaffen, sofern ich die Integrität der Nachweisdaten durch Siegelung mithilfe eines Zertifikats sicherstellen möchte. | \- | 6.1.1.1 | nein |
| 5 | * [ ] meine bestehende **Systemarchitektur** anpassen, um den Betrieb des SAK in meiner Betriebsumgebung abzubilden. | \- | 6.2.1.3 | ja |
| 6 | * [ ] für meine Entwicklungs- und Testumgebungen für den SAK ein **Server-Zertifikat und ggf. für den Data Provider und SAK ein Client-Zertifikat für das Anschlussprotokoll** generieren (abhängig davon, ob aktiver oder passiver Empfänger). | 5 | 6.2.1.2 | nein |
| 7 | * [ ] meine Testumgebungen an die **NOOTS-Referenzumgebung** anschließen. | 6.2.1.2 | geplant Q1/2025 | |
| 8 | * [ ] 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 | |
| 9 | * [ ] für meine Entwicklungs- und Testumgebungen ein **Zertifikat** der betriebsverantwortlichen Stelle generieren. | 6.2.1.2 | ja | |
| 10 | * [ ] 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 | |
| 11 | * [ ] alle nötigen **Netzfreischaltungen** (z.B. Firewallfreischaltung) veranlassen, damit der SAK mit dem SAK des Data Consumer kommunizieren kann. | 6.2.1.2 | nein |
2.9.3 Checkliste Softwarelieferant
| Als Softwarelieferant muss ich... | Welcher Schritt muss vorher ausgeführt worden sein? | Referenz auf Anschlusskonzept DP | 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 Provider die **Anbindung an das** **Anschlussprotokoll** (Provider-API, abhängig vom Kommunikationsmodell - aktiver oder passiver Empfänger) des SAK umsetzen. | \- | 6.2.1.2 | ja |
| 3 | * [ ] im Data Provider den Nachweisabrufstandard **XNachweis** implementieren. | \- | 6.2.1.1 | 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 meine Entwicklungs- und Testumgebungen für den SAK ein **Server-Zertifikat und ggf. für den Data Provider und SAK ein Client-Zertifikat für das Anschlussprotokoll** generieren (abhängig davon, ob aktiver oder passiver Empfänger). | \- | 6.2.1.2 | ja |