Zum Hauptinhalt springen

Im Folgenden wollen wir euch wieder ein kurzes Update zum vergangenen Sprint geben. Hierbei wollen wir auf die Stories eingehen, die wir bearbeitet haben, sowie den Stand der noch offenen Stories durchgeben.

Umgesetzte Stories#

Der Fokus dieses Sprints lag ganz darauf die API in einen Release Candidate Zustand für 1.0.0 zu bringen. Daher wurden primär Stories umgesetzt, die direkt die Spezifikation betreffen.

CaseId bei der Anlage einer Einreichung#

Die caseId wird nun nach der Anlage einer Einreichung in der Antwort mit zurückgeliefert. Des Weiteren funktioniert die Verarbeitung einer übergebenen caseId nun korrekt und sie wird der Einreichung zugeordnet.

Änderung von Status Codes und Antworten#

Für die folgenden Endpunkte haben sich die Status Codes im Erfolgsfall auf 204 geändert, da sie bisher immer eine leere Antwort lieferten. Im gleichen Zug wurde die Antwort gleich ganz entfernt.

  • DELETE /destinations/{destinationId}
  • PUT /submissions/{submissionId}/attachments/{attachmentId}
  • POST /submissions/{submissionId}/events

Versand einer Submission#

Bisher bekam man auf ein PUT /submissions/{submissionId} in der Antwort eine Repräsentation, die die gleichen Metadaten und Fachdaten enthalten hat, die vorher über den PUT übermittelt wurden. Da beides größer ausfallen kann und die Übertragungszeit dadurch nicht strapaziert werden soll, wurden diese aus der Antwort von entfernt. Dies betrifft aber nur PUT /submissions/{submissionId} und nicht GET /submissions/{submissionId}}.

Bereitstellung FIM Stammdatenschemas als JSON- bzw. XML-Schema#

Von FIM Stammdatenschemas soll ein JSON- und XML-Schema abgeleitet werden. Dafür wurde ein entsprechendes Konzept entwickelt, wie aus einem FIM Stammdatenschema ein JSON- bzw. XML-Schema abgeleitet werden kann. Zusätzlich wurde eine entsprechende Software zur Konvertierung entwickelt. In einem der kommenden Sprints wird dieser Prozess dann automatisiert und die Endergebnisse über schema.fitko.de bereitgestellt.

Pagination#

Für einige Endpunkte ist es Pagination empfehlenswert, da sie potenziell viele Ressourcen auflisten. Daher wurde für die folgenden Endpunkte Pagination definiert:

  • GET /destinations
  • GET /submissions

Die Pagination zeigt sich wie folgt, dass zusätzlich zu den destinations bzw. submissions die Attribute offset, count und totalCount zurückgegeben werden. Über die Query-Parameter limit und offset kann die Seitenlänge und die entsprechende Seite angegeben werden.

Hier eine kurze Übersicht über die Definition der Begriffe:

BegriffBeschreibung
limitAnzahl der zurückzugebenden Ergebnisse (standardmäßig 100)
offsetStartposition der Teilmenge zurückzugebender Ergebnisse aus der Gesamtergebnismenge. Standard ist 0.
countAnzahl der zurückgegebenen Ergebnisse.
totalCountAnzahl der existierenden Ergebnisse

Visualisierung der API Version in der URL#

Die Major-Version der Submission-API wird in der URL der API mit visualisiert, wodurch einfach zu erkennen ist, welche Major-Version verwendet wird. Dies ist eine vorausblickende, grundlegende und kleinere Änderung der API-URL.

Unfertige Stories#

Im Allgemeinen steht von einigen API-Änderungen noch die Implementierung bzw. der endgültige Review noch aus.

zusätzlich dazu steht noch das Statusmodell eines Zustellpunktes aus. Dieses soll eingeführt werden, damit der Betreiber bzw. Service-Anbieter eines Zustellpunktes den vollständigen Lebenszyklus des Zustellpunktes verwalten kann.


Ein Überblick über alle anstehenden Änderungen der Submission API gibt der Issue-Tracker des Submission API-Repositories. Auch an der Dokumentation arbeiten wir weiterhin kontinuierlich und freuen uns dazu über euer Feedback! Die uns bereits bekannten Verbesserungspotenziale finden sich im Issue-Tracker des Dokumentations-Repositories.


Bei sonstigen Fragen, Hinweisen oder Wünschen freuen wir uns über Feedback über unseren Service Desk oder per Mail an fit-connect <ät> fitko.de.

Im Folgenden wollen wir euch wieder ein kurzes Update zum vergangenen Sprint geben. Hierbei wollen wir auf die Stories eingehen, die wir bearbeitet haben, sowie den Stand der noch offenen Stories durchgeben.

Umgesetzte Stories#

API Änderungen#

Das Feld announcedContentStructure wurde umbenannt in announcedAttachments, da das Flag data implizit über die Angabe von encryptedData beim Absenden einer Einreichung mit angegeben wird. Des Weiteren wurde das umbenannte Feld aus jeglichen Antworten, die eine Einreichung zurückliefern entfernt, da die Information rein für den Zustelldienst zur Überprüfung der Einreichung gedacht ist. Folgende Endpunkte sind von den beschriebenen Änderungen betroffen:

  • PUT /submissions/{submissionId}
  • GET /submissions/{submissionId}

Zukünftig gibt es die Optionen, sowohl für sendende, als auch für empfangende Systeme über Callbacks über gewisse Ereignisse benachrichtigt zu werden. Es wurde ein entsprechendes Konzept ausformuliert und in der API Spezifikation eingearbeitet. Nun können sendende Systeme bei der Anlage einer Einreichung ein Callback-Objekt angeben, worüber man vorerst über Statusänderungen der Einreichung benachrichtigt wird. Empfangende Systeme konnten schon einen Callback hinterlegen, welcher nun angepasst werden muss. Betroffene Endpunkte sind die Folgenden:

  • POST /submissions
  • GET /destinations/{destinationId}

Unfertige Stories#

Keine.


Ein Überblick über alle anstehenden Änderungen der Submission API gibt der Issue-Tracker des Submission API-Repositories. Auch an der Dokumentation arbeiten wir weiterhin kontinuierlich und freuen uns dazu über euer Feedback! Die uns bereits bekannten Verbesserungspotenziale finden sich im Issue-Tracker des Dokumentations-Repositories.


Bei sonstigen Fragen, Hinweisen oder Wünschen freuen wir uns über Feedback über unseren Service Desk oder per Mail an fit-connect <ät> fitko.de.

Im Folgenden wollen wir euch wieder ein kurzes Update zum vergangenen Sprint geben. Hierbei wollen wir auf die Stories eingehen, die wir bearbeitet haben, sowie den Stand der noch offenen Stories durchgeben.

Umgesetzte Stories#

Schlüsselverwaltung eines Zustellpunktes#

Um zu vereinfachen, wie öffentliche kryptographische Schlüssel über die API bereitgestellt und heruntergeladen werden können, wurden 3 neue Endpunkte geschaffen:

  • GET /destinations/{destinationId}/keys/{keyId}
  • POST /destinations/{destinationId}/keys
  • PATCH /destinations/{destinationId}

Wie oben beschrieben, wird sich dabei auch der Mechanismus zum Abrufen von kryptografischen Schlüsseln eines Zustellpunktes bis zur Veröffentlichung der finalen API-Spezifikation noch einmal ändern.

Fehlerbehebungen in der Infrastruktur#

Da Testnutzer inzwischen FIT-Connect nutzen sind einige Dinge aufgefallen, die bei internen Tests übersehen worden sind. Es ging hier v.a. um das Zusammenspiel der Teilkomponenten von FIT-Connect. Diese sind inzwischen behoben, sollen hier aber zumindest erwähnt werden.

Unfertige Stories#

Keine.


Ein Überblick über alle anstehenden Änderungen der Submission API gibt der Issue-Tracker des Submission API-Repositories. Auch an der Dokumentation arbeiten wir weiterhin kontinuierlich und freuen uns dazu über euer Feedback! Die uns bereits bekannten Verbesserungspotenziale finden sich im Issue-Tracker des Dokumentations-Repositories.


Bei sonstigen Fragen, Hinweisen oder Wünschen freuen wir uns über Feedback über unseren Service Desk oder per Mail an fit-connect <ät> fitko.de.

Im Folgenden wollen wir euch wieder ein kurzes Update zum vergangenen Sprint geben. Hierbei wollen wir auf die Stories eingehen, die wir bearbeitet haben, sowie den Stand der noch offenen Stories durchgeben.

Stories#

Umgesetzt#

Generierung von JWKs ohne Zertifikatskette#

Zur Vereinfachung von Anbindungstests haben wir ein Tool zur Generierung von Test-Schlüsselpaaren ohne Zertifikatskette erstellt.

Umsetzung des Self-Service-Portals#

Das Self-Service Portal erfüllt in der ersten MVP-Ausbaustufe zwei Funktionen:

  • Entwickler:innen und Verfahrensbetreiber:innen sollen ihre Software als API-Clients registrieren und deren Berechtigungen (Scopes) verwalten können. Die Anmeldung im Self-Service-Portal und die Registrierung von API-Clients ist im Artikel Accountregistrierung und Client-Verwaltung beschrieben.
  • Entwickler:innen und Verfahrensbetreiber:innen von empfangenden Systemen können über das Self-Service-Portal Zustellpunkte einrichten und verwalten. Das Anlegen von Zustellpunkten für empfangende Systeme ist im Artikel Zustellpunkt anlegen beschrieben.

Interessierten Entwickler:innen stehen folgende Login-Möglichkeiten zur Verfügung:

  • Login mit einem Account des FITKO-Gitlab (Account muss bei der FITKO angefragt werden)
  • Login mit einem Github.com- oder Gitlab.com-Account

Mehrere Regionen pro Service#

Durch die Nutzung des regions-Arrays (statt bisher region-Attributs) können mehrere Regionen pro Verwaltungsleistung angegeben werden. Siehe Zustellpunkt ermitteln.

Alle abholbereiten Einreichungen auflisten / abrufen#

Wenn im Zustellpunkt eine Callback-URL hinterlegt ist, kann der Zustelldienst empfangende Systeme direkt via Callback informieren, sobald eine neue Einreichung eingeht. Empfangende Systeme können nun zusätzlich durch Polling, d.h. regelmäßiges Abfragen des Endpunktes GET /submissions prüfen, ob neue Einreichungen zur Abholen bereitstehen. Dies wird aus Performancegründen jedoch nicht empfohlen. Der Endpunkt kann zu Testzwecken als Alternative zu Callbacks genutzt werden oder, falls aus technischen Gründen die Nutzung eines Callbacks im Produktivbetrieb nicht möglich ist (bspw. Security Policies im RZ).

Die Nutzung des Endpunkts ist im Artikel Vorhandensein neuer Einreichungen prüfen beschrieben.

Event Logs#

Zur Prüfbarkeit der Datenübermittlung und Empfangsbestätigung von Einreichungen erhält jede Submission einen Event Log, das Security Event Tokens (SET) gemäß RFC 8417 speichert. Manche der Events werden vom Zustelldienst erzeugt, manche werden extern über die API zugeliefert. Die Hintergründe sind im Artikel Event Log beschrieben. Das Abfragen des Status ist im Artikel Status abfragen beschrieben. Wie empfangende Systeme einen Security Event Tokens (SET) erzeugen und über die API bereitstellen können, ist im Artikel Empfangsbestätigung beschrieben.

Hinweis: Der Mechanismus zum Abrufen von kryptografischen Schlüsseln des empfangenden Systems wird sich bis zur Veröffentlichung der finalen API-Spezifikation noch einmal ändern.

Typ other des Identifikationsnachweises entfernt#

Der bisherige Wert other als Typ einer AuthenticationInformation wurde im Metadatenschema entfernt, da er nicht besonders aussagekräftig ist und zur Bestimmung des Authentifizierungsschemas nicht ausreicht. Unser Ziel mit FIT-Connect ist, möglichst einheitliche Verfahren zur Authentifizierung zu unterstützen und zu dokumentieren. Daher werden wir diese bei zukünftigen Anforderungen hinsichtlich neu zu schaffender Authentifizierungschemata explizit inkl. einer ausführlichen Dokumentation zu deren Nutzung aufnehmen. Kommen Sie bei Bedarf gerne auf uns zu!

Diverse Verbesserungen der Dokumentation#

  • In der Dokumentation wurden die Bezeichnungen "FIT-Connect API", "Einreichungs-API" etc. zu "Submission API" vereinheitlicht. Künftig werden wir nur noch von Submission API sprechen, wenn die Schnittstelle des Zustelldienstes zur Übermittlung von Einreichungen gemeint ist.
  • Der Artikel Zustellpunkt ermitteln wurde aktualisiert.
  • Neu: Dokumentation zur Nutzung von Fachdatenschema für Sender
  • Neu: Dokumentation zur Nutzung von Fachdatenschema für Empfänger
  • Der Artikel Einreichung herunterladen wurde auf den neusten Stand der API aktualisiert.

Im Sprint nicht abgeschlossene Stories#

Schlüsselverwaltung eines Zustellpunktes#

Um zu vereinfachen, wie öffentliche kryptographische Schlüssel über die API bereitgestellt und heruntergeladen werden können, werden die neuen Endpunkte GET/PUT /destinations/{destinationId}/keys/{keyId} geschaffen. Wie oben beschrieben, wird sich dabei auch der Mechanismus zum Abrufen von kryptografischen Schlüsseln eines Zustellpuntes bis zur Veröffentlichung der finalen API-Spezifikation noch einmal ändern.

Ausblick: Weitere anstehende Änderungen bis zur finalen Schnittstelle#

Neben einigen internen Arbeiten werden wir bis zur Veröffentlichung der finalen Schnittstelle einige weitere Änderungen vornehmen. Mit Blick auf ggf. notwendige Anpassungen der Schnittstellenanbindung sind hierbei insb. die folgenden anstehenden Aspekte relevant:

  • Weitere Verbesserungen im Self-Service-Portal: Der aktuelle MVP des Self-Service-Portals wird hinsichtlich Benutzbarkeit (UX) und Design weiterentwickelt werden.
  • Das im Endpunkt GET /submissions/{submissionId} enthaltene Attribut announcedContentStructure wird entfernt. Die Liste der Anlagen ist bereits im Attribut attachments enthalten.
  • Der im Metadatenschema genutzte IdenfitcationReport soll versioniert werden.
  • Für die Endpunkte GET /destinations, GET /submissions und GET /submissions/{submissionId}/events wird eine Pagination umgesetzt.
  • Umsetzung von Best-Practices für Callbacks: Zur Erhöhung der Sicherheit von Callbacks werden wir einheitliche Sicherheitsvorgaben für die Callback-Nutzung definieren, dokumentieren und in der API umsetzen. Dabei werden sich auch die Schnittstelle zur Konfiguration von Callbacks sowie die Vorgaben zur Prüfung von Callbacks noch einmal ändern. Auch sendende Systeme sollen zukünftig via Callback über Statusänderungen benachricht werden.
  • In der Testumgebung können zu Testzwecken selbst-generierte kryptographische Schlüsselpaare ohne Absicherung über die Verwaltungs-PKI genutzt werden. Dies wird in der Produktivumgebung nicht mehr der Fall sein. Wir werden entsprechende Vorgaben zur Prüfung der Zertifikatskette sowie die nötigen Schritte zur Ableitung von JSON Web Keys (JWKs) aus Zertifikaten beschreiben.
  • Eine Methode zum Deaktivieren/Löschen von Zustellpunkten wird noch ergänzt.
  • Vorgaben zur Maximalgröße von Einreichungen werden noch ergänzt.
  • Die Möglichkeiten zur Angabe von Rückkanaloptionen werden noch einmal überarbeitet und ausgebaut.
  • Ein Konzept zur Versionierung der API und des Metadatenschema befindet sich gerade in der Entwicklung und wird Handreichungen zum Umgang mit zukünftigen API-Änderungen bieten.

Ein Überblick über alle anstehenden Änderungen der Submission API gibt der Issue-Tracker des Submission API-Repositories. Auch an der Dokumentation werden wir kontinuierlich Arbeiten. Die uns bereits bekannten Verbesserungspotenziale finden sich im Issue-Tracker des Dokumentations-Repositories.


Bei sonstigen Fragen, Hinweisen oder Wünschen freuen wir uns über Feedback über unseren Service Desk oder per Mail an fit-connect <ät> fitko.de.

Im Folgenden wollen wir euch ein kurzes Update bzgl. unseres Sprints geben. Hierbei wollen wir auf die Stories eingehen, die wir bearbeitet haben, sowie den Stand der noch offenen Stories durchgeben.

Falls relevant soll auch ein entsprechendes Update der Roadmap kommuniziert werden.

Dieses Format soll nun bei jedem Sprintwechsel veröffentlicht werden.

Stories#

Umgesetzt#

Finalisierung des Autorisierungskonzepts#

Im Rahmen dieser Story wurden die begonnenen Arbeiten an der Umstellung der OAuth Autorisierung umgesetzt. Die FIT-Connect-Infrastruktur wurde gegen die neuen Tokens und Scopes getestet und die Dokumentation und API-Spec aktualisiert. Die Neuerungen der OAuth-Autorisierung lassen sich wie folgt zusammenfassen:

  • Die Zugriffsberechtigung für Zustellpunkte basiert nun auf Scopes (manage:destination:<uuid> bzw. subscribe:destination:<uuid>) und nicht mehr auf der Identität des konkreten API-Client, der den Zustellpunkt initial erstellt hat. Dies erlaubt es, API-Clients flexibel auszutauschen, ohne hierfür den Zustellpunkt neu anzulegen oder auch mehreren API-Clients einen Zugriff auf einen Zustellpunkt zu ermöglichen.
  • Neue Zustellpunkte können nur noch über das Self-Service-Portal angelegt werden. Die Verwaltung von Zustellpunkten ist weiterhin über die API möglich.
  • Sendende Systeme können Access Tokens mit eingeschränkten Scopes abrufen, die nur für den Versand von Einreichungen an Zustellpunkte mit bestimmten Leistungen und Regionen gültig sind, um hiermit den Berechtigungsumfang eines Tokens einzuschränken. Wird von dieser Option kein Gebrauch gemacht, ist der Scope des Access Token für alle Regionen und Leistungen in Deutschland gültig.
    • Um diese spezifischen Berechtigungseinstellungen bei Access Tokens von sendenden Systemen zu ermöglichen, müssen in den Zustellpunkten nun die Leistungs-IDs (bspw. Angabe eines Leika Schlüssel) und die Region-IDs (aktuell ARS), die in diesem Zustellpunkt abgebildet werden, verpflichtend hinterlegt werden. Bei Leistungen, die nicht über den ARS abgebildet werden können oder keinen Ortsbezug haben, wird in dem Zustellpunkt als Regionsangabe lediglich DE angeben.

Die Nutzung von OAuth ist folgenden Artikeln beschrieben:

Wie Scopes bei der Registrierung und Verwaltung von API-Clients hinterlegt werden, wird in der Dokumentation zum Self-Service-Portal beschrieben, sobald dieses umgesetzt ist.

Endpunkt zur Abfrage der öffentlichen Informationen einer Destination#

Bisher gab es keine Möglichkeit, dass ein sendendes System die öffentlichen Informationen eines Zustellpunktes abfragen konnte. Ein solcher Abruf ist bis zur Umsetzung der Routing-API notwendig, damit sendende Systeme die hinterlegten Informationen eines Zustellpunktes ermitteln können, da diese Informationen für eine fachlich und technisch korrekte Übermittlung zwingend erforderlich sind.

Daher wurde ein neuer Endpunkt umgesetzt, um die öffentlichen Informationen einer Destination abzurufen. Empfangende Systeme können für ihre eigenen Zustellpunkte zusätzlich auch die internen Informationen abrufen (technische Ansprechpersonen, Callback-Adresse).

Event Log der Submission#

Zur Prüfbarkeit der Datenübermittlung erhält die Submission einen Event Log, der Security Event Tokens (SET) gemäß RFC 8417 enthält, die einzelne Ereignisse in der Datenübermittlung signiert dokumentieren. Ein Teil der Events werden vom Zustelldienst erzeugt, andere Events (bspw. im Kontext Akzeptanz oder Ablehnung der Submission) werden durch das empfangende System erzeugt. Der Event Log bzw. die SETs der einzelnen Events ersetzen das bisherige Statusmodell. Im Vergleich zum bisherigen Statusobjekt zeichnet sich ein SET durch eine Absicherung mittels Signatur, einen Zeitstempel und eine eindeutige Identifikation von Events aus. Aktuell werden SETs noch ohne einen Payload umgesetzt, der Events detaillierter beschreibt. Entsprechende Event-Payloads werden in zukünftigen Weiterentwicklung spezifiziert und umgesetzt.

Die Dokumentation kann hier eingesehen werden:

Schlüsselverwaltung des Zustelldienstes#

Um die Urheberschaft und Integrität eines durch den Zustelldienst ausgestellen Security Event Tokens (SET) validieren zu können, ist es notwendig, die benutzten Schlüssel allen API-Clients zur Verfügung zu stellen. Daher stellt der Zustelldienst über einen /.well-known/jwks.json-Endpunkt alle Schlüssel dauerhaft bereit, damit eine Validierung von SETs auch noch Monate oder Jahre nach dem Einreichungsvorgang möglich ist. Näheres zur Validierung ist in der Dokumentation zu finden.

Implementierung des neuen Statusmodells#

Mit der Einführung des Event Logs wurde auch ein neues Statusmodell für Einreichungen beschlossen. Dieses Statusmodell wurde im Zustelldienst implementiert und wird durch die Events des Eventlogs gesteuert.

schemas in submissionSchemas umbenennen#

Im Rahmen der Qualitätsprüfungen der API wurde beschlossen, den Bezeichner schemas, der die referenzierten Fachdatenschemata in einer Destination bzw. im Metadatenschema beinhaltet, in submissionSchemas umzubenennen. Diese Umbenennung wurde in der API-Spec und Dokumentation angepasst.

Dokumentationsartikel "Versenden" im Überblick von Getting Started aufteilen#

Um einen besseren Einstieg für Entwickler:innen von sendenden Systemen zu ermöglichen, wurden Inhalte aus dem Artikel "Überblick" in einen Artikel "Zustellpunkt ermitteln" überführt, der detaillierter beschreibt, wie die korrekte Destination-ID des gewünschten Zustellpunktes ermittelt werden kann und wie die Informationen eines Zustellpunkts für die Datenübermittlung zu nutzen sind.

Im Sprint nicht abgeschlossene Stories#

Umsetzung des Self-Service-Portals#

Das Self-Service-Portal soll in der ersten MVP Ausbaustufe zwei Funktionen erfüllen:

  • Entwickler:innen und Verfahrensbetreiber:innen sollen ihre Software als API-Clients registrieren können und deren Berechtigungen (Scopes) verwalten können.
  • Entwickler:innen und Verfahrensbetreiber:innen von empfangenden Systemen können über das Self-Service-Portal Zustellpunkte einrichten und verwalten.

Das Self-Service-Portal wird bis kommende Woche für die Nutzung für die öffentliche Test-API bereitgestellt. Interessierten Entwickler:innen stehen folgende Login-Möglichkeiten zur Verfügung:

  • Login mit einem Account des FITKO-Gitlab (Account muss bei der FITKO beantragt werden)
  • Login mit einem Github.com- oder Gitlab.com-Account

XFall Schema: Erstellung eines Konzepts zur Ableitung eines JSON Schemas aus einem FIM Stammdatenschema#

Um die Nutzung von FIM zur Datenübermittlung weiter zu vereinfachen, wurde eine JSON-Schema-Variante konzipiert. Das Konzept befindet aktuell noch in einem internen Review, wird aber demnächst zur Einsicht über das Gitlab der FITKO bereitgestellt.


Bei Fragen, Hinweisen oder Wünschen freuen wir uns gerne über Feedback. Dieses bitte über unseren Service Desk einkippen.

Im Folgenden wollen wir euch ein kurzes Update bzgl. unseres Sprints geben. Hierbei wollen wir auf die Stories eingehen, die wir bearbeitet haben, sowie den Stand der noch offenen Stories durchgeben. Falls relevant soll auch ein entsprechendes Update der Roadmap kommuniziert werden.

Dieses Format soll nun bei jedem Sprintwechsel veröffentlicht werden.

Stories#

Umgesetzt#

Umsetzung des OAuth-Konzeptes#

Ein neues OAuth Konzept soll umgesetzt werden, das detaillierte Berechtigungen für den API-Zugriff ermöglicht und eine höhere Sicherheit für die Nutzung von Access Token gewährleistet.

Die Umsetzung des neuen OAuth-Konzeptes verzögerte die Bereitstellung der Testinfrastruktur. Aufgrund von kurzfristigen Änderungen im Konzept mussten und müssen wir noch etwas umbauen. Der Großteil des Konzeptes ist bereits abgeschlossen und die wenigen Nacharbeiten werden im aktuellen Sprint bearbeitet und dokumentiert.

Neues Metadatenschema entwickeln#

Ein Metadatensatz beschreibt die Struktur einer Einreichung und deren Inhalte, wie beispielsweise Anlagen oder Fachdaten. Das bisherige Metadatenschema für Einreichungen wurde aus beta7 komplett überarbeitet:

  • Es ist als JSON-Schema beschrieben und orientiert sich an der JSON Schema Spezifikation 2020-12.
  • Die Nutzung und die Struktur des Metadatenschemas wurden in der Dokumentation erläutert.
  • Es besteht primär aus den fünf Bereichen Authentifizierungsinformationen, Inhaltsstruktur, Bezahlinformationen, Verwaltungsleistung und Rückkanal.
Hinweis

Das Metadatenschema ist aktuell in der Version 1.0.0-rc.2 verfügbar und wird zukünftig unabhängig vom Zustelldienst versioniert, um größtmögliche Flexibilität und Erweiterbarkeit zu erzielen.

Info-Endpunkt liefert die falsche Version#

Wir hatten im Zustelldienst den Fehler, dass über den Endpunkt /info die falsche Version ausgegeben wurde. Dieses Problem wurde behoben und sollte nicht mehr auftreten.

Erstellung eines Konzepts zur Ableitung eines JSON Schemas aus einem FIM Stammdatenschema#

Aktuell werden aus einem Stammdatenschema einer Antragsleistung, einer XML-Datei zur Generierung von Anträgen, in FIM ein XML-Schema für die Datenübertragung abgeleitet. Dieses Schema wird umgangssprachlich XFall Schema bzw. XFall Schema genannt.

Durch die Verbreitung von JSON wurde für Fachdaten auf FIM Basis eine JSON Schema basierte Variante entwickelt. Dieses soll kurzfristig als Zusatzoption ermöglicht werden und langfristig als Ersatz für das bestehende XML Schema platziert werden.

Es wurde erprobt und dokumentiert, wie ein solches JSON-Schema allgemein und über eine eigene Software abzuleiten ist, sodass dies zukünftig automatisiert durchgeführt werden kann.

Im Sprint nicht abgeschlossene Stories#

Event Log der Submission#

Der bisherige Übermittlungsstatus wird durch einen Security Event Log ersetzt, der aus signierten Security Event Tokens nach RFC 8417 besteht und die einzelnen Übermittlungsschritte beweissicher dokumentiert. Die jeweiligen Security Event Tokens sind durch die jeweils verantwortlichen Systeme (Zustelldienst bzw. das empfangende System) zu erstellen und zu signieren. Dieser Security Event Log kann über die API von beiden Parteien abgerufen werden und dient späteren Nachweisen über die korrekte Zustellung.

Die Implementierung des Security Event Logs ist größten teils abgeschlossen, muss jedoch noch final getestet und dokumentiert werden.

Schlüsselverwaltung des Zustelldienstes#

Aufbauend auf die vorherige Thematik des Event Logs benötigt ein Zustelldienst ein öffentliches "JSON Web Key (JWK)"-Set nach RFC 7517, worin er seine öffentlichen Schlüssel zur Verfügung stellt, mit denen die Signatur eines Security Event Tokens überprüft werden kann.

Hier fehlt noch die Dokumentation der Erreichbarkeit des JWK-Sets und wie dieses angewendet werden kann.

Implementierung des neuen Statusmodells#

Ebenfalls im Kontext der Umsetzung des Event Logs ist die Implementierung des neuen Statusmodells anzusiedeln. Eine Einreichung wird zukünftig einen Status innehaben, der über definierte Events in Form von Security Event Tokens verändert werden kann.

Die Implementierung des neuen Statusmodells wurde im Rahmen der Umbauten durch den Event Log abgeschlossen und muss im Rahmen dieser noch mit dokumentiert werden.

schema in submissionSchemas umbenennen#

Als Follow-Up aus einem vorherigen Sprint wurde beschlossen, dass der technische Bezeichner der "Fachschemareferenz" an verschiedensten Stellen von schema zu submissionSchemas geändert wird.

Die Umsetzung hiervon konnte noch nicht begonnen werden und wird daher in einem der nächsten Sprints angegangen.

Roadmap Update#

Unser Ziel eine Vorabversion der API und ein frei zugängliches Testsystem bereitzustellen verschiebt sich auf Anfang August.


Bei Fragen, Hinweisen oder Wünschen freuen wir uns gerne über Feedback. Dieses bitte über unseren Service Desk einkippen.