Rückkanal

Summary

Es soll ermöglicht werden, über FIT-Connect auch fachliche Nachrichten zwischen Sende und Empfänger in einem Dialog nach einer initialen Submission auszutauschen.

  1. Übermittlung des Rückkanalwunsches
  2. Mitteilung über eine abholbereite Reply über den Callback aus der Submission an den Sender
  3. Mitteilung über eine abholbereite Reply über den Callback der Destination an den Subscriber
  4. Darstellung von abholbereiten Replies über GET an eine Destination oder einen Case
  5. Übermittlung einer Reply über einen Case
  6. Übermittlung eines SET an eine Reply Ressource
  7. Bereitstellung eines Security Event Log über die Reply Ressource
  8. Event Log auf Ebene Case
  9. Zugriffabsicherung für den Sender
  10. Statusmodell für Case

Annahme:

Wir haben im API V1 in den Rückkanaloption der Destination schon die FIT-Connect Option eingebaut, um einen Breaking Change in V1.1 zu vermeiden. Ansonsten weitere Story hierfür.

Architekturfragestellung:

Entscheidung 1: Muss ein Rückkanal explizit gewünscht werden (Siehe Story 1) oder muss der Sender es einfach unterstützen? - Entscheidung: Sinnvoll, da -

Entscheidung 2: Was muss in den verschlüsselten Metadaten sein und was im Klartext. -

Story 1: Übermittlung des Rückkanalwunsches

Als sendendes System will ich in der Submission dem empfangenden System mitteilen, dass ich über FIT-Connect bilateral kommunizieren will und gemäß welchem Fachstandard diese bilaterale Kommunikation entspricht.

Ein Public Key für die Verschlüsselung, damit dieser die Rückantwort verschlüsselt empfangen kann. Eine Referenz auf den Prozessstandard der genutzt werden soll. Ein Callback, damit der Sender über eine Rückantwort informiert wird.

Der Public Key und Referenz auf den Prozessstandard wird dem Empfänger zugeleitet.

Ein Callback ist nur für den Zustelldienst.

Davids Notizen Beim Anlegen einer Submission notwendig:
  • Callback -> wird dem Case zugeordnet
  • Public Key -> wird dem Case zugeordnet
  • Prozessstandard f. Kommunikation -> URN

wenn nicht beides in Art von Destination hinterlegt, dann nur eine Referenz auf jene. Public Key könnte auch in Metadaten verpackt sein

Story 2: Mitteilung über eine abholbereite Reply über den Callback aus der Submission an den Sender

Davids Notizen GET /cases//replies/ { ... }

Story 3: Mitteilung über eine abholbereite Reply über den Callback der Destination an den Subscriber

Story 4: Darstellung von abholbereiten Replies über GET an eine Destination oder einen Case

Davids Notizen Unterscheidung welche Replies relevant sind via Token bzw. Scope

GET /cases//replies/ { replies: [{...},...] }

Story 5: Übermittlung einer Reply über einen Case

Davids Notizen POST /cases//replies/ { announcedContentStructure: {...} }

...

PUT /cases//replies/ { ... }

Datenstruktur ist identisch zu einer Submission

Story 6: Abbildung und Nachweis der Übermittlungsvorgänge in einer Reply über einen Security Event Log (Zusammengefasst aus der ursprünglichen Story 6 und 7) --> Idee wird im Rückkanal nicht umgesetzt, sondern alle Vorgänge werden nur über einen Case Event Log abgebildet

Als Kommunikationspartner (Sender oder Empfänger) oder dritte Party möchte ich alle Events einer Reply über einen Security Event Log nachweissicher nachvollziehen können.

Offener Diskussionspunkt für die Umsetzung:

  • Es gibt keine PKI basierte Zertifikatskette für Sender. Eine Signatur eines SET zu prüfen oder zu Vertrauen ist sehr schwierig. V-PKI ist nicht für alle machbar und erhöht auch wieder die Komplexität für Sender. Weitere PKIs einzubinden, erhöht auch wieder die Gesamtkomplexität.
    • Eine einfache Lösung wäre es, alle SETs durch den Zustelldienst erstellen und signieren zu lassen
Davids Notizen POST /cases//replies//events asdafnjafslk.asdjbfaspoasf 
-> Über welche Events kann ein Online-Service auf eine Reply antworten?
Davids Notizen -> User Value?! 
```
GET /cases/<uuid>/replies/<uuid>/events

```

Case: - Beide Kommunikationspartner

Story 7: Event Log auf Ebene Case 
- Pfad für Event Log abzurufen oder einzustellen
- Event Log erweitern (Wird haben ein Closed, aber kein Open Event)
Davids Notizen -> Event?: Submission submitted -> Event?: Reply eingegangen

Story 8: Zugriffabsicherung für den Sender

  • Option Einfach: An die Client-ID binden
    • Case ist an Access Token mit dieser Client-ID gebunden
  • Option Rocketscience: Case Schlüssel aka DPOP

Story 9: Statusmodell für Case

Idee: Autoclose nach einem Jahr ohne Aktivität

Davids Notizen
URL Supported methods Description
Destination
/destinations GET, POST
/destinations/<uuid> GET, PATCH, PUT, DELETE
/destinations/<uuid>/keys GET, POST->PUT?
Anlage einer Submission
/submissions GET, POST
/submissions/<uuid> GET, PUT
/submissions/<uuid>/events GET, POST
/submission/<uuid>/attachments/<uuid> GET, PUT
Case
/cases GET
/cases/<uuid> GET
/cases/<uuid>/events GET, POST
Submission eines Cases
/cases/<uuid>/submission GET
/cases/<uuid>/submission/attachments/<uuid> GET
/cases/<uuid>/submission/events GET, POST
Antworten
/cases/<uuid>/replies GET
/cases/<uuid>/replies/<uuid> GET, POST, PUT
/cases/<uuid>/replies/<uuid>/events GET, POST
/cases/<uuid>/replies/<uuid>/attachments/<uuid> GET, PUT

FIT-Connect_Rückkanal.pptx

Edited by Alexander Hoose