diff --git a/news/2021-08-11-sprint-report-cw-32.md b/news/2021-08-11-sprint-report-cw-32.md index 2465a002a21d7d7bf5426449ee2f435e6c308eca..a81a85490f54a5760e2117cb39eac50d90aa25a1 100644 --- a/news/2021-08-11-sprint-report-cw-32.md +++ b/news/2021-08-11-sprint-report-cw-32.md @@ -18,10 +18,10 @@ Dieses Format soll nun bei jedem Sprintwechsel veröffentlicht werden. #### Finalisierung des Autorisierungskonzepts Im Rahmen dieser Story wurden begonnenen Arbeiten an Umstellung der OAuth Autorisierung für die API Zugriffe umgesetzt. Hierzu wurde Software gegen die neuen Tokens und Scopes getestet und die Dokumentation und API Spec aktualisiert. Wesentliche Neuerungen der neuen OAuth Autorisierung: -- Zugriff auf die Verwaltung von Zustellpunkten und Abruf von Einreichungen basiert nun auf Scopes und nicht mehr auf dem konkreten Client, der den Zustellpunkt erstellt hat. Dies erlaubt es, flexibel API-Clients auszutauschen, ohne hierfür die Destination neu anzulegen oder auch den Zugriff auf Zustellpunkte für mehrere API-Clients zu ermöglichen. +- Zugriff auf die Verwaltung von Zustellpunkten und Abruf von Einreichungen basiert nun auf Scopes und nicht mehr auf dem konkreten Client, der den Zustellpunkt erstellt hat. Dies erlaubt es, flexibel API-Clients auszutauschen, ohne hierfür den Zustellpunkt neu anzulegen oder auch den Zugriff auf Zustellpunkte für mehrere API-Clients zu ermöglichen. - Neue Zustellpunkte können nur noch durch das Self-Service-Portal erstellt werden. Die Verwaltung von Zustellpunkten ist jedoch weiterhin über die API möglich. -- Sendende Systeme können Access Token ... -- Um diese Berechtigungen bei Access Tokens von sendenden Systemen zu ermöglichen. Müssen nun in den Zustellpunkten die ... +- Sendende Systeme können Access Token mit Scopes abrufen, die nur für Zustellpunkte mit bestimmten Leistungen und Regionen gültig sind, um hiermit den Berechtigungsumfang weiter einzuschränken. Wird von dieser Option kein Gebrauch gemacht, ist der Scope des Access Token für alle Regionen und Leistungen in Deutschland gültig. + - Um diese Berechtigungen bei Access Tokens von sendenden Systemen zu ermöglichen, müssen nun in den Zustellpunkten die Leistungs-IDs (bspw. Angabe eines Leika Schlüssel) und die Region-ID (aktuell ARS) verpflichtend angegeben werden, die in diesem Zustellpunkt abgebildet werden. Leistungen, die nicht über den ARS abgebildet werden oder keinen Ortsbezug haben, werden in dem Zustellpunkt mit DE angeben werden. https://docs.fitko.de/fit-connect/docs/getting-started/authentication @@ -33,11 +33,11 @@ Daher wurde ein neuer Endpunkt umgesetzt, der es sendenden Systemen erlaubt, fü #### Event Log der Submission -... +Zur Prüfbarkeit der Datenübermittlung erhält die Submission ein Event Log, das Security Event Token (SET) gemäß RFC 8417 und dem Dokument Event Log speichert. Ein Teil der Events werden vom Zustelldienst erzeugt, andere Events im Kontext Akzeptanz oder Ablehnung der Submission werden durch das empfangende System erzeugt. Der Event Log bzw. die SETs der einzelnen Events ersetzen das bisherige Statusmodell. Im Vergleich zum bisherigen Statusobjekt zeichnet sich der SET durch eine Integritätssicherung durch eine Signatur, Zeitstempel und eine eindeutige Identifikation von Events. Aktuell werden SETs noch ohne einen Payload umgesetzt, der die Events detailierter beschreibt. Entsprechende Payloads werden in zukünftigen Weiterentwicklung spezifiziert und umgesetzt. #### Schlüsselverwaltung des Zustelldienstes -... +Um Security Event Tokens (SET) zu #### Implementierung des neuen Statusmodells @@ -45,7 +45,7 @@ Daher wurde ein neuer Endpunkt umgesetzt, der es sendenden Systemen erlaubt, fü #### schemas` in `submissionSchemas` umbenennen -Es wurde im Rahmen der Qualitätsprüfungen der API beschlossen, den Bezeichner `schemas`, der die referenzierten Fachdatenschemata in der Destination bzw. im Metadatenschema beinhaltet hat, in `submissionSchemas` umzubenennen. Diese Umbenennung wurde in der API Spec und Dokumentation ungepasst. +Im Rahmen der Qualitätsprüfungen der API wurde beschlossen, den Bezeichner `schemas`, der die referenzierten Fachdatenschemata in der Destination bzw. im Metadatenschema beinhaltet, in `submissionSchemas` umzubenennen. Diese Umbenennung wurde in der API Spec und Dokumentation ungepasst. #### Dokumentationsartikel "Versenden" im Überblick von Getting Started aufteilen