diff --git a/docs/changelog.md b/docs/changelog.md
index cfb2ad7c974892aa16b435865d54f36979e27044..96c8658170b4e30a9489a669538838d562c2bec4 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 ecd284e74da848b3414ecc36c65637f3008140e0..f9df723becf00e064458d1e404ae00e725e64c43 100644
--- a/docs/getting-started/event-log/set-creation.mdx
+++ b/docs/getting-started/event-log/set-creation.mdx
@@ -5,19 +5,22 @@ title: Erzeugen eines Security-Event-Token (SET)
import Tabs from '@theme/Tabs'
import TabItem from '@theme/TabItem'
-# Event
+# SET Erzeugung
-Je nach Event ist ein Payload für das Event vorgesehen.
-Auf der Seite [Ereignisse](./events.mdx) finden Sie eine Liste der Ereignisse und deren Struktur.
+## Ereignis Payload {#ereignis-payload}
-Derzeit ist es weiterhin möglich, Events ohne Payload zu senden.
-In diesem Fall darf kein Schema (`$schema`) angegeben werden.
+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.
-## Event Payload
+:::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
+### Authentication Tags Ereignis Payload
-Die Struktur der "Authentication Tags" sieht wie folgt aus.
+Die Struktur der `Authentication Tags` Ereignis Payload sieht wie folgt aus.
```json
{
@@ -83,9 +86,9 @@ values={[
</Tabs>
-### Problems
+### Problems Ereignis Payload
-Die Struktur der "Problems" sieht wie folgt aus.
+Die Struktur der `Problems` Ereignis Payload sieht wie folgt aus.
```json
{
@@ -165,17 +168,30 @@ values={[
</Tabs>
-## SET Claims
+## SET Claimset/Payload
-Der SET Payload ist wie folgt aufgebaut.
-Die Elemente der obersten Ebene sind bei allen SETs vorhanden.
-Der Claim `events` enthält als Schlüssel das eigentliche Event, das ggf. einen Payload (hier: `authenticationTags`) enthält.
+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
-:::info
+:::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 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 die Version 0.1.0 des SET-Payload-Schemas aktuell.
-Die in den Beispielen genannte Version 1.0.0 wird im Zuge des Rückkanals veröffentlicht.
+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 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 925dd79ba8a266526b4ea92b1e9648fbe500e258..b8d4e4b221580631cde20ee1cd4fcf42f294f027 100644
--- a/docs/getting-started/event-log/set-validation.mdx
+++ b/docs/getting-started/event-log/set-validation.mdx
@@ -6,31 +6,42 @@ import ApiLink from '@site/src/components/ApiLink'
import Tabs from '@theme/Tabs'
import TabItem from '@theme/TabItem'
+# SET Prüfung
+
+## Einleitung {#einleitung}
+
Um eine vollständige Prüfung eines Security-Event-Tokens durchzuführen, MUSS zwingend sowohl die Einhaltung der (kryptografischen) Vorgaben als auch die Signatur geprüft werden.
Die Prüfung der Signatur des SET ist abhängig vom ausstellenden System (Zustelldienst, Subscriber oder Sender).
-Sowohl die Prüfung der kryptografischen Vorgaben, als auch die Prüfung der Signatur darf KEINESFALLS ausgelassen werden.
+Aus technischer Sicht sollte auch das unter `$schema` angegebene SET-Payload-Schema validiert werden.
+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 Warnung
+Sowohl die Prüfung der kryptografischen Vorgaben, als auch die Prüfung der kryptografischen Signatur darf KEINESFALLS ausgelassen werden.
+:::
## Prüfung der Einhaltung von kryptografischen Vorgaben und der Struktur
Alle generierten Security-Event-Tokens MÜSSEN den Vorgaben aus [RFC 7519](https://tools.ietf.org/html/rfc7519) entsprechen und über folgende Header-Attribute verfügen:
-| Feld | Inhalt | Erläuterung |
-|-------|-------------------------------------|---------------------------------------------------------------------------------------|
-| `typ` | `secevent+jwt` | Wird gemäß [RFC 8417, Abschnitt 2.3](https://datatracker.ietf.org/doc/html/rfc8417#section-2.3) auf den festen Wert "`secevent+jwt`" gesetzt. |
-| `alg` | `PS512` | Zur Signaturerstellung wird der Signaturalgorithmus RSASSA-PSS mit SHA-512 und MGF1 mit SHA-512 verwendet. Vorgabe gemäß [BSI TR-02102](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) in der Version 2021-01 (Stand 24. März 2021). |
-| `kid` | Key-ID des zugehörigen Public Keys | Die Key-ID des Public Key, mit dem die Signatur des JWT geprüft werden kann. |
-
-In der Payload des signierten SET MÃœSSEN die folgenden [standardisierten Felder](https://www.iana.org/assignments/jwt/jwt.xhtml) gesetzt sein:
-
-| Feld | Inhalt | Erläuterung |
-|-----------|-----------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| `$schema` | Referenz auf das verwendete SET-Schema | Gibt das SET-Schema an, dem das SET entspricht. Das Schema kann von [schema.fitko.de](https://schema.fitko.de/fit-connect/set-payload/) bezogen werden. Mit dem Schema kann die Struktur des SET Payloads validiert werden. |
-| `jti` | UUID des Token | Die JWT ID ist eine eindeutige ID des SET bzw. JWT. Es wird eine zufällige UUID verwendet. |
-| `iss` | ID des Token Issuers | Diese Angabe dient dazu, um herauszufinden, wer den Token ausgestellt hat. Für SETs, die vom Zustelldienst ausgestellt sind, wird die Host-Adresse (API-URL) verwendet. Bei SETs von empfangenden Systemen ist die `destinationId`, an der dieser die Submission schickt. |
-| `iat` | Timestamp (UNIX-Format) | Zeitpunkt der Ausstellung des SET. |
-| `sub` | URI, die den Gegenstand des SET identifiziert | Das Subject eines SET ist eine Kombination aus dem Schlüsselwort `submission` und der Id `submissionId` der Resource. |
-| `txn` | URI, die den Vorgang identifiziert | Als "Transaction Identifier" wird die Vorgangsreferenz `caseId` angegeben. |
-| `events` | JSON-Objekt der Events in diesem Event-Token | Das Objekt `events` enthält genau ein Ereignis zu einem logischen Sachverhalt bzw. Gesamtereignis, wie bspw. der Versendung einer Einreichung durch den Sender. Dieses Objekt beinhaltet immer zwingend eine URI, die das jeweilige Gesamtereignis eindeutig identifiziert. Das Objekt der URI des Gesamtereignisses ist aktuell leer, kann aber zukünftig weitere Details zu einem Gesamtereignis enthalten. |
+| Feld | Inhalt | Erläuterung |
+|-------|------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `typ` | `secevent+jwt` | Wird gemäß [RFC 8417, Abschnitt 2.3](https://datatracker.ietf.org/doc/html/rfc8417#section-2.3) auf den festen Wert "`secevent+jwt`" gesetzt. |
+| `alg` | `PS512` | Zur Signaturerstellung wird der Signaturalgorithmus RSASSA-PSS mit SHA-512 und MGF1 mit SHA-512 verwendet. Vorgabe gemäß [BSI TR-02102](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) in der Version 2021-01 (Stand 24. März 2021). |
+| `kid` | Key-ID des zugehörigen Public Keys | Die Key-ID des Public Key, mit dem die Signatur des JWT geprüft werden kann. |
+
+In der Payload des signierten SET MÜSSEN die folgenden [standardisierten Felder](https://www.iana.org/assignments/jwt/jwt.xhtml) gesetzt sein (Temporäre Ausnahme `$schema`):
+
+| Feld | Inhalt | Erläuterung |
+|-----------|----------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| `$schema` | URL Referenz auf das verwendete SET-Payload-Schema | Gibt das SET-Payload-Schema an, dem das SET entspricht. Dieses Schema wird auch vom Zustelldienst validert. <br/><br/> Aktuell ist es noch möglich kein `$schema` anzugeben. In diesem Fall findet keine Validation im Zustelldienst statt und ist auch keine client-seitige Validierung möglich. Siehe [Einleitung](#einleitung) <br/><br/> Das Schema kann zur client-seitigen Validierung der SET Payload von der referenzierten URL bezogen werden. Auch eine client-seitige Validierung durch statisch hinterlegten Schema Versionen ist möglich, solange die von uns vorgegebenen Versionen unterstützt werden. 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 nicht mehr verwendet werden. <br/><br/> Aktuell muss eine SET-Payload Validation beide SET-Payload-Schema Versionen (`0.1.0` und `1.0.0`) sowie ein fehlendes SET-Payload-Schema unterstüzten. |
+| `jti` | UUID des Token | Die JWT ID ist eine eindeutige ID des SET bzw. JWT. Es wird eine zufällige UUID verwendet. |
+| `iss` | ID des Token Issuers | Diese Angabe dient dazu, um herauszufinden, wer den Token ausgestellt hat. Für SETs, die vom Zustelldienst ausgestellt sind, wird die Host-Adresse (API-URL) verwendet. Bei SETs von empfangenden Systemen ist die `destinationId`, an der dieser die Submission schickt. |
+| `iat` | Timestamp (UNIX-Format) | Zeitpunkt der Ausstellung des SET. |
+| `sub` | URI, die den Gegenstand des SET identifiziert | Das Subject eines SET ist eine Kombination aus dem Schlüsselwort `submission` und der Id `submissionId` der Resource. |
+| `txn` | URI, die den Vorgang identifiziert | Als "Transaction Identifier" wird die Vorgangsreferenz `caseId` angegeben. |
+| `events` | JSON-Objekt der Events in diesem Event-Token | Das Objekt `events` enthält genau ein Ereignis zu einem logischen Sachverhalt bzw. Gesamtereignis, wie bspw. der Versendung einer Einreichung durch den Sender. Dieses Objekt beinhaltet immer zwingend eine URI, die das jeweilige Gesamtereignis eindeutig identifiziert. Das Objekt der URI des Gesamtereignisses kann leer sein oder weitergehende Informationen beinhalten (Siehe [Ereignisse](./events.mdx)) |
:::note SET Beispiel
diff --git a/docs/receiving/process-and-acknowledge.mdx b/docs/receiving/process-and-acknowledge.mdx
index 8b54cdd3763a336239aa8095c72456429c74169f..038f85849960835092a6ba64da39a6f9dbf8b6b7 100644
--- a/docs/receiving/process-and-acknowledge.mdx
+++ b/docs/receiving/process-and-acknowledge.mdx
@@ -47,7 +47,7 @@ Weiterhin ist es notwendig, dass die Id der Einreichung (`submissionID`) und des
String transactionId = "case:f73d30c6-8894-4444-8687-00ae756fea90"; // caseId
```
- Die Payload- und Header-Attribute des SET müssen wie oben beschrieben definiert werden (siehe markierte Zeilen).
+ Die Payload- und Header-Attribute des SET müssen wie oben beschrieben definiert werden (siehe markierte Zeilen). Mehr Informationen zu dem SET Aufbau finden Sie unter [SET Erzeugen](../getting-started/event-log/set-creation.mdx)
Im dritten markierten Block wird das SET mit dem Schlüssel signiert. Anschließend kann der serialisierte Wert an den Endpunkt <ApiLink api="submission-api" to="/v1/cases/{caseId}/events" withMethod="post" /> gesendet werden.
```java {3-10,12-16,22-24}