Skip to content
Snippets Groups Projects
New look: Off

Rückkanal

    • Closed Issue created by David Schwarzmann @David_Schwarzmann

    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

    0 of 10 checklist items completed · Edited

    Designs

      Child items ...

      2. Activity

      Please register or sign in to reply