7. Grobkonzept Registerdatennavigation (RDN)

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

7.1 Abstract

Die Registerdatennavigation (RDN) ist eine zentrale Komponente des NOOTS und unterstützt Data Consumer (DC) dabei, den zuständigen Data Provider (DP) für den Abruf eines nationalen Nachweises oder die zuständige Intermediäre Plattform (IP) für den Abruf eines EU-Nachweises zu ermitteln. Die Beschreibung der Prozesse zur Erfassung und Pflege der von der RDN benötigten Daten ist nicht Teil dieses Konzepts, sondern wird im Fachdatenkonzept (FDK) behandelt.

Dieses Dokument richtet sich an IT-Verantwortliche der öffentlichen Verwaltung mit Verantwortung für die Registerdatennavigation, mit Verantwortung für Data Consumer, die die RDN benötigen, um zuständige Data Provider zu ermitteln oder mit Verantwortung für Data Provider, die wissen müssen, wie ihre Nachweisangebote den Data Consumern bereitgestellt werden. 

Das Grobkonzept Registerdatennavigation verweist auf weitere NOOTS-Dokumente, in denen zusätzliche Informationen zu den jeweiligen Themen zu finden sind.

7.2 Einführung und Ziele

7.2.1 Überblick

Die Registerdatennavigation unterstützt den Data Consumer, indem sie Informationen über den zuständigen Data Provider ermittelt und bereitstellt sowie die Auflösung eines Identifiers (Service-ID) in technische Verbindungsparameter anbietet.

7.2.2 Ziele der Registerdatennavigation

Im Folgenden sind die Ziele der Registerdatennavigation beschrieben und durch welche Ablaufszenarien der Registerdatennavigation sie umgesetzt werden.

Tab. 1: Ziele der Registerdatennavigation

7.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.

Tab. 2: Begriffsdefinitionen

7.3 Randbedingungen

7.3.1 Technische / Organisatorische Randbedingungen

Das Zielbild der Lösungsarchitektur wird von verschiedenen übergreifenden organisatorischen und technischen Randbedingungen eingegrenzt.

7.3.1.1 Intermediäre Plattform agiert innerhalb des NOOTS als Data Consumer bzw. Data Provider

Bei grenzüberschreitenden EU-Nachweisabrufen tritt die Intermediäre Plattform innerhalb des NOOTS in der Rolle des Data Consumer bzw. Data Provider auf.

• Beim Abruf von nationalen Nachweisen aus dem EU-Ausland agiert die Intermediäre Plattform als Data Consumer und nutzt die Registerdatennavigation zur Ermittlung des zuständigen Data Provider.
• Beim Abruf von EU-Nachweisen aus Deutschland nutzt der nationale Data Consumer die Registerdatennavigation, um die für ihn zuständige Intermediäre Plattform zu ermitteln. Die Intermediäre Plattform agiert in der Rolle eines Data Provider.

Der Begriff "Data Consumer" bezeichnet also sowohl nationale Data Consumer (Onlinedienste und Fachverfahren) als auch eine in der Rolle eines Data Consumer agierende Intermediäre Plattform.

Analog bezeichnet der Begriff "Data Provider" sowohl nationale Data Provider als auch eine in der Rolle eines Data Provider agierende Intermediäre Plattform.

7.3.1.2 Sichere Anschlussknoten

Ein Sicherer Anschlussknoten (SAK) ist eine zentral bereitgestellte NOOTS-Komponente, die jedoch dezentral im Verantwortungsbereich der NOOTS-Teilnehmer betrieben wird. Er ermöglicht den NOOTS-Teilnehmern ü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. Der Einsatz eines Sicheren Anschlussknoten ist für Data Consumer und Data Provider verpflichtend.

Im Rahmen des Nachweisabrufs übernimmt der Sichere Anschlussknoten für den Data Consumer bestimmte Aufgaben, u.a. die Auflösung der Service-ID in die technischen Verbindungsparameter. Dies ermöglicht eine Abstraktion des Transportverfahrens und damit eine Stabilität des NOOTS-Anschlussprotokolls für den Data Consumer (vgl. 6.3 Die Ermittlung der Zuständigkeit und die Auflösung der technischen Verbindungsparameter erfolgt in zwei getrennten Schritten).

7.3.1.3 Lose Kopplung zum Transportverfahren, um einen zukünftigen Wechsel nicht zu erschweren

Die Transportinfrastruktur des NOOTS soll einen zukünftigen Wechsel des zugrundliegenden Transportverfahrens ermöglichen. Deshalb muss die Registerdatennavigation grundsätzlich in der Lage sein, Verbindungsparameter für verschiedene Transportverfahren zu ermitteln. Im Once-Only-Diensteverzeichnis können für einen Once-Only-Dienst mehrere Verbindungsparameter eingepflegt werden, und zwar genau ein Parametersatz je unterstütztem Transportverfahren. Die Verbindungsparameter müssen mit Gültigkeitszeiträumen versehen werden. Für einen Once-Only-Dienst darf zu jedem Zeitpunkt nur genau ein Satz von Verbindungsparametern gültig sein.

7.4 Annahmen

Tab. 3: Annahmen

7.4.1 Abgrenzungen

Die Registerdatennavigation unterstützt nicht:

• die Bereitstellung von Codelisten für Onlinedienste
• Codelisten werden üblicherweise über Repositorien zur Verfügung gestellt (bspw. für den ARS (XS-08))
• unter Umständen werden neue Codeliste im Kontext der Definition der Zuständigkeiten entstehen (vgl. Fachdatenkonzept)
• die Bereitstellung von Mapping-Funktionen (bspw. PLZ & Ort zu ARS)
• Hier kann auf bestehende Angebote zurückgegriffen werden (bspw. vom Bundesamt für Kartographie und Geodäsie)
• die Pflege von Zuständigkeiten, Nachweisangeboten, und Verbindungsparametern
• Siehe 3.3.1 Nachweiskatalog
• Siehe 3.3.2 Once-Only-Diensteverzeichnis (OODV).

Hinweis

Die Details zu den im Fachdatenkonzept beschriebenen Systemen Nachweiskatalog und OODV sowie die damit verbundenen Einzelheiten zu Datenmodell und Schnittstellen befinden sich derzeit in Klärung. Der aktuelle Abstimmungsstand wird im Folgenden dargestellt. Dies gilt auch für alle Bezüge im gesamten Dokument.

7.4.1.1 Nachweiskatalog

Die Registerdatennavigation benötigt für die Bereitstellung ihrer Funktionalitäten Daten aus dem Nachweiskatalog. Die Registerdatennavigation stellt selbst keinen Zugang zur Pflege der Daten im Nachweiskatalog bereit (vgl. 6.1 Die von der Registerdatennavigation benötigten (fachlichen) Daten werden außerhalb der RDN gepflegt und importiert).

Für die Sicherstellung der Funktionsfähigkeit der Registerdatennavigation ergeben sich die folgenden Anforderungen an das Fachdatenkonzept (bzw. dessen Komponenten).

Die Anforderungen an den Nachweiskatalog werden künftig nur noch im Anforderungsmanagement von PB Register gepflegt. Sobald die Anforderungen dort final abgenommen sind, können sie hier entfernt werden, um eine doppelte Pflege zu vermeiden.

Tab. 4: Anforderungen der Registerdatennavigation an den Nachweiskatalog

7.4.1.2 Once-Only-Diensteverzeichnis (OODV)

Für die Verwaltung der Verbindungsparameter der Once-Only-Dienste wird das Once-Only-Diensteverzeichnis (OODV) eingerichtet. Dort erfolgt die Zuordnung der notwendigen technischen Angaben für die Kommunikation (bspw. Endpunkt-URL) zu den stabilen Identifiern (Service-IDs). Für jeden Once-Only-Dienst wird mindestens ein Satz von Verbindungsparametern benötigt. Für die Unterstützung verschiedener Transportverfahren ist es möglich, jeweils einen eigenen Verbindungsparametersatz je Transportverfahren anzugeben. 

Den Mitarbeitenden der öffentlichen Verwaltung soll über eine einheitliche Portalseite eine einfache Pflege der Daten des Nachweiskatalogs, der Registerlandkarte und des OODV ermöglicht werden. Dieses Ziel und weitere Gründe haben zu der Entscheidung geführt, von einer Erweiterung des DVDV für weitere Transportverfahren abzusehen (vgl. 6.4 Keine Nutzung des DVDV).

Die Registerdatennavigation wird diese Daten über eine Schnittstelle des OODV abrufen.

Für die Sicherstellung der Funktionsfähigkeit der Registerdatennavigation ergeben sich die folgenden Anforderungen an das Once-Only-Diensteverzeichnis (OODV).

Die Anforderungen an das OODV werden mittelfristig nur noch im Anforderungsmanagement von PB Register gepflegt. Sobald die Anforderungen dort final abgenommen sind, können sie hier entfernt werden, um eine doppelte Pflege zu vermeiden.

Tab. 5: Funktionale Anforderungen der Registerdatennavigation an das Once-Only-Diensteverzeichnis (OODV)

Tab. 6: Nichtfunktionale Anforderungen der Registerdatennavigation an das Once-Only-Diensteverzeichnis (OODV)

7.5 Kontextabgrenzung

7.5.1 Fachlicher Kontext

Abb. 1: Fachlicher Kontext der Registerdatennavigation

NOOTS

Die Registerdatennavigation ist eine zentrale Komponente des NOOTS. Sie übernimmt zwei wesentliche Aufgaben: Zum einen ermittelt sie für den Data Consumer den zuständigen Data Provider für einen Nachweis, und zum anderen stellt sie die Verbindungsparameter für den zuständigen Data Provider bereit. Dadurch wird die Registerdatennavigation an zwei Stellen in den Ablauf eines Nachweisabrufs eingebunden.

• Zunächst meldet sich der Data Consumer über seinen Sicheren Anschlussknoten beim IAM für Behörden am NOOTS an. Nach der erfolgreichen Anmeldung erhält er ein Zugriffstoken, das die Kommunikation mit anderen NOOTS-Komponenten ermöglicht. Dieses Zugriffstoken enthält u. a. die Komponenten-ID des Data Consumer sowie seinen Verwaltungsbereich.
• Der Data Consumer ermittelt über den Sicheren Anschlussknoten und mithilfe des Zugriffstokens über die Registerdatennavigation den zuständigen Data Provider (beim nationalen Nachweisabruf inklusive Nachweisangebot) sowie die zugehörige Service-ID.
• Der Data Consumer initiiert anschließend den Nachweisabruf über den Sicheren Anschlussknoten und übermittelt dabei unter anderem die relevanten Informationen zum zuständigen Data Provider sowie die zugehörige Service-ID. Der Sichere Anschlussknoten des Data Consumer ruft daraufhin Schnittstellen verschiedener Systeme auf:
• Falls erforderlich, erfolgt eine abstrakte Berechtigungsprüfung, bei der die Informationen zum zuständigen Data Provider an die Vermittlungsstelle weitergeleitet werden.
• Auf Basis der Service-ID ermittelt die Registerdatennavigation die Verbindungsparameter für den Sicheren Anschlussknoten des zuständigen Data Provider.
• Abschließend erfolgt der eigentliche Nachweisabruf über den Sicheren Anschlussknoten des zuständigen Data Provider.

Datenimport

Damit die Registerdatennavigation den zuständigen Data Provider ermitteln und die Service-ID auflösen kann, muss sie Zugriff auf die dafür notwendigen Informationen haben. Diese ruft sie aus vorgelagerten Systemen ab und hält sie dann in einem lokalen Datenbestand.

• Die Informationen zu Zuständigkeiten der Data Provider ruft sie aus dem Nachweiskatalog ab. Hier ist notwendig, dass sich die erhaltenen Data Provider den im IAM für Behörden registrierten IT-Komponenten eindeutig zuordnen lassen (mittels ihrer Komponenten-ID).
• Die Informationen zur Auflösung der Service-ID bezieht sie aus dem Once-Only-Diensteverzeichnis. Auch hier ist eine Zuordenbarkeit von Nachweisangebot der Data Provider zu ihren Verbindungsparametern notwendig (mittels der Service-ID).

7.5.2 Technischer Kontext

Die folgende Abbildung veranschaulicht im technischen Kontext die Kommunikationsbeziehungen der Registerdatennavigation zu ihren direkt verbundenen Systemen.

Abb. 2: Technischer Kontext der Registerdatennavigation

Die technischen Kommunikationsbeziehungen aus der Abbildung werden in der folgenden Tabelle erläutert.

Tab. 7: Übersicht Technischer Kontext der Registerdatennavigation

7.6 Anforderungen

7.6.1 Funktionale Anforderungen

In diesem Kapitel werden die funktionalen Anforderungen an die Registerdatennavigation beschrieben.

Tab. 8: Funktionale Anforderungen Registerdatennavigation

7.6.2 Nicht-Funktionale Anforderungen

In diesem Kapitel werden die nicht-funktionalen Anforderungen an die Registerdatennavigation beschrieben.

Tab. 9: Nicht-funktionale Anforderungen Registerdatennavigation

7.7 Lösungsstrategie

Im Folgenden sind die wesentlichen Architekturentscheidungen und Lösungsansätze der Registerdatennavigation dargestellt.

7.7.1 Die benötigten Daten werden außerhalb der Registerdatennavigation gepflegt und von ihr importiert

Die Daten, die die Registerdatennavigation benötigt (Angaben zu Nachweistypen, Registertypen, Zuständigkeiten von Data Providern, Verbindungsparameter der Data Provider, ...) werden nicht über die Registerdatennavigation selbst gepflegt, sondern von ihr aus anderen Systemen importiert. Die Gründe dafür sind vielfältig.

1. Pflege von Informationen zu den Registern an einer Stelle
2. Die Angaben zu angebotenen Nachweistypen, Zuständigkeiten, usw. sind fachlich eng mit den Informationen zu Registern verwandt, die über die Registerlandkarte sowie im Kontext des Fachdatenkonzepts erhoben werden. Eine gemeinsame Pflege ist aufgrund dieser Nähe sinnvoll, da die Daten so in einem gemeinsamen Kontext und in ihrer fachlichen Verbindung gepflegt werden können.
3. Hohe Anforderungen an die Registerdatennavigation bzgl. Verfügbarkeit
4. Die Registerdatennavigation ist für die Funktionsfähigkeit des NOOTS von herausgehobener Bedeutung und unterliegt deshalb hohen Anforderungen an die Verfügbarkeit. Die Pflege der Daten in einem separaten System wirkt sich positiv auf Komplexität und Fehleranfälligkeit und somit auf Ausfallsicherheit und Verfügbarkeit aus, da die Registerdatennavigation nur ihre Kernfunktionen umsetzen muss.

7.7.2 Die Registerdatennavigation wird beim Abruf von EU-Nachweisen durch nationale Data Consumer eingesetzt, um die zuständige Intermediäre Plattform zu ermitteln

Nationale Data Consumer wenden sich an eine Intermediäre Plattform des NOOTS, um Nachweise aus dem EU-Ausland abzurufen. Aus Sicht des Data Consumer agiert die Intermediäre Plattform so als Data Provider. Um das Risiko der Profilbildung zu verringern, ist vorgesehen, dass eine Intermediäre Plattform je Verwaltungsbereich etabliert wird und dass ein nationaler Data Consumer sich an die Intermediäre Plattform wendet, die zu seinem Verwaltungsbereich gehört.

Bei einem Abruf von EU-Nachweisen sind die verfügbaren Nachweistypen weder der Intermediären Plattform noch der Registerdatennavigation bekannt, da diese erst zur Laufzeit von der Intermediären Plattform ermittelt werden. Folglich kann für eine Intermediäre Plattform in der Rolle eines Data Provider auch kein Nachweisangebot definiert werden.

In der Registerdatennavigation werden die vorgenannten Besonderheiten im Datenmodell (vgl. auch 7.1 Datenmodell) und in einer eigenen Schnittstelle (vgl. 7.2.5.2 Schnittstelle für die Zuständigkeitsermittlung einer Intermediären Plattform) berücksichtigt.

7.7.3 Die Ermittlung der Zuständigkeit und die Auflösung der technischen Verbindungsparameter erfolgt in zwei getrennten Schritten

Die Registerdatennavigation liefert dem Data Consumer über seinen Sicheren Anschlussknoten in einem ersten Schritt den zuständigen Data Provider mit seinem Nachweisangebot und der zugehörigen Service-ID. In einem folgenden Aufruf löst die Registerdatennavigation die Service-ID für den Sicheren Anschlussknoten des Data Consumer auf und liefert dazu die Verbindungsparameter des Once-Only-Dienstes. Dieses Vorgehen ist ähnlich einer DNS-Auflösung zu IP-Adressen (DNS-Lookup) und in verschiedenen Motivationen begründet.

• Es ermöglicht eine Kapselung der technischen Verbindungsparameter von den fachlich motivierten Service-IDs. Der Data Consumer selbst kommt nur mit den Service-IDs in Berührung und muss keine technischen Parameter verarbeiten, da die Auflösung der Service-ID im Sicheren Anschlussknoten erfolgt. Dies verringert die Komplexität für den Data Consumer und führt darüber hinaus zu einer Reduktion des Fehler- und Missbrauchspotentials.
• Die Service-ID zu einem Nachweisangebot eines Data Provider wird einmal festgelegt und bleibt dann stabil. Diese Stabilität der Service-ID auch bei Änderung der technischen Verbindungsparameter trägt ebenfalls zur Verringerung des Fehlerrisikos bei.
• Die Service-ID ist ein technologieunabhängiger Identifier. Dies ermöglicht es, mehrere Transportverfahren bzw. den Wechsel des Transportverfahrens zu unterstützen, da vom jeweiligen Transportverfahren abstrahiert wird und auch die API des Sicheren Anschlussknotens so für den Data Consumer stabil bleibt.

7.7.4 Keine Nutzung des DVDV

Das Deutsche Verwaltungsdiensteverzeichnis (DVDV) ist eine Infrastrukturkomponente für die Adressierung automatisierter Dienste der öffentlichen Verwaltung. Im Rahmen der Konzeption der Registerdatennavigation wurde eine Wiederverwendbarkeit geprüft und schlussendlich verworfen. Gründe dafür waren u.a. die fehlende Eignung des DVDV für die Zuständigkeitsinformationen, die bei der Registerdatennavigation im Mittelpunkt stehen, die Anforderungen an Netzanschlüsse (NdB, ...), sowie die Zielsetzung des Once-Only-Diensteverzeichnisses, über eine einheitliche Portalseite verfügbar zu sein und für die Mitarbeiter der öffentlichen Verwaltung eine einfache Pflege im Kontext der Registerinformationen zu ermöglichen.

7.7.5 Zuständigkeitsbestimmung und Zuständigkeit

Ein Nachweistyp ist über genau einen Registertyp abrufbar (sachliche Zuständigkeit). Für einen Registertyp bestimmt sich die örtliche Zuständigkeit eines Data Provider eindeutig anhand der Zuständigkeitsbestimmung zu diesem Registertyp. Insbesondere gilt (vgl. auch 7.1 Datenmodell):

• Die Zuständigkeitsbestimmung ist die Abstraktion eines Regelwerks zur Ermittlung des zuständigen Data Provider für den Abruf eines Nachweises in Abhängigkeit von Angaben zum Nachweissubjekt. 
• Eigenschaft der Zuständigkeitsbestimmung sind v.a. ihre zugehörigen Zuständigkeitsparameter (d.h. welche Angaben zur Ermittlung der Zuständigkeit notwendig sind). Weitere sinnvolle Eigenschaften können ein sprechender Name sowie eine kurze Beschreibung sein, diese sind aus Perspektive der Registerdatennavigation aber nicht von Bedeutung.
• Eine Zuständigkeitsbestimmung kann eine beliebige, aber fixe Anzahl an Zuständigkeitsparametern haben.
• Eine Zuständigkeitsbestimmung ohne Zuständigkeitsparameter ist möglich, wenn ein Nachweistyp von genau einem Data Provider geliefert wird (wie das bei zentralen Registern der Fall ist).
• Ebenso ist eine Zuständigkeitsbestimmung mit mehreren Zuständigkeitsparametern möglich, wenn mehrere Angaben notwendig sind, um den zuständigen Data Provider zu bestimmen. Zuständigkeitsparameter können kontextbezogen (z.B. relevant für bestimmte Bundesländer) sein.
• Die konkrete örtliche Zuständigkeit eines DP wird durch Zuständigkeitswerte festgelegt. Diese sind die konkreten Kombinationen von Ausprägungen ihrer Zuständigkeitsparameter. Jeder Zuständigkeitswert (n-Tupel, wobei n die Anzahl der Zuständigkeitsparameter ist) ist einem Data Provider zugeordnet und stellt so eine Zuständigkeit dar.
• Anhand der Zuständigkeitswerte ermittelt die Registerdatennavigation aus den vom Data Consumer über seinen Sicheren Anschlussknoten übergebenen konkreten Ausprägungen der Zuständigkeitsparametern (i.S.v. beim Aufruf übergebenen Werten) denjenigen Data Provider, dem dieser Zuständigkeitswert (als n-Tupel, d.h. genau diese Kombination von Ausprägungen der Zuständigkeitsparameter) zugeordnet ist.

Beispiel 1: Für eine Zuständigkeitsbestimmung "Amtlicher Regionalschlüssel" ist der Zuständigkeitsparameter "ARS" (ein 1-Tupel). Die Zuständigkeit von Data Providern wird durch ihre Zuordnung zu konkreten amtlichen Regionalschlüsseln ("Zuständigkeitswerte") festgelegt.

Beispiel 2: Für eine Zuständigkeitsbestimmung "Hochschulen" könnten die Zuständigkeitsparameter "Bundesland" und "Name der Hochschule" festgelegt werden. Zuständigkeitswerte wären gültige n-Tupel dieser beiden Parameter, bspw. ("Bayern", "Hochschule für Fernsehen und Film München") oder ("Hamburg", "Hochschule für Angewandte Wissenschaften Hamburg"). In diesem Beispiel wurden zwei Parameter gewählt, weil Bildung in die Zuständigkeit der Länder fällt.

Anmerkung: Bisher sind wenige konkrete Beispiele für Zuständigkeitsbestimmungen bekannt (u.a. der ARS). Da die Menge und Ausprägung weiterer Zuständigkeitsbestimmungen aktuell nicht bekannt sind, beschränken wir uns in dieser Version des Konzepts auf die Zuständigkeitsbestimmung anhand von n-Tupeln. Andererseits möchten wir nicht ausschließen, dass für weitere zukünftig noch bekannt werdende Zuständigkeitsbestimmungen dieses Konzept noch angepasst werden muss. 

7.7.6 Technisches Logging

Das NOOTS muss eine effiziente Lokalisierung und Analyse von Fehlern unterstützen. Dazu ist erforderlich, dass der Datenfluss eines Nachweisabrufs anhand eines Identifikators durch die verschiedenen NOOTS-Komponenten nachverfolgt werden kann. Die Registerdatennavigation führt zu diesem Zweck ein technisches Logging der Aufrufe durch. Als Identifikator zur Nachverfolgbarkeit wird die Trace-ID aus der Anfrage verwendet (siehe Grobkonzept Transportinfrastruktur (AD-NOOTS-19), Abschnitt Verteilte Nachrichtenverfolgung).

Darüber hinaus erfolgt ein technisches Logging in den Funktionen der Registerdatennavigation. Die Logs müssen anhand von Suchparametern effizient analysiert werden können.

7.8 Bausteinsicht

7.8.1 Datenmodell

Im Folgenden wird das fachliche Datenmodell der Registerdatennavigation erläutert. Um die Übersichtlichkeit zu wahren, werden in den Fachklassen nur die Attribute aufgeführt, die für die weiterführende Beschreibung relevant sind.

Abb. 3: Fachliches Datenmodell der Registerdatennavigation

Im Kontext eines Nachweisabrufs im NOOTS werden zwei Typen von Data Providern unterschieden: der nationale Data Provider für den Abruf nationaler Nachweise und die Intermediäre Plattform für den Abruf von EU-Nachweisen.

Zuständigkeitsermittlung für nationale Data Provider

Die Registerdatennavigation benötigt für die Zuständigkeitsermittlung die Information, welcher Data Provider für die Lieferung welcher Nachweistypen zuständig ist, sowie weitere Angaben zu dessen Nachweisangeboten.

• Ausgehend vom Nachweistyp ist der fachlich zuständige Registertyp eindeutig bestimmt.
• Die Zuständigkeitsbestimmung gibt an, wie die örtliche Zuständigkeit ermittelt werden kann. Sie definiert insbesondere die notwendigen Zuständigkeitsparameter für die Zuständigkeitsermittlung.
• Zuständigkeitswerte sind Kombinationen konkreter Ausprägungen der Zuständigkeitsparameter (n-Tupel). Über sie erfolgt die Ermittlung des zuständigen Data Provider.
• Zu einem Data Provider und einem von ihm bereitgestellten Nachweistyp kann es im Rahmen seiner Zuständigkeit eines oder mehrere Nachweisangebote geben. Ein Nachweisangebot eines Data Provider zu einem Nachweistyp umfasst:
• dass für den Abruf erforderliche Vertrauensniveau,
• mögliche Nachweissubjektidentifikatortypen für den Abruf, d.h. Abruf mittels eines Identifikationsmerkmals (IDNr oder beWiNr) oder mittels Basisdaten des Nachweissubjekts,
• angebotene Nachweisformate, insbesondere der MediaType gemäß Codeliste urn:xoev-de:xnachweis:codeliste:ootsmediatypes und für strukturierte Formate der Verweis auf das Schema, sowie
• die Service-ID des OO-Dienstes des Nachweisangebots.
• Ein Data Provider kann zu einem Nachweistyp mehrere Nachweisangebote bereitstellen, bspw. differenziert nach Nachweisformat. Er hat so die Möglichkeit, Once-Only-Dienste (und damit auch Verbindungsparameter und insbesondere technische Endpunkte) für verschiedene Zwecke zu vergeben.

Zuständigkeitsermittlung für Intermediäre Plattform

Für eine Intermediäre Plattform in der Rolle eines Data Provider sind einige Unterschiede zu beachten:

• Die Zuständigkeitsbestimmung kann über die Zuordnung der Intermediären Plattformen (Data Provider) zu Verwaltungsbereichen erfolgen (siehe auch OP-RDN-005).
• Die Zuständigkeitsbestimmung hat keinen zugehörigen Registertyp und bietet auch keinen spezifischen Nachweistyp an, hat also kein Nachweisangebot. 
• Der Intermediären Plattform (Data Provider) wird ihre Service-ID ohne Nachweisangebot zugeordnet, sie stellt den Once-Only-Dienst direkt bereit.
• Dieses Verfahren ist aktuell nur für die Zuständigkeitsermittlung Intermediärer Plattformen relevant. Es lässt sich durch diese grundsätzliche Abbildung im Datenmodell zukünftig auf vergleichbare Fälle ausweiten, in denen ein zuständiger Once-Only-Dienst nur auf Basis von Zuständigkeitsparametern ermittelt werden soll (insbesondere ohne den Kontext eines Registertyps und Nachweistyps) und v.a. kein Nachweisangebot hat

Once-Only-Dienst mit Verbindungsparameter

Für die Auflösung der Once-Only-Dienste zu ihren Verbindungsparametern sind ebenfalls entsprechende Zuordnungen notwendig.

• Zu jedem Once-Only-Dienst gibt es mindestens einen Satz an Verbindungsparametern.
• Jedem Satz an Verbindungsparametern ist genau ein Transportverfahren zugeordnet.
• Zu jedem Zeitpunkt darf nur genau ein Satz an Verbindungsparametern gültig sein.

7.8.2 Facharchitektur

7.8.2.1 Bausteine und Abhängigkeiten

Abb. 4: Fachliche Architektur der Registerdatennavigation

7.8.2.1.1 Zuständigkeitsermittlung

Die Registerdatennavigation ermittelt für einen Data Consumer (aufgerufen durch dessen Sicheren Anschlussknoten) den für einen nationalen Nachweis zuständigen Data Provider mit seinen Nachweisangeboten (7.2.5.1 Schnittstelle für die Zuständigkeitsermittlung eines Data Provider) bzw. die für den Abruf von EU-Nachweisen zuständige Intermediäre Plattform (7.2.5.2 Schnittstelle für die Zuständigkeitsermittlung einer Intermediären Plattform).

Die dafür notwendigen Informationen bezieht die Registerdatennavigation aus dem Nachweiskatalog (vgl. 7.2.1.3 Datenimport).

Dabei ist es notwendig, dass die aus dem Nachweiskatalog bezogenen Daten in wesentlichen Eigenschaften mit den Daten der NOOTS-Komponenten übereinstimmen bzw. diesen zugeordnet sind (insbesondere Data Provider zu ihrer Komponenten-ID des IAM für Behörden).

7.8.2.1.2 Dienstauflösung

Die Registerdatennavigation stellt die Auflösung der Service-ID in Verbindungsparameter je Transportverfahren bereit (7.2.5.3 Schnittstelle für die Ermittlung der Verbindungsparameter).

Die dafür notwendigen Informationen bezieht die Registerdatennavigation aus dem Once-Only-Diensteverzeichnis (vgl. 7.2.1.3 Datenimport).

Dabei ist es notwendig, dass die Verbindungsparameter der Once-Only-Dienste im OODV über die Service-ID den Nachweisangeboten, die aus dem Nachweiskatalog bezogen werden, zugeordnet werden.

7.8.2.1.3 Datenimport

Den Mitarbeitenden der öffentlichen Verwaltung soll über eine einheitliche Portalseite eine einfache Pflege der Daten im Kontext des Fachdatenkonzepts, der Registerlandkarte und des OODV ermöglicht werden. Auch aus Sicherheitsgründen soll der Zugriff auf die Registerdatennavigation auf ein notwendiges Minimum beschränkt werden.

Die Registerdatennavigation importiert deshalb Daten aus vorgelagerten Komponenten, d.h. aus dem Nachweiskatalog (7.2.5.4 Schnittstelle für die Aktualisierung der Zuständigkeiten) und aus dem Once-Only-Diensteverzeichnis (7.2.5.5 Schnittstelle für die Aktualisierung der Once-Only-Dienste).

Die genaue Ausgestaltung dieses Importprozesses ist im Umsetzungskonzept festgelegt.

7.8.2.1.4 Technische Administration

Die Registerdatennavigation bietet einen direkten Zugriff einzig für die technische Administration an. Dies ist bspw. die Pflege technisch notwendiger Parameter (bspw. für die Verbindung zum Nachweiskatalog und zum Once-Only-Diensteverzeichnis) oder der Zugriff auf das technische Logging.

Dieser Zugriff erfolgt besonders gesichert, um die Stellung der Registerdatennavigation im Nachweisabrufprozess und damit ihre Relevanz für die Funktionsfähigkeit des NOOTS zu berücksichtigen.

Die Ausgestaltung der technischen Administration erfolgt durch das Umsetzungskonzept.

7.8.2.2 Service-ID eines Once-Only-Dienstes

Die Once-Only-Dienste zur Bereitstellung einer bestimmten Funktionalität (insbesondere den Abruf eines Nachweises zu einem Nachweisangebot) ermöglichen eine Entkopplung dieser Dienste von ihren technischen Verbindungsparametern. Gleichzeitig erfolgt so eine Abstraktion des Transportverfahrens, die u.a. Flexibilität und Zukunftsfähigkeit schafft. Der Identifier eines Once-Only-Dienstes ist seine Service-ID. Er ermöglicht eine Trennung von Identifikation und Adressierung.

Die Service-ID wird als UUID abgebildet, da aktuell kein Bedarf für eine komplexere Struktur besteht.

7.8.2.3 Zuständigkeitstoken

Nach Ermittlung des zuständigen Data Provider stellt die Registerdatennavigation ein Zuständigkeitstoken aus. In diesem Token speichert sie die Informationen zum zuständigen Data Provider und (falls es ein Nachweisabruf von einem nationalen Data Provider ist) sein Nachweisangebot und siegelt das Token, damit die Integrität und Authentizität der von der Registerdatennavigation zurückgegebenen Informationen überprüft werden kann.

Das Zuständigkeitstoken existiert in zwei Ausprägungen:

• Ausprägung nationaler Data Provider - enthält Informationen zum Data Provider selbst sowie zu allen von ihm zum gegebenen Nachweistyp angebotenen Nachweisangebote
• Ausprägung Intermediäre Plattform - enthält nur die für die Identifizierung der zuständigen Intermediären Plattform benötigten Attribute

Folgend ist der (fachliche) Inhalt dieser zwei Ausprägungen des Zuständigkeitstokens dargestellt.

Tab. 10: Zuständigkeitstoken (Ausprägung nationaler Data Provider)

Tab. 11: Zuständigkeitstoken (Ausprägung Intermediäre Plattform)

7.8.2.4 Verbindungstoken

Nach Ermittlung der Verbindungsparameter einer gegebenen Service-ID stellt die Registerdatennavigation ein Verbindungstoken aus und siegelt dieses, damit die Integrität und Authentizität der Verbindungsparameter überprüft werden kann.

Tab. 12: Verbindungstoken

7.8.2.5 Schnittstellen zu anderen IT-Systemen

7.8.2.5.1 Schnittstelle für die Zuständigkeitsermittlung eines Data Provider

Tab. 13: Schnittstelle für die Zuständigkeitsermittlung eines Data Provider

7.8.2.5.2 Schnittstelle für die Zuständigkeitsermittlung einer Intermediären Plattform

Tab. 14: Schnittstelle für die Zuständigkeitsermittlung einer Intermediären Plattform

7.8.2.5.3 Schnittstelle für die Ermittlung der Verbindungsparameter

Tab. 15: Schnittstelle für die Ermittlung der Verbindungsparameter

7.8.2.5.4 Schnittstelle für die Aktualisierung der Zuständigkeiten

Tab. 16: Schnittstelle für die Aktualisierung der Zuständigkeiten

7.8.2.5.5 Schnittstelle für die Aktualisierung der Once-Only-Dienste

Tab. 17: Schnittstelle für die Aktualisierung der Once-Only-Dienste

7.9 Laufzeitsicht

7.9.1 Prozesse

Abb. 5: Sequenzdiagramm Registerdatennavigation

Folgend ist die Einbindung der Registerdatennavigation in den Nachweisabrufprozess beschrieben. Die Darstellung erfolgt aus Perspektive der Registerdatennavigation und beschränkt sich auf die dafür relevanten Aspekte.

Tab. 18: Nachweisabruf aus Perspektive der Registerdatennavigation

7.9.2 Ablaufszenarien der Registerdatennavigation

7.9.2.1 Ablaufszenario 1: Zuständigen nationalen Data Provider ermitteln

Tab. 19: Beschreibung des Ablaufszenarios "Zuständigen nationalen Data Provider ermitteln"

7.9.2.2 Ablaufszenario 2: Zuständige Intermediäre Plattform ermitteln

Tab. 20: Beschreibung des Ablaufszenarios "Zuständige Intermediäre Plattform ermitteln"

7.9.2.3 Ablaufszenario 3: Verbindungsparameter eines Once-Only-Dienstes ermitteln

Tab. 21: Beschreibung des Ablaufszenarios "Verbindungsparameter eines Once-Only-Dienstes ermitteln"

7.9.2.4 Ablaufszenario 4: Zuständigkeiten aktualisieren

Tab. 22: Beschreibung des Ablaufszenarios "Zuständigkeiten aktualisieren"

7.9.2.5 Ablaufszenario 5: Once-Only-Dienste aktualisieren

Tab. 23: Beschreibung des Ablaufszenarios "Once-Only-Dienste aktualisieren"

7.10 Ausblick und Weiterführende Aspekte

Tab. 24: Offene Punkte

7.11 Änderungsdokumentation

Tab. 25: Änderungsdokumentation