3. High-Level-Architecture (HLA)

Redaktioneller Hinweis

Das Dokument stellt einen fortgeschrittenen und stabilen Arbeitsstand dar. Weitere Anpassungen sind in einer zukünftigen Veröffentlichung möglich.

Zielgruppe: Stakeholder, die sich mit der Funktionsweise des NOOTS beschäftigen

3.1 Abstract

Das Dokument High-Level-Architecture (HLA) verschafft einen Überblick über das Nationale Once-Only-Technical-System (NOOTS). Es beschreibt übergreifende Anforderungen an das NOOTS, den nationalen und europäischen Rechtsrahmen, das Architekturzielbild des NOOTS, die NOOTS-Komponenten sowie deren Zusammenwirken zum Nachweisabruf und übergreifenden Konzepten. Die High-Level-Architecture dient als Grundlage zur Analyse der weiteren Konzepte der Architekturdokumentation-NOOTS (AD-NOOTS). Daher ist eine detailliertere Betrachtung der Architektur der einzelnen NOOTS-Komponenten kein Bestandteil dieses Dokuments. Die High-Level-Architecture richtet sich an alle Stakeholder, die sich mit der Funktionsweise des NOOTS befassen wollen.

3.2 Einführung und Ziele

3.2.1 Überblick

Das Dokument High-Level-Architecture (HLA) schafft eine Grundlage zur Darstellung der Gesamtarchitektur des Nationalen Once-Only-Technical-Systems (NOOTS). Es umfasst folgende Inhalte:

Darstellung der Rahmenbedingungen und Rechtsgrundlagen des NOOTS
Beschreibung des NOOTS-Architekturzielbilds
Beschreibung von Anforderungen an das NOOTS
Beschreibung des übergreifenden Zusammenwirkens der NOOTS-Komponenten

3.2.2 Ziele des Dokuments

Das Dokument High-Level-Architecture verschafft einen Überblick über die zentralen Aspekte des NOOTS. Es stellt einen Einstieg in die Gesamtarchitektur des NOOTS dar und wird durch die weiteren Dokumente der Architekturdokumentation NOOTS (AD-NOOTS) ergänzt, die einzelnen Aspekte des NOOTS in detaillierter Form beschreiben.

Abb. 1: Dokumentenstruktur AD-NOOTS

Die AD-NOOTS unterscheidet zwei Formen von Klammerdokumenten:

High-Level-Architecture: Das hier vorliegende Dokument dient dem Einstieg in die Zielarchitektur des NOOTS. Es beschreibt übergreifende Anforderungen an die NOOTS-Infrastruktur, den nationalen und europäischen Rechtsrahmen, das Architekturzielbild des NOOTS, die zentralen Komponenten und deren Zusammenwirken sowie übergreifende Konzepte.
Anschlusskonzepte: Zwei weitere Klammerdokumente stellen die Anschlusskonzepte für Data Consumer (AD-NOOTS-01) und Data Provider (AD-NOOTS-02) dar. Diese dienen dem Zweck, Anschluss- und Rahmenbedingungen zu dokumentieren und aufzubereiten, um den Anschluss von Data Consumern und Data Providern an das NOOTS und das EU-OOTS zu ermöglichen.

Neben den übergreifenden Dokumenten gibt es eigenständige Komponenten-Dokumentationen und übergreifende Konzepte, die jeweils Teilaspekte des NOOTS beschreiben.

Über Querverweise werden Abhängigkeitsbeziehungen zwischen den Dokumenten dargestellt.

Grobkonzepte sind Dokumente, die durch den PB NOOTS erstellt werden und die eine NOOTS-Komponente auf konzeptioneller Ebene beschreiben. Dazu werden komponentenspezifische funktionale und nicht-funktionale Anforderungen, Anwendungsfälle sowie fachliche und technische Konzepte dokumentiert.
Komponentensteckbriefe werden dann erstellt, wenn eine NOOTS-Komponente durch ein assoziiertes Vorhaben umgesetzt wird. Ein assoziiertes Vorhaben ist ein Vorhaben, welches nicht aus FITKO-Mitteln finanziert wird, von oder zu den jedoch relevanten Abhängigkeiten bestehen (IT-PLR-E-09). Innerhalb eines Komponentensteckbriefs dokumentiert der PB NOOTS spezifische Aspekte, die für die Funktionalität der Gesamtarchitektur und die Anschlusskonzepte von besonderer Relevanz sind. Der Komponentensteckbrief stellt eine Ergänzung zum Umsetzungskonzept dar, welches durch die assoziierten Vorhaben selbst veröffentlicht wird.
Umsetzungskonzepte werden durch assoziierte Vorhaben oder Umsetzungsprojekte erstellt. Umsetzungsprojekte sind Projekte, die einen unmittelbaren und substanziellen Beitrag zur Erreichung der Ziele der Gesamtsteuerung der Registermodernisierung leisten, indem sie auf die Erprobung einzelner Komponenten des NOOTS, des EU-OOTS und/oder Anschlussbedingungen an das NOOTS bzw. EU-OOTS einzahlen (IT-PLR-E-09). Umsetzungskonzepte beschreiben die Details der technischen Lösung.
Standards umfassen technische Spezifikationen einer Schnittstelle oder von Datenstrukturen zum Austausch über eine Schnittstelle, wie zum Beispiel die SAK-APIs (SQ-31) oder das XÖV-Rahmenwerk (XS-09).
Übergreifende Konzepte sind Dokumente, die übergreifende fachliche oder technische Regelungsbedarfe im NOOTS beschreiben, die nicht einer einzelnen NOOTS-Komponente zugeordnet werden können, z.B. die Nutzeridentifizierung und -authentifizierung.
Begleitdokumente umfassen Whitepaper oder Ergänzungsdokumente, die zusätzlich zu den komponentenspezifischen oder übergreifenden Konzepten bereitgestellt werden. White Paper sind informative Dokumente, die ein Problem erläutern, Lösungsansätze aufzeigen oder einen innovativen Ansatz präsentieren.

3.2.3 Begriffsdefinitionen

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.

3.2.3.1 Nachweis

Der Begriff Nachweis wird im zentralen Glossar der Gesamtsteuerung Registermodernisierung definiert (SQ-14).

Das Reifegradmodell für Nachweisabrufe definiert unterschiedliche Digitalisierungsgrade für die Übermittlung von Nachweisen zwischen der nachweisanfordernden Stelle und der nachweisliefernden Stelle über das NOOTS (IT-PLR-B-12). Im Rahmen der Registermodernisierung wird angestrebt, ausschließlich konkret angeforderte, maschinenlesbare Nachweisdaten über NOOTS gemäß dem Prinzip der Datensparsamkeit zu übermitteln, was als Reifegrad D1 definiert ist. Dabei ist zu beachten, dass der Mindeststandard im EU-OOTS auf Reifegrad B festgelegt ist. Dieser Reifegrad umfasst die Übertragung von vollständigen Nachweisen, beispielsweise in Form von PDFs, die digital übertragbar, jedoch nicht direkt maschinenlesbar sind.

3.2.3.2 Register

Als „Register“ werden (vgl. u.a. Definition des Nationalen Normenkontrollrat (NKR)) Datenbestände der öffentlichen Verwaltung bezeichnet, die mindestens eines der folgenden Kriterien erfüllen:

enthält Informationen, die für das Erbringen einer Verwaltungsleistung erforderlich sind,
kann zur Unterstützung von administrativen und politischen Entscheidungen oder
für die amtliche Statistik genutzt werden.

3.3 Randbedingungen

Die Randbedingungen des NOOTS sowie des Anschlusses an das EU-OOTS leiten sich unter anderem aus den folgenden Quellen ab:

Rechtsgrundlagen und Dokumente der Europäischen Kommission zur SDG-Umsetzung (EU-01 bis EU-02)
Nationale Rechtsgrundlagen im Kontext der Registermodernisierung (RGR-01 bis RGR-04)
Beschlüsse des IT-Planungsrats und Entscheidungen des IT-Planungsrats (IT-PLR-B-01 bis IT-PLR-B-09) & (IT-PLR-E-01 bis IT-PLR-E-09)
Sonstige weiterführende Dokumente (SQ-01 bis SQ-03).

3.3.1 Übergreifende Entwurfsentscheidungen

Die folgenden IT-Planungsrat-Beschlüsse und Entscheidungen sind von besonderer Relevanz für das Architekturzielbild des NOOTS.

Tab. 1: relevante IT-PLR-Beschlüsse

Entscheidung	Erläuterung
IT-PLR Beschluss 2021/05: Registermodernisierung ([IT-PLR-B-04](./AD-NOOTS-00_+Quellenverzeichnis.md))	Der IT-Planungsrat beschließt das vom Koordinierungsprojekt Registermodernisierung erarbeitete Zielbild der Registermodernisierung und schlägt die Einrichtung des Bund-Länder-Projekts “Gesamtsteuerung Registermodernisierung” vor, um ein systematisches und schlüssiges Vorgehen bei der Modernisierung der deutschen Registerlandschaft sicherzustellen. Das Projekt, unter der Leitung des BMI sowie der Länder Bayern und Hamburg, soll eine ressort- und ebenenübergreifende Umsetzung aller Teilprojekte der Registermodernisierung vorantreiben. Auf Grund des Umfangs des Gesamtvorhabens Registermodernisierung sowie der bereichs- und ebenenübergreifenden Relevanz wurde die Federführerschaft im Projektverlauf durch Baden-Württemberg und Nordrhein-Westfalen erweitert (IT-PLR Beschluss 2021/25: Registermodernisierung).
IT-PLR Beschluss 2022/06: Entscheidung zur Umsetzung eines NOOTS ([IT-PLR-B-07](./AD-NOOTS-00_+Quellenverzeichnis.md))	Im Rahmen der Validierung des Zielbilds der Registermodernisierung wurde festgestellt, dass nicht alle nationalen Anforderungen durch das bei der Europäischen Kommission (EU-KOM) in Entwicklung befindliche EU-OOTS abgedeckt werden können. Aus diesem Grund wurde entschieden, dass ein NOOTS umgesetzt werden muss. Um die Anschlussfähigkeit an das EU-OOTS sicherzustellen, dürfen Abweichungen zwischen den nationalen und europäischen Lösungen nur dann erfolgen, wenn diese für die Umsetzung der nationalen Anforderungen zwingend erforderlich sind. Der Anschluss an die EU soll zusätzlich durch eine zentral entwickelte technische Lösung unterstützt werden, die sogenannte “Intermediäre Plattform”.
IT-PLR Beschluss 2022/22: Aufbau eines nationalen DSD und Nutzung des europäischen EB ([IT-PLR-E-04](./AD-NOOTS-00_+Quellenverzeichnis.md))	Der Lenkungskreis Registermodernisierung beschließt, bei der Bereitstellung des Data Service Directory (DSD) für das technische System der EU zum Nachweisabruf nach Artikel 14 SDG-VO zur Bereitstellung der Routing-Informationen zu deutschen Evidence Providern (registerführenden Stellen) auf eine nationale Implementierung des DSD zu setzen. Der Lenkungskreis Registermodernisierung beschließt außerdem, bei der Bereitstellung des Evidence Brokers (EB) für das technische System der EU zum Nachweisabruf nach Artikel 14 SDG-VO die von der Europäischen Kommission zentral bereitgestellte Lösung zu nutzen und auf eine separate nationale Implementierung zu verzichten.
IT-PLR-Beschluss 2022/22: Entscheidung zur Umsetzung der Komponente Registerdatennavigation ([IT-PLR-E-05](./AD-NOOTS-00_+Quellenverzeichnis.md))	Der Lenkungskreis Registermodernisierung beauftragt das Kompetenzteam Architektur mit der Formulierung eines Projektauftrags, aus dem Zielsetzung und Rahmenbedingungen zur Umsetzung der Komponente Registerdatennavigation hervorgehen. Die Registerdatennavigation soll als neue Komponente nach dem Vorbild des FIT-Connect Routingdienstes aufgebaut werden. Die technischen Dienste werden, wie bisher im DVDV, zentral verwaltet. Für die Zuständigkeiten wird ein neues Zuständigkeitsverzeichnis aufgebaut, das jedoch Zuständigkeiten in einer verallgemeinerten Form speichert, so dass es gleichermaßen für Leistungen aus dem LeiKa, für Nachweise aus der Registermodernisierung und für Zuständigkeiten für beliebige Rechtsgrundlagen geeignet ist. Die Pflege der Daten soll analog zum PVOG über XZuFi erfolgen. Darüber sind bspw. automatisierte Abgleiche mit dem PVOG möglich. Perspektivisch kann dieses Zuständigkeitsverzeichnis zu einem zentralen Zuständigkeitsverzeichnis der Deutschen Verwaltung (DVZV) entwickelt werden.
IT-PLR-Beschluss 2022/22: Entscheidung asynchrone Prozesse ([IT-PLR-E-02](./AD-NOOTS-00_+Quellenverzeichnis.md))	Im Zielbild der Registermodernisierung werden sowohl synchrone als auch asynchrone Prozesse vorgesehen. Die Begriffe “synchron“ und „asynchron” sind dabei nicht in einem technischen Sinne zu verstehen, sondern entsprechend der Eignung für einen Nachweisabruf unter Beteiligung von Bürgerinnen und Bürgern und Unternehmen. Um die für den Nachweisabruf notwendige Nutzerinteraktion zu ermöglichen, muss ein Nachweis synchron, also innerhalb weniger Sekunden, für die Weiterverarbeitung bereitstehen. In asynchronen Prozessen hingegen könnte die Zeit mehrere Minuten, Stunden oder Tage betragen, was sich für einen Nachweisabruf mit Nutzerinteraktion nicht eignet. Dies entspricht auch den Anforderungen des EU-OOTS, in dem ausschließlich synchrone, “automatisiert austauschbare” Nachweisabrufe unterstützt werden. Entsprechend wurde im IT-PLR-Beschluss 2022/22 festgelegt, dass wenn der Data Consumer ein Onlinedienst ist (z. B. ein Portal oder ein Formularmanagementsystem), nur fachlich synchrone Nachweisabrufe möglich sein sollen. Für die Behörde-zu-Behörde-Kommunikation, in denen keine Nutzerinteraktion notwendig ist, sollen auch fachlich asynchrone Nachweisabrufe möglich sein. Dies ermöglicht die Anbindung von Registern an das NOOTS, die noch nicht in der Lage sind, synchron zu antworten.
IT-PLR-Beschluss 2022/22: Entscheidung Nachweisabrufstandard ([IT-PLR-E-03](./AD-NOOTS-00_+Quellenverzeichnis.md))	Für die Umsetzung des Once-Only-Prinzips wird es erforderlich sein, eine Vielzahl heterogener IT-Systeme für den Nachweisabruf zu ertüchtigen und miteinander zu verbinden. Um den Abruf und die Übermittlung von Nachweisen zu standardisieren, hat der IT-Planungsrat entschieden, einen generischen Nachweisabrufstandard zu entwickeln. Um Vorteile gleichermaßen im nationalen wie auch europäischen Kontext zu erzeugen und die SDG-Umsetzung zu fördern, soll dieser Standard auf Grundlage des Exchange Data Model (EDM) des EU-OOTS entwickelt werden und nur dann von diesem abweichen, wenn es im NOOTS zwingend erforderlich ist. Im Folgenden wird dieser Standard als XNachweis bezeichnet.
IT-PLR-Beschluss 2022/22: Entscheidung Reifegradmodell ([IT-PLR-E-01](./AD-NOOTS-00_+Quellenverzeichnis.md))	Für die erfolgreiche Umsetzung des Once-Only-Prinzips in der öffentlichen Verwaltung müssen Data Consumer (Onlinedienste bzw. Fachverfahren) und Data Provider (registerführende öffentliche Stellen) umfassend digitalisiert werden, um einen medienbruchfreien und automatisierten Abruf von Nachweisen zu ermöglichen. Der Lenkungskreis Registermodernisierung beschließt, ein Reifegradmodell für Nachweisabrufe einzuführen.
IT-PLR-Beschluss 2022/34: Entscheidung NOOTS-Registeranbindung ([IT-PLR-E-06](./AD-NOOTS-00_+Quellenverzeichnis.md))	Sowohl das EU-OOTS als auch das NOOTS stellen eine Vielzahl unterschiedlicher Anforderungen, sogenannte Anschlussbedingungen, die beim Anschluss an die nationale oder europäische Infrastruktur umgesetzt werden müssen. 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 kommunale Ebene erstreckt, kann nicht davon ausgegangen werden, dass die notwendigen Ressourcen zur Anbindung an das NOOTS vorhanden sind. Auf technischer Ebene ist daher in diesen Fällen überlegenswert, ob der Anschluss an die Systeme zum Nachweisabruf als Anlass genommen werden kann, auch hier zentrale Strukturen, wie Spiegelregister oder Abrufportale, zu schaffen und diesen dann die Rolle als Data Provider zu übertragen.
IT-PLR-Beschluss 2022/34: Entscheidung zur Anbindung der Register und Online-Services an das europäische Once-Only-Technical-System über Intermediäre Plattformen ([IT-PLR-E-06](./AD-NOOTS-00_+Quellenverzeichnis.md))	Um die Aufwände und Belastungen für die verantwortlichen Stellen zur Anbindung der Register und Onlinedienste an das EU-OOTS möglichst gering zu halten, sollen im Rahmen der Registermodernisierung Aufgaben und Funktionen zur Umsetzung der Anschlussbedingungen soweit möglich und sinnvoll von zentralen Strukturen übernommen werden. Das EU-OOTS erlaubt gemäß Artikel 1 Nr. 6 der Durchführungsverordnung (DVO) für den Anschluss an das System die indirekte Anbindung über Intermediäre Plattformen, die von den Mitgliedstaaten ausgestaltet werden können. Dadurch kann verhindert werden, dass spezifische Funktionalitäten, die nur für die EU-Anbindung benötigt werden, in einer Vielzahl von dezentralen Registern und Onlinedienste implementiert werden müssen. Der Anschluss öffentlicher Stellen an das technische System gemäß Artikel 14 SDG-VO (EU-OOTS) soll daher verpflichtend über Intermediäre Plattformen (technische Komponenten i.S.v. Artikel 1 Nr. 6 DVO zu Artikel 14 SDG-VO) erfolgen. Die technische, rechtliche, finanzielle und organisatorische Ausgestaltung der Anbindung soll im Rahmen der Ausarbeitung detailliert werden.
IT-PLR-Beschluss 2023/22: Konkretisierung des Zielbildes Registermodernisierung in Form von zwei Aufträgen ([IT-PLR-B-11](./AD-NOOTS-00_+Quellenverzeichnis.md))	Der IT-Planungsrat beschließt die Konkretisierung des Zielbildes Registermodernisierung in Form von zwei Aufträgen. Auf dieser Grundlage wurde ein Gesamtplan zur Umsetzung, Steuerung und Überwachung des Programmfortschritts erstellt: * Auftrag 1: Umsetzung des Once-Only-Prinzips: Bereitstellung des technischen Systems und Entwurfserstellung der rechtlichen Grundlagen zur Umsetzung des Art. 14 SDG-VO sowie Begleitung des Anschlusses der SDG relevanten Register / Nachweise und Onlinedienste / Serviceportale an das NOOTS. * Auftrag 2: Umsetzung des Once-Only-Prinzips: Entwicklung und Betrieb der technischen Infrastruktur zur Nachweisübermittlung (NOOTS) sowie Entwurf der rechtlichen Regelung des NOOTS zur Umsetzung des Once-Only-Prinzips und Begleitung des Anschlusses der Top Register / Nachweise und Onlinedienste / Serviceportale an das NOOTS.
IT-PLR-Beschluss 2023/38: Kommunikationsinfrastruktur für den Nachweisabruf über das NOOTS ([IT-PLR-B-10](./AD-NOOTS-00_+Quellenverzeichnis.md))	Es wird eine Kommunikationsinfrastruktur für den Abruf von Nachweisen über das NOOTS benötigt, die alle sich aus den Zielen des NOOTS ergebenden Anforderungen erfüllt und rechtzeitig zur Bereitstellung des NOOTS zur Verfügung steht. Der IT-Planungsrat beauftragt die Gesamtsteuerung Registermodernisierung mit der Konzeption einer NOOTS-spezifischen Kommunikationsinfrastruktur. Diese soll auf bestehenden Grundlagen aufbauen, sodass Lösungsbausteine des IT-Planungsrats und Infrastrukturelemente soweit sinnvoll nachgenutzt werden können.
IT-PLR-Beschluss 2024/15: Weiterentwicklung des Reifegradmodells der Registermodernisierung ([IT-PLR-B-12](./AD-NOOTS-00_+Quellenverzeichnis.md))	Das Reifegradmodell aus dem IT-Planungsrat Beschluss 2022/22 wird geändert, sodass der Reifegrad D in D 1 und D 2 geteilt wird (Nachweis-Reifegradmodell v2.0). Im Reifegrad D 1 werden im Sinne der Datensparsamkeit nur die für eine Verwaltungsleistung tatsächlich erforderlichen Informationen in maschinell auswertbarer Form übertragen. Die nachweisabrufenden Stellen müssen gewährleisten, dass ihre Onlinedienste und Fachverfahren diese Datensätze entsprechend digital abrufen und verarbeiten können. In Reifegrad D2 wird die Antwort auf eine konkrete Frage übermittelt. Eine möglichst schnelle Erreichung des Reifegrads D1 auf nationaler Ebene wird angestrebt und ist das Ziel des Programms Gesamtsteuerung Registermodernisierung. Mit der Erreichung des Reifegrads C auf Seiten der nachweisabrufenden und nachweisliefernden Stellen gilt jedoch auf nationaler Ebene der Reifegrad 4 des OZG als erreicht.

3.3.2 Abgrenzungen

3.3.2.1 Standardisierung der Nachweistypen

Damit Nachweise automatisiert verarbeitet werden können, muss Einigkeit unter allen beteiligten Akteuren über Semantik, Struktur und Syntax der Nachweise bestehen. Dazu ist eine fachliche Standardisierung aller Nachweistypen erforderlich. Diese Standardisierung ist nicht Teil des Umfangs des NOOTS. Im Dokument "Fachdatenkonzept" des Programmbereichs Register wird beschrieben, wie der automatisierte Nachweisaustausch von Fachdaten 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 von Nachweisdaten.

3.3.2.2 Befähigung der Register

Die Register müssen nicht nur technisch an das NOOTS angebunden werden. Sie müssen auch befähigt werden, Protokolldaten zu Nachweisabrufen von natürlichen Personen bereitzustellen und Nachweise in angemessener Zeit zu liefern. Dazu gehören bspw.

die Einspeicherung der Identifikationsnummer und bundeseinheitlichen Wirtschaftsnummer, wenn eine gesetzliche Verpflichtung dazu besteht,
die Bereinigung des Datenbestands, z.B. durch Auflösen von Dubletten,
die Schaffung technischer Voraussetzungen, um Verfügbarkeit und Antwortzeit zu gewährleisten.

Im Einzelfall ergeben sich daraus weitere Herausforderungen, bspw. wenn das Register keine Datenhoheit über den eigenen Datenbestand hat (bspw. Spiegelregister). Die Steuerung und Umsetzung dieser Maßnahmen liegt nicht im Umfang des NOOTS. Das NOOTS definiert lediglich Anschlussbedingungen, die einen Nachweisabruf über das NOOTS technisch grundsätzlich ermöglichen.

3.3.2.3 Verarbeitung von Nachweisen

Zur Erbringung von Verwaltungsleistungen verarbeiten Data Consumer Nachweise, die über das NOOTS abgerufen wurden, im Onlinedienst oder im Fachverfahren weiter. Dies umfasst z.B. die Weiterleitung des Nachweises oder die Übernahme von Daten in das Antragsformular. Diese weitere Datenverarbeitung des Data Consumer ist kein Bestandteil des NOOTS.

3.4 Kontextabgrenzung

3.4.1 Fachlicher Kontext

Das NOOTS ist ein gemeinsames informationstechnisches System, das aus IT-Komponenten, Schnittstellen und Standards besteht. Es ermöglicht öffentlichen Stellen den Abruf sowie die Übermittlung elektronischer Nachweise und Daten aus öffentlichen Datenbeständen – sowohl national als auch grenzüberschreitend – zur Erfüllung ihrer öffentlichen Aufgaben. Zu diesem Zweck stellt das NOOTS zentrale Komponenten bereit und formuliert Anschlussbedingungen an Data Consumer und Data Provider. Über einen zentralen Anschluss an das EU-OOTS wird ein Austausch von Nachweisen mit dem EU-Ausland ermöglicht. Der nationale Nachweisabruf erfolgt dabei über das NOOTS, der grenzüberschreitende Austausch von Nachweisen innerhalb der EU über das NOOTS und das EU-OOTS.

Die folgende Grafik zeigt das NOOTS und alle Systeme, die mit ihm interagieren, sowohl im nationalen als auch im grenzüberschreitenden Kontext innerhalb der EU. Das NOOTS umfasst alle NOOTS-Komponenten, die für die Durchführung oder Nachvollziehbarkeit eines Nachweisabrufs notwendig sind. Data Consumer und Data Provider sind NOOTS-Teilnehmer, die sich als registrierte technische Verfahren an NOOTS anbinden.

Abb. 2: Fachlicher Kontext des NOOTS

3.4.1.1 Rollen im NOOTS und EU-OOTS

Die folgende Tabelle stellt die Rollen im Kontext des nationalen und grenzüberschreitenden Nachweisabrufs über das NOOTS und das EU-OOTS dar. Weiterführende Beschreibungen der einzelnen Begriffe finden sich im Glossar (SQ-14).

Tab. 2: Kurzbeschreibung der Rollen im NOOTS und EU-OOTS

Bezeichnung	Beschreibung
Data Consumer ([AD-NOOTS-01](./AD-NOOTS-01_+Anschlusskonzept+Data+Consumer+_DC_.md))	Ein Data Consumer ist ein NOOTS-Teilnehmer zum Abruf von Nachweisen. Data Consumer sind nationale Onlinedienste und Fachverfahren. Im Kontext des Abrufs nationaler Nachweise aus dem EU-Ausland übernimmt die Intermediäre Plattform im NOOTS ebenfalls die Rolle eines Data Consumer.
Data Provider ([AD-NOOTS-02](./AD-NOOTS-02_+Anschlusskonzept+Data+Provider+_DP_.md))	Ein Data Provider ist ein NOOTS-Teilnehmer zur Lieferung von Nachweisen. Data Provider sind nationale Register. Im Kontext des Abrufs von EU-Nachweisen aus Deutschland übernimmt die Intermediäre Plattform im NOOTS ebenfalls die Rolle eines Data Provider.
Evidence Requester	Ein Evidence Requester ist eine Rolle im EU-OOTS, die dazu berechtigt ist (entweder durch Entscheidung des Antragsstellenden oder Rechtsgrundlage) Daten (u.a. Nachweise) auf elektronischem Weg von Evidence Providern (über das EU-OOTS) im Kontext der Leistungsverwaltung abzurufen. Beim Datenabruf muss der Evidence Requester oder gegebenenfalls die Intermediäre Plattform die Vollständigkeit und Rechtmäßigkeit der Nachweisanfrage sicherstellen. Dabei muss gewährleistet werden, dass die Nachweise für das jeweilige Verfahren von Antragstellenden angefordert werden oder eine Rechtsgrundlage zum Abruf der Nachweise besteht. Wenn von deutschen Stellen ein Nachweis aus dem EU-Ausland abgerufen werden soll, übernimmt die Intermediäre Plattform die Rolle des Evidence Requesters im EU-OOTS.
Evidence Provider	Ein Evidence Provider ist eine Rolle im EU-OOTS, die dazu verpflichtet ist, Daten (u.a. Nachweise) auf elektronischem Weg an Evidence Requester (über das EU-OOTS) im Kontext der Leistungsverwaltung bereitzustellen. Der Evidence Provider oder gegebenenfalls die Intermediäre Plattform muss gemäß Artikel 16 DVO (EU) 2022/1463 prüfen, ob die Identitätsattribute der angeforderten Nachweise mit denen aus dem Identifizierungsmittel übereinstimmen. Wenn von europäischen Stellen ein Nachweis aus Deutschland abgerufen werden soll, übernimmt die Intermediäre Plattform die Rolle des Evidence Provider im EU-OOTS.

3.4.1.2 Exkurs: Nationale Anbindung an das EU-OOTS

Die Single Digital Gateway-Verordnung der Europäischen Union (SDG-VO) verfolgt das Ziel, den grenzüberschreitenden automatisierten Austausch von Nachweisen gemäß dem Once-Only-Prinzip (EU-03) zu ermöglichen. Für Bürgerinnen, Bürger und Unternehmen entfällt dadurch die Notwendigkeit, Nachweise mehrfach bereitzustellen, sofern sie der Übermittlung des jeweiligen Nachweises zustimmen.

Die EU hat zur Umsetzung der SDG-VO das europäische Once-Only Technical System (EU-OOTS) errichtet, an das alle zum Anschluss verpflichteten nationalen Behörden seit dem 12.12.2023 angeschlossen sein müssen. Mithilfe der sog. Evidence Survey wurde und wird fortlaufend durch die SDG-Koordination ermittelt und auf der OZG-Informationsplattform dokumentiert, welche Onlinedienste und welche Register in Deutschland betroffen sind:

Für die betroffenen Onlinedienste gilt nach Artikel 6 der SDG-VO die Pflicht der vollständigen Online-Bereitstellung von Verfahren sowie die Pflicht, Nachweisabrufe über das EU-OOTS gemäß Artikel 14 der SDG-VO in das EU-Ausland zu ermöglichen.
Für die betroffenen Register gilt nach Artikel 14 der SDG-VO die Pflicht der vollständigen Online-Bereitstellung von Nachweisen sowie die Pflicht, Nachweisabrufe über das EU-OOTS aus dem EU-Ausland zu ermöglichen.

Im IT-Planungsrats-Beschluss 2022/34 (IT-PLR-E-06) wurde entschieden, dass

der Anschluss an das EU-OOTS über die Intermediäre Plattform (technische Komponente i.S.v. Artikel 1 Nr. 6 DVO zu Artikel 14 SDG-VO) erfolgen soll,
der Anschluss öffentlicher Stellen an das EU-OOTS ausschließlich über die Intermediäre Plattform erfolgen soll. Es ist nicht vorgesehen, dass sich nationale Behörden direkt an das EU-OOTS anschließen. Dadurch kann verhindert werden, dass spezifische Funktionalitäten, die nur für die EU-Anbindung benötigt werden, in einer Vielzahl von dezentralen Registern und Onlinediensten implementiert werden müssen,
ein SDG-Connector als Produkt des IT-Planungsrates entwickelt werden soll. Bei dem SDG-Connector handelt es sich um eine Sammlung von standardisierten und wiederverwendbaren Softwarebausteinen, darunter die eigenständige, fachunabhängige und lauffähige Komponente für den Nachweisabruf im europäischen Kontext, dem sogenannten “eDelivery Access Point”.

3.4.1.2.1 Zusammenwirken Intermediäre Plattform und eDelivery Access Point

Der Anschluss des NOOTS an das EU-OOTS erfolgt durch ein Zusammenspiel zwischen der Intermediären Plattform und dem eDelivery Access Point. Der eDelivery Access Point verbindet die Intermediäre Plattform mit den eDelivery-Access Points anderer EU-Mitgliedstaaten.

Sowohl die Intermediäre Plattform als auch der eDelivery Access Point erbringen spezifische Funktionen beim europäischen Nachweisabruf.

Die Intermediäre Plattform ist für die Fachnachricht zuständig und überführt dabei eine nationale XNachweis-Nachricht in eine europäische EDM-Nachricht und umgekehrt.
Der eDelivery Access Point ist für die Kommunikation mit dem EU-OOTS zuständig und tauscht dabei Nachrichten mit anderen Access Points im Transportstandard des EU-OOTS (AS4) aus.

3.4.1.2.2 Nutzung der Common Services der EU-Kommission

Zur Unterstützung des Austauschs von Nachweisen zwischen Evidence Requestern und Evidence Providern nutzt das EU-OOTS Dienste, die in Artikel 4 der Durchführungsverordnung als Common Services bezeichnet werden. Für die Dienste Evidence Broker und Data Service Directory ermöglicht Artikel 8 der DVO den Mitgliedstaaten die Wahl, ihre Daten entweder dem zentralen Verzeichnis der Europäischen Kommission zuzuliefern oder ein eigenes nationales Verzeichnis für diese Aufgaben bereitzustellen.

Tab. 3: Common Services des EU-OOTS

Common Service _Rechtsgrundlage_	Funktion	Verwendung durch die Bundesrepublik Deutschland
Evidence Broker _Artikel 6 SDG-DVO_	Dienst, mit dem ein Evidence Requester bestimmen kann, welchen Nachweistyp er von einem anderen Mitgliedstaat für einen bestimmten Zweck in einem bestimmten Kontext anfordern kann.	Deutschland wird gemäß IT-Planungsrat-Beschluss 2022/22 ([IT-PLR-B-08](./AD-NOOTS-00_+Quellenverzeichnis.md)) den zentralen Evidence Broker der EU-Kommission nutzen; eine nationale Instanz des Evidence Brokers wird es nicht geben.
Data Service Directory _Artikel 5 SDG-DVO_	Dienst, mit dem ein Evidence Requester Informationen über den Data Service erhalten kann, der in einem anderen Mitgliedstaat den gewünschten Nachweis bereitstellt.	Deutschland wird das zentrale Data Service Directory der EU-Kommission nutzen; eine nationale Instanz des DSD wird es nicht geben. Zur Begründung siehe Hinweis unterhalb der Tabelle.
Semantic Repository _Artikel 7 SDG-DVO_	Archiv semantischer Spezifikationen von Nachweistypen, die mit dem Evidence Broker und dem DSD verknüpft sind und aus Definitionen von Namen, Datentypen und Datenelementen bestehen, um das gegenseitige Verständnis der Beteiligten beim Austausch von Nachweisen über das OOTS sicherzustellen.	Aktuell noch nicht aktiv genutzt.

Hinweis zur Verwendung des zentralen Data Service Directory (DSD): Im IT-Planungsrat-Beschluss 2022/22 vom Juni 2022 wurde ursprünglich festgelegt, ein nationales Data Service Directory zu entwickeln bzw. dieses als Funktionalität in die nationale Komponente Registerdatennavigation aufzunehmen. Begründung für diese Entscheidung war, dass die komplexen Routinglogiken durch die deutsche Registerlandschaft in einer nationalen Komponente besser pflegbar wären und außerdem nicht redundant zur Registerdatennavigation in einem europäischen Verzeichnisdienst gepflegt werden sollten. Im weiteren Projektverlauf wurde aber im November desselben Jahres der verpflichtende Einsatz Intermediärer Plattformen für den EU-OOTS-Anschluss beschlossen (IT-PLR-B-09). Diese fungieren gegenüber dem EU-Ausland als Evidence Provider und kapseln damit die nationale Registerwelt. Da die Intermediären Plattformen die im DSD einzutragenden Data Services bereitstellen und es voraussichtlich nur eine ein- oder niedrige zweistellige Anzahl von Intermediären Plattformen geben wird, greift das Argument der komplexen Pflege nicht mehr. Daher wurde im PB NOOTS beschlossen, die Data Services der Intermediären Plattformen im zentralen DSD zu hinterlegen und nicht in einem nationalen Dienst.

Redaktioneller Hinweis

Das Pflegekonzept für die Common Services werden durch den PB OZG / EU OOTS bzw. durch die SDG-Koordination geliefert.

3.4.1.2.3 Nationale zentrale Kontaktstelle

Jeder Mitgliedstaat benennt gem. Artikel 21 SDG-DVO (2022/1463) eine zentrale Kontaktstelle für technische Unterstützung, um den Betrieb und die Wartung der Komponenten des OOTS, für die der jeweilige Mitgliedstaat gemäß Abschnitt 9 zuständig ist, sicherzustellen. Die nationale zentrale Kontaktstelle hat eine Vielzahl von Aufgaben, darunter das

Untersuchen und Beheben von Sicherheitsverletzungen (Artikel 21 (2) b SDG-DVO) und das Unterrichten anderer Kontaktstellen über alle Vorgänge, die zu einer (mutmaßlichen) Sicherheitsverletzung führen können (Artikel 21 (2) c SDG-DVO)
Untersuchen und Lösen von Ausfällen einzelner Komponenten (z.B. eDelivery Access Points oder IP) oder der ganzen nationalen Domäne (NOOTS),
Überprüfen von Nachweisanfragen (und der Historie) bei Zweifel an der Rechtmäßigkeit (Artikel 21 (3) SDG-DVO),
Erstellen von Risikomanagementplänen zur Ermittlung und Bewertung von Risken und potenziellen Auswirkungen und zur Planung von geeigneten technischen und organisatorischen Gegenmaßnahmen (Artikel 24 (4) SDG-DVO),
Bereitstellen von Fachwissen und Beratung zur Unterstützung der Systeme des OOTS und anzuschließender Behörden (Artikel 21 (2) a SDG-DVO),
Vermitteln von Kontakten zu anderen Kontaktstellen (Artikel 21 (2) a SDG-DVO).

3.4.1.2.4 Rollen beim Nachweisabruf über das EU-OOTS

Dieses Kapitel beschreibt das Zusammenwirken der Rollen im NOOTS und EU-OOTS. Der verpflichtende Einsatz einer Intermediären Plattform hat zur Folge, dass gegenüber dem EU-Ausland Data Consumer nicht direkt als Evidence Requester und Data Provider nicht direkt als Evidence Provider auftreten. Abhängig davon, ob ein Nachweis über das EU-OOTS aus einem Mitgliedstaat oder aus Deutschland abgerufen wird, fungiert die Intermediäre Plattform stets als Stellvertreterin für Nachweisabrufe. Dabei agiert sie in Richtung des NOOTS als Data Consumer bzw. Data Provider und muss die für diese NOOTS-Teilnehmer geltenden Anforderungen zur NOOTS-Teilnahme erfüllen. Gegenüber dem EU-OOTS wiederum erfüllt sie die Anforderungen eines Evidence Requesters bzw. eines Evidence Provider.

Fachlich verantwortlich für die ausgestellten Nachweise bleiben jedoch nach aktuellem Verständnis die nachweisliefernden Stellen. Die genaue Rechtsstellung der Intermediären Plattform in diesem Zusammenhang befindet sich noch in Prüfung. Es ist möglich, dass die Intermediäre Plattform mit einer Rechtspersönlichkeit ausgestattet wird, durch die sie unmittelbar als Evidence Requester bzw. als Evidence Provider gilt.

Abb. 3: Rollenmodell im NOOTS unter Verwendung der Intermediären Plattform

3.5 Anforderungen

In diesem Kapitel werden funktionale und nicht-funktionale Anforderungen an das NOOTS dokumentiert. Diese beschreiben, welche Eigenschaften, Leistungen und Qualitätsmerkmale das NOOTS auf übergeordneter Ebene erbringen soll. In Ergänzung dazu werden funktionale und nicht-funktionale Anforderungen an die einzelnen Komponenten des NOOTS in den jeweiligen Konzepten oder Komponentensteckbriefen beschrieben, wenn passend unter Bezugnahme auf die entsprechende übergreifende Anforderung.

Die Übersicht der Anforderungen entspricht dem aktuellen Stand der Konzeption des NOOTS.

3.5.1 Vorgehensweise und Quellen

Die Anforderungen an das NOOTS wurden in mehreren Schritten ermittelt. Zur Identifikation der relevanten Anforderungen wurden folgende Quellen analysiert (zu finden im Quellenverzeichnis):

zentrale Rechtsgrundlagen im Kontext der Registermodernisierung (IDNrG, UBRegG, etc.),
Rechtsgrundlage des europäischen Vorhabens Single Digital Gateway (SDG-Verordnung, SDG-Durchführungsverordnung),
Beschlüsse und Entscheidungen des IT-Planungsrats,
föderale IT-Architekturrichtlinien.

Für die nicht-funktionalen Anforderungen wurden zusätzlich die Qualitätskriterien des ISO-Standards 25010 betrachtet. Sofern sich zu den dort genannten Kriterien aus den obenstehenden Quellen keine Anforderung ableiten ließ, das Kriterium für das NOOTS aber als relevant erachtet wurde, wurde eine entsprechende Anforderung ergänzt. Diese Anforderungen tragen den Quellen-Verweis "PB NOOTS".

Bei der Auswertung der Quellen wurden solche Aspekte betrachtet, die für die Entwicklung des NOOTS relevant sind. Im Kontext der nicht-funktionalen Anforderungen wurde dabei insbesondere berücksichtigt, dass das NOOTS selbst keine technische Umsetzung umfasst und damit einige Aspekte der Quellen nicht zutreffen, z.B. die Anforderung aus den föderalen IT-Architekturrichtlinien, bevorzugt Open Source zu entwickeln. Diese sind aber für die konkrete Implementierung in den Umsetzungsprojekten einschlägig und werden daher in der Anforderungserhebung auf Komponentenebene berücksichtigt.

Die aus diesen Quellen ermittelten Anforderungen wurden dokumentiert, um alle Informationen detailliert zu erfassen. Im Anschluss wurden die Anforderungen verifiziert und validiert. Hierzu konnten Mitglieder des PB NOOTS und weitere relevante Stakeholder Rückmeldungen zu den einzelnen Anforderungen geben und es erfolgten weitere Abstimmungen zu Anforderungen mit Klärungsbedarf.

3.5.2 Funktionale Anforderungen

Tab. 4: Übersicht funktionale Anforderungen an das NOOTS

ID	Anforderung	Ergänzende Erläuterung nach Bedarf	Quelle
NOOTS-658	Das NOOTS MUSS einem Data Consumer den Abruf von Nachweisen aus Deutschland und anderen EU-Mitgliedstaaten ermöglichen.		[Art. 14 EU-03](./AD-NOOTS-00_+Quellenverzeichnis.md)
NOOTS-860	Das NOOTS MUSS den Abruf nationaler Nachweise durch andere EU-Mitgliedstaaten ermöglichen.		[Art. 14 EU-03](./AD-NOOTS-00_+Quellenverzeichnis.md)
NOOTS-693	Das NOOTS MUSS gewährleisten, dass Kommunikation nur zwischen dazu autorisierten technischen Komponenten öffentlicher Stellen möglich ist.	Verwendung der Definition von öffentlichen Stellen gem. § 2 BSDG	[IT-PLR-B-07](./AD-NOOTS-00_+Quellenverzeichnis.md)
NOOTS-654	Das NOOTS MUSS Nachweisabrufe ermöglichen.	Ein Nachweisabruf kann auf verschiedene Arten stattfinden: * im Dialog mit einer Person, die zu sich selbst oder in Vertretung des Nachweissubjekts zu diesem einen Nachweis abruft. * ohne Beteiligung des Nachweissubjekts oder seines Vertreters. Ein Nachweisabruf kann sowohl Nachrichtenmuster des fachlich synchronen Nachweisabrufs als auch des fachlich asynchronen Nachweisabrufs nutzen.	[IT-PLR-E-02](./AD-NOOTS-00_+Quellenverzeichnis.md)
NOOTS-656	Das NOOTS MUSS die Kommunikation zwischen Data Consumern und Data Providern durch einen fachunabhängigen Nachweisabrufstandard ermöglichen.	Fachunabhängiger Nachweisabrufstandard: Der Nachweisabruf bei Data Providern erfolgt grundsätzlich zu gleichen rechtlichen, organisatorischen und technischen Bedingungen, sodass die Data Consumer nicht für verschiedene Nachweise jeweils neue Fachstandards und deren Schnittstellen implementieren müssen.	[IT-PLR-E-03](./AD-NOOTS-00_+Quellenverzeichnis.md)
NOOTS-657	Das NOOTS MUSS Abrufe von Nachweisen zu natürlichen Personen und Unternehmen im Sinne des § 3 Abs. 1 UBRegG ermöglichen.	Unternehmen im Sinne des § 3 Abs. 1 UBRegG sind: * Kaufleute im Sinne des Handelsgesetzbuchs, * Genossenschaften im Sinne des Genossenschaftsgesetzes, * Partnerschaften im Sinne des Partnerschaftsgesellschaftsgesetzes, * Vereine im Sinne des Bürgerlichen Gesetzbuchs, * wirtschaftlich Tätige im Sinne der Abgabenordnung: * natürliche Personen, die wirtschaftlich tätig sind * juristische Personen und * Personenvereinigungen sowie * weitere Unternehmen im Sinne des Siebten Buches Sozialgesetzbuch.	[IT-PLR-B-04](./AD-NOOTS-00_+Quellenverzeichnis.md)
NOOTS-690	Das NOOTS MUSS unterstützen, dass natürliche Personen behördlichen Datenaustausch unter Verwendung der IDNr nachvollziehen können.	Datenaustausch betrifft Protokoll- und Inhaltsdaten der Register	[§ 2 Abs. 3 RGR-01](./AD-NOOTS-00_+Quellenverzeichnis.md)
NOOTS-691	Das NOOTS MUSS bei einem Nachweisabruf die Verwendung der IDNr zur eindeutigen Identifikation von natürlichen Personen ermöglichen.		[IT-PLR-B-07](./AD-NOOTS-00_+Quellenverzeichnis.md)
NOOTS-715	Das NOOTS MUSS bei einem Nachweisabruf die Verwendung der beWiNr. und weiterer Identifikatoren zur eindeutigen Identifikation von Unternehmen unterstützen.		[IT-PLR-B-07](./AD-NOOTS-00_+Quellenverzeichnis.md)
NOOTS-635	Das NOOTS DARF die automatische Vor-Befüllung von Online-Anträgen mit Hilfe von Nachweisdaten nicht verhindern.	Die Nachweisdaten, die mit Unterstützung des NOOTS aus dem Register abgerufen werden, müssen vom Data Consumer gelesen und entschlüsselt werden können, sodass dieser sie zur automatischen Vor-Befüllung von Online-Anträgen nutzen kann. Die automatische Vor-Befüllung der Online-Anträge liegt jedoch nicht im Umfang des NOOTS.	[IT-PLR-B-04](./AD-NOOTS-00_+Quellenverzeichnis.md)

3.5.3 Nicht-funktionale Anforderungen

Tab. 5: Übersicht nicht-funktionale Anforderungen an das NOOTS

ID	Anforderung	Ergänzende Erläuterung nach Bedarf	ISO-Kriterium	Quelle
NOOTS-628	Das NOOTS SOLL bei Abrufen von nationalen Nachweisen innerhalb von 40s und MUSS innerhalb von 60s eine Antwort liefern.	Die angegebene Antwortzeit bezieht sich auf den gesamten Nachweisabrufprozess, d.h. die Antwortzeit des Data Provider, den Aufruf aller benötigten NOOTS-Komponenten sowie jeweils den Transport der Nachrichten für diese Aufrufe. Für jedes einzelne System (d.h. für den Data Provider sowie für die einzelnen NOOTS-Komponenten) ergibt sich jeweils eine maximale Antwortzeit von drei Sekunden. Genaueres wird in den Konzepten der Komponenten festgelegt.	Leistungseffizienz	PB NOOTS
NOOTS-721	Das NOOTS MUSS Sicherheitseinstellungen bereits in der Grundkonfiguration seiner Dienste aktiviert haben (Security by default).	Alle Sicherheitseinstellungen der NOOTS-Komponenten müssen bereits in der Grundkonfiguration des Dienstes aktiviert sein.	Sicherheit	[ITPLR-FAR ](./AD-NOOTS-00_+Quellenverzeichnis.md)
NOOTS-535	Das NOOTS MUSS es NOOTS-Teilnehmern ermöglichen, sicherzustellen, dass in der Leistungsverwaltung personenbezogene Daten ausschließlich von berechtigten Personen abgerufen werden können.	Berechtigt können Personen sein, die entweder Daten für sich selbst abrufen oder vertretungsberechtigt für eine andere Person sind. Entsprechende (Vertretungs-)Berechtigungen zu definieren und zu prüfen, obliegt den Data Consumern bzw. Data Providern. Aus diesem Grund ist die Anforderung so formuliert, dass das NOOTS eine solche Prüfung nur _ermöglicht_, nicht aber selbst als verantwortliches System sicherstellt.	Sicherheit	PB NOOTS
NOOTS-605	Das NOOTS MUSS eine Profilbildung technisch wirksam begrenzen.	Mit Profilbildung ist die unzulässige Erstellung von Persönlichkeitsprofilen durch das Zusammenführen von personenbezogenen Daten aus verschiedenen Registern gemeint.	Sicherheit	[IT-PLR-B-04](./AD-NOOTS-00_+Quellenverzeichnis.md)
NOOTS-729	Das NOOTS MUSS der Registermodernisierungsbehörde die Möglichkeiten bieten, die Zulässigkeit von Nachweisabrufen aus gegebenem Anlass oder durch Stichproben zu prüfen.	Die Zulässigkeit von Nachweisabrufen bezieht sich auf die rechtlichen, technischen und organisatorischen Voraussetzungen, unter denen ein Data Consumer einen Nachweis von einem Data Provider abrufen darf. Für die Prüfung dieser Zulässigkeit sind Informationen zum Nachweisabruf erforderlich, wie die Nachweisdaten sowie sogenannte Metadaten, beispielsweise Angaben zu den beteiligten NOOTS-Teilnehmern, zum Nachweissubjekt usw. Nachweisabrufe können personenbezogene Daten enthalten, etwa im Nachweissubjekt oder in den Nachweisdaten. Aus Datenschutzgründen werden diese Daten nicht in Protokollen der NOOTS-Komponenten gespeichert. Stattdessen obliegt die Bereitstellung und Protokollierung dieser Daten den NOOTS-Teilnehmern und erfolgt somit außerhalb des NOOTS. NOOTS kann jedoch die für die Prüfung der Zulässigkeit erforderlichen Metainformationen zum Nachweisabruf ohne personenbezogene Daten oder Nachweisedaten bereitstellen. Dazu gehört beispielsweise die Protokollierung der abstrakten Berechtigungsprüfung in der Vermittlungsstelle. Die Prüfung der Zulässigkeit von Nachweisabrufen setzt daher ein abgestimmtes Zusammenwirken zwischen NOOTS und seinen Teilnehmern voraus.	Sicherheit	PB NOOTS
NOOTS-733	Das NOOTS MUSS Protokolldaten bezüglich Nachweisaustauschen im Standardfall zwei Jahre aufbewahren und danach unverzüglich löschen.	Gemäß der Anforderung NOOTS-729 protokolliert NOOTS keine personenbezogenen Daten oder Nachweisdaten im Rahmen eines Nachweisabrufs. Allerdings werden Metadaten zum Nachweisabruf, wie beispielsweise das Ergebnis der abstrakten Berechtigungsprüfung innerhalb der Vermittlungsstelle, protokolliert. Die Aufbewahrungsfrist dieser Metadaten zum Nachweisabruf orientiert sich an § 9 Abs. 3 IDNrG, um eine gemeinsame Auswertung zu ermöglichen. Hinweis: Genauere Protokollierungsvorgaben werden auf Komponentenebene beschrieben.	Sicherheit	PB NOOTS
NOOTS-735	Das NOOTS MUSS alle einschlägigen Datenschutzvorschriften einhalten.	Einschlägig sind die Regelungen der Datenschutzgrundverordnung (DSGVO), insbesondere die Artikel 5-7 sowie 25, und des Bundesdatenschutzgesetzes.	Sicherheit	[EU-03](./AD-NOOTS-00_+Quellenverzeichnis.md)
NOOTS-738	Das NOOTS MUSS die einschlägigen nationalen IT-Sicherheitsstandards erfüllen.	Laut BSI muss es eine Risikoanalyse gemäß IT-Grundschutz ([SQ-04](./AD-NOOTS-00_+Quellenverzeichnis.md)) mit entsprechender Maßnahmenableitung pro Komponente geben. Anschließend ist zu bewerten, ob die pro Komponente identifizierten Maßnahmen für das System insgesamt die nötige Sicherheit gewährleisten.	Sicherheit	[EU-03](./AD-NOOTS-00_+Quellenverzeichnis.md)
NOOTS-739	Das NOOTS MUSS bei der Übertragung schützenswerter Daten deren Vertraulichkeit sicherstellen.	Definition von "Vertraulichkeit" gemäß BSI IT-Grundschutz-Kompendium Edition 2023: "Vertraulichkeit ist der Schutz vor unbefugter Preisgabe von Informationen. Vertrauliche Daten und Informationen dürfen ausschließlich Befugten in der zulässigen Weise zugänglich sein" ([SQ-04](./AD-NOOTS-00_+Quellenverzeichnis.md)). Dies gilt sowohl für den Zugriff auf Daten in Datenspeichern, als auch für den Zugriff auf übertragene Daten während des Transports. Um die Vertraulichkeit der Daten beim Transport sicher zu stellen, müssen sie verschlüsselt übertragen werden. Hierzu fordert auch das §7 Abs 2 IDNrG: "Datenübermittlungen unter Nutzung einer Identifikationsnummer nach diesem Gesetz zwischen öffentlichen Stellen verschiedener Bereiche erfolgen über Vermittlungsstellen verschlüsselt in gesicherten Verfahren, die dem aktuellen Stand von Sicherheit und Technik entsprechen müssen." _Hinweis: Das Thema Verschlüsselung wird im Arbeitspaket "IT-Sicherheit und Datenschutz" ausgearbeitet._	Sicherheit	[EU-03](./AD-NOOTS-00_+Quellenverzeichnis.md)
NOOTS-740	Das NOOTS MUSS die Integrität der übermittelten Nachweise sicherstellen.	Definition von "Integrität" gemäß BSI IT-Grundschutz-Kompendium Edition 2023: "Integrität bezeichnet die Sicherstellung der Korrektheit (Unversehrtheit) von Daten und der korrekten Funktionsweise von Systemen. Wenn der Begriff Integrität auf „Daten“ angewendet wird, drückt er aus, dass die Daten vollständig und unverändert sind. In der Informationstechnik wird er in der Regel aber weiter gefasst und auf „Informationen“ angewendet. Der Begriff „Information“ wird dabei für „Daten“ verwendet, denen je nach Zusammenhang bestimmte Attribute wie z. B. Autorenschaft oder Zeitpunkt der Erstellung zugeordnet werden können. Der Verlust der Integrität von Informationen kann daher bedeuten, dass diese unerlaubt verändert, Angaben zur verfassenden Person verfälscht oder Zeitangaben zur Erstellung manipuliert wurden" ([SQ-04](./AD-NOOTS-00_+Quellenverzeichnis.md)).	Sicherheit	[EU-03](./AD-NOOTS-00_+Quellenverzeichnis.md)
NOOTS-737	Das NOOTS MUSS dem Empfänger von Nachweisen die Information über deren Herkunft eindeutig und überprüfbar zur Verfügung stellen.	Die Anforderung ist eng verknüpft mit der Anforderung NOOTS-740 zur Integrität von Nachweisen. In der Umsetzung empfiehlt es sich, beide gemeinsam zu denken.	Sicherheit	[EU-03](./AD-NOOTS-00_+Quellenverzeichnis.md)
NOOTS-741	Das NOOTS MUSS sicherstellen, dass Nachweise nur in notwendigem Umfang und für die notwendige Dauer innerhalb des NOOTS verarbeitet werden.	Der NOOTS-Transport der Nachweisdaten sollte idealerweise ohne Zwischenspeicherung durchgeführt werden.	Sicherheit	[EU-03](./AD-NOOTS-00_+Quellenverzeichnis.md)
NOOTS-629	Das NOOTS MUSS für Nutzende eine normale Verfügbarkeit erreichen und perspektivisch 99% der Zeit verfügbar sein.	* Die Gesamtverfügbarkeit des NOOTS berechnet sich aus dem Produkt der Verfügbarkeit seiner Komponenten. * Eine Komponente gilt als nicht-verfügbar, wenn sie eine Anfrage nicht verarbeitet. Entsprechende Fehlermeldungen zu Nicht-Bearbeitung gelten demnach nicht als verfügbar. Eine Reaktion mit fachlichen Fehlermeldungen dagegen gilt als verfügbar. * Die Verfügbarkeit ist inklusive der Zeiten für geplante Wartungen anzugeben, d.h. während geplanter Wartung wird das System als "verfügbar" gewertet. * Von dem NOOTS-Verfügbarkeitszielwert leitet sich ein Verfügbarkeitsziel von je 99,9% je NOOTS-Komponente ab. Für NOOTS-Teilnehmer gilt dies nicht. * "Perspektivisch" bedeutet, dass der angegebene Wert als finales Ziel zu verstehen ist. Es ist demnach denkbar, sofern dies organisatorisch und wirtschaftlich vorteilhaft ist, dass die Verfügbarkeit beim Go-Live des NOOTS niedriger ist und mit steigenden Nutzungszahlen bis zum Zielwert anwächst.	Zuverlässigkeit	PB NOOTS
NOOTS-878	Das NOOTS MUSS den Betrieb im Katastrophenfall gemäß den Ergebnissen einer Risikoanalyse nach Vorgaben des BSI gewährleisten.	Dabei zu berücksichtigen ist das Umsetzungsrahmenwerk zum Notfallmanagement des BSI ([SQ-09](./AD-NOOTS-00_+Quellenverzeichnis.md)).	Zuverlässigkeit	PB NOOTS
NOOTS-1274	Die Komponenten des NOOTS müssen uneingeschränkt horizontal skalierbar sein.	Dies bedeutet: * Es müssen beliebig viele Instanzen einer NOOTS-Komponente redundant betrieben werden können. * Die Gesamtleistungsfähigkeit der Instanzen der Komponente muss annähernd linear mit der Anzahl der Instanzen steigen.	Zuverlässigkeit	[Mengengerüst](./BD-NOOTS-02_+Mengengeruest.md)
NOOTS-722	Das NOOTS MUSS so gestaltet sein, dass es nicht durch nur ein einziges IT-Produkt oder einen einzigen Hersteller umgesetzt werden kann.	\-	Portierbarkeit	[ITPLR-FAR ](./AD-NOOTS-00_+Quellenverzeichnis.md)
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.	Diese Anforderung ergibt sich aus der Rahmenbedingung, dass sowohl Data Consumer als auch Data Provider zu heterogen sind, um Umstellungen an einem gemeinsamen Stichtag durchzuführen. Erklärung: ein Parallelbetrieb unterschiedlicher Versionen von Standards (z.B. XNachweis), als auch Schnittstellen (z.B. RDN) innerhalb des Gesamtsystems NOOTS muss möglich sein. Die NOOTS-Komponenten und DC/ DP müssen bei ihrer Planung, Implementierung und Betrieb berücksichtigen, dass angebotene Schnittstellen verschiedene Versionen eines Standards parallel liefern können und genutzte Services ggf. mit unterschiedlichen Versionen antworten. Bei der Einführung neuer Versionen von Schnittstellen und Standards muss eine Übergangszeit für den Parallelbetrieb mit einem festgelegten Enddatum für die Unterstützung abgelöster Versionen definiert werden.	Portierbarkeit	PB NOOTS
NOOTS-723	Das NOOTS MUSS modular aufgebaut sein.	Modular bedeutet in diesem Kontext, dass jede NOOTS-Komponente eigenständig nutzbar sein und entsprechend unabhängig weiterentwickelt, aktualisiert und betrieben werden können soll. Dabei sind Schnittstellen stabil zu halten.	Wartbarkeit	[ITPLR-FAR ](./AD-NOOTS-00_+Quellenverzeichnis.md)
NOOTS-836	Das NOOTS MUSS eine effiziente Lokalisierung und Analyse von Fehlern wirksam unterstützen.	\-	Wartbarkeit	PB NOOTS
NOOTS-105	Das NOOTS MUSS für jede NOOTS-Komponente und NOOTS-Teilnehmer deren Schnittstellen so spezifizieren, dass deren Implementierungen durch Kompatibilitätstests verifiziert werden können.	\-	Wartbarkeit	[ITPLR-FAR](./AD-NOOTS-00_+Quellenverzeichnis.md)
NOOTS-720	Das NOOTS SOLL soweit möglich und zweckmäßig bestehende Lösungen, u.a. des IT-Planungsrats, wiederverwenden oder weiterentwickeln.	\-	Wartbarkeit	[IT-PLR-B-04](./AD-NOOTS-00_+Quellenverzeichnis.md)
NOOTS-726	Das NOOTS SOLL sich an dem Aufbau und den Standards des EU-OOTS orientieren und bei nationalen Abweichungen Interoperabilität mit dem EU-OOTS gewährleisten.	\-	Kompatibilität	[IT-PLR-B-04](./AD-NOOTS-00_+Quellenverzeichnis.md)
NOOTS-743	Das NOOTS SOLL die Vorgaben des Europäischen Interoperabilitätsrahmenwerks (EIF) erfüllen.	Näheres zum Europäischen Interoperabilitätsrahmenwerk in [SQ-05](./AD-NOOTS-00_+Quellenverzeichnis.md). Ausblick: Es entsteht zurzeit die EU-Verordnung "Interoperable Europe Act" ([SQ-06](./AD-NOOTS-00_+Quellenverzeichnis.md)), die ähnliche Aspekte adressiert. Sobald diese im Jahr 2024 verabschiedet wird, ist diese zusätzlich zu berücksichtigen.	Kompatibilität	[IT-PLR-B-04](./AD-NOOTS-00_+Quellenverzeichnis.md)

3.6 Lösungsstrategie

3.6.1 Architekturzielbild des NOOTS

Das Architekturzielbild des NOOTS wurde in enger Abstimmung mit der Gesamtsteuerung der Registermodernisierung entwickelt und festgelegt. Mit der Umsetzung dieses Architekturzielbilds wird die nationale technische NOOTS-Infrastruktur vollständig aufgebaut, die sowohl nationale als auch europäische Nachweisabrufe unterstützt. Data Consumer und Data Provider können kontinuierlich an NOOTS angebunden werden.

Die folgende Darstellung zeigt das angestrebte Zielbild der NOOTS-Architektur.

Abb. 4: Architekturzielbild des NOOTS

Die Realisierung des Architekturzielbilds umfasst folgende NOOTS-Komponenten:

Tab. 6: Kurzbeschreibung der Komponenten im NOOTS

Bezeichnung	Beschreibung
Access Point ([AD-NOOTS-04](./AD-NOOTS-00_+Quellenverzeichnis.md))	Der “eDelivery Access Point” ist eine eigenständige und fachunabhängige Komponente für den Nachweisabruf im europäischen Kontext (gemäß SDG). Er verbindet die Intermediäre Plattform mit den eDelivery-Access Points anderer EU-Mitgliedstaaten und übernimmt den Übergang vom Transportstandard des NOOTS in den Transportstandard des EU-OOTS (AS4).
Datenschutzcockpit ([AD-NOOTS-09](./AD-NOOTS-00_+Quellenverzeichnis.md))	Das „Datenschutzcockpit" ist eine IT-Komponente im Portalverbund, mit der sich natürliche Personen Auskünfte zu Datenübermittlungen zwischen öffentlichen Stellen anzeigen lassen können. Erfasst werden diejenigen Datenübermittlungen, bei denen eine Identifikationsnummer nach § 5 des Identifikationsnummerngesetzes zum Einsatz kommt. Die Anzeige der Bestandsdaten der Register ist vorgesehen.
Identity and Accessmanagement für Behörden ([AD-NOOTS-05](./AD-NOOTS-05_+Grobkonzept+IAM+für+Behoerden.md))	Das Identity and Accessmanagement (IAM) für Behörden ist ein zentrales System zur Zuordnung und zum Abruf berechtigungsrelevanter Informationen für Zugriffe auf Ressourcen gemäß rechtlichen Vorgaben.
Identity Management für Personen ([AD-NOOTS-10](./AD-NOOTS-00_+Quellenverzeichnis.md))	Das IDM für Personen (Art. 1 Registermodernisierungsgesetz) stellt die IDNr eines Bürgers bzw. einer Bürgerin und weitere Basisdaten zur Person bereit.
Identity Management für Unternehmen	Das IDM für Unternehmen befasst sich mit der registerübergreifenden eindeutigen Identifikation von Unternehmen im Sinne des § 3 Abs. 1 UBRegG anhand einer bundeseinheitlichen Wirtschaftsnummer (beWiNr.). Die beWiNr. wird durch das Bundeszentralamt für Steuern vergeben und von der W-IdNr.-Datenbank des Bundeszentralamtes für Steuern bereitgestellt. _Hinweis: Die Umsetzung des IDM für Unternehmen ist aufgrund einer fehlenden Rechtsgrundlage aktuell nicht vorgesehen._
Intermediäre Plattform ([AD-NOOTS-06](./AD-NOOTS-06_+Grobkonzept+Intermediaere+Plattform+_IP_.md))	Die Intermediäre Plattformen (IP) ist eine technische Lösung, die je nach der Verwaltungsorganisation der Mitgliedstaaten, in denen die Intermediäre Plattform tätig ist, in Erfüllung eigener Aufgaben oder im Namen anderer Behörden wie Nachweislieferanten oder Nachweise anfordernden Behörden tätig wird und über die Nachweislieferanten oder Nachweise anfordernde Behörden mit den in Artikel 4 Absatz 1 SDG-DVO (EU) 2022/1463 genannten gemeinsamen Diensten oder mit Nachweislieferanten oder Nachweise anfordernden Behörden aus anderen Mitgliedstaaten verbunden werden.
Registerdatennavigation _(_[AD-NOOTS-07](./AD-NOOTS-07_+Grobkonzept+Registerdatennavigation+_RDN_.md))	Die Registerdatennavigation (RDN) ist der zentrale Routingdienst des NOOTS. Sie liefert auf Anfrage die Information, von welchem technischen Dienst einer Behörde ein gesuchter Nachweistyp abgerufen werden kann. Dazu übermittelt die RDN notwendige Verbindungsparameter.
Sicherer Anschlussknoten ([AD-NOOTS-19](./AD-NOOTS-19_+Transportinfrastruktur.md))	Der Sichere Anschlussknoten (SAK) ist eine zentral bereitgestellte NOOTS-Komponente, die jedoch dezentral im Verantwortungsbereich der NOOTS-Teilnehmer oder einer anderen NOOTS-Komponente betrieben wird. Er ermöglicht den NOOTS-Teilnehmern und -Komponenten über ein interoperables Anschlussprotokoll einen einfachen und sicheren Anschluss an das NOOTS. Darüber hinaus ermöglicht der SAK ihnen den Versand und Empfang von Nachrichten über die NOOTS-Transportinfrastruktur.
Vermittlungsstelle ([AD-NOOTS-08](./AD-NOOTS-08_+Grobkonzept+Vermittlungsstelle+_VS_.md))	Die Vermittlungsstelle ist eine dritte öffentliche Stelle, die beim bereichsübergreifenden Nachweisabruf unter Verwendung der IDNr die abstrakte Berechtigungsprüfung durchführt und so die Zulässigkeit von Datenübermittlungen zwischen Data Consumer und Data Provider sicherstellt. Vorrangiges Ziel der Vermittlungsstelle ist, das Risiko der unzulässigen Zusammenführung von personenbezogenen Daten zur Bildung von Persönlichkeitsprofilen zu verringern.

3.6.2 Datenflüsse im NOOTS

Beim Abruf von Nachweisen werden Daten zwischen den NOOTS-Komponenten und den NOOTS-Teilnehmern übermittelt. Diese Datenflüsse im NOOTS stellen sicher, dass die erforderlichen Informationen für die einzelnen Prozessschritte verfügbar sind und die NOOTS-Komponenten ihre Funktionalitäten ausführen können. Die Kommunikation zwischen Data Consumer und Data Provider erfolgt über die Sicheren Anschlussknoten.

In der folgenden Abbildung werden exemplarisch die Datenflüsse beim Nachweisabruf einer natürlichen Person über einen Onlinedienst unter Verwendung der IDNr dargestellt. Eine detaillierte Beschreibung der Datenflüsse ist im Grobkonzept Transportinfrastruktur (AD-NOOTS-19), Kapitel '8. Laufzeitsicht', zu finden.

Abb. 5: Datenflüsse beim Nachweisabruf einer natürlichen Person über einen Onlinedienst unter Verwendung der IDNr

3.6.3 Nachweisabruf

In diesem Kapitel wird der Prozess des Nachweisabrufs über das NOOTS beschrieben. Dazu wird das Architekturzielbild des NOOTS als Grundlage genutzt.

3.6.3.1 Annahmen

Tab. 7: Annahmen für den Nachweisabruf über das NOOTS

Annahme	Beschreibung
ANN-001	Beim Nachweisabruf von nationalen Data Providern ist dem Data Consumer bekannt, welche Nachweistypen für die Erbringung einer Verwaltungsleistung abgefragt werden müssen.
ANN-002	Beim Nachweisabruf von nationalen Data Providern ist dem Data Consumer bekannt, welche Zuständigkeitsparameter für die Ermittlung des zuständigen Data Provider angegeben werden müssen.

3.6.3.2 Hinweise zum Nachweisabruf

Wenn für einen Antrag mehrere Nachweise benötigt werden, müssen die Prozessschritte für jeden Nachweisabruf durchlaufen werden. Dies kann parallel erfolgen.
Weder Data Consumer noch der Data Provider sind Bestandteil des NOOTS, weshalb das Ausfüllen des Antrags, das Ausstellen von Nachweisen und die Antragseinreichung nicht beschrieben werden.
Auf eine detaillierte Betrachtung der zugrundeliegenden Transportinfrastruktur sowie der Prozesse zur Sicherstellung von IT-Sicherheit und Datenschutz (Ausstellung von Zertifikaten, Ver- und Entschlüsselung von Nachrichten, Signatur, Token-Prüfung, etc.) wird in dieser Darstellung verzichtet. Sie sind in eigenen Konzepten beschrieben.

3.6.3.3 Nachweisabrufprozess des NOOTS

Im Folgenden ist der Prozess des Nachweisabrufs aus Perspektive des NOOTS dargestellt und beschrieben. Dementsprechend sind Abläufe, die das EU-OOTS und die Intermediären Plattform betreffen, nicht näher betrachtet. Weiterführende Informationen dazu sind im Grobkonzept Intermediäre Plattform (AD-NOOTS-06) zu finden. Ebenso werden Prozesse innerhalb der Data Consumer und Data Provider nicht im Detail betrachtet. Weitergehende Informationen dazu finden sich in den jeweiligen Anschlusskonzepten (AD-NOOTS-01, AD-NOOTS-02).

Abb. 6: Nachweisabruf über das NOOTS

Tab. 8: Prozessbeschreibung des Nachweisabrufs

Prozessschritt	Beschreibung	Erläuterung	Anmerkung
_\[UC-01\]_	* Für den Bezug einer Verwaltungsleistung meldet sich die Nutzerin oder der Nutzer beim Data Consumer an.	* Der Data Consumer muss die Authentizität der Nutzerin oder des Nutzers durch geeignete Maßnahmen sicherstellen.	* Über ein Nutzerkonto muss eine Authentifizierung mit einem Identifizierungsmittel erfolgen, das das für den Nachweisabruf erforderliche Vertrauensniveau erfüllt. * Data Consumer sind nationale Onlinedienste, nationale Fachverfahren und die Intermediäre Plattform (in der Rolle des Data Consumer).
_\[UC-02\]_	* Der Nachweisabruf wird durch die Nutzerin oder den Nutzer initiiert.	* Der Nachweisabruf wird durch die Entscheidung der Nutzerin oder des Nutzers ausgelöst.
_\[UC-03\]_	* Der Data Consumer meldet sich über seinen Sicheren Anschlussknoten beim IAM für Behörden am NOOTS an und erhält als Bestätigung ein Zugriffstoken.	* Das Zugriffstoken enthält identifizierende Informationen über den Data Consumer sowie dessen Berechtigungen zum Zugriff auf die NOOTS-Komponenten. Es wird bei jedem Nachrichtenaustausch über das NOOTS mitgesendet.	* Der Austausch von Nachrichten des Data Consumer mit anderen NOOTS-Komponenten und NOOTS-Teilnehmern erfolgt ausschließlich über seinen Sicheren Anschlussknoten (SAK). Der Sichere Anschlussknoten übernimmt sowohl den sicheren Versand von Nachrichten als auch den Empfang der Antworten. Eine detaillierte Beschreibung findet sich im Grobkonzept Transportinfrastruktur ([AD-NOOTS-19](./AD-NOOTS-19_+Transportinfrastruktur.md)).
_\[UC-04\]_	* Der Data Consumer ermittelt über seinen Sicheren Anschlussknoten den zuständigen Data Provider sowie dessen Nachweisangebot über die Registerdatennavigation.	* Beim EU-Nachweisabruf ist keine Übermittlung von Parametern an die Registerdatennavigation erforderlich. * Beim nationalen Nachweisabruf hingegen muss der Data Consumer den Nachweistyp sowie gegebenenfalls zusätzliche Zuständigkeitsparameter übermitteln.	* Dem Data Consumer ist a priori beim nationalen Nachweisabruf bekannt, welche Zuständigkeitsparameter zur Ermittlung des für einen Nachweistyp zuständigen Data Provider benötigt werden. * Eine ausführliche Beschreibung finden Sie im Grobkonzept Registerdatennavigation ([AD-NOOTS-07](./AD-NOOTS-07_+Grobkonzept+Registerdatennavigation+_RDN_.md#82-ablaufszenarien-der-registerdatennavigation)), Kapitel „8.2 Ablaufszenarien der Registerdatennavigation“, sowie in den SAK-APIs ([SQ-31](./AD-NOOTS-00_+Quellenverzeichnis.md)).
_\[UC-05\]_	* Falls die IDNr als Ordnungsmerkmal im Register gespeichert ist und die Voraussetzungen zu deren Nutzung erfüllt sind, dann ruft der Data Consumer über seinen Sicheren Anschlussknoten die IDNr des Nachweissubjekts über das IDM für Personen ab.	* Falls das IDM für Personen keine positive Antwort liefert (IDNr kann nicht oder nicht eindeutig ermittelt werden), bricht der Data Consumer den Nachweisabruf ab (vgl. [AD-NOOTS-01](./AD-NOOTS-01_+Anschlusskonzept+Data+Consumer+_DC_.md)). * Die Nutzung der IDNr erfolgt nur beim nationalen Nachweisabruf und wenn die Anforderungen (insbes. § 5 Abs. 1 IDNrG) erfüllt sind.	* Die IDNr ermöglicht die zuverlässige Identifizierung einer natürlichen Person im Register. * Detaillierte Informationen zur Schnittstelle sind in den SAK-APIs ([SQ-31](./AD-NOOTS-00_+Quellenverzeichnis.md)) und im Standard XBasisdaten ([XS-03](./AD-NOOTS-00_+Quellenverzeichnis.md)), insbesondere im Kapitel „3 Datenabrufe mit Personendaten“, verfügbar.
_\[UC-06\]_	* Der Data Consumer unterscheidet die Art des Data Provider: * nationaler Data Provider oder * Intermediäre Plattform.		* Dem Data Consumer ist die Art des Data Provider bereits im Vorfeld bekannt. Im Folgenden gibt es jedoch wesentliche Unterschiede je nach Art des Data Provider, die in den jeweiligen Prozessschritten beschrieben sind und vom Data Consumer berücksichtigt werden müssen.
_\[UC-07\]_	* Der Data Consumer erstellt eine Nachweisanfrage gemäß der XNachweis-Spezifikation ([XS-01](./AD-NOOTS-00_+Quellenverzeichnis.md#xs-01)) und übergibt diese an seinen Sicheren Anschlussknoten zum Abruf des Nachweises.	* Der Data Consumer muss je nach Art des Data Provider unterschiedliche Informationen in der Nachweisanfrage übermitteln: * nationaler Data Provider: z.B. Nachweistyp * Intermediäre Plattform: z.B. anfragendes Verfahren (Procedure) gemäß Anhang 2 der SDG-VO. Die Angabe der nachzuweisenden Tatsachen (Requirement) und des Ländercodes (CountryCode) pro Requirement ist gemäß EDM optional.	* Die Intermediäre Plattform bestimmt den Nachweistyp basierend auf "Procedure" und "Requirements". Detaillierte Informationen dazu sind im Grobkonzept Intermediäre Plattform ([AD-NOOTS-06](./AD-NOOTS-06_+Grobkonzept+Intermediaere+Plattform+_IP_.md)) verfügbar.
_\[UC-08\]_	* Der Sichere Anschlussknoten holt die Abrufberechtigung für den Nachweisabruf ein und fordert dazu ein Abruftoken von der Vermittlungsstelle an.	* Stellt die Vermittlungsstelle kein Abruftoken aus, d.h. liegt für diesen Nachweisabruf keine abstrakte Berechtigung vor, dann bricht der Sichere Anschlussknoten den Nachweisabruf ab.	* Die Vermittlungsstelle wird für alle Nachweisabrufe über das NOOTS eingebunden. In Fällen, in denen keine abstrakte Berechtigungsprüfung vorgeschrieben ist (z.B. Abruf ohne Verwendung der IDNr), stellt sie das Abruftoken pauschal aus, d.h. ohne Durchführung einer abstrakten Berechtigungsprüfung. In jedem Fall protokolliert sie den Nachweisabruf. * Weitergehende Informationen finden sich in dem Grobkonzept Vermittlungsstelle ([AD-NOOTS-08](./AD-NOOTS-08_+Grobkonzept+Vermittlungsstelle+_VS_.md)).
_\[UC-09\]_	* Der Sichere Anschlussknoten ermittelt die Verbindungsparameter des zuständigen Data Provider über die Registerdatennavigation.		* Eine ausführliche Beschreibung finden Sie im Grobkonzept Registerdatennavigation ([AD-NOOTS-07](./AD-NOOTS-07_+Grobkonzept+Registerdatennavigation+_RDN_.md)), Kapitel „8.2 Anwendungsfälle der Registerdatennavigation“.
_\[UC-10\]_	* Der Sichere Anschlussknoten führt den Nachweisabruf durch. Dazu fügt er das Abruftoken dem XNachweis-Request hinzu und versendet den XNachweis-Request sowie das IAM-Zugriffstoken an den Sicheren Anschlussknoten des Data Provider.
_\[UC-11\]_	* Der Sichere Anschlussknoten des Data Provider empfängt den XNachweis-Request. * Er validiert das Zugriffstoken und das Abruftoken. * Nach positivem Ergebnis gibt er den Request an den Data Provider weiter.	* Für die Prüfung des Abruftokens der Vermittlungsstelle prüft er zunächst die Echtheit des Tokens anhand der Siegelung und prüft anschließend, ob die Angaben im Abruftoken mit denen im XNachweis-Request übereinstimmen.	* Durch die Prüfung des Abruftokens bestätigt der Sichere Anschlussknoten des Data Provider die abstrakte Berechtigungsprüfung der Vermittlungsstelle. Dies ist notwendig, da sie keine Einsicht in die Nachrichteninhalte haben darf.
_Prozessvariante: Nationaler Data Provider_
_\[UC-12A\]_	* Der Data Provider prüft die Nachweisanfrage und stellt den Nachweis dem Data Consumer bereit.
_\[UC-13A\]_	* Falls der Data Consumer ein Onlinedienst ist, bietet er der Nutzerin oder dem Nutzer die Möglichkeit zur Preview an. Im Rahmen der Preview erfolgt die Prüfung des Nachweises durch die Nutzerin oder den Nutzer sowie die anschließende Freigabe für die weitere Verwendung.	* Bei einem Nachweisabruf durch ein Fachverfahren ist eine Preview nicht vorgesehen.
_Prozessvariante: Intermediäre Plattform in der Rolle Data Provider_
_\[UC-12B\]_	* Die Intermediäre Plattform in der Rolle als Data Provider benötigt weitere Daten von der Nutzerin oder dem Nutzer und meldet dies an den Data Consumer. Der Data Consumer leitet die Nutzerin oder den Nutzer auf eine Nutzeroberfläche der Intermediären Plattform (Evidence Provider Space) um. Die Intermediäre Plattform erfasst die erforderlichen Daten, ruft den Nachweis aus dem EU-Mitgliedstaat ab und speichert den Nachweis zwischen.		* Die Preview erfolgt durch den Evidence Provider des jeweiligen EU-Mitgliedstaates. * Weitergehende Informationen finden sich in dem Grobkonzept Intermediäre Plattform ([AD-NOOTS-06](./AD-NOOTS-06_+Grobkonzept+Intermediaere+Plattform+_IP_.md)).
_\[UC-13B\]_	* Der Data Consumer holt den zwischengespeicherten Nachweis von der Intermediären Plattform ab.		* Beim zweiten Aufruf der Intermediären Plattform erfolgt keine erneute Einbindung der Vermittlungsstelle, da diese beim vorhergehenden Aufruf _\[UC-12B\]_ bereits eingebunden wurde und insbes. eine Protokollierung für diesen Nachweisabruf durchgeführt hat.
_Ende Prozessvarianten_
_\[UC-14\]_	* Der Nachweis wird vom Data Consumer zur weiteren Verwendung übernommen.
_\[UC-15\]_	* Der Nachweisabruf ist abgeschlossen.

3.7 Querschnittliche Themen

3.7.1 Nachrichtenaustauschmuster

Nutzerinnen und Nutzer sollen Nachweisdaten gemäß den Anwendungsszenarien der SDG und der Registermodernisierung [IT-PLR-E-02] während des interaktiven Antragsprozesses nahtlos, beispielsweise als Anhang zu einem Online-Antrag oder zur automatischen Vorbefüllung eines Online-Antrags, nutzen können. Dafür muss der Prozess des Nachweisabrufs über das NOOTS Nachweise unmittelbar bereitstellen. NOOTS und EU-OOTS unterstützen diese Szenarien durch fachlich synchrone Nachweisabrufe, die nur wenige Sekunden dauern, sodass der Data Consumer direkt nach der Nachweisanfrage eine Antwort erhält.

Um jedoch auch Register als Data Provider an das NOOTS anschließen zu können, die aktuell nicht in der Lage sind, Nachweisdaten innerhalb weniger Sekunden bereitzustellen, wird zusätzlich ein fachlich asynchroner Nachweisabruf unterstützt. Bei diesem Verfahren kann die Bereitstellung eines Nachweises mehrere Minuten, Stunden oder sogar Tage dauern. In solchen Fällen erhält der Data Consumer die angefragten Nachweise zeitversetzt. Es ist wichtig zu beachten, dass die Komplexität und der Implementierungsaufwand für die sichere Zustellung und Fehlerbehandlung bei fachlich asynchronen Nachweisabrufen im Vergleich zu synchronen Abrufen deutlich höher sind. Dieses Verfahren dient daher als Übergangslösung, bis die Register in der Lage sind, Nachweise innerhalb weniger Sekunden bereitzustellen. Der fachlich asynchrone Nachweisabruf wird im NOOTS über einen Retry-Mechanismus umgesetzt.

Im Folgenden werden die Nachrichtenaustauschmuster beschrieben, die dem Nachrichtenaustausch bei fachlich synchronen und fachlich asynchronen Nachweisabrufen im NOOTS zugrunde liegen. Diese Muster beschreiben die Art und Weise, wie Nachrichten für den Nachweisabruf zwischen dem Data Consumer und dem Data Provider ausgetauscht werden.

In diesem Kapitel erfolgt die Betrachtung der Nachrichtenaustauschmuster aus der Perspektive eines Data Consumer und eines Data Provider über das Anschlussprotokoll der Sicheren Anschlussknoten des NOOTS. Die Sicheren Anschlussknoten kapseln dabei die Art und Weise, wie Nachrichten über das Transportprotokoll in der NOOTS Transportinfrastruktur (AD-NOOTS-19) übertragen werden.

Alle Nachweisabrufe über das NOOTS werden durch das Request-Response-Muster abgebildet. Gemäß der XNachweis-Spezifikation (XS-01) sendet der Data Consumer eine Nachweis-Anfrage (XNachweis-Request) an einen Data Provider, der diese Anfrage entgegennimmt und entweder mit einer Nachweis-Antwort (XNachweis-Response) oder einer Fehlermeldung (XNachweis-Error) antwortet.

3.7.1.1 Request-Response/Sync

Ein fachlich synchroner Nachweisabruf, bei dem der Nachweis sofort vom Data Provider bereitgestellt wird, wird durch das Request-Response-Muster in Kombination mit einem synchronen Kommunikationsprotokoll wie HTTP realisiert. Dabei werden die Nachweis-Anfrage und die Nachweis-Antwort innerhalb derselben Kommunikationsverbindung übertragen. Dieses Verfahren stellt sicher, dass die Nutzerinteraktion im Data Consumer so lange blockiert bleibt, bis die Antwort vorliegt. Gleichzeitig wird gewährleistet, dass ein Data Provider keine Nachweis-Antworten versenden kann, ohne zuvor eine entsprechende Nachweis-Anfrage erhalten zu haben.

Abb. 7: Nachrichtenmuster Request-Response/Sync für einen fachlich synchronen Nachweisabruf

Tab. 9: Prozessschritte für Nachrichtenmuster Request-Response/Sync

Prozessschritt	Beschreibung	Erläuterung
_\[MEP1-01\]_	* Ein Nachweisabruf wird im Data Consumer explizit durch eine Nutzerin oder ein Nutzer initiiert.
_\[MEP1-02\]_	* Der Data Consumer erstellt eine XNachweis-Anfrage und sendet diese unter Verwendung des synchronen Kommunikationsprotokolls über seinen Sicheren Anschlussknoten.	* Die Nutzerinteraktion im Data Consumer wartet auf die Antwort.
_\[MEP1-03\]_	* Der XNachweis-Request wird über das synchrone Kommunikationsprotokoll an den Data Provider über seinen Sicheren Anschlussknoten zugestellt.
_\[MEP1-04\]_	* Der Data Provider erzeugt innerhalb weniger Sekunden die XNachweis-Antwort mit Nachweisdaten oder alternativ eine Fehlermeldung. * Der Data Provider sendet über seinen Sicheren Anschlussknoten die XNachweis-Antwort mit Nachweisdaten oder alternativ die Fehlermeldung sofort in dem Response des synchronen Kommunikationsprotokolls.	* Die erwarteten Antwortzeiten für die Bereitstellung von Nachweisen durch den Data Provider sind als Qualitätsmerkmal "Antwortzeiten von Nachweisabrufen" im Konzept "Anschlusskonzept Data Provider (DP)" ([AD-NOOTS-02](./AD-NOOTS-02_+Anschlusskonzept+Data+Provider+_DP_.md)) definiert. * Bei einem technischen oder fachlichen Fehler wird nur ein XNachweis-Error ohne Nachweisdaten gesendet.
_\[MEP1-05\]_	* Der Data Consumer empfängt über seinen Sicheren Anschlussknoten in der Response des synchronen Kommunikationsprotokolls die XNachweis-Antwort mit Nachweisdaten oder alternativ die Fehlermeldung und verarbeitet die Daten.	* Die Nutzerinteraktion im Data Consumer wird fortgesetzt.

Die "Once-Only Technical System High Level Architecture" spezifiziert im Kapitel "7.2. Integration and Service Interaction Patterns", dass im EU-OOTS auch das Request-Response-Muster verwendet werden muss. Im Rahmen der FAQ "Is the eDelivery communication used in OOTS synchronous or asynchronous?" wird festgestellt, dass bei Nutzerinteraktionen eine fachlich synchrone Kommunikation verwendet werden soll, auch wenn das Transportprotokoll "eDelivery AS4 Profile" ausschließlich eine technische asynchrone Kommunikation unterstützt. Im EU-OOTS werden Nachweis-Anfragen und Nachweis-Antworten durch eine eindeutige Kennung miteinander korreliert und dadurch synchronisiert.

3.7.1.2 Request-Response/Sync mit erneutem Abruf (Retry)

Ein fachlich asynchroner Nachweisabruf, bei dem der Nachweis nicht sofort vom Data Provider bereitgestellt werden kann, wird durch einen erneuten Abruf (Retry) realisiert.

Der Data Consumer fordert zunächst über das Request-Response/Sync-Muster einen Nachweis an. Sollte der Data Provider nicht in der Lage sein, den Nachweis innerhalb der geforderten Antwortzeit zu erzeugen, sendet er eine XNachweis-Response mit einem Zeitpunkt ("ResponseAvailableDateTime"), zu dem der Nachweis verfügbar sein wird. Der Data Provider ist bestrebt, den Nachweis bis zu diesem Zeitpunkt verfügbar zu machen. Anschließend kann die Nutzerin oder der Nutzer den Nachweisabruf erneut über den Data Consumer initiieren.

Diese Nachrichtenaustauschmuster entspricht dem SDG-Mechanismus gemäß Artikel 15 Absatz 5 der Durchführungsverordnung (EU) 2022/1463, wenn zum Zeitpunkt des Austauschs über das OOTS noch keine Nachweise verfügbar sind. Dabei kann ein definierter Zeitpunkt für die zukünftige Bereitstellung des Nachweises durch den Data Provider angegeben werden.

Abb. 8: Nachrichtenmuster Request-Response mit erneutem Abruf (Retry)

Tab. 10: Prozessschritte Nachrichtenmuster Request-Response erneutem Abruf (Retry)

Prozessschritt	Beschreibung	Erläuterung
1.Schritt: Nachweisabruf mit Request-Response/Sync
_\[MEP2-01\]_	* Ein Nachweisabruf wird im Data Consumer explizit durch eine Nutzerin oder ein Nutzer initiiert.
_\[MEP2-02\]_	* Der Data Consumer erstellt eine XNachweis-Anfrage und sendet diese unter Verwendung des synchronen Kommunikationsprotokolls über seinen Sicheren Anschlussknoten
_\[MEP2-03\]_	* Der Data Provider empfängt über seinen Sicheren Anschlussknoten die XNachweis-Anfrage über das synchrone Kommunikationsprotokoll.
_\[MEP2-04\]_	* Der Data Provider sendet über seinen Sicheren Anschlussknoten eine XNachweis-Antwort mit einem Zeitpunkt ("ResponseAvailableDateTime"), zu dem der Nachweis verfügbar sein wird. * Der Data Provider initiiert die Bereitstellung des Nachweises zum definierten Zeitpunkt ("ResponseAvailableDateTime").	* Der Data Provider kann den Nachweis nicht innerhalb weniger Sekunden bereitstellen und veranlasst im Nachgang eine Vorbereitung des Nachweises für einen folgenden Abruf zu einem späteren Zeitpunkt.
_\[MEP2-05\]_	* Der Data Consumer empfängt über seinen Sicheren Anschlussknoten eine XNachweis-Antwort mit der Aufforderung zur erneuten Nachweisabfrage zum definierten Zeitpunkt ("ResponseAvailableDateTime") und teilt diesen ggf. der Nutzerin oder dem Nutzer mit.
2.Schritt: Erneuter Nachweisabruf mit Request-Response/Sync zum definierten Zeitpunkt
_\[MEP2-06\]_	* Die Nutzerin oder der Nutzer initiiert erneut den Nachweisabruf. * Der Data Consumer führt den erneuten Nachweisabruf über seinen Sicheren Anschlussknoten durch.	* Wurde der Nachweisabruf vom Nachweissubjekt über einen Onlinedienst oder die Intermediäre Plattform initiiert, dann ist hier eine erneute Nutzerinteraktion notwendig, insbes. da der Nachweis über die Preview freigegeben werden muss, bevor er im Onlinedienst verwendet werden darf. * Gemäß den Vorgaben im Rahmen der OZG-Umsetzung, z.B. Mindestanforderungen an „Einer für Alle“-Services, sollten Onlinedienste i.d.R. über eine Möglichkeit zum Unterbrechen und Abbrechen von Antragsprozessen verfügen, sodass keine erneute Eintragung der Daten durch die Nutzerin oder dem Nutzer erforderlich ist. * Erfolgt der Nachweisabruf über ein Fachverfahren, dann ist eine systemseitig automatisierte erneute Auslösung ohne Initiierung durch die Nutzerin oder dem Nutzer möglich. * In jedem Fall muss der Nachweisabruf selbst erneut begonnen werden, bspw. ist ein gültiges Zugriffstoken notwendig und die IDNr muss ggf. erneut ermittelt werden.
_\[MEP2-07\]_	* Der Data Provider empfängt über seinen Sicheren Anschlussknoten die erneute XNachweis-Anfrage.
_\[MEP2-08\]_	* Der Data Provider sendet über seinen Sicheren Anschlussknoten die XNachweis-Antwort an den Data Consumer.	* Der Nachweis sollte inzwischen vom Data Provider im Nachgang der ersten Nachweisanfrage (Prozessschritt _\[MEP2-04\])_ verfügbar gemacht worden sein.
_\[MEP2-09\]_	* Der Data Consumer empfängt über seinen Sicheren Anschlussknoten die XNachweis-Antwort.

Zur Vollständigkeit sei darauf hingewiesen, dass neben dem Retry-Verfahren auch ein sogenanntes Callback-Verfahren (auch bekannt als One-Way/One-Way) zur Realisierung einer asynchronen Kommunikation denkbar ist. Hierbei sendet das abrufende System die Anfrage an das bereitstellende System, welches die Anfrage zunächst nur bestätigt. Zu einem späteren Zeitpunkt sendet das bereitstellende System die Antwort aktiv zurück an das anfragende System. Dieses Verfahren erfordert zusätzliche Mechanismen zur Fehlerbehandlung und zur Gewährleistung einer sicheren Zustellung von Nachrichten, insbesondere im Hinblick auf mögliche Nachrichtenverluste. Dies führt zu einer erhöhten Komplexität und einem größeren Implementierungsaufwand. Das Callback-Verfahren wird im NOOTS nicht verwendet.

3.8 Ausblick und Weiterführende Aspekte

Die konzeptionelle Gestaltung der High-Level-Architecture ist fortlaufend und wird in die nächsten Iterationen dieser Architekturdokumentation einfließen. Dabei werden die im Folgenden beschriebenen weiterführenden Aspekte berücksichtigt.

Tab. 11: Weiterführende Aspekte

Bezeichnung	Beschreibung
Szenarien registerbasierter Zensus und wissenschaftliche Zwecke	Die Szenarien zur Nutzung des NOOTS für den registerbasierter Zensus und wissenschaftliche Zwecke müssen analysiert und ausgearbeitet werden.
Technisches Logging und fachliche Protokollierung im NOOTS (317)	Übersicht über das technische Logging und die fachliche Protokollierung im NOOTS-System

3.9 Änderungsdokumentation

Tab. 12: Änderungsdokumentation

	Release-Versionen	Kapitel	Beschreibung der Änderung	Art der Änderung	Priorisierung/major changes	Quelle der Änderung
1	Q4/2023	Anforderungen an das NOOTS-Gesamtsystem	* funktionale und nicht-funktionale Anforderungen an das NOOTS-Gesamtsystem aufgenommen	neuer Inhalt	:star:	NOOTS-Board
2	Q4/2023	Architekturzielbilder und Umsetzungsstufen des NOOTS	* Inhalte des übergreifenden Konzepts Umsetzungsstufen in HLA integriert (siehe Kapitel "Architekturzielbilder und Umsetzungsstufen des NOOTS")	neuer Inhalt		Komponententeam
3	Q4/2023	Architekturdokumentation NOOTS	* Bezeichnung von Dokumenten der AD-NOOTS und Darstellung zur Dokumentenstruktur der AD-NOOTS angepasst * Bezeichnung Umsetzungskonzept für alle Konzepte, die durch assoziierte Vorhaben oder Umsetzungsprojekte erstellt werden eingeführt * Grafik zur Dokumentenstruktur angepasst, um Abgrenzung zwischen den unterschiedlichen Dokumententypen zu verdeutlichen	Aktualisierung	:star:	externer Review anderer PBs
4	Q4/2023	Ausblick und weiterführende Aspekte	* offene Punkte zur weiteren Analyse und Bearbeitung identifiziert * Voraussetzungen für nicht-interaktive Nachweisabrufe im NOOTS * Begriffsschärfung bzgl. Data Consumer / Data Provider / Register / Nachweis * Ergänzung von Informationen bzgl. Reifegradmodell & Fachdatenkonzept	Aktualisierung		externer Review anderer PBs
5	Q1/2024	Nachrichtenaustauschmuster	* neues Kapitel zur Beschreibung der Nachrichtenaustauschmuster bei fachlich synchronem und fachlich asynchronem Nachweisabruf ergänzt	neuer Inhalt		Komponententeam
6	Q1/2024	Umsetzungsstufen des Architekturzielbilds des NOOTS	* Grafiken zu Umsetzungsstufen des Architekturzielbilds des NOOTS aktualisiert: * sichere Anschlussknoten ergänzt, V-PKI entfernt, Verfügbarkeit IAM für Behörden bereits in 2025	Aktualisierung	:star:	Grobkonzept Transportinfrastruktur, Grobkonzept IAM für Behörden
7	Q1/2024	alle	* Verwendung der Begriffe Data Consumer und Data Provider an aktuellen Stand der Definitionen angepasst: * Data Consumer: Ein NOOTS-Teilnehmer mit einer Behördenfunktion zum Abruf von Nachweisen. Der Fachverantwortliche eines Data Consumer muss beim Nachweisabruf ermittelbar sein. * Data Provider: Ein NOOTS-Teilnehmer zur Lieferung von Nachweisen einer nachweisausstellenden Registerstruktur. Eine nachweisliefernde Stelle ist für die Lieferung von Nachweisen eines Data Provider zuständig.	Korrektur, Aktualisierung		Anschlusskonzept Data Consumer, Anschlusskonzept Data Provider
8	Q1/2024	Anwendungsfälle des NOOTS	* Aktualisierung der Definitionen zum interaktiven und nicht-interaktiven Nachweisabruf: * interaktiver Nachweisabruf: Nachweisabruf im Dialog mit einer Person, die zu sich selbst oder in Vertretung des Nachweissubjekts zu diesem einen Nachweis abruft. * nicht-interaktiver Nachweisabruf: Nachweisabruf ohne Beteiligung des Nachweissubjekts oder seines Vertreters.	Aktualisierung		NOOTS-Board
9	Q1/2024	Anwendungsfälle des NOOTS	* Aktualisierung der Grafiken und Beschreibungen zu den Anwendungsfällen des NOOTS * Die Nutzung der Vermittlungsstelle erfolgt für alle Nachweisabrufe im NOOTS. Eine abstrakte Berechtigungsprüfung wird nur durchgeführt, wenn dies rechtlich erforderlich ist; andernfalls wird ein Token pauschal ausgestellt.	Aktualisierung	:star:	Grobkonzept Vermittlungsstelle
10	Q2/2024	alle	* Kapitelstruktur wurde im Kontext der Harmonisierung der AD-NOOTS inkl. der Orientierung an der Arc42-Vorlage angepasst	Aktualisierung		Konsultationsprozess, PB NOOTS
11	Q2/2024	Anwendungsfall 2: Nicht-interaktiver Nachweisabruf über das NOOTS	* nicht-interaktiver Nachweisabruf von Unternehmen im Sinne von § 3 Abs. 1 UBRegG wurde in der Beschreibung und Darstellung ergänzt	Ergänzung		Komponententeam, Konsultationsprozess
12	Q2/2024	Datenflüsse im NOOTS	* Grafik zur Darstellung der Datenflüsse beim Nachweisabruf für natürliche Personen unter Verwendung der IDNr wurde aufgenommen, um übermittelte Attribute zwischen Komponenten zu konkretisieren	neuer Inhalt	:star:	Konsultationsprozess, NOOTS-Board
13	Q2/2024	Umsetzungsstufen des Architekturzielbilds des NOOTS	* Grafik zu den Umsetzungsstufen des Architekturzielbilds des NOOTS wurde aktualisiert: * relevante XÖV-Standards ergänzt * Sichere Anschlussknoten der NOOTS-Komponenten dargestellt * Funktion der NOOTS-Komponenten zur Unterstützung der Kommunikation verdeutlicht * Datenflüsse des Datenschutzcockpits ergänzt * Legende ergänzt	Aktualisierung	:star:	Konsultationsprozess, PB NOOTS
14	Q2/2024	Anwendungsfälle des NOOTS	* Grafik und Beschreibung zu den Anwendungsfällen des NOOTS wurde aktualisiert: * Prozess zum Abruf eines Zugriffstokens (IAM für Behörden) ergänzt * zwei Aufrufe der Registerdatennavigation * Sichere Anschlussknoten von DC, DP und NOOTS-Komponenten dargestellt	Aktualisierung	:star:	Grobkonzept IAM für Behörden, Grobkonzept Registerdatennavigation, Grobkonzept Transportinfrastruktur
15	Q2/2024	Ziele des Dokuments	* Grafik zur Dokumentenstruktur der AD-NOOTS wurde aktualisiert: * High-Level-Architecture Registermodernisierung und übergreifendes Konzept Zertifikate entfernt, da Dokumente nicht (mehr) genutzt werden	Aktualisierung		PB NOOTS
16	Q3/2024	Ziele des Dokuments	* Grafik zur Dokumentenstruktur der AD-NOOTS wurde aktualisiert: * übergreifendes Konzept IT-Sicherheit und Datenschutz sowie übergreifendes Konzept Betrieb entfernt, da Dokumente nicht (mehr) genutzt werden	Aktualisierung		PB NOOTS
17	Q3/2024	Abstract	* Aktualisierung des Abstracts gem. der übergreifenden Anforderungen der AD-NOOTS	Aktualisierung		PB NOOTS
18	Sprint 2 (28.10 - 22.11.24)	Nachweisabruf	* Konsolidierung der Anwendungsfälle: Vereinheitlichung des Prozessmodells und der Prozessbeschreibung zum Nachweisabruf über das NOOTS * vorherige Darstellung der Anwendungsfälle 1 bis 4 wurde durch einen übergreifenden Nachweisabrufprozess des NOOTS ersetzt	Aktualisierung	:star:	PB NOOTS
19	Sprint 3 (25.11 - 20.12.24)	Allgemein	* NOOTS-Komponente IDM für Unternehmen wurde aufgrund einer fehlenden Rechtsgrundlage im UBRegG entfernt.	Aktualisierung		PB NOOTS
20	Sprint 3 (25.11 - 20.12.24)	Datenflüsse im NOOTS	* Entfernen der SAKs bei den zentralen NOOTS-Komponenten.	Aktualisierung		PB NOOTS, Konsultationsprozess
21	Sprint 3 (25.11 - 20.12.24)	Nachrichtenaustauschmuster	* Änderung der Bezeichnung des fachlich asynchrone Nachweisabrufs von Request-Response/Sync mit Polling\ zu Request-Response/Sync mit erneutem Abruf (Retry), um herauszustellen, dass der erneute Nachweisabruf aktiv durch den Data Consumer initiiert werden muss.	Aktualisierung		PB NOOTS
22	Sprint 3 (25.11 - 20.12.24)	Architekturzielbild des NOOTS	* Die Umsetzungsstufen 2023, 2025 und 2028 des Architekturzielbilds des NOOTS wurden entfernt. Es wird ein Architekturzielbild des NOOTS dargestellt. * Die SAKs der NOOTS-Komponenten wurden im Architekturzielbild des NOOTS entfernt. * Das IDM für Unternehmen wurde mit dem Hinweis vermerkt, dass es aufgrund fehlender Rechtsgrundlage derzeit nicht umgesetzt wird. * Die SAK-APIs wurden als Standard im Architekturzielbild ergänzt.	Aktualisierung	:star:	PB NOOTS
23	Sprint 3 (25.11 - 20.12.24)	Ziele des Dokuments	* Die Dokumentenstruktur der AD-NOOTS wurde aktualisiert: * Begleitdokumente als neuer Dokumententyp aufgenommen * Whitepaper Zero Trust als Begleitdokument ergänzt * SAK-APIs als Standard ergänzt	Aktualisierung		PB NOOTS
24	Sprint 4 (01.01. - 31.01.25)	6.3.3 Nachweisabrufprozess des NOOTS, 7.1.1 Request-Response/Sync, 7.1.2 Request-Response/Sync mit erneutem Abruf (Retry)	* Anpassung der Beschreibung der Prozessschritte, um die Nutzung des Sicheren Anschlussknotens zur Kommunikation zwischen Data Consumer und Data Provider zu verdeutlichen.	Aktualisierung		PB NOOTS
25	Sprint 4 (01.01. - 31.01.25	Anforderungen NOOTS-654 NOOTS-655	* Anlass der Änderung: Im Hinblick auf entsprechende Anpassungen in der HLA wurden die Anforderungen umformuliert. * Die Unterscheidung "interaktiv" und "nicht-interaktiv" ist entfallen, die Anforderung NOOTS-654 wurde umformuliert und deckt nun alle Nachweisabrufe ab. Die Anforderung NOOTS-655 wurde gestrichen.	Aktualisierung		PB NOOTS
26	Sprint 5 (03.02. - 28.02.25	Anforderungen NOOTS-1274	* Anforderung NOOTS-1274 ergänzt.	Aktualisierung		PB NOOTS