FIT-Connect 2.0

Inhalt

• Überblick
• Migration Guide
• Häufig gestellte Fragen

Überblick

Im Oktober 2025 erscheint das erste FIT-Connect Major Release. Mit diesem Major Release führt FIT-Connect einen jährlichen Release-Zyklus ein. Dies stellt Planungssicherheit und Verlässlichkeit bei der Weiterentwicklung zukünftiger Features sicher.

Inhalt des Releases sind neue API-Versionen, ein neues Metadaten-Schema, sowie eine weitere Optimierung von FIT-Connect Diensten. Dadurch garantiert FIT-Connect seinen Nutzern eine stabile Basis, klar definierte Standards, sowie langfristige Kompatibilität.

Mit diesem Major Release werden alle API- und Metadatenschema-Versionen vor 2.0 abgekündigt und sind damit nur noch ein Jahr gültig. Ausgenommen hiervon sind bereits abgekündigte Versionen.

Der IT-Support steht bei Fragen oder Bedarf bei der technischen Umsetzung zur Verfügung. Bei allgemeinen Fragen rund um das Major Release steht Ihnen das Anbindungsmanagement zur Verfügung.

Folgender Zeitplan für die Bereitstellung des Major Releases wurde festgelegt:

• 01. Oktober 2025 - Deployment auf TEST
• 02. Oktober 2025 - Deployment auf STAGE
• 04. November 2025 - Deployment auf PROD

Zu dem Release werden Sondersitzungen im Nutzenden- und Technikkreis durchgeführt. Anmeldungen zu diesen Sondersitzungen sind über die Seite Termine & Veranstaltungen möglich.

Geschätzter Aufwand

Die nachfolgende Tabelle gibt einen Überblick über den Aufwand, der für alle Anbindungsprojekte betreffenden Änderungen zu erwarten ist:

Den geschätzten Aufwand für die Änderungen für Anbindungen ohne SDK können wird in der folgenden Tabelle aufgelistet:

Welche Neuerungen bringt dieses Release?

Mit dem Major Release stehen die folgenden Komponenten in Version 2.0.0 oder höher zur Verfügung:

• Self-Service-Portal
• Zustelldienst
• Routingdienst
• Submission-API
• Destination-API
• Routing-API
• Metadatenschema

Self-Service-Portal

Mit dem neuen Major Release werden neue Banner eingeführt. Wichtige Hinweise werden nun visuell hervorgehoben und für den Anwender direkt sichtbar.

Um die Navigation in großen Listen zu vereinfachen wird eine Pagination eingeführt. Die Informationen werden dadurch übersichtlicher und eine Navigation innerhalb großer Listen möglich.

Das Major Release führt einen Entwurfsmodus für Zustellpunkte ein. Dadurch können Ziele als Draft angelegt und die Veröffentlichung zu einem späteren Zeitpunkt durchgeführt werden.

Bestandteil des Releases ist auch eine Login-Konsolidierung. Das Login-Verfahren wird dadurch vereinfacht und vereinheitlicht.

Das Major Release 2.0 führt ein neues Design für FIT-Connect ein. Modernisierte Oberflächen mit aktualisierten UI-Komponenten gestalten die Inhalte übersichtlicher und vereinfachen die Anwendung.

Weitere Informationen hierzu finden sich auf der Seite Changelog.

Zustelldienst

Für das Major Release wurde die API vereinfacht, indem die Submission-, Destination- und Routing-API mit einheitlichen Begriffen überarbeitet wurde.

Das Metadatenschema hat das neue Array dataSets für mehr Flexibilität bei externen Daten (z. B. für Authentifizierung, Bezahlung, usw.) erhalten. Ebenso kann nun die Elektronische Bescheidzustellung direkt im Schema angegeben werden. Zusätzlich wurden weitere Optimierungen am Metadatenschema vorgenommen.

Weitere Informationen hierzu finden sich auf der Seite Changelog.

Technische Details

Release Notes

Informationen zu den technischen Details des Major Releases 2.0 können den zugehörigen Release Notes entnommen werden. Diese sind auf der Seite Changelog einsehbar.

Breaking Changes

Bei Systemen, die auf das Major Release 2.0 migrieren, sind umfassende Änderungen und Anpassungen notwendig. Werden diese Änderungen und Anpassungen nicht durchgeführt, ist ein ordnungsgemäßer Betrieb des migrierten Systems nicht möglich. Details hierzu finden sich im Abschnitt Migration Guide.

Release-Plan

Das Release 2.x und das Release 1.x werden für eine Übergangsfrist von einem Jahr unterstützt und sind parallel gültig. Bestehende Abkündigungen behalten weiterhin ihre Gültigkeit. Alle API- und Metadatenschema-Versionen unter 2.0 werden mit dem Major Release abgekündigt und sind nur noch ein Jahr gültig (ausgenommen davon sind bereits abgekündigte Versionen).

Abkündigungen

Hinweis

Sämtliche Informationen zu aktuellen und bestehenden Abkündigungen Sind auf der Seite Abkündigungen verfügbar.

Major Release

Die 1.x.x-Versionen unserer APIs und des Metadatenschemas werden zum 01.10.2026 abgekündigt. Nachfolgend erhalten Sie einen Überblick der davon aktuell betroffenen Versionen.

Destination API:

• 1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.9.0, 1.10.0

Submission API:

• 1.2.1, 1.3.0, 1.4.0, 1.4.1, 1.4.2, 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.9.0, 1.10.0, 1.11.0, 1.12.0, 1.13.0, 1.14.0

Routing API:

• 1.2.0, 1.3.0

Metadatenschema:

• 1.3.0, 1.4.0, 1.5.0

Online-Veranstaltungen

Zu dem Release werden Sondersitzungen im Nutzenden- und Technikkreis durchgeführt. Anmeldungen zu diesen Sondersitzungen sind über die Seite Termine & Veranstaltungen möglich.

SDKs

Die aktuellen SDKs können hier eingesehen und heruntergeladen werden:

• Java SDK
• JavaScript SDK
• .NET-SDK

Migration Guide

FIT-Connect hat ein Major Update bekommen und damit stehen die Submission API, Destination API, Routing API und das Metadatenschema in Version 2.0.0 zur Verfügung. Anbindungen können ab sofort auf diese neuen Versionen umgestellt werden. Die 1.x.x-Versionen sind hiermit abgekündigt und werden nur noch ein Jahr zur Verfügung stehen.

Hinweis

Anbindungen müssen innerhalb eines Jahres auf die neuen Versionen umgestellt werden, da sonst bereits bestehende Integrationen nicht mehr funktionieren werden.

Die nachfolgende Anleitung beschreibt die Migration von FIT-Connect Version 1.x.x auf 2.0.0.

Änderungen, die jede bestehende Anbindung betreffen

Submissions ohne Fachdaten

Es ist nicht mehr möglich, Einreichungen (Submissions) ohne Fachdaten zu versenden. Technisch formuliert bedeutet dies, dass das Feld encryptedData des PUT /v2/submissions/{submissionId}-Endpunkts nun verpflichtend ist. Für Fachverfahren ist zu beachten, dass Onlinedienste immer noch Submissions ohne Fachdaten an bestehende Anbindungen senden können, solange diese noch nicht auf die v2-API umgestellt haben.

Webhooks

In den new-events und new-submissions-Webhooks der Submission API wurde das submissionIds-Array als deprecated und optional markiert. Zum jetzigen Zeitpunkt gibt es aber noch keine Änderungen im Verhalten. Implementierungen müssen aber dennoch bereits jetzt dahingehend umgestellt werden, dass Sie das Array submissionIds nicht mehr verarbeiten und stattdessen auf submissions.submissionId zurückgreifen. Dies ist notwendig, da in einem Jahr die Webhooks ohne das genannte Feld versendet werden.

Das forward-submission-Event

Events vom Typ forward-submission werden nicht mehr akzeptiert und können über die Submission API v2 nicht mehr ausgelöst werden. Kommunikationspartner können aberweiterhin solche Events erzeugen, solange diese noch v1-Endpunkte verwenden. Dies ist noch für ein Jahr lang möglich. Ebenso können sich weiterhin historische forward-submission-Events in Event-Logs befinden.

Metadaten

Fachverfahren sollten das Metadatenschema in Version 2.0.0 technisch unterstützen und danach im Self-Service-Portal diese Unterstützung eintragen. Onlinedienste sollten bei entsprechender Indikation der Destination diese neue Version für ihre Einreichungen verwenden, da Metadatenschemata älterer Versionen ebenso als abgekündigt gelten. Davon abgesehen bietet das Metadatenschema 2.0.0 auch inhaltliche Erweiterungen und Vorteile.

Das Metadatenschema wurde modularisiert. Das bedeutet, dass das authenticationInformation-Objekt vollständig entfernt wurde und das additionalReferenceInfo-Objekt keine beliebigen zusätzlichen Felder mehr erlaubt. Stattdessen wurde auf Wurzelebene ein dataSets-Array hinzugefügt. Dieses Array ermöglicht es, je nach Art der Einreichung, auf beliebige (Sub-)Schemata anhand ihrer URL zu verweisen. So kann zum Beispiel das Schema https://raw.githubusercontent.com/Governikus/IdentificationReport/2.0.0/schema/identification-report.json verwendet werden, um die Informationen aus dem vormaligen authenticationInformation-Objekt zu übermitteln. Generell ist die Frage, welche (Sub-)schemata verwendet werden sollen, eine bilaterale Absprache zwischen zwei Kommunikationspartnern. Für die abgesprochenen Schemata sollten dann die entsprechenden versionierten Schema-Dateien auf dem System lokal vorgehalten werden und den URLs zugeordnet sein. Ein dynamisches Nachladen von beliebigen Dateien aus dem Web ist nicht empfohlen.

Außerdem wurde das Feld publicServiceType entfernt. Die Verwaltungsleistung ist bereits seit längerem Teil der Klardaten einer Submission und soll hier nicht mehr redundant spezifiziert werden.

Eine Angabe von contentStructure.data ist nun verpflichtend. Diese Änderung steht in Einklang mit der Entscheidung, Submissions ohne Fachdaten nicht mehr zuzulassen.

Ein boolean-Feld additionalReferenceInfo.zustimmungZumDigitalenBescheid wurde hinzugefügt, um die Zustimmung des Antragsstellers zur elektronischen Bescheidzustellung standardisiert übermitteln zu können.

Ein optionales Feld author wurde auf Wurzelebene hinzugefügt. Mit diesem Feld kann ein absendendes System eine Selbstauskunft geben, die bei der Nachverfolgbarkeit von Fehlern hilfreich sein kann. Es wird empfohlen, hier Werte zu setzen.

Das Feld replyChannel.fink.finkPostfachRef erfordert nun mindestens ein Zeichen, um Verwirrungen frühzeitig vorzubeugen.

Das $schema-Feld ist nun verpflichtend.

Entfernung von destinationParameters aus der Routing API

Aus dem /routes-Endpunkt der Routing API wurden die Felder routes.destinationParameters und routes.destinationParametersSignature entfernt. In den 3.x.x-Versionen der SDKs finden sich die Felder ebenfalls nicht mehr an den entsprechenden Objekten. Die vormals hier enthaltenen Informationen können über die Submission API über GET /destinations/{destinationId} bezogen werden.

Änderungen für Anbindungen mit dem Java SDK

Mit dem Major Release FIT-Connect 2.0.0 wurden sämtliche API-Endpunkte auf die neue Version /v2 umgestellt. Das Java SDK wurde entsprechend angepasst. Damit unterstützt das JAVA SDK nun auch vollständig die neuen FIT-Connect Strukturen und Metadatenmodelle.

Die wichtigste Änderung betrifft die API-Versionierung. Alle relevanten Endpunkte, insbesondere die für Submission, Destination und Routing, verwenden nun die neue Version /v2. Bestehende Methodenaufrufe bleiben weiterhin nutzbar, sofern die aktuelle SDK-Version eingebunden ist. Eine Aktualisierung auf die Version 2.0.0 ist daher erforderlich, um volle Kompatibilität mit der neuen Infrastruktur zu gewährleisten.

Das Java SDK arbeitet nun vollständig mit dem Metadatenschema 2.x. Dieses Schema bildet die Grundlage für eine einheitliche und standardisierte Übertragung von Antragsdaten. Das Schema ist abwärtskompatibel, erfordert jedoch bei der Validierung und Verarbeitung von Metadaten gegebenenfalls kleinere Anpassungen in den referenzierten Schema-URIs.

Ein weiterer Schwerpunkt liegt auf der sicheren Zertifikatsverwaltung. Das SDK unterstützt die neuen FIT-Connect Sicherheitsmechanismen, insbesondere die Verwendung von JSON Web Keys (JWK) und verschlüsselten Schlüsselcontainern. Dadurch wird die Sicherheit der Datenübertragung weiter erhöht.

Zusätzlich wurden Verbesserungen an der Fehlerbehandlung vorgenommen. Exception-Typen wurden vereinheitlicht und um eindeutige Statuscodes ergänzt, um die technische Analyse im Fehlerfall zu erleichtern und die Integration in bestehende Monitoring-Systeme zu verbessern.

Die Version 3.x des JavaSDKs führt Breaking Changes ein die die folgenden Code-Updates erfordern.

1. Klassenumbenennungen

Alte Klasse	Neue Klasse	Package
ServiceType	PublicService	dev.fitko.fitconnect.api.domain.model.submission
StatusEnum	Status	dev.fitko.fitconnect.api.domain.model.destination
DestinationService	Service	dev.fitko.fitconnect.api.domain.model.destination

2. Eigenschaftsumbenennungen

Klasse	Alte Eigenschaft	Neue Eigenschaft
Submission	serviceType	publicService
AnnounceSubmission	serviceType	publicService

3. Entfernte Methoden

Die folgenden Methoden wurden vollständig entfernt:

Attachment.fromString(String content, String mimeType)
Attachment.fromString(String content, String mimeType, String fileName, String description)

4. Collection-Typ-Änderungen

Klasse	Eigenschaft	Alter Typ	Neuer Typ
SubmissionsForPickup	submissions	Set<SubmissionForPickup>	List<SubmissionForPickup>

5. Entfernte Felder

Klasse	Entferntes Feld
Submission	callback
Route	destinationParameters
Route	destinationParametersSignature

Weitere Informationen und Hinweise zur Integration finden Sie auf der Seite zum Java SDK.

Änderungen für Anbindungen mit dem .NET SDK

Mit der Veröffentlichung des FIT-Connect .NET SDK 3.0.0 am 27. Oktober 2025 wurde die Kompatibilität mit der FIT-Connect API Version 2.0 eingeführt. Diese Veröffentlichung ist Teil des ersten jährlichen Major Releases und bildet den Grundstein für die zukünftige Weiterentwicklung und Vereinheitlichung der API-Strukturen.

Das Update umfasst eine vollständige Migration aller API-Endpunkte auf die Version /v2. Dazu gehören insbesondere die Schnittstellen für Submission, Destination und Routing. Diese Migration wird durch die aktualisierten SDK-Clients automatisch umgesetzt. Entwickler:innen müssen daher keine manuellen Anpassungen im Anwendungscode vornehmen, da die Umstellung von den neuen Clients vollständig abgedeckt wird.

Ein wichtiger Bestandteil dieses Releases ist die Anpassung von Klassen und Eigenschaften. Das bisherige Property serviceType wurde in den Klassen Submission, AnnounceSubmission, SendableSubmission und SendableEncryptedSubmission in publicService umbenannt. Darüber hinaus wurde der Datentyp der Sammlung SubmissionsForPickup.submissions von Set<SubmissionForPickup> in List<SubmissionForPickup> geändert, um eine bessere Kompatibilität und eine konsistentere Verarbeitung zu ermöglichen.

Im Rahmen der Bereinigung wurden zudem nicht mehr benötigte Funktionen entfernt. Dazu zählen die callback-Property in der Klasse Submission sowie sämtliche Methoden Attachment.fromString(...), die bereits in der Version 2.x als veraltet gekennzeichnet waren. Diese Änderungen verbessern die Übersichtlichkeit des SDKs und reduzieren potenzielle Fehlerquellen.

Das Update führt außerdem eine erneute Validierung auf Basis von URN-Schemata ein, um eine verbesserte Datenkonformität sicherzustellen. Gleichzeitig wurden verschiedene Abhängigkeiten aktualisiert, darunter Testcontainers-dotnet auf Version 4.8.1 und WireMock.Net auf Version 1.15.0, wodurch Stabilität und Testabdeckung weiter verbessert wurden.

Für die Nutzung des SDKs ist es erforderlich, auf die Version 3.0.0 zu aktualisieren. Im Anschluss sollten Entwickler:innen prüfen, ob in ihren Anwendungen veraltete Methoden wie Attachment.fromString verwendet werden, und gegebenenfalls Anpassungen vornehmen. Ebenso sollte ein Testlauf in der FIT-Connect-Testumgebung durchgeführt werden, um die reibungslose Kommunikation mit den /v2-Endpunkten sicherzustellen. Optional kann auch überprüft werden, ob die neue Property publicService korrekt genutzt wird.

Weitere Informationen und technische Details finden Sie im Changelog des .NET SDKs.

Änderungen für Anbindungen ohne SDK

Basis-URLs und Pfade

Für API-Requests sind die Basis-URLs, die auf der Seite Betriebs-Umgebungen der FIT-Connect Infrastruktur beschrieben sind zu verwenden. (Die v1-API ist derzeit noch auf einigen bereits abgekündigten Domains wie submission-api-prod.fit-connect.niedersachsen.de verfügbar, aber die v2-APIs werden auf diesen Domains nicht zur Verfügung gestellt.) Zu beachten ist auch, dass alle Request-Pfade nun /v2 beinhalten, wie in den API-Specs beschrieben. Ein valider Request-Pfad, um in der produktiven Umgebung Submissions abzuholen, wäre also https://prod.fit-connect.fitko.net/submission-api/v2/submissions.

In den v2-APIs sind alle Request-Pfade grundsätzlich nur noch ohne Trailing-Slash zulässig. Das bedeutet, dass https://prod.fit-connect.fitko.net/submission-api/v2/submissions korrekt ist, nicht jedoch https://prod.fit-connect.fitko.net/submission-api/v2/submissions/!

Verbot der Verwendung des JWE "zip" Headers

Die Verwendung des JWE "zip" Headers ist aufgrund von Sicherheitsbedenken nicht empfohlen (siehe RFC 8725, Sec. 3.6). Mit FIT-Connect 2.0 ist die Verwendung dieses Header nun explizit verboten, d.h. JWEs mit gefülltem "zip" Header werden abgelehnt. Dies betrifft den Upload sämtliche JWEs, sowohl Anhänge als auch Fach- und Metadaten von Submissions und Replies.

Umbenennung von serviceType und services

In den Request- und Response-Bodies der Submission API wurde das serviceType-Objekt in publicService umbenannt. Dies betrifft die Endpunkte:

• POST /v2/submissions
• PUT /v2/submissions/{id}
• GET /v2/submissions/{id}

Im Response-Body der Submission API wurde services in publicServices umbenannt. Dies betrifft den Endpunkt GET /v2/destinations/{id}.

In den Request- und Response-Bodies der Destination API wurde das services-Array in publicServices umbenannt. Dies betrifft die Endpunkte:

• POST /v2/destinations
• PUT /v2/destinations/{id}
• PATCH /v2/destinations/{id}
• GET /v2/destinations/{id}
• GET /v2/destinations

Diese Umbenennung soll zu einer besseren Verständlichkeit der Felder führen, welche ja eine Verwaltungsleistung repräsentieren.

replyChannels auf Wurzelebene

Im Response-Body des GET /v2/submissions/{id}-Endpunkts der Submission API wurde bisher ein replyChannels-Objekt auf Wurzelebene zurückgeben. Das Feld wurde schon vor einiger Zeit abgekündigt und ist nun vollständig entfernt worden. replyChannels sind jetzt nur noch unterhalb des publicServices-Arrays zu finden.

In der Destination API ist eine analoge Änderung in den folgenden Request- und Response-Bodies zu beachten:

• POST /v2/destinations
• PUT /v2/destinations/{id}
• PATCH /v2/destinations/{id}
• GET /v2/destinations/{id}
• GET /v2/destinations

Status-Codes und Header

Der PUT /v2/submissions/{id}-Endpunkt der Submission API gibt im Erfolgsfall nun HTTP 200 zurück (statt wie zuvor 202). Zwecks Konformität mit dem HTTP-Standard geben die Endpunkte POST /v2/replies und POST /v2/submissions jetzt einen Location-Header mit relativer URL zur angelegten Ressource zurück. Diese Header muss aber nicht ausgewertet werden.

Abruf von Destinations über die Submission API

In der Submission API können über GET /v2/destinations/{id} ohne Authentifizierung die öffentlichen Informationen eines Zustellpunkts abgeholt werden. Daran ändert sich nichts. Die v1-API hatte aber die zusätzliche Eigenschaft, bei entsprechender Autorisierung des anfragenden Clients, zusätzlich private Felder zurückzugeben (name, possibleNextStatus, contactInformation, callback, senderAccessRestricted). Dies ist nun nicht mehr der Fall.

Die Änderung erfolgt, um die beiden APIs klar nach Anwendungsfällen zu trennen:

• Die Submission API ist für das tägliche Geschäft rund um Einreichungen.
• Die Destination API ist für die optionale programmatische Verwaltung von Zustellpunkten.

Das jwk.use-Feld

In beiden APIs wurde das Feld use aus dem Response-Body von GET /v2/destinations/{id}/keys/{id} entfernt. In der Destination API wurde zusätzlich das Feld keys.use aus GET /v1/destinations/{destinationId}/keys entfernt. Das Feld enthält bereits in der v1-Version ausschließlich den Wert null. (Inhaltlich wird für die Unterscheidung von Schlüsseltypen nach wie vor das Feld key_ops verwendet.)

Das callback-Feld

In der Submission API wurde das Feld callback aus dem Response-Body von PUT /v2/submissions/{id} entfernt.

Häufig gestellte Fragen

Muss man, nachdem man in seinem Zustellpunkt die Metadatenversion v2 aktiviert hat, die DestinationSignature im Landesredaktionssystem bzw. im PVOG aktualisieren?

Nein. Die Aktivierung der Unterstützung für eine neue Metadatenversion (wie Metadatenschema 2.0.0, eine der wichtigen Neuerungen des Major Releases) ist eine Information, die das Fachverfahren im Self-Service-Portal (SSP) einträgt. Die DestinationSignature muss im PVOG nur dann aktualisiert werden, wenn eine Änderung der unterstützten Leistungen oder der Regionen, in denen diese Leistungen angeboten werden, vorgenommen wurde.

Muss die Destination Signature im PVOG aktualisiert werden, wenn beim Regionalschlüssel oder bei der Verwaltungsleitung etwas geändert wird?

Ja. Die Aktualisierung der DestinationSignature im PVOG (Landesredaktionssystem) ist zwingend erforderlich, sobald sich die von Ihrem Zustellpunkt unterstützten Verwaltungsleistungen oder die Regionen (Regionalschlüssel), in denen diese Leistungen angeboten werden, ändern.

Ist beim Submission API 2.0 der Fachdatensatz noch optional?

Nein. Der Fachdatensatz ist nicht mehr optional. Mit dem Major Release und der Submission API 2.0 wird eine der verbindlichen Änderungen für alle Nutzenden umgesetzt: Es ist nun nicht mehr möglich, Einreichungen (Submissions) ohne Fachdaten zu versenden. Diese Anforderung manifestiert sich in den folgenden technischen Spezifikationen:

1. Submission API v2: Das Feld encryptedData beim Endpunkt PUT /v2/submissions/{submissionId} der Submission API ist jetzt verpflichtend.
2. Metadatenschema 2.0.0: Die Angabe von contentStructure.data im Metadatensatz 2.0.0 ist nun verpflichtend, was im direkten Einklang mit der Entscheidung steht, Submissions ohne Fachdaten nicht mehr zuzulassen.

Was muss beachtet werden, wenn ein Onlinedienst die Submission-API 1.0 verwendet und das Verwaltungssystem die Submission-API v2?

Die Version 1.x und die Version 2.x der APIs werden für eine Übergangsfrist von einem Jahr parallel unterstützt. Dies gewährleistet die Interoperabilität zwischen Systemen, die bereits auf v2 migriert haben, und anderen Beteiligten, die noch v1 verwenden. Es ist entscheidend, dass die verwendete Metadatenversion und das darin enthaltene Fachdatenschema (contentStructure.data) zwischen dem Onlinedienst und dem Fachverfahren kompatibel sind und zusammenpassen. Allen Fachverfahren wird empfohlen, das Metadatenschema 2.0.0 technisch zu unterstützen und dies im Self-Service-Portal einzutragen.

Wo wird der JWE zip-Header gesetzt bzw. wo sollte dieser nicht mehr gesetzt werden?

Der JWE-String an sich (bestehend aus base64-Zeichen und dem Punkt als Trenner) enthält neben der verschlüsselten Payload auch eine Header-Sektion. In dieser würde man den zip-Header finden.

Die Kommunen werden nicht zeitgleich auf das Metadatenschema 2.0 umstellen. Ein Onlinedienst, der verschiedene Kommunen anschließt, muss auf die SDK Version 3.x.x wechseln. Geht das?

Die Kommunen geben im Self-Service-Portal an ihren Zustellpunkten selbst an, welche Metadatenschema-Version sie unterstützen. Auch mit SDKs der Version 3.x.x können weiterhin Metadaten der Version 1.x.x gesendet werden. Der Onlinedienst kann also jederzeit auf SDK-Version 3.x.x upgraden. Vor dem Einreichungsversand würde dieser dann den Ziel-Zustellpunkt abrufen und je nach unterstützen Metadatenschema-Versionen die Metadaten in einem älteren oder dem neuen Schema versenden.

Ist es möglich, mit der Submission-API 2.0 bei Anfrage auf neue Submissions nach Leistung zu filtern?

Nein, das Filtern nach Verwaltungsleistung (Leistung) ist bei der Abfrage neuer Submissions über die Submission-API 2.0 nicht möglich.

Wann wird es das SDK für neues FIT-Connect geben?

Das Software Development Kit (SDK) für das neue FIT-Connect (Major Release 2.0) wird in Version 3.0.0 demnächst bereitgestellt.

Wird im Java-SDK 3.x.x weiterhin eine veraltete Version der Bibliothek <code>nimbus-jose-jwt</code> verwendet werden?

Es sollte möglich sein, die Bibliothek nun zu aktualisieren. Im Zuge des Major Releases wurden die SDKs (Java und .NET) technisch überarbeitet (Refactoring/Modularisierung) und müssen auf die Version 3.0.0 oder höher umgestellt werden. Die Möglichkeit zum Upgrade der Bibliothek hängt direkt mit einer spezifischen Änderung des Major Releases zusammen, die die Notwendigkeit einer vorherigen technischen Einschränkung von Komprimierung und Größenlimitierung aufhebt:

• Mit FIT-Connect 2.0 ist die Verwendung des JWE "zip" Headers nicht mehr möglich und können durch den Empfänger nicht entschlüsselt werden.
• Diese nicht mehr mögliche Entschlüsslung gilt für den Upload sämtlicher JWEs, darunter Anhänge sowie Fach- und Metadaten von Submissions und Replies.
• Dieses Vorgehen wurde aufgrund von Sicherheitsbedenken ausgesprochen (siehe RFC 8725, Sec. 3.6).
• Die bisherige Beschränkung auf JWE-Payloads, die im Zusammenhang mit der Komprimierung standen, greift ohne die Verwendung des "zip" Headers nicht mehr ("Ohne Komprimierung greift keine Größenlimitation für JWE-Payloads mehr").

Da der technische Blocker (die Notwendigkeit der Komprimierung) entfällt, sollte das Java-SDK 3.0.0 oder höher in der Lage sein, die Bibliothek nimbus-jose-jwt in einer aktuellen Version zu verwenden.

Welche Umgebungen und Komponenten von FIT-Connect sind betroffen?

Betroffen sind sämtliche Umgebungen – also Test-, Stage- und Produktionsumgebung. Auf eine Version 2.x angehoben werden alle FIT-Connect-Komponenten, darunter die APIs (Destination API, Submission API und Routing API), das Metadatenschema sowie der Zustelldienst, das Self-Service-Portal und der Routingdienst.

Werden Zustellpunkte automatisch unbenutzbar, wenn alle ihre unterstützen Metadaten-Versionen ausgelaufen sind?

Ja, ein Zustellpunkt wird faktisch unbenutzbar für neue Einreichungen, sobald alle von ihm unterstützten Metadaten-Versionen ihre Gültigkeit verlieren. Das Anbindungsmanagement-Team wird proaktiv auf betroffene Nutzende zugehen, um diese Situation abzufangen und die notwendige Umstellung zu begleiten. Wir empfehlen daher jedem Fachverfahren das neue Metadatenschema in Version 2.0.0 technisch zu unterstützen und diesen Status im Self-Service-Portal (SSP) einzutragen. Das Metadatenschema 2.0.0 bietet zudem inhaltliche Erweiterungen und Optimierungen.

Werden SDKs der Version 3.x.x weiterhin Submissions mit älteren Metadaten-Versionen empfangen können?

Ja, diese können alle Schemata noch verstehen. Abgekündigte Schemata können aber nicht mehr verwendet werden; hier schlägt unter Umständen bereits das Senden fehl.

Was ändert sich konkret, wenn das Self-Service-Portal (SSP) nach dem Major Release genutzt wird?

Das Self-Service-Portal (SSP) wird mit dem Major Release umfassend modernisiert und durch neue Funktionen erweitert. Die wichtigsten Änderungen betreffen die Benutzerfreundlichkeit:

1. Neues Design: Die Oberfläche erhält ein neues Design mit aktualisierten UI-Komponenten, die die Inhalte übersichtlicher gestalten.
2. Entwurfsmodus für Zustellpunkte: Es wird ein Entwurfsmodus (Draft-Modus) eingeführt. Dieser erlaubt es, Zustellpunkte als Entwurf anzulegen und die Veröffentlichung zu einem späteren Zeitpunkt durchzuführen.
3. Verbesserte Navigation: Eine Pagination (Seitenumbruch) wird eingeführt, um die Navigation und Übersichtlichkeit in großen Listen zu erleichtern.
4. Wichtige Hinweise: Neue Banner werden eingeführt, um wichtige Hinweise visuell hervorzuheben und direkt sichtbar zu machen.
5. Vereinfachtes Login: Das Login-Verfahren wird durch eine Login-Konsolidierung vereinfacht und vereinheitlicht.