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 alle gleichzeitig auf das Metadatenschema 2.0 umstellen. Ein Onlinedienst, der verschiedene Kommunen anschließt, muss aber zu einem Zeitpunkt 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.