From 3ddc9e73ae26551346ef5b6bbd584e1929d244f9 Mon Sep 17 00:00:00 2001
From: Florian Kaufmann <florian.kaufmann@codecentric.de>
Date: Wed, 30 Mar 2022 12:45:50 +0200
Subject: [PATCH] =?UTF-8?q?docs:=20=E2=9C=8F=EF=B8=8F=20set-creation=20Dok?=
=?UTF-8?q?u=20=C3=BCberarbeitet=20(planning#366)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
---
docs/changelog.md | 2 +-
.../event-log/set-creation.mdx | 21 +++++++++++++------
.../event-log/set-validation.mdx | 2 +-
3 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/docs/changelog.md b/docs/changelog.md
index cfb2ad7c9..96c865817 100644
--- a/docs/changelog.md
+++ b/docs/changelog.md
@@ -84,7 +84,7 @@ Das Format dieser Datei basiert auf [Keep a Changelog](https://keepachangelog.co
([Bug](https://git.fitko.de/fit-connect/planning/-/issues/303))
### Zustelldienst 1.3.1
-- Die Reihenfolge der Ereignise im Ereignis-Log für einen Einreichungsvorgang wurde von "Aufsteigend basiert auf der
+- Die Reihenfolge der Ereignisse im Ereignis-Log für einen Einreichungsvorgang wurde von "Aufsteigend basiert auf der
Ereignis Id und gruppiert basierend auf der Einreichungsid" zu "Aufsteigend basiert auf der Ereignis Id" geändert
([Bug](https://git.fitko.de/fit-connect/planning/-/issues/279))
- Security Feature: Der Zustelldienst wird über einen Docker Container ausgeliefert. Dieser Docker Container nutzt
diff --git a/docs/getting-started/event-log/set-creation.mdx b/docs/getting-started/event-log/set-creation.mdx
index 1c278293c..f9df723be 100644
--- a/docs/getting-started/event-log/set-creation.mdx
+++ b/docs/getting-started/event-log/set-creation.mdx
@@ -7,14 +7,16 @@ import TabItem from '@theme/TabItem'
# SET Erzeugung
-## Ereignis Payload
+## Ereignis Payload {#ereignis-payload}
Je nach SET ist ein Ereignis-Payload für das darin vorkommendes Ereignis vorgesehen.
Auf der Seite [Ereignisse](./events.mdx) finden Sie eine Liste der Ereignisse und deren Struktur.
-Derzeit ist es weiterhin möglich, Ereignise auch ohne Ereignis-Payload zu senden.
+:::caution Warnung
+Derzeit ist es möglich, Ereignisse auch ohne Ereignis-Payload zu senden.
In diesem Fall darf kein SET-Payload-Schema (unter `$schema`) angegeben werden.
Denn sollte ein SET-Payload-Schema verwendet werden, das ein Ereignis-Payload vorschreibt, wird das SET ohne diese Ereignis-Payload vom Zustelldienst mit einem Fehler zurückgewiesen.
+:::
### Authentication Tags Ereignis Payload
@@ -171,18 +173,25 @@ values={[
Die SET Payload ist wie folgt aufgebaut.
Die Elemente der obersten Ebene sind bei allen SETs vorhanden (Ausnahme `$schema`).
Der Claim `events` enthält als Schlüssel das eigentliche Ereignis, das ggf. einen eigenen Ereignis Payload (hier: `authenticationTags`) enthält.
+Mehr zu der Ereignis spezifischen Payload finden Sie auf dieser Seite under [Ereignis Payload](#ereignis-payload) und auf der [Ereignisse](./events.mdx) Seite
+:::caution Warnung
Für die SET Payload wird unter `$schema` ein Schema zur Validierung definiert.
-Entspricht ein SET Payload nicht dem definierten Schema wird es z.B. vom Zustelldienst zurückgeweisen.
-Es ist aktuell noch möglich kein `$schema` zu setzten. Dadurch findet keine Validation statt.
-Dies wird in unspezifizierter Zukunft `deprecated` und alle SETs müssen ein valides Schema verwenden.
+Entspricht ein SET Payload nicht dem definierten Schema wird es z.B. vom Zustelldienst und vom Empfänger zurückgewiesen.
+Es ist aktuell noch möglich kein `$schema` an zu geben. Dadurch findet keine Validation auf Seiten des Zustelldienst und des Empfänger statt.
+Dies wird in unspezifizierter Zukunft `deprecated` und alle SETs müssen dann ein valides Schema verwenden und angeben.
+
+Derzeit ist es auch noch möglich, Ereignisse auch ohne [Ereignis Payload](#ereignis-payload) zu senden.
+In diesem Fall darf kein SET-Payload-Schema (unter `$schema`) angegeben werden.
+Denn sollte ein SET-Payload-Schema verwendet werden, das ein Ereignis-Payload vorschreibt, wird das SET ohne diese Ereignis-Payload vom Zustelldienst mit einem Fehler zurückgewiesen.
+:::
:::info
Derzeit ist die Version [1.0.0](https://schema.fitko.de/fit-connect/set-payload/1.0.0/set-payload.schema.json) des SET-Payload-Schemas aktuell.
Mit diesem Schema `1.0.0` stellt auch der Zustelldienst seine SETs aus.
Bis auf weiteres kann auch noch die Version [0.1.0](https://schema.fitko.de/fit-connect/set-payload/1.0.0/set-payload.schema.json) verwendet werden.
Inhaltlich ist sie deckungsgleich mit der Version `1.0.0`.
-Diese Version `0.1.0` wird deswegen in noch unspezifizierter Zukunft mit Ankündigung `deprecated` und sollte dann nicht mehr verwendet werden.
+Diese Version `0.1.0` wird deswegen in noch unspezifizierter Zukunft mit Ankündigung `deprecated` und sollte nicht mehr verwendet werden.
:::
```json
diff --git a/docs/getting-started/event-log/set-validation.mdx b/docs/getting-started/event-log/set-validation.mdx
index 2c26b4bc6..b8d4e4b22 100644
--- a/docs/getting-started/event-log/set-validation.mdx
+++ b/docs/getting-started/event-log/set-validation.mdx
@@ -17,7 +17,7 @@ Dies wird z.B. auch schon vom zuständigen Zustelldienst gemacht.
Aktuell ist die Angabe eines SET-Payload-Schemas aber noch optional und kann nicht existieren.
Dies wird in unspezifizierter Zukunft `deprecated` und alle SETs müssen ein valides SET-Payload-Schema verwenden und angeben.
In dem Fall, dass das SET-Payload-Schema nicht angegeben ist, müssen trotzdem die kryptografischen Vorgaben bzw. die kryptografische Signatur validiert werden.
-:::caution
+:::caution Warnung
Sowohl die Prüfung der kryptografischen Vorgaben, als auch die Prüfung der kryptografischen Signatur darf KEINESFALLS ausgelassen werden.
:::
--
GitLab