Spezifikation Bidirektionale Kommunikation in FIT-Connect

Warum machen wir das?

Als empfangendes System möchte ich dem sendenden System einer initialen Submission über FIT-Connect eine Antwort schicken können, um Rückfragen, Prozessanweisungen oder Bescheide im Rahmen des Verwaltungsverfahren zu übermitteln. Dafür möchte ich einen einfach zu implementierenden Adressierungsmechanismus angeboten bekommen, der auch für langlaufende Verwaltungsverfahren zuverlässig nutzbar ist, weil dieser Adressierungsmechanismus auch mit Änderungen der Adressparameter umgehen kann.

Ich möchte als empfangendes Systemen vor einer initialen Submission allen potentiellen Kommunikationspartnern mitteilen, nach welchem Prozessstandard ich bereit bin, in einem Verwaltungsverfahren bilateral zu kommunizieren, damit die technisch Voraussetzungen und Pflichten bei einem sendenden System vor der Entscheidung des Nutzers für einen FIT-Connect basierten Rückkanal bekannt sind.

Als sendendes System möchte ich für meinen Nutzer eine Ende zu Ende Kommunikation bis zum Bescheid für meinen Nutzer anbieten können. Ich möchte eine Auswahl anbieten können, ob der Rückkanal über FIT-Connect genutzt wird und der empfangenden Seite mitteilen, nach welchem der Prozesstandards, die die empfangende Seite unterstützt, erfolgt.

Als sendendes System möchte ich meine Kommunikationsparameter für die Rückantwort einheitlich anpassen können, falls sich Änderungen im Zeitverlauf ergeben.

Relevante Links und Bemerkungen

Wiki: https://wiki.fit-connect.fitko.dev/de/Konzeption/verworfen/R%C3%BCckkanal

- Hinweis aus Event Schema Bug Ticket: Für neue Events die Schema Version hochziehen

Funktionale Anforderungen

Wiki: https://wiki.fit-connect.fitko.dev/de/Konzeption/verworfen/R%C3%BCckkanal

- Hinweis aus Event Schema Bug Ticket: Für neue Events die Schema Version hochziehen

Aufgaben

API

Events:

Spiegelevents für Reply
~~Freigabe zur Vorgangsschließung~~
~~Vorgang geschlossen~~

Diskussionspunkte

Muss der Sender dem Zustelldienst ankündigen, ob die Kommunikation bidirektional ist?
- -> ~~JA: POST /v1/submssions { ..., "bidirectional": "true" }~~
- -> NEIN: Bidirektionale Kommunikation ist ausschließlich ein Protokoll zwischen Sender und Subscriber (Reply-Channel ist dann FIT-Connect)
~~Ist encryptedMetadataabsichtlich optional? ~~~~~~~~~~~~https://preview.docs.fitko.dev/submission-api/bilateral-communication/#get-/v1/replies/-replyId-~~
~~Beim Reject muss problems required sein. ~~~~~~~~~~~~https://preview.docs.fitko.dev/submission-api/bilateral-communication/#put-/v1/replies/-replyId-/reject~~
~~Wozu dieses "Schließen vormerken"? Wenn eine Seite nicht mehr will macht sie den Case einfach zu.~~
~~finalClosure könnte ein string mit Format date-time sein. Oder erklären, dass ein UNIX timestamp verwendet wird.~~ (Anmerkung: Cases haben keinen Zustand und werden nicht geschlossen)
"GET Cases Endpunkt":
- Sender: Wir haben keine Ownership im Zustelldienst. Auch der OAuth-Server weiß nichts über Cases. Die einzige Absicherung zum Zugriff auf Cases ist, die UUID zu kennen.
  - Zugriff auf Replies und Zuordnung von Cases / Replies basiert auf der ~~Client-ID~~ dem Subject des Senders
- Subscriber: Das ginge:
  - Wir nehmen alle Destinations aus dem Token,
  - suchen dazu alle Submissions (auch beendete) und
  - erhalten eine Liste aller Cases.
- -> Cases werden im Zustelldienst der ~~Client-ID~~ dem Subject des Senders zugeordnet.
Wird es ein forward-reply Event geben? Z.B. wenn das Antragssystem die Antwort an ein Servicekonto weiter gibt.
- Falls ja, muss ein entsprechender REST-Endpunkt geschaffen werden.
- -> NEIN

Ablauf

Überarbeitetes Diagramm:

%% You may edit this on https://mermaid.live

sequenceDiagram

autonumber

participant OS as Onlineservice
participant FC as FIT-Connect
participant FV as Fachverfahren

loop Nutzung des bidirektionalen Kommunikation

    %%  Prüfung, ob Fachverfahren den Rückkanal FIT-Connect unterstützt
    OS ->> FV: Zustellpunkt (Destination) abrufen
    FV -->> OS: Zustellpunktdetails mit Rückkanaloptionen
    
    %% Vorgangsspezifischen Schlüssel erzeugen
    opt Falls Rückkanal genutzt wird soll und noch kein Schlüsselpaar vorhanden
        OS ->> OS: Generiere Schlüsselpaar (pro Vorgang / Antragsteller:in) für Antworten vom Fachverfahren
    end

    %% Submission mit Rückkanaloption FIT-Connect
    OS ->> OS: Metadatensatz mit öffentlichem Schlüssel des oben generierten Schlüsselpaars und Prozesstandards generieren
    OS ->> OS: Einreichung (Submission) mit öffentlichem Schlüssel des Zustellpunktes verschlüsseln
    alt Falls ein neuer Vorgang (Case) angelegt wird
        OS ->> FC: Einreichung mit Rückkanaloption FIT-Connect anlegen
        FC ->> FC: Vorgang anlegen mit initialer Einreichung anlegen
    else Falls ein bestehender Vorgang genutzt wird
        OS ->> FC: Einreichung an bestehenden Vorgang anfügen
    end
    OS ->> FC: Einreichung verschicken

    %% Submission verarbeiten
    FV ->> FC: Einreichung abrufen
    FV ->> FV: Ereignis (Security Event Token) für Accept / Reject generieren
    FV ->> FC: Ereignis mit Accept / Reject verschicken
    
    %% Reply
    FV ->> FV: Antwort (Reply) mit öffentlichem Schlüssel aus dem Metadatenschema verschlüsseln
    FV ->> FC: Antwort anlegen und verschicken

    %% Reply verarbeiten
    FC ->> OS: Antwort abrufen
    OS ->> FC: Antwort akzeptieren (Accept) oder zurückweisen (Reject)
    FC ->> FC: Ereignis (Security Event Token) für Accept / Reject generieren
end

Altes Diagramm:

sequenceDiagram
    autonumber
    loop Bidirektionale Kommunikation
    opt Falls noch kein Key vorhanden
    Sender->>Sender: Pro Vorgang (bzw. pro Antragsteller:in) einen Encryption Key für Rückkanal generieren
    end
    Sender->>Sender: Metadatensatz mit Encryption Key und Angabe zum Prozesstandard generieren
    Sender->>Sender: Submission Bestandteile mit dem Public Key der Destination verschlüsseln
    alt Falls ein neuer Case angelegt wird
    Sender->>Zustelldienst: Submission mit Rückkanaloption anlegen
    Zustelldienst->>Zustelldienst: Bidirektionalen Vorgang anlegen
    else Falls ein bestehender Case genutzt wird
    Sender->>Zustelldienst: Submission für ein bestehenden Case anlegen
    end
    Sender->>Zustelldienst: Submission übersenden
    Zustelldienst->>Subscriber: Einreichung abrufen
    Subscriber->>Subscriber: Security Event Token für Accept / Rejectgenerieren
    Subscriber->>Zustelldienst: Security Event Token übermitteln
    Subscriber->>Subscriber: Prozessstandard und Encryption Key aus dem Metadatenschema entnehmen
    Subscriber->>Subscriber: Reply Bestandteile mit dem Encryption Key verschlüsseln
    Subscriber->>Zustelldienst: Reply anlegen und übersenden
    Zustelldienst->>Sender: Reply abrufen
    Sender->>Zustelldienst: Accept oder Reject senden
    Zustelldienst->>Zustelldienst: Security Event Token für Accept / Reject generieren
    end
    opt Wenn der Zeitraum X bis zur closeTime des Cases erreicht wurde 
    par Subscriber über anstehende Schließung per Callback informieren
    Zustelldienst->>Subscriber: Callback mit Closetime
    and Sender über anstehende Schließung per Callback informieren
    Zustelldienst->>Sender: Callback mit Closetime
    end
    alt Falls der Case noch genutzt wird
    Subscriber->>Zustelldienst: Mit Patch Case (Open) die Closetime zurücksetzen
    else closeTime für den Case wird erreicht
    Zustelldienst->>Zustelldienst: Vorgangsschließung durchführen
    Zustelldienst->>Zustelldienst: Security Event Token (Close-case) für die Schließung generieren
    par Subscriber über neues Ereignis informieren
    Zustelldienst->>Subscriber: Ereignis Callback
    and Sender über neues Ereignis informieren
    Zustelldienst->>Sender: Ereignis Callback
    end
    end
    end
    Subscriber->>Zustelldienst: Mit Patch Case (Close) die Vorgangsschließung anweisen
    Zustelldienst->>Zustelldienst: Vorgangsschließung durchführen
    Zustelldienst->>Zustelldienst: Security Event Token (Close-case) für die Schließung generieren
    par Subscriber über neues Ereignis informieren
    Zustelldienst->>Subscriber: Ereignis Callback
    and Sender über neues Ereignis informieren
    Zustelldienst->>Sender: Ereignis Callback
    end

## Akzeptanzkriterien

Neue Spec-Version ist finalisiert
Alle neuen Events sind hier dokumentiert: ~~https://git.fitko.de/fit-connect/konzepte/-/blob/main/Event_Log.md~~
- derzeit hier: https://preview.docs.fitko.dev/fit-connect/bilateral-communication/docs/getting-started/event-log/events/
- nach Merge hier: https://docs.fitko.de/fit-connect/docs/getting-started/event-log/events

Durchführungsplan

Spec-Entwurf erstellen (Due: 03.12)
Spec abstimmen

Potentielle API Änderungsbedarfe:

Services sind in der Destination optional, damit auch eine Destination für Prozesskommunikation genutzt werden kann
Fähigkeit zur bilateralen Case Kommunikation in der Destination deklarieren und Prozessstandards hinterlegen
Case-ID Angabe in der Submissionanlage muss wirksam sein
- Case Event Log muss die dazugehörigen Submissions loggen
- Case-ID darf nicht überschrieben werden
Destinations ohne Services im Produktivkontext brauchen keine Zertifikate mit Verwaltungs-PKI
- Alternative wären bspw. Elster Zertifikate oder Zertifikate aus der Liste der EIDAS Siegel Anbieter zulässig (https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/Digital+Signature+Service+-++DSS#DigitalSignatureServiceDSS-Documentation)
- In der Dokumentation und in den Self-Service-Portal sollte hingewiesen werden, dass der Name (der Organisation) im Zertifikat dem Namen des Self-Service-Accounts entsprechend muss
In den Metadaten im Rückkanalobjekt für die FIT-Connect Option oder in der der API soll die Destination-ID für die Rückantwortnachricht hinterlegt werden können

Edited Mar 21, 2024 by Wojciech Gdaniec