PoC BundID ZBP - Nachrichtenversand in transmissions oder eigenen Endpunkten
Ausgangslage
Mit der Anbindung des BundID ZBP haben wir einen ersten am Antrag beteiligten dritten Akteur neben dem bisherigen Sender und Subscriber.
Zielsetzung
Am Ende dieser Story sollten wir in der Lage sein zu entscheiden, ob wir die Anbindung des BundID ZBPs ohne ein größeres Refactoring des Konstruktes rund um submissions / replies umsetzen können. In die Entscheidung soll die mittel bis langfristige Weiterentwicklungsfähigkeit von FIT-Connect einbezogen werden.
Links, Hinweise, Bemerkungen
Kernfragen:
- Sollte die Nachricht des FV an das ZBP als eine Reply abgebildet werden? [long]
- Bürger wird in Zukunft auf ZBP-Nachrichten antworten können - ist es dann eine neue submission?
- Statusupdates an den Statusmonitor werden im nächsten auch an das ZBP übermittelt werden [mid]
- wird das auch über Replies oder etwas anderes abgebildet?
- Verfolgen wir einen generischen Endpunkt (angenähert an submissions / replie) oder spezifisch für die BundID
- Bald müssen wir weitere Postfächer anbinden. Unternehmenskonto, EUDI Wallet - teilweise bereits bidirektional [mid]
- erweiterte Unternehmensszenarien - weitere öffentliche oder private Beteiligte sollten an einem Case sowohl vom Sender oder Empfänger kontaktiert werden [mid]
- wie behalten wir bei der Weiterentwicklung die Übersicht (Logs, Fristen, Prozesse) [long]
- bei Weiterentwicklungen werden wir für alle Anbindenden wahrscheinlich sehr ähnliche Prozesse nachziehen müssen [long]
- wie schaffen wir es eine transparenz in der Doku auch beizubehalten [long]
- Fachdatenschema/Prozessstandards - nicht relevant für ZSD, jedoch für den ZBP-Adapter
- falls wir das Konzept der Submission & Reply verwenden müssen wir wahrscheinlich einen generischen Standard ausspielen (Andreas hat hierzu einen Entwurf gemacht), dann wäre auch zu klären wie wir es in Richtung FIM spielen
- Welche Auswirkungen hätte die angedachten Refactorings auf auf den EventLog
- Welche Auswirkungen hätte die angedachten Refactorings auf auf die Security- / Validierungsmaßnahmen
LEGENDE:
- [mid] - mittelfristig - Q4 / Q1
- [long] - langfristig ab Q2 2025
- rest bleibt sehr kurzfristig relevant
Mögliche Folgeaktivitäten (vom Entwickler zu ergänzen)
-
... -
... -
... -
Definition of Done was checked.
Edited by Wojciech Gdaniec