[Epic] Bidirektionale Kommunikation (Rückkanal)

Warum?

Es soll die Rückkanal Erweiterung der Submission implementiert werden, die hier spezifiziert ist: #42

Relevante Links und Bemerkungen

API Spec Issue: #42 API Spec MR: submission-api!132 Dokumentation der neuen Events: docs!180 Schema der neuen Events: event-payload!1

Initiale Ticket Schnitte @Andreas_Huber & @Jonas_Groeger: https://md.darmstadt.ccc.de/rueckkanal-tickets#

Ablauf der API Nutzung

Click to expand

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

1. Die Implementierung der Submission API im Zustelldienst ist gemäß den Vorgaben aus #42 erfolgt.
2. Die neue Implementierung der Submission API im Zustelldienst und die neuen Schemata wurden auf Abwärtskompatibilität getestet. Ggf. auch mit den .Net und Java SDKs geprüft.
3. Die Implementierung im SSP ist gemäß den Vorgaben aus #42 erfolgt.
   • Destinations können mit den zusätzlichen Parametern für einen Rückkanal über FIT-Connect umgesetzt werden
   • Für Clients können die notwendigen Scopes hinterlegt werden
4. In der Dokumentation wurden alle Aspekte der Umsetzung durch Subscriber und Sender beschrieben.
5. Mit der Veröffentlichung der Dokumentation wurden auch die Aktualisierungen der API Spec und Schemata (Metadata und Security Event Token durchgeführt)
6. Die Einträge in den Collection-Resourcen sind zeitlich aufsteigend (neueste zuletzt) zu sortieren (ORDER BY id). Betrifft:
   • GET /v1/replies
   • GET /v1/cases
   • CaseInformation/caseMessages <- Hier reicht ORDER BY id nicht, da sie aus zwei Tabellen kommen.
7. Die spätere Umsetzung von #516 führt zu keinen Problemen.

Alte Sammlung von Akzeptanzkriterien und Issue-Verweisen

1. Die Implementierung im Zustelldienst ist gemäß den Vorgaben aus #42 erfolgt.
2. In der Dokumentation wurde das Rückkanal-Feature in einem Überblicks-Artikel beschrieben. -> #515
3. In der Dokumentation wurde das Rückkanal-Feature aus Sender-Sicht beschrieben. -> #515
4. In der Dokumentation wurde das Rückkanal-Feature aus Subscriber-Sicht beschrieben. -> #515
5. In der Dokumentation wurden alle neuen Events beschrieben (siehe https://git.fitko.de/fit-connect/konzepte/-/blob/main/Event_Log.md). -> #515
6. Im Glossar ist der Begriff processStandards definiert -> #514 (closed)
7. Die Einträge in den Collection-Resourcen sind zeitlich aufsteigend (neueste zuletzt) zu sortieren (ORDER BY id). Betrifft:
   • GET /v1/replies
   • GET /v1/cases
   • CaseInformation/caseMessages <- Hier reicht ORDER BY id nicht, da sie aus zwei Tabellen kommen.
8. Nach dem Schließen eines Cases dürfen keine Einreichungen und Antworten mehr begonnen oder abgesendet werden. Folgende Events dürfen nach einem close-case nicht mehr auftreten: create-submission, submit-submission, create-reply, submit-reply.
9. Der Zustelldienst prüft die Zugriffsberechtigung des Senders anhand des sub-Claims (Subject).
10. DVDV und Routing-Dienst / Routing API angepasst (Verbundendes Issue #278 prüfen)
11. SSP für FIT-Connect Rückkanal Option angepasst

Stories zur Umsetzung der Akzeptanzkriterien im EPIC

Backend Stories

• #506
• #507
• #509
• #510
• #511
• #512
• #513

Ergänzend Umsetzung von folgendem Issue prüfen: #278 (aktuell in Buffer und nicht in Ready)

Frontend Stories

• #508

Abwärtskompatibilität

Offener Punkt: Eigenes Issue?

Doku Stories

• #515
• #514 (closed)
• #115 (Sollte sinnvollerweise hier aufgegriffen werden, da der Rückkanal nun bedeutender wird.

Klärungspunkt: Wie sinnvoll die einzelnen Issues umsetzen und in Main mergen?

Durchführungsplan (vom Entwickler bei Storyplanung auszufüllen)

• Implementierung im Zustelldienst (API-Verhalten & Erstellung von SETs)
• Rückkanal-Möglichkeiten im SSP ist angepasst
• Aufnehmen ins Glossar: processStandards
• Die Client-IDDer Subject-Claim (sub) des Senders wird in den Case übernommen.
• Die Client-IDDer Subject-Claim (sub) aus dem Case wird bei allen Zugriffen des Senders geprüft. Achtung: Zugriffe des Subscribers werden weiterhin über die Destination geprüft.
• ...
• Definition of Done wurde geprüft