diff --git a/docs/getting-started/submission-structure.md b/docs/getting-started/submission-structure.md
index d673da4b2ebc6c8a55a2e6551fc565dbfe265847..9d423c3cc27eaba2bc4ace848ac96523273e76a1 100644
--- a/docs/getting-started/submission-structure.md
+++ b/docs/getting-started/submission-structure.md
@@ -10,7 +10,7 @@ Einreichung können aus fachlicher Sicht Anträge (bspw. ein strukturierter Date
## Wie ist eine Einreichung aufgebaut?
-
+
Eine Einreichung, die über die Submission API übermittelt wird, besteht aus drei Bestandteilen:
- Ein optionaler Fachdatensatz (`data`), der die Daten eines Antrags oder Berichts enthält und einem im Zustellpunkt vorgegebenen Datenschema (`submissionSchema`) entspricht.
diff --git a/docusaurus.config.js b/docusaurus.config.js
index 769d5b96d3f1897fff6c76f273cc89fd22de4747..fafa76e778aa8911968d0e0fab5a192a22ac3dca 100644
--- a/docusaurus.config.js
+++ b/docusaurus.config.js
@@ -15,6 +15,14 @@ module.exports = {
locales: ['de'],
},
themeConfig: {
+ announcementBar: {
+ id: 'under-construction',
+ content:
+ '🚧 Die Dokumentation ist aktuell noch in stetigem Wandel. Bei Fragen, Probleme oder Feedback einfach an uns über <a target="_blank" rel="noopener noreferrer" href="https://git.fitko.de/fit-connect/docs/-/issues/new">Gitlab</a> wenden.',
+ backgroundColor: '#FFC819',
+ textColor: '#000000',
+ isCloseable: false,
+ },
colorMode: {
disableSwitch: true,
},
@@ -30,16 +38,13 @@ module.exports = {
items: [
{to: '/docs', label: 'Dokumentation', position: 'left'},
{to: '/news', label: 'News', position: 'left'},
- // {to: '/concepts', label: 'Konzepte', position: 'left'},
- // {to: '/operations', label: 'Betriebshandbuch', position: 'left'},
-
- /*{
+ {
type: 'docsVersionDropdown',
position: 'right',
dropdownActiveClassDisabled: true,
docsPluginId: 'default',
}
- {to: '/portal/', label: 'Self-Service-Portal', position: 'right'},*/
+ /* {to: '/portal/', label: 'Self-Service-Portal', position: 'right'},*/
],
},
footer: {
@@ -57,6 +62,11 @@ module.exports = {
editUrl: ({ version, versionDocsDirPath, docPath }) =>
`https://git.fitko.de/fit-connect/docs/-/edit/${gitBranch}/${versionDocsDirPath}/${docPath}`,
routeBasePath: 'docs',
+ versions: {
+ current: {
+ label: 'Vorschau'
+ }
+ }
},
theme: {
customCss: require.resolve('./src/css/custom.css'),
diff --git a/src/css/custom.css b/src/css/custom.css
index e06ae715499f8a359e2bc914bc07444eabc24e97..2527fb0dfd77fbe60c8750dbb1455e89f1409477 100644
--- a/src/css/custom.css
+++ b/src/css/custom.css
@@ -2,6 +2,7 @@ dl dt {
font-weight: bold;
}
+.alert,
.alert a,
.admonition,
.admonition-icon svg {
@@ -12,4 +13,4 @@ dl dt {
.center {
text-align: center;
-}
\ No newline at end of file
+}
diff --git a/versioned_docs/version-0.14/account.mdx b/versioned_docs/version-0.14/account.mdx
new file mode 100644
index 0000000000000000000000000000000000000000..e97853e89f7e1e879f68fe4ab4fd8d2a209db5de
--- /dev/null
+++ b/versioned_docs/version-0.14/account.mdx
@@ -0,0 +1,87 @@
+# Accountregistrierung und Client-Verwaltung
+
+import useBaseUrl from '@docusaurus/useBaseUrl';
+
+Das **Self-Service-Portal** von FIT-Connect erlaubt es Ländern, Kommunen oder interessierten IT-Dienstleistern über eine grafische Oberfläche mit wenigen Klicks OAuth-API-Clients anzulegen und Zustellpunkte, auch **Destinations** genannt, für ihre bereits bestehenden Fachverfahren und Verwaltungsleistungen zu registrieren.
+OAuth-API-Clients müssen für jedes an FIT-Connect angebundene System registriert werden.
+Das Anlegen eines Zustellpunktes ist dagegen nur für empfangende Systeme (Subscriber) notwendig.
+Zustellpunkte können dann im Rahmen von FIT-Connect über den Antrags-Routingdienst gefunden werden.
+
+## Anmeldung am Self-Service-Portal
+
+Eine Nutzung des Self-Service-Portals setzt zwingend eine vorangehende Authentifizierung über einen der unterstützten Identity Provider voraus.
+In der Testumgebung ist neben der Authentifizierung über das GitLab der FITKO auch ein Login mit einem bestehenden GitLab.com- oder GitHub-Account möglich.
+
+<img width="600" alt="Übersicht der aktuell unterstützten OAuth 2.0 Identiy Provider" src={useBaseUrl('/images/ssp/1-Login-Verfahren.png')} />
+
+Nach erfolgreicher Authentifizierung wird die Startseite des Self-Service-Portals angezeigt: Die Clientverwaltung.
+
+## Verwaltung von API-Clients
+
+Über die Client-Verwaltung lassen sich bereits hinzugefügt OAuth-API-Clients verwalten, neue OAuth-API-Clients anlegen und auch wieder entfernen.
+
+<img width="600" alt="Startansicht" src={useBaseUrl('/images/ssp/2-Start-Ansicht.png')} />
+
+Über den Menüpunkt <mark>Client hinzufügen</mark> können neue API-Clients zu Ihren Konto hinzugefügt werden.
+
+<img width="600" alt="Client-Verwaltung mit eingerichteten Clients" src={useBaseUrl('/images/ssp/6-Clientverwaltung.png')} />
+
+Hierbei wird zwischen **Sendern** und **Subscribern** unterschieden.
+**Sender** repräsentieren dabei technische Systeme, die Einreichungen über die Submission API des Zustelldiensts vornehmen.
+**Subscriber** stellen technische Systeme dar, die Einreichungen auf Verwaltungsseite entgegennehmen und bearbeiten.
+
+### Sender hinzufügen
+
+Mit Auswahl der Optionsschaltfläche <mark>Sender</mark> und Eingabe einer Bezeichnung und anschließender Betätigung wird ein Client von Typ **Sender** angelegt.
+
+<img width="600" alt="Neuen OAuth-API-Client vom Typ: Sender hinzufügen" src={useBaseUrl('/images/ssp/3-Client-hinzufuegen-Sender.png')} />
+
+Das Self-Service-Portal generiert daraufhin **Client-ID** und **Client-Secret**.
+Die **Client-ID** stellt dabei einen öffentlichen, im FIT-Connect Umfeld einzigartigen Identifikator für eine Anwendungen dar.
+Das **Client-Secret** wiederum ist ein Geheimnis, welches nur der Anwendung und dem OAuth-Server bekannt ist.
+Mit Hilfe von Client-ID und Client-Secret können API-Clients anschließend OAuth Access Tokens [beim OAuth-Dienst abrufen](getting-started/authentication), die zum Zugriff auf die FIT-Connect Submission API berechtigen.
+
+Für den Zugriff auf die Submission API werden Berechtigungen in Form von OAuth-Scopes verwaltet.
+Jedem **API-Client** werden zu diesem Zweck ein oder mehrere OAuth-Scopes zugeordnet.
+
+Für **Sender** legen diese fest, ob ein sendendes System eine Einreichung an einen bestimmten Zustellpunkt übermitteln darf.
+In der Testphase ist dieser mit `send:region:DE` vorbefüllt.
+Dies erlaubt eine Antragstellung bei allen in FIT-Connect registrierten **Subscribern**.
+
+<img width="600" alt="OAuth-API-Client vom Typ: Sender" src={useBaseUrl('/images/ssp/4-Client-hinzufuegen-Sender2.png')} />
+
+Weitere Informationen zu den Scopes von sendenden Systemen finden Sie unter [OAuth-Scopes für sendende Systeme](details/authentication/scopes-sender).
+
+### Subscriber hinzufügen
+
+Mit Auswahl der Optionsschaltfläche <mark>Subscriber</mark> und Eingabe einer Bezeichnung und anschließender Betätigung wird ein Client von Typ **Sender** angelegt.
+
+<img width="600" alt="Neuen OAuth-API-Client vom Typ: Subscriber hinzufügen" src={useBaseUrl('/images/ssp/3b-Client-hinzufuegen-Subscriber.png')} />
+
+Das Self-Service-Portal generiert daraufhin **Client-ID** und **Client-Secret**.
+Die **Client-ID** stellt dabei einen öffentlichen, im FIT-Connect Umfeld einzigartigen Identifikator für eine Anwendungen dar.
+Das **Client-Secret** wiederum ist ein Geheimnis, welches nur der Anwendung und dem OAuth-Server bekannt ist.
+Mit Hilfe von Client-ID und Client-Secret können API-Clients anschließend OAuth Access Tokens [beim OAuth-Dienst abrufen](getting-started/authentication), die zum Zugriff auf die FIT-Connect Submission API berechtigen.
+
+Für den Zugriff auf die Submission API werden Berechtigungen in Form von OAuth-Scopes verwaltet.
+Jedem **API-Client** werden zu diesem Zweck ein oder mehrere OAuth-Scopes zugeordnet.
+
+**Subscribern** wird initial kein OAuth-Scope zugeordnet. Dieser wird durch [Zuordnung einer oder mehrerer Zustellpunkten (Destinations)](getting-started/receiving/destination) bestimmt und berechtigt den API-Client zum Abruf von Einreichungen bei einem oder mehreren Zustellpunkten.
+
+<img width="600" alt="OAuth-API-Client vom Typ: Subscriber" src={useBaseUrl('/images/ssp/4b-Client-hinzufuegen-Subscriber2.png')} />
+
+Weitere Informationen zu den Scopes von empfangenden Systemen finden Sie unter [OAuth-Scopes für empfangende Systeme](details/authentication/scopes-subscriber).
+
+### Clients bearbeiten und löschen
+
+Durch einen Klick auf die <mark>Client-ID</mark> in der Client-Verwaltung öffnet sich die Detailansicht für den ausgewälten Client.
+
+<img width="600" alt="Detailansicht von Clients, hier ein Sender" src={useBaseUrl('/images/ssp/18-Client-Detailansicht-Sender.png')} />
+
+Durch einen Klick auf <mark>bearbeiten</mark> öffnet sich die Bearbeitungsansicht. Hier kann derzeit die Bezeichnung des Clients angepasst werden.
+
+<img width="600" alt="Client bearbeiten" src={useBaseUrl('/images/ssp/5-Client-bearbeiten.png')} />
+
+Durch einen Klick auf <mark>löschen</mark> öffnet sich hingegen ein Kontrolldialog, in dem das Löschen bestätigt werden muss.
+
+<img width="600" alt="Client löschen" src={useBaseUrl('/images/ssp/15-Client-loeschen.png')} />
diff --git a/versioned_docs/version-0.14/apis/metadata.mdx b/versioned_docs/version-0.14/apis/metadata.mdx
new file mode 100644
index 0000000000000000000000000000000000000000..336ee6dac2b35d4ecf5f7b911306539d0758f19c
--- /dev/null
+++ b/versioned_docs/version-0.14/apis/metadata.mdx
@@ -0,0 +1,8 @@
+---
+title: Metadatenschema
+hide_table_of_contents: true
+---
+
+import JSONSchema from '@site/src/components/JSONSchema'
+
+<JSONSchema />
diff --git a/versioned_docs/version-0.14/apis/routing-api.mdx b/versioned_docs/version-0.14/apis/routing-api.mdx
new file mode 100644
index 0000000000000000000000000000000000000000..c41155d5d39869b260f6f1f327c1ed591ce94b23
--- /dev/null
+++ b/versioned_docs/version-0.14/apis/routing-api.mdx
@@ -0,0 +1,8 @@
+---
+title: Routing API
+hide_table_of_contents: true
+---
+
+import ApiSpec from '@site/src/components/ApiSpec'
+
+<ApiSpec gitlabProjectId={"44"} path={"routing-api"} artifact={"routing-api.yaml"} />
diff --git a/versioned_docs/version-0.14/apis/submission-api.mdx b/versioned_docs/version-0.14/apis/submission-api.mdx
new file mode 100644
index 0000000000000000000000000000000000000000..05ff5ded25c66a624a79e531285eb9a2fb829cc9
--- /dev/null
+++ b/versioned_docs/version-0.14/apis/submission-api.mdx
@@ -0,0 +1,8 @@
+---
+title: Submission API
+hide_table_of_contents: true
+---
+
+import ApiSpec from '@site/src/components/ApiSpec'
+
+<ApiSpec gitlabProjectId={"1"} path={"submission-api"} artifact={"submission-api.yaml"} />
diff --git a/versioned_docs/version-0.14/changelog.md b/versioned_docs/version-0.14/changelog.md
new file mode 100644
index 0000000000000000000000000000000000000000..77385e3867540d6ae8400172319da834740ed156
--- /dev/null
+++ b/versioned_docs/version-0.14/changelog.md
@@ -0,0 +1,587 @@
+# Changelog
+
+Das Format dieser Datei basiert auf [Keep a Changelog](https://keepachangelog.com/de).
+
+## [Unveröffentlicht] - ????-??-??
+
+:::caution
+Diese Version beinhaltet **breaking changes**
+:::
+
+### Allgemein
+
+- Reduktion der Verarbeitung von personenbezogenen Daten
+- Daten einer Einreichung müssen nun Ende-zu-Ende verschlüsselt übertragen werden
+- API-Endpunktstruktur hat sich verändert, um
+ - die Pfade einfacher und kürzer zu gestalten
+ - und nur Parameter zu erfassen, die auch benötigt werden
+
+#### Destinations
+
+Der Aufbau & Umfang von Destination-Objekten hat sich geändert:
+
+- Das Attribut `publicOrganization` entfällt, weil
+ - nur Kontaktinformationen für den Fall von technischen Problemen erfasst und hierbei so wenig Informationen wie
+ möglich gespeichert werden sollen.
+ - Der Name der Organisation ist als Attribut für eine bessere Zuordnung zu `contactInformation` unter `legalName`
+ gewandert.
+- Das Attribut `technicalContact` wird umbenannt zu `contactInformation` und inhaltlich wie im Beispiel unten geändert
+- Die Attribute `callback` und `callbackURI` wurden zusammengeführt,
+ - um die Struktur flacher zu gestalten,
+ - und weil neben `callbackURI` keine anderen Attribute angeordnet sind.
+- Im Attribut `submissionSchemas` entfällt das Attribut `encoding`,
+ - da ab Version 1 jede Kommunikation Ende-zu-Ende verschlüsselt sein muss.
+- Das Attribut `publicKey` wurde umbenannt zu `encryptionKid`. Weiterhin wurde ein Feld `keys` eingefügt.
+ - `encryptionKid`: Die KeyId des Schlüssels der zur Verschlüsselung der an einen Zustellpunkt gesendeten Daten
+ verwendet wird. Der Schlüssel ist abrufbar im Attribut `keys`.
+ - `keys`: Hier befinden sich die öffentlichen Schlüssel des Zustellpunktes.
+ - Der `signingKid` fehlt, da dieser an signierten Nachrichten mit angehängt wird und ebenso im Attribut `keys`
+ auffindbar ist.
+- Ein Schema besteht nun aus einer `schemaURI` und einem `mimeType`.
+ - Wurde im Zuge der Vereinfachung so umgesetzt. URLs und URNs können in das Feld `schemaURI` eingetragen werden.
+
+```json
+{
+ "contactInformation": {
+ "legalName": "Max",
+ "address": "Mustermann",
+ "phone": "+49170123456789",
+ "email": "max@mustermann.not",
+ "unit": "Musterabteilung XYZ"
+ },
+ "submissionSchemas": [
+ {
+ "schemaURI": "urn:xoev-de:xfall:standard:fim-s00000000009_1.0.0",
+ "mimeType": "application/xml"
+ }
+ ],
+ "callback": "http://127.0.0.1:4010/voluptas",
+ "keys": {
+ "my-key-id": {
+ }
+ },
+ "encryptionKid": "my-key-id"
+}
+```
+
+##### Get Destination
+
+- `destinationId`
+- `submissionSchemas`
+- `encryptionKid`
+- `keys`
+
+Das Attribut `contact` (vormals `technicalContact`) wird nicht mehr zurückgegeben, da dies schützenswerte Informationen
+sind.
+
+##### Update Destination
+
+- Attribut `destinationId` ist nicht länger aktualisierbar, da die Id vom Service und nicht vom Nutzer der API verwaltet
+ wird
+- Liefert jetzt bei erfolgreicher Aktualisierung die öffentlichen Attribute des Zustellpunktes zurück, anstatt vorher
+ nur `{ "result": "success" }`.
+
+##### Create Destination
+
+Liefert jetzt bei erfolgreichem Erstellen die öffentlichen Attribute des Zustellpunktes zurück, anstatt vorher nur
+die `destinationId`.
+
+#### Delete Destination
+
+Eigentlich müsste dieser Endpunkt gar keinen Body mitliefern. Damit nicht-konforme Middleware den Request trotzdem
+sauber routen kann, liefert er jetzt `{}` anstatt `{ "result": "success" }` zurück.
+
+### Application Transfer
+
+- Die Grundstruktur einer Einreichung wurde angepasst, da der Großteil der Informationen nun verschlüsselt übertragen
+ wird.
+- Einige Endpunkte und HTTP-Methoden wurden angepasst, um den Ablauf kürzer, einfacher, stabiler und sicherer zu
+ gestalten.
+- Metadaten einer Einreichung: Alle Metadaten einer Einreichung werden nun verschlüsselt im Attribut `encryptedMetadata`
+ übertragen.
+
+#### Create Application
+
+- Beim Anlegen einer Einreichung muss nun die Id der Destination (Zustellpunktes) mit angegeben werden, da sie nur bei
+ der Anlage der Einreichung notwendig ist und nicht bei den weiteren Aufrufen.
+- Struktur um eine Application anzulegen ist nun nur noch `{ destinationId: …, announcedContentStructure: … }`, da sich
+ die Gesamtstruktur geändert hat. In `announcedContentStructure` wird angegeben ob Fachdaten für diesen Einreichung
+ hochgeladen werden als auch eine Liste an UUIDs die für diesen Einreichung hochgeladen werden. Die Erstellung der
+ UUIDs ist dem Client überlassen.
+
+#### Add Document to Application
+
+- Der Inhalt des Dokuments wird nun verschlüsselt, daher ist der Content-Type statt application/json nun
+ application/jose
+- Als Antwort müsste dieser Endpunkt gar keinen Body mitliefern. Damit nicht-konforme Middleware den Request trotzdem
+ sauber routet: liefert er jetzt `{}` statt `{"result": "success"}`
+
+#### Send Application
+
+- Send Application und Application Data hinzuzufügen ist nun in einem Endpunkt kombiniert, da kein Einreichung ohne
+ Fachdaten übertragen werden können soll.
+- Der Aufruf des Endpunktes und die Übertragung der verschlüsselten Fachdaten markiert den Einreichung dann auch als
+ "final"
+ und löst die Übertragung an den Zustellpunkt aus.
+- Die Fachdaten sind nun verschlüsselt, wodurch der Content-Type nicht mehr application/json sonder application/jose ist
+- Der Response Status ist nicht mehr 200, sondern 202, da die Fachdaten akzeptiert wurden und der Einreichung
+ abgeschickt wird.
+
+#### Status Endpunkte
+
+- Der `upload-status` entfällt, da alle Informationen verschlüsselt sind und nun nicht bekannt ist, wie viele Dokumente
+ einer Einreichung bereits hochgeladen wurden.
+- Die Informationen zum Status einer Einreichung und dessen Historie sind nun direkt im Einreichung hinterlegt und
+ werden mit zur Verfügung gestellt, wodurch keine separaten Endpunkte mehr notwendig sind.
+
+### Application Retrieval
+
+Wie oben schon angesprochen hat sich die Struktur einer Einreichung verändert, sodass ein Einreichung bei der Abholung
+wie folgt beispielhaft aufgebaut ist:
+
+```json
+{
+ "destinationId": "879ee109-a690-4db8-ab32-424284184d7d",
+ "submissionId": "ce75a6b8-d72f-4b94-b09e-af6be35bc2ae",
+ "attachments": [
+ "879ee109-a690-4db8-ab32-424284184d7d",
+ "2046f9f1-dc89-4440-9c24-c76a8f40d668"
+ ],
+ "encryptedMetadata": "eyJlbmMiOiJBMjU2R0NNIiwiYWxnIjoiUlNBLU9BRVAtMjU2In0.nlXGAufYH36IABDy0En0LXEhGfC20IZSSchs27ADalHpRoTZKfXhc7hcMk8Y9V8yTP0jYbmrq6NtEg-QS2O5TQFD9Hluhpb631PBgKjPXHYX1Y6iUcR1sXxSUPjePi8F8PcZUZuUJLnhz6myyc9scdAq9BXG2cDJVgkfLI8eZdrqnrY24Hh32_7d5OKLFSpSDrBlqfyQuY8Wbs2h8Wy4Z4hwT1aWDO7b-SqJA181hUbNcF_rR4Mze3Fdtu-3uOIQYgLBBRmN1ZHDLk0EKNCI4B8MyDKLGPoM0ZomV5lVwVWjAMRI4CgQkIQ9rnm-Adof-GbegQL3yJSoNIWRWgzCnZBYZ638QgPllCMVW3WvEVvsgj0Hj16PbofqXTQ5S73LINfP6FZawfC0yMrYjSV_N2L0Lkp2KI3BkJcy-PcFhBnhwu2IsJGAlyDRCnXdVqig8m5yLHuSMQTpLW69LzPEskfsjhnNDR-CEBZpicjMfc-4CL6U7E7YoGc_99DzE5U5._JfqyKH23GiKsnDW.ZtMMjZ3GgcgHss8qbFRhrjl4L0kAfbco-oXICkk.VBHJ00FyDTYjOA_OYfiz5g",
+ "encryptedData": "eyJlbmMiOiJBMjU2R0NNIiwiYWxnIjoiUlNBLU9BRVAtMjU2In0.nlXGAufYH36IABDy0En0LXEhGfC20IZSSchs27ADalHpRoTZKfXhc7hcMk8Y9V8yTP0jYbmrq6NtEg-QS2O5TQFD9Hluhpb631PBgKjPXHYX1Y6iUcR1sXxSUPjePi8F8PcZUZuUJLnhz6myyc9scdAq9BXG2cDJVgkfLI8eZdrqnrY24Hh32_7d5OKLFSpSDrBlqfyQuY8Wbs2h8Wy4Z4hwT1aWDO7b-SqJA181hUbNcF_rR4Mze3Fdtu-3uOIQYgLBBRmN1ZHDLk0EKNCI4B8MyDKLGPoM0ZomV5lVwVWjAMRI4CgQkIQ9rnm-Adof-GbegQL3yJSoNIWRWgzCnZBYZ638QgPllCMVW3WvEVvsgj0Hj16PbofqXTQ5S73LINfP6FZawfC0yMrYjSV_N2L0Lkp2KI3BkJcy-PcFhBnhwu2IsJGAlyDRCnXdVqig8m5yLHuSMQTpLW69LzPEskfsjhnNDR-CEBZpicjMfc-4CL6U7E7YoGc_99DzE5U5._JfqyKH23GiKsnDW.ZtMMjZ3GgcgHss8qbFRhrjl4L0kAfbco-oXICkk.VBHJ00FyDTYjOA_OYfiz5g",
+ "currentStatus": "queued",
+ "statusHistory": [
+ {
+ "sourceState": "incomplete",
+ "targetState": "queued",
+ "timestamp": "2021-01-30T08:30:00Z"
+ }
+ ]
+}
+```
+
+Die Fachdaten und Metadaten sind verschlüsselt, die Struktur verändert und daher hat sich auch bei der Abholung einer
+Einreichung der Prozess verändert bzw. reduziert, indem die Endpunkte für die Abholung der Fachdaten und Metadaten nun
+kombiniert sind.
+
+#### Dokument abholen
+
+Bei der Abholung werden nun als Antwort keine Binärdaten mehr zur Verfügung gestellt, sondern die verschlüsselten
+Inhalte.
+
+#### Bestätigung der Abholung
+
+- Als Antwort müsste dieser Endpunkt gar keinen Body mitliefern. Damit nicht-konforme Middleware den Request trotzdem
+ sauber routet liefert er jetzt `{}` (statt vorher `{"result": "success"}`).
+
+## [0.7.0]
+
+### Umgesetzte Change Requests
+
+#### #13 API Specification: Method of Acknowledge Application endpoint of Subscriber API should be PUT instead of POST
+
+Die Operationen "Send Application" und "Acknowledge Application" wurden auf PUT umgestellt.
+
+Bitte beachten Sie, dass die PUT-Operationen jetzt auf die Status-Resource wirken.
+
+#### #19 contentStructure.data.size entfernen
+
+Aufgrund verschiedener Codierungen kann die Größe der Fachdaten (JSON oder XML) in Bytes nicht einfach und verlässlich
+vorhergesagt werden. Daher wurde die Angabe der Größe der Fachdaten aus den Metadaten entfernt.
+
+#### #23 Pattern nicht referenzieren
+
+Im Dokument (document.json) wurde bei der Property `signature` als Pattern eine Referenz auf base64url.json gesetzt:
+
+```json
+ "signature": {
+"pattern": {
+"$ref": "../common/base64url.json#/pattern"
+},
+"type": "string",
+"description": "Sofern der Antragstellers dieses Dokument signiert hat, wird die Signatur hier base64url-encoded eingebettet"
+}
+```
+
+Dies führt beim Swagger-Codegen und dem OpenAPI-Generator zu Fehlern. Um die Codegenerierung zu erleichtern wurde das
+Pattern dorthin kopiert.
+
+```json
+ "signature": {
+"type": "string",
+"description": "Sofern der Antragstellers dieses Dokument signiert hat, wird die Signatur hier base64url-encoded eingebettet",
+"pattern": "^[a-zA-Z0-9-_=]+$"
+}
+```
+
+#### #24 Keine mehrfachen Typen
+
+Im Modell address-national.json wurde für die Hausnummer (houseNumber) die Typen `integer` und `string` definiert. Die
+Hausnummer sollte eigentlich vom Typ `integer` sein und Zusätze in den Hausnummerzusatz (houseNumberSuffix) kommen. Um
+etwas flexibler zu sein, wurde aber alternativ auch ein `string` für die Hausnummer zugelassen. In FIM wurde die
+Hausnummer auch als Text-Feld definiert (F00000016).
+
+```json
+ "houseNumber": {
+"type": [
+"string",
+"integer"
+],
+"description": "Hausnummer",
+"maxLength": 9,
+"pattern": "^[1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?$",
+"minimum": 1
+}
+```
+
+Die Verwendung von mehr als einem Typen führt bei Codegeneratoren zu Problemen. Daher wird nur noch der Typ `string`
+verwendet.
+
+```json
+ "houseNumber": {
+"type": "string",
+"description": "Hausnummer",
+"maxLength": 9,
+"pattern": "^[1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?$"
+}
+```
+
+#### #25 Rechtsgrundlage der Verwaltungsleistung
+
+Das Modell "Public Service Type" (public-service-type.json) wurde in "Verwaltungsleistung" umbenannt und hat ein
+zusätzliches Feld "Rechtsgrundlage" (legalBasis) erhalten.
+
+#### #33 Antragsdatum
+
+Unter `additionalReferenceInfo` wurde eine optionale Property `applicationDate` (Antragsdatum) hinzugefügt.
+
+#### #34 Status History und aktuellen Status verschieben
+
+Die Pfade für den aktuellen Status und die Statushistorie sind jetzt:
+
+- `/destinations/{destinationId}/applications/{applicationId}/status` - aktueller Status
+- `/destinations/{destinationId}/applications/{applicationId}/status/history` - Statushistorie
+
+#### #35 Info/Test Resource hinzufügen
+
+Es wurde in beiden APIs eine Resource `/info` hinzugefügt, die aktuell die API-Version ausgibt. Dies kann genutzt
+werden, um die Grundsätzliche Erreichbarkeit der API zu testen und um sicherzustellen, dass eine kompatible Version der
+API verwendet wird.
+
+#### #43 AuthentificationInfo um Liste von verifizierten Feldern ergänzen
+
+Die `authentificationInfo` wurde um ein Array `authenticatedFields` ergänzt, das die Felder aus der `identityInfo`
+auflistet, für die die Authentifkation gilt. Zusätzlich wurde `authentificationMethod` zu einem Enum umgewandelt.
+
+#### #45 Mime-Types
+
+Die Mime-Types in Application Schema wurden gemäß RFC abgebildet werden:
+
+- `application/json` statt `json`
+- `application/xml` statt `xml`
+
+#### #49 JSON Web Key Set durch JSON Web Key ersetzt
+
+Die Destination enthält nun einen JWK statt einem JWK Set.
+
+## [0.6.0]
+
+### Dokumentation
+
+- [Fehlercodes](status-and-error-codes.md) dokumentiert
+- [Erste Schritte](getting-started/overview.md) überarbeitet
+
+### Umgesetzte Change Requests
+
+#### #3 Sematic error of the OAS in editor.swagger.io
+
+Das Security Schema darf keine Leerzeichen enthalten und wurde deswegen von "OAuth 2.0" in "OAuth20" umbenannt.
+
+#### #4 academicTitle -> doctoralDegrees
+
+Alle Vorkommen von `academicTitle` wurden durch `doctoralDegrees` ersetzt.
+
+#### #5 telephone -> telephones
+
+Da Arrays mit einem Plural bezeichnet werden sollen wurde `telephone` durch `telephones` ersetzt.
+
+#### #7 Regex für Hausnummernzusatz ist falsch
+
+Das Pattern für den Hasnummernzusatz `^[\\p{L}0-9. ]*$` war inkorrekt da die Zeichenklassen `\p{L}` nicht zulässig ist.
+Es wurde daher zu `^[A-Za-z0-9. ]*$` korrigiert.
+
+#### #10 API Specification: senderId and subscriberId in URIs
+
+Die Sender- und Subscriber-ID muss nicht mehr über den Pfad mitgegeben werden sondern wird automatisch über das Token
+ermittelt. Damit entfallen die IDs als Pfadangabe.
+
+#### #11 API Specification: Missing nouns in Sender API URIs endpoints
+
+Die Pfade auf in der Sender API enthielten vor den IDs kein beschreibendes Nomen. Dies wurde korrigiert. Zum Beispiel:
+
+- vorher: `/{destinationId}/{applicationId}/data`
+- nachher: `/destinations/{destinationId}/applications/{applicationId}/data`
+
+#### #12 API Specification: Missing destinationId in Get Status endpoint of Sender
+
+Die Operation "Get Status" wies im Gegensatz zu den anderen Operationen keine vorangestellte Destination-ID auf.
+
+- vorher: `/{applicationId}/status`
+- nachher: `/destinations/{destinationId}/applications/{applicationId}/status`
+
+#### #16 Fachdaten optional
+
+Das Element `data` in der `contentStructure` war verpflichtend. Damit mussten Fachdaten übertragen werden. Das Element
+ist jetzt optional.
+
+## [0.5.0]
+
+### Übergreifende Änderungen
+
+#### Basis-URLs
+
+Die Basis-URLs werden ab sofort mit jeder neuen Version geändert, damit ein paralleler Betrieb mehrerer API-Versionen
+möglich ist. Die Basis-URLs für diese Version sind:
+
+- <https://sender.fiep-poc.de/beta5/>
+- <https://subscriber.fiep-poc.de/beta5/>
+
+#### CR-1: Diversen Modellen wurde der Discriminator `type` hinzugefügt
+
+- `models/application/applicant-contact-info.json`
+- `models/application/applicant-contact-info.json`
+- `models/application/applicant-person.json`
+- `models/application/applicant.json`
+- `models/common/address-international.json`
+- `models/common/address-national.json`
+- `models/common/address-postbox.json`
+- `models/common/individual.json`
+- `models/destination-no-id.json`
+
+#### CR-3: Source in Sender ändern
+
+In der Dokumentation werden die Begriffe "Source" und "Sender" synonym verwendet. Um die Dokumentation klarer zu machen,
+wurden alle Vorkommen von "Source" in "Sender" geändert.
+
+<!-- theme: warning -->
+> **Hinweis:** Dies wirkt sich auch auf die OAuth-Scopes aus. Der Scope `{senderId}:source:manage` wurde in `{senderId}:sender:manage` geändert.
+
+#### CR-5: Zusätzliche Properties verbieten
+
+- Wo möglich wurde `"additionalProperties": false` gesetzt um weitere Properties zu verbieten.
+- Bei den Metadaten und der Destination ohne ID musste `"additionalProperties": false` wieder entfernt werden da sonst
+ keine Ableitung mit `allOf` möglich ist.
+
+### Dokumentation
+
+- Release Notes mit aufgenommen
+- Dokumentation zu OAuth integriert
+- Token-URL eingetragen
+- Postman Collection & Environment integriert
+
+### Modelle
+
+#### Destination
+
+`models/destination-no-id.json`
+
+#### eID
+
+- eID-org-acting-person.json aufgelöst und in eID-natural-person.json integriert.
+
+#### Postfachadresse
+
+`models/common/address-national.json`
+`models/common/address-postbox.json`
+
+- Um ein doppeltes `oneOf` zu vermeiden wurde die Postfach Adresse aus der nationalen Adresse herausgelöst.
+
+#### Application Document
+
+`models/application/document.json`
+
+- Regex Pattern für SHA-256/512 Hash präzisiert: "`[0-9A-F]{64,128}`" -> "`^[A-Fa-f0-9]{64}([A-Fa-f0-9]{64})?$`"
+
+### Application Sender API
+
+#### Add Application Data
+
+- Im Erfolgsfall enthält der Body `{"result":"success"}`
+
+#### Add Application Document
+
+- Im Erfolgsfall enthält der Body `{"result":"success"}`
+
+### Application Subscriber API
+
+#### Update Destination
+
+- Im Erfolgsfall enthält der Body `{"result":"success"}`
+
+#### Delete Destination
+
+- Im Erfolgsfall enthält der Body `{"result":"success"}`
+
+#### Acknowledge Application
+
+- Bugfix: Property `final-delivery` auf Camelcase umgestellt.
+- Bugfix: Angaben von `finalDelivery` in Acknowledge Application ist verpflichtend.
+
+## [0.4.0]
+
+### Modelle
+
+- Alle Bezeichner auf CamelCase umgestellt.
+- Beispiele angepasst.
+
+#### Application Metadata
+
+`models/application/metadata-no-id.json`
+
+- `data/mimeType` entfernt, da redundant zu `data/schema/mimeType`
+
+### Application Sender API
+
+- Alle Bezeichner auf CamelCase umgestellt.
+- Beispiele angepasst.
+
+### Application Subscriber API
+
+- Alle Bezeichner auf CamelCase umgestellt.
+- Beispiele angepasst.
+
+## [0.3.0]
+
+### Modelle
+
+#### Application Metadata
+
+`models/application/metadata-no-id.json`
+
+- Property `data/size` ergänzt
+
+#### eID
+
+`models/common/eID-org-acting-person.json`
+
+- Property `artictic-name` in `artistic-name` umbenannt
+
+#### Internationale Adresse
+
+`models/common/address-international.json`
+
+- Property `lines`:
+ - Es müssen mindestens zwei Zeilen angegeben werden
+ - Maximallänge 35 Zeichen
+
+#### Nationale Adresse
+
+`models/common/address-national.json`
+
+- Alle Eigenschaften mit weiteren Einschränkungen mit Maximallänge oder Pattern versehen
+
+#### eID
+
+`models/common/eID-org-acting-person.json`
+
+- Property `academic-title` in `doctoral-degrees` umbenannt
+
+#### Phone
+
+`models/common/phone.json`
+
+- Property `number`: Formatbeschränkung gelockert
+- Property `type` entfernt
+- Property `description` hinzugefügt
+
+#### Phone Number
+
+`models/common/phonenr.json`
+
+- Unbenutztes Modell gelöscht
+
+## [0.2.0] - 2020-03-31
+
+### Modelle
+
+#### Antragsteller - Organisation
+
+`models/application/applicant-organization.json`
+
+- Property `role` entfernt
+- Property `org-validation/validated` entfernt
+- Property `legal-representatives` ist jetzt eine `$ref` auf `models/common/individual.json`
+
+#### Antragsteller - Natürliche Person
+
+`models/application/applicant-person.json`
+
+- Property `role` entfernt
+
+#### Application Schema
+
+Das Schema wurde umgebaut und enthält jetzt drei Angaben:
+
+- mime-type: ist entweder `json` oder `xml`
+- schema-source: Quelle für das Schema. Kann `fim` oder `none` sein. Bei `none` dürfen beliebige Datenstrukturen
+ übertragen werden.
+- schema-id: ID des Schemas, ist von der Schemaquelle (`schema-source`) abhängig.
+
+#### Person
+
+Die Person (Verzeichnis models/person/) wurde weitestgehend entfernt. Es gibt nur noch das Modell
+models/common/individual.json für eine natürliche Person.
+
+#### Phone
+
+`models/common/phone.json`
+
+- Properties `number` und `type` sind jetzt verpflichtend
+
+#### Destination
+
+Die Destination wurde in mehrere Modelle zerlegt, um dem Sender einen anderen Umfang zu zeigen als dem Subscriber.
+
+#### Statusübersicht
+
+`models/status-overview.json`
+
+- Umbenannt: `models/status.json` → `models/status-overview.json`
+- Enum Wert `sending` entfernt
+- Property `since` in `timestamp` umbenannt
+- Property `number` ergänzt
+
+#### Error Body
+
+`models/error-body.json`
+
+- Umbenannt: `models/error.json` → `models/error-body.json`
+- Enthält jetzt ein Array von Fehlern, statt nur einem.
+
+#### Neue Modelle
+
+- base64: `models/common/base64.json`
+- JSON Web Encryption (JWE): `models/common/jwe.json`
+- JSON Web Key (JWK): `models/common/jwk.json`
+
+### Application Sender API
+
+`reference/sender.json`
+
+- Vorkommen von "Transfer" in "Application" umbenannt
+ - Dadurch sind auch Operation-IDs geändert worden (siehe unten)
+- OAuth2 Scopes ergänzt
+- Operation "Get Status Entry" (get-application-status-entry) entfernt
+- Operation "Get Application Upload Status"
+ - Property `docs/doc-id` ergänzt
+- Operation "Create Application": ID in create-application geändert
+- Operation "Send Application" (früher "Commit Application"): ID in commit-application geändert
+
+### Application Subscriber API
+
+- OAuth2 Scopes ergänzt
+- Operation "Acknowledge Application" (früher "Commit Application"): ID in ack-application geändert
+
+### Dokumentation
+
+Die Dokumentation im Verzeichnis `docs` wurde erstellt.
diff --git a/versioned_docs/version-0.14/details/authentication/scopes-sender.md b/versioned_docs/version-0.14/details/authentication/scopes-sender.md
new file mode 100644
index 0000000000000000000000000000000000000000..333ecc51ea77dbe51a23db04a9e3c4ece7d9e385
--- /dev/null
+++ b/versioned_docs/version-0.14/details/authentication/scopes-sender.md
@@ -0,0 +1,156 @@
+# OAuth-Scopes für sendende Systeme
+
+Für den Zugriff auf die Submission API werden vom Autorisierungsserver Berechtigungen in Form von OAuth-Scopes vergeben.
+Sendende Systeme werden damit berechtigt, Einreichungen vorzunehmen.
+
+## Zustellberechtigungs-Scopes
+
+Die Zustellberechtigungs-Scopes erlauben dem Zustelldienst festzustellen, ob ein sendendes System eine Einreichung an einen bestimmten Zustellpunkt übermitteln darf.
+Zustellberechtigungs-Scopes werden im Self-Service-Portal bei der Registrierung von API-Clients festgelegt und sind im [`scope`-Claim des Access Tokens](/details/infrastructure-docs/sender.md) hinterlegt.
+
+### Zusammensetzung der Zustellberechtigungs-Scopes
+
+Der Zustellberechtigungs-Scope kann eine beliebige Anzahl an Regionen oder eine Kombination aus Region und Leistungen enthalten.
+Scopes für sendende Systeme bestehen aus drei mit `:` getrennten Teilen:
+
+- `send`
+- `region` oder `service`
+- Bei `region`: Einschränkung nach Region. Bei `service`: Einschränkung nach Service.
+
+Im folgenden eine Beschreibung der einzelnen Varianten:
+
+#### Scope: Region
+
+- **Typ**: Geographische Zuordnung
+- **Beispiel**: `send:region:DE081150045045`
+- **Erläuterung**: Eine geographische Zuordnung zu einem Bundesland, Landkreis, einer Gemeinde etc. erfolgt über den [Amtlichen Regionalschlüssel](https://de.wikipedia.org/wiki/Amtlicher_Gemeindeschl%C3%BCssel#Regionalschl%C3%BCssel), vorangestellt mit `DE`.
+Siehe auch: [Gemeindeverzeichnis des Statistischen Bundesamtes](https://www.destatis.de/DE/Themen/Laender-Regionen/Regionales/Gemeindeverzeichnis/_inhalt.html)
+
+#### Scope: Leistung (innerhalb LeiKa)
+
+- **Typ**: Leistungstyp innerhalb des LeiKa (LeiKa-Schlüssel)
+- **Beispiel**: `send:service:urn:de:fim:leika:leistung:99108008252000`
+- **Erläuterung**: Eine Leistung, die im [Leistungskatalog der öffentlichen Verwaltung](https://leitfaden.ozg-umsetzung.de/display/OZG/2.1+Verwaltungsleistungen+im+Sinne+des+OZG) (LeiKa) verzeichnet ist, wird über ihren LeiKa-Schüssel, vorangestellt mit `urn:de:fim:leika:leistung:` referenziert.
+Der LeiKa ist im [FIM-Portal](https://fimportal.de/kataloge#download-leistungen) abrufbar.
+
+#### Scope: Leistung (außerhalb LeiKa)
+
+- **Typ**: Leistungstyp außerhalb des LeiKa
+- **Beispiel**: `send:service:urn:myleistung`
+- **Erläuterung**: Eine Leistung, die nicht im Leistungskatalog abgebildet ist, kann übergangsweise über eine andere Leistungs-ID referenziert werden.
+Diese ID muss eindeutig sein.
+Reine Leistungsscopes werden nicht vergeben sondern sind immer mit einer Region gekoppelt.
+
+#### Scope: Kombination Region / Leistung
+
+- **Typ**: Kombination aus Leistungstyp und Region
+- **Beispiel**: `send:region:DE081100000000+send:service:urn:de:fim:leika:leistung:99108008252000` oder `send:region:DE081100000000+send:service:urn:myleistung`
+- **Erläuterung**: Eine Kombination aus amtlichem Gemeindeschlüssel und LeiKa-Schlüssel.
+Hier erfolgt eine Einschränkung nach beiden angegeben Kriterien (Zugriff nur auf spezifische Leistung in der angegebenen Region).
+Reine Leistungsscopes werden nicht vergeben sondern sind immer mit einer Region gekoppelt.
+
+### Einschränkung: Region
+
+Eine Einschränkung der Berechtigung für bestimmte Regionen erfolgt auf Basis des zwölfstelligen [Amtlichen Regionalschlüssels (ARS)](https://de.wikipedia.org/wiki/Amtlicher_Gemeindeschl%C3%BCssel#Regionalschl%C3%BCssel), vorangestellt mit `DE`:
+```
+1.-2. Stelle = DE
+3.–4. Stelle = Kennzahl des Bundeslandes
+5. Stelle = Kennzahl des Regierungsbezirks; wenn nicht vorhanden: 0
+6.–8. Stelle = Kennzahl des Landkreises oder der kreisfreien Stadt
+8.–11. Stelle = Verbandsschlüssel
+12.–14. Stelle = Gemeindekennzahl
+```
+
+Es ist je möglich nur einen Teil des ARS anzugeben, z.B. nur `DE` + Bundesland + Regierungsbezirk.
+
+Eine Liste der amtlichen Regionalschlüssel findet sich im [Gemeindeverzeichnis des Statistischen Bundesamtes](https://www.destatis.de/DE/Themen/Laender-Regionen/Regionales/Gemeindeverzeichnis/_inhalt.html) sowie im [XRepository](https://www.xrepository.de/details/urn:de:bund:destatis:bevoelkerungsstatistik:schluessel:rs).
+
+**Hinweis**: Ohne zusätzliche Einschränkung auf eine Leistung ist ein Zustellberechtigungs-Scope für alle Leistungen in der angegebenen Region gültig.
+
+**Beispiel**: Mit der Angabe des zwölfstelligen ARS kann die Stadt Sindelfingen eindeutig adressiert werden:
+
+```
+send:region:DE081150045045
+```
+
+Werden nicht alle zwölf Stellen des ARS angegeben, sondern nur ein Prefix des ARS, so können statt einer spezifischen Gemeinde auch darüberliegende Kreise, Regierungsbezirke oder Bundesländer abgebildet werden.
+Wird ein solcher Prefix eines ARS angegeben, schließt dieser alle sich darin befindlichen Gliederungen mit ein.
+
+**Beispiel**: Dieser Schlüssel steht für alle Leistungen in der Region Stuttgart und schließt alle darunterliegenden Landkreise, Städte und Gemeinden mit ein:
+
+```
+send:region:DE0811
+```
+
+**Beispiel**: Der folgenden Schlüssel referenziert über die Angabe der ersten beiden Ziffern des ARS alle Regierungsbezirke, Landkreise, Städte und Gemeinden im Bundesland Brandenburg:
+
+```
+send:region:DE12
+```
+
+**Beispiel**: Über die ausschließliche Angabe des Prefix `DE` können alle Gebietskörperschaften in Deutschland referenziert werden:
+
+```
+send:region:DE
+```
+
+Eine Einschränkung auf konkrete Verwaltungsebenen ist durch das Auffüllen des ARS auf zwölf Stellen mit Nullen möglich.
+
+**Beispiel**: Der folgende Schlüssel referenziert explizit nur den Kreis Böblingen, nicht jedoch beispielsweise die Stadt Leonberg, die im Kreis Böblingen liegt.
+Hierdurch ist eine Einschränkung auf Zustellpunkte möglich, die von der Kreisverwaltung Böblingen betrieben werden, ohne eine Berechtigung für Zustellpunkte der Stadt Leonberg zu gewähren.
+
+```
+send:region:DE081150000000
+```
+
+### Einschränkung: Leistung
+
+Um sendende Systeme zur Einreichung bei allen Zustellpunkten mit einer bestimmten Leistung zu berechtigen, ist eine Vergabe von Berechtigungen auf Basis von Leistungs-IDs möglich.
+Ein Download des Leistungskatalogs mit allen LeiKa-Schlüsseln ist [über das FIM-Portal](https://fimportal.de/kataloge#download-leistungen) möglich.
+
+**Beispiel**: Berechtigung für die LeiKa-Leistung "[Begutachung von abgeschleppten Fahrzeugen](https://fimportal.de/detail/L/99108008252000)" mit LeiKa-Schlüssel `99108008252000`:
+
+```
+send:service:urn:de:fim:leika:leistung:99108008252000
+```
+
+Vor dem LeiKa-Schlüssel muss also der Präfix `urn:de:fim:leika:leistung:` stehen.
+
+**Hinweis**: Reine Leistungsscopes werden nicht vergeben sondern sind **immer** mit einer Region gekoppelt.
+Um ein sendendes System zur Einreichung bei allen existierenden Zustellpunkten unabhängig der Leistung zu berechtigen wird der Schlüssel `send:region:DE` genutzt (siehe nächster Abschnitt).
+Hier wäre das:
+
+```
+send:region:DE+send:service:urn:de:fim:leika:leistung:99108008252000
+```
+
+### Einschränkung: Region+Leistung
+
+Über die Kombination einer geographischen Zuordnung mit einer Leistung über das Plus-Symbol (`+`) ist eine Einschränkung auf Verwaltungsleistungen in einer bestimmten Region möglich.
+Hierbei wird immer zuerst ("vor dem `+`") eine Einschränkung nach der Region und dann ("nach dem `+`") eine Einschränkung nach Leistung vorgenommen.
+
+**Beispiel**: Der folgende Zustellberechtigungs-Scope berechtigt zur Einreichung für die LeiKa-Leistung "[Begutachung von abgeschleppten Fahrzeugen](https://fimportal.de/detail/L/99108008252000)" im Landkreis Böblingen:
+
+```
+send:region:DE08115+send:service:urn:de:fim:leika:leistung:99108008252000
+```
+
+### Nutzung mehrerer Scopes im Scope Claim eines Access Tokens
+
+Der `scope` Claim des Access Tokens kann mehrere Zustellberechtigungs-Scopes – separiert mit Leerzeichen gemäß [RFC 6749, Abschnitt 3.3](https://datatracker.ietf.org/doc/html/rfc6749#section-3.3) – enthalten.
+Diese sind unabhängig (`oder`-Verknüpfung) voneinander zu betrachten.
+Die parallele Nutzung aller Berechtigungsvarianten (Region und Leistung+Region) ist möglich.
+Das kann erfolgen, wenn z.B. zu einem Client mehrere unterschiedliche Berechtigungen hinterlegt sind oder ein Client bei der Tokenabfrage explizit bestimmte Scopes abfragt.
+
+**Beispiel**: Ein Client hat die Scopes `send:region:DE12` hinterlegt und könnte somit an alle Zustellpunkte in Brandenburg (`12`) senden.
+Die Token-Abfrage geschieht allerdings mit dem Scope eines Landkreises: `send:region:DE124412`.
+Da sich dieser Landkreis innerhalb von Brandenburg befindet, erhält der Client einen Token mit dem Token des Landkreises.
+Dies ist aus sicherheitsperspektive einreichungsspezifisch zu bevorzugen ("Prinzip der geringsten Privilegien").
+
+Ein sendendes System ist daher zur Einreichung bei allen Zustellpunkten berechtigt, auf die mindestens einer der Scopes zutrifft.
+
+**Beispiel**: Mit diesem Zustellberechtigungs-Scope kann ein sendendes System Einreichungen für alle Leistungen im Landkreis Böblingen, als auch die Leistung "[Begutachung von abgeschleppten Fahrzeugen](https://fimportal.de/detail/L/99108008252000)" im Bundesland Brandenburg vornehmen:
+
+```
+send:region:DE08115 send:region:DE12+send:service:urn:de:fim:leika:leistung::99108008252000
+```
diff --git a/versioned_docs/version-0.14/details/authentication/scopes-subscriber.md b/versioned_docs/version-0.14/details/authentication/scopes-subscriber.md
new file mode 100644
index 0000000000000000000000000000000000000000..430c4694cde378035305b5c5c831ea79fe0f4561
--- /dev/null
+++ b/versioned_docs/version-0.14/details/authentication/scopes-subscriber.md
@@ -0,0 +1,27 @@
+# OAuth-Scopes für empfangende Systeme
+
+Für den Zugriff auf die Submission API werden vom Autorisierungsserver Berechtigungen in Form von OAuth-Scopes vergeben.
+Empfangende Systeme werden damit berechtigt Einreichungen abzuholen.
+
+Typischerweise existiert für einen Zustellpunkt genau ein empfangsberechtigtes System (z.B. ein Fachverfahren oder eine virtuelle Poststelle).
+Berechtigungen für empfangende Systeme werden beim Anlegen eines Zustellpunktes im Self-Service-Portal vergeben.
+
+Die Erstellung von Zustellpunkten ist [nur durch das Self-Service-Portal möglich](/details/infrastructure-docs/scopes-internal.md).
+
+## Zusammensetzung der Zustellberechtigungs-Scopes
+
+Scopes für empfangende Systeme bestehen aus drei mit `:` getrennten Teilen:
+
+- `subscribe` oder `manage`
+- `destination`
+- Der eindeutigen ID eines Zustellpunktes (destination id)
+
+### Scope: Empfangsberechtigung für einen Zustellpunkt
+
+- **Beispiel**: `subscribe:destination:655c6eb6-e80a-4d7b-a8d2-3f3250b6b9b1`
+- **Erläuterung**: Mit dieser Berechtigung ist ein Abruf von Einreichungen sowie das Schreiben des Event Logs einer Einreichung beim referenzierten Zustellpunkt (destination) möglich.
+
+### Scope: Verwalten eines Zustellpunktes
+
+- **Beispiel**: `manage:destination:655c6eb6-e80a-4d7b-a8d2-3f3250b6b9b1`
+- **Erläuterung**: Mit dieser Berechtigung ist die Änderung der in einem Zustellpunkt hinterlegten Daten (z.B. Antragsdaten-Schemata) möglich.
diff --git a/versioned_docs/version-0.14/details/callbacks.mdx b/versioned_docs/version-0.14/details/callbacks.mdx
new file mode 100644
index 0000000000000000000000000000000000000000..e9bac650c9c247e79b199450e7a7fcf382997cf7
--- /dev/null
+++ b/versioned_docs/version-0.14/details/callbacks.mdx
@@ -0,0 +1,143 @@
+---
+title: Verwendung von Callbacks
+---
+
+import ApiLink from '@site/src/components/ApiLink'
+
+Der FIT-Connect Zustelldienst informiert sendende und empfangende Systeme (API-Clients) aktiv über [neue Einreichungen](../getting-started/receiving/query.mdx) oder [Statusupdates](../getting-started/sending/query-status.mdx).
+Hierzu werden HTTP-Callbacks genutzt, die auch als [Webhooks](https://de.wikipedia.org/wiki/WebHooks) bezeichnet werden.
+Webhooks ermöglichen es, API-Clients aktiv über diese Ereignisse zu informieren ohne dass eine regelmäßige Abfrage ([Polling](https://de.wikipedia.org/wiki/Polling_(Informatik))) nötig wäre.
+Technisch werden Webhooks als HTTP-POST-Request realisiert.
+
+Im Folgenden verwenden wir die Begriffe *Callback* und *Webhook* synonym.
+
+## Callback-URL
+API-Clients stellen zum Empfang von Callbacks einen HTTP-Endpunkt bereit, an den der Zustelldienst einen HTTP-POST-Request übermitteln kann.
+API-Clients müssen auf eingehende Callbacks mit einer HTTP-Response mit Status Code `200 OK` antworten.
+Die URL dieses HTTP-Endpunkts bezeichnen wir als Callback-URL (`callbackUrl`).
+Sie wird von dem an FIT-Connect angebundenen System festgelegt.
+
+Eine solche Callback-URL kann z.B. wie folgt aussehen:
+```
+https://fachverfahren.beispielstadt.example.org/callbacks/fit-connect
+```
+
+Die Callback-URL **DARF NUR** über HTTPS erreichbar sein.
+Der Zustelldienst wird Callbacks nur über eine via HTTPS verschlüsselte Verbindung auslösen.
+
+## Konfiguration von Callbacks
+Eine Konfiguration von Callbacks ist [über das Self-Service-Portal](../getting-started/receiving/destination.mdx) und über die API-Endpunkte <ApiLink to="/destinations/{destinationId}" withMethod="put" /> bzw. <ApiLink to="/destinations/{destinationId}" withMethod="patch" /> möglich.
+Bei der Konfiguration werden die *Callback-URL* und ein *Callback-Secret* vom API-Client festgelegt.
+Das *Callback-Secret* dient der Überprüfung der Echtheit (Authentizität) von eingehenden Callbacks (siehe nächster Abschnitt).
+Das angegebene *Callback-Secret* kann über die API nur geschrieben und aktualisiert, aber nicht gelesen werden und **DARF NICHT** an Dritte weitergegeben werden.
+
+Ein sicheres *Callback-Secret* kann über die folgenden Aufrufe erzeugt werden:
+- Python: `python -c 'import secrets; print(secrets.token_urlsafe(32))'`
+- Ruby: `ruby -rsecurerandom -e 'puts SecureRandom.hex(32)'`
+- pwgen: `pwgen --secure 64 1`
+
+Die Einrichtung von Callbacks im Self-Service-Portal wird im Artikel `TODO: Link einfügen` näher beschrieben.
+
+### Konfiguration von Callbacks für Zustellpunkte
+Über die API können Callbacks für Zustellpunkte wie folgt konfiguriert werden:
+<Tabs
+defaultValue="curl"
+values={[
+ {label: 'curl', value: 'curl',},
+ {label: 'Java', value: 'java',},
+ {label: 'JavaScript', value: 'javascript',},
+]}>
+<TabItem value="curl" label="curl">
+
+```bash
+$ SERVICE_URL=...
+$ JWT_TOKEN=...
+$ DESTINATION_ID=...
+$ CALLBACK_URL=https://fachverfahren.beispielstadt.example.org/callbacks/fit-connect
+$ CALLBACK_SECRET=insecure_unsafe_qHScgrg_kP-R31jHUwp3GkVkGJolvBchz65b74Lzue0
+$ curl -X PATCH \
+ -H "Content-Type: application/json" \
+ -H "Authorization: Bearer $JWT_TOKEN" \
+ --data "{ \"callback\": { \"url\": \"$CALLBACK_URL\", \"secret\": \"$CALLBACK_SECRET\" }}" \
+ "$SERVICE_URL/destinations/$DESTINATION_ID"
+```
+
+</TabItem>
+<TabItem value="java" label="Java">
+:::caution TODO
+TODO: Codebeispiel ergänzen
+:::
+</TabItem>
+<TabItem value="JavaScript" label="JavaScript">
+:::caution TODO
+TODO: Codebeispiel ergänzen
+:::
+</TabItem>
+</Tabs>
+
+## Prüfung von Callbacks
+API-Clients, die Callbacks empfangen, **MÜSSEN** zwingend sicherstellen, dass ausgelöste Callbacks von einem vertrauenswürdigen Zustelldienst stammen.
+Hierzu enthalten Callbacks einen Message Authentication Code (HMAC) gemäß [RFC 2104](https://datatracker.ietf.org/doc/html/rfc2104) auf Basis des angegebenen *Callback-Secrets*.
+Ein Message Athentication Code kann als „symmetrische Signatur“ verstanden werden und ermöglicht die Prüfung der Herkunft und Integrität eines eingehende Callbacks.
+
+Der Message Authentication Code wird im HTTP-Header `callback-authentication` übertragen.
+Um [Replay-Angriffe](https://de.wikipedia.org/wiki/Replay-Angriff) zu vermeiden, enthält der Message Authentication Code einen aktuellen Timestamp.
+Dieser Timestamp wird im HTTP-Header `callback-timestamp` übertragen.
+Bei der Prüfung der Echtheit des ausgelösten Callbacks **MÜSSEN** API-Clients prüfen, dass der angegebene Timestamp nicht älter als **5 Minuten** ist.
+
+Das folgende Beispiel zeigt die Verwendung der HTTP-Header `callback-authentication` und `callback-timestamp`:
+```http
+POST /callbacks/fit-connect
+callback-authentication: f4eig0ht6hdlsfz6DVqGjXi1j3RAombIQ7vjG1M2TFZx1fGurzg1nOEh00lPfLEulhio1RyTOav1e1aMi69SRg==
+callback-timestamp: 1672527599
+
+{"type":"https://schema.fitko.de/fit-connect/callbacks/new-submissions","submissionIds":["f39ab143-d91a-474a-b69f-b00f1a1873c2"]}
+```
+
+Der HMAC wird gebildet aus dem im HTTP-Header `callback-timestamp` übertragenen Zeitstempel und dem im HTTP-Body übertragenen Payload, getrennt durch das Zeichen `.` (Punkt), jeweils UTF-8-kodiert.
+Als Hash-Algorithmus wird SHA-512 verwendet.
+```
+callback-authentication = BASE64(HMAC(key={callback-secret}, message={timestamp}.{http-body}))
+```
+
+Um den Message Authentication Code (HMAC) zu verifizieren, bildet der API-Client mit Hilfe des *Callback Secret* den HMAC nach und vergleicht diesen mit dem im HTTP-Header `callback-authentication` übertragenen HMAC.
+
+Bei der Prüfung **MÜSSEN** die folgenden Implementierungshinweise zwingend zu beachten:
+- Das Callback Secret **MUSS** in API-Clients konfigurierbar sein und **DARF NICHT** fest im Quellcode eines API-Clients einprogrammiert sein.
+ - Dies kann beispielsweise durch die Konfiguration des Callback Secret in einer Konfigurationsdatei oder über eine Umgebungsvariable (`$ export CALLBACK_SECRET=your_secret`) erreicht werden.
+- Bei der Erzeugung des HMAC **MUSS** der Hash-Algorithmus `SHA-512` verwendet werden.
+- Es **MUSS** geprüft werden, dass der angegebene Zeitstempel nicht älter als **5 Minuten** ist.
+- Beim Vergleich des übertragenen HMAC und des vom API-Client gebildeteten HMAC **MUSS** ein zeitlich konstanter Zeichenfolgenvergleich (*constant time string comparison*) verwendet werden.
+ - In Python kann dies über die Verwendung der Methode [`hmac.compare_digest`](https://docs.python.org/2/library/hmac.html#hmac.compare_digest) erreicht werden.
+ - In Ruby kann dies über die Verwendung der Methode [`secure_compare`](https://rubydoc.info/github/rack/rack/master/Rack/Utils:secure_compare) erreicht werden.
+- Callbacks mit ungültigem Message Authentication Code **MÜSSEN** von API-Clients ignoriert/verworfen werden.
+
+Dabei ist zunächst der Zeitstempel (`callback-timestamp`-Header) und anschließend der HMAC (`callback-authentication`-Header) zu prüfen:
+
+```python
+# 1. Timestamp überprüfen
+current_time_epoch = int(time.time())
+seconds_five_minutes = 60 * 5
+if current_time_epoch - request['headers']['callback-timestamp'] > seconds_five_minutes:
+ print('Error: timestamp too old')
+ sys.exit(1)
+else:
+ print('timestamp ok')
+
+# 2. HMAC berechnen
+payload = str(request['headers']['callback-timestamp']) + '.' + request['body']
+
+expected_hmac = hmac.digest(CALLBACK_SECRET.encode("utf-8"), payload.encode("utf-8"), digest=sha512)
+expected_hmac_base64 = base64.b64encode(expected_hmac).decode()
+
+print('hmac', expected_hmac_base64)
+
+# 3. Berechneten HMAC mit HMAC aus HTTP-Header vergleichen
+if not hmac.compare_digest(request['headers']['callback-authentication'], expected_hmac_base64):
+ print('Error: invalid hmac')
+ sys.exit(2)
+else:
+ print('hmac ok')
+```
+
+Das dargestellte Script findet sich auch zur freien Verwendung im [FIT-Connect-Tools-Repository](https://git.fitko.de/fit-connect/fit-connect-tools/-/blob/main/validate-callback.py).
diff --git a/versioned_docs/version-0.14/details/crypto.md b/versioned_docs/version-0.14/details/crypto.md
new file mode 100644
index 0000000000000000000000000000000000000000..f32bc28a2d7635c027d3c177cac3557e4c5da69e
--- /dev/null
+++ b/versioned_docs/version-0.14/details/crypto.md
@@ -0,0 +1,155 @@
+# Vorgaben für kryptographische Verfahren
+
+FIT-Connect verwendet zur Übertragung von Antragsdaten und Metadaten mit direktem Bezug zu Anträgen eine Ende-zu-Ende-Verschlüsselung. Diese ist auf Basis des Standards [JSON Web Encryption (JWE)](https://tools.ietf.org/html/rfc7516) unter Verwendung von Schlüsseln gemäß des Standards [JSON Web Keys (JWK)](https://tools.ietf.org/html/rfc7517) umgesetzt.
+
+Zudem bietet FIT-Connect digital signierte Eingangsbestätigungen für Anträge. Die ausgestellten Signaturen werden auf Basis von [Security Event Tokens (SET)](https://tools.ietf.org/html/rfc8417) erzeugt und die dazugehörigen Schlüssel gemäß des Standards [JSON Web Keys (JWK)](https://tools.ietf.org/html/rfc7517) implementiert.
+
+Die [Liste der standardisierten Algorithmen](https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms) für Signaturen und Verschlüsselung mit JWE/JWS wird für die Nutzung in FIT-Connect unter Berücksichtigung der Vorgaben des BSI gemäß der Richtlinie [TR-02102-1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) eingeschränkt. Diese Einschränkung der zu unterstützenden Algorithmen senkt die Komplexität in Implementierungen der angebundenen Systeme und erfolgte unter Berücksichtigung der praktischen Nutzbarkeit der Algorithmen durch eine breite Unterstützung in Implementierungen der Standards.
+
+## Vorgaben für eingesetzte X.509-Zertifikate
+Dem JSON Web Key zur *Verschlüsselung von Antragsdaten* muss ein für die Empfangsbehörde der Einreichung signiertes X.509 Zertifikat zugrundeliegen. Dem für die *Signaturprüfung von digitalen Eingangsbestätigungen* verwendete JSON Web Key muss ein für die Behörde, die den Einreichung im FIT-Connect-System zwischenspeichert oder empfängt, signiertes X.509 Zertifikat zugrundeliegen. Bei der Erstellung von Zertifikaten und der Zertifikatsprüfung sind die Regelungen und Standards aus BSI [TR-02103](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02103/BSI-TR-02103.pdf?__blob=publicationFile&v=4) zu beachten.
+
+Die verwendeten X.509-Zertifikate müssen der Verwaltungs-PKI entstammen. CA-Zertifikate der Zertifizierungsstellen innerhalb der Verwaltungs-PKI werden gemäß den [Vorgaben des BSI zur Verwaltungs-PKI](https://www.bsi.bund.de/VPKI) durch die Wurzelzertifizierungsstelle des BSI ausgestellt. Für Zertifikate müssen CRL Distribution Points (siehe 8.5 BSI [TR-02103](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02103/BSI-TR-02103.pdf?__blob=publicationFile&v=4)) oder ein OCSP-Endpunkt (siehe 8.5.5 BSI [TR-02103](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02103/BSI-TR-02103.pdf?__blob=publicationFile&v=4)) mit signierten Antworten nach [RFC 6125](https://tools.ietf.org/html/rfc6125) bereitstehen.
+
+Für die den JSON Web Keys zugrundeliegenden X.509-Zertifikate gelten die folgenden kryptographischen Vorgaben:
+
+| Feld | Inhalt | **Erläuterung** |
+| -------------------- | ---------- | ------------------------------------------------------------ |
+| Hashfunktion | SHA-512 | Hashfunktion, die bei der Signatur des Zertifikats verwendet werden muss. (vgl. [BSI TR-02102-1 Tabelle 4.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html)). |
+| asym. Schlüssellänge | 4096 Bit | Länge des zugrundeliegenden RSA-Schlüssels (vgl. [BSI TR-02102-1 Tabelle 3.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html)) |
+| Signaturalgorithmus | RSASSA-PSS | Entspricht dem Standard beschrieben in [RFC 4056](https://tools.ietf.org/html/rfc4056) und vom BSI empfohlen in [BSI TR-02102-1 Abschnitt 5.4.1.](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) |
+
+## Vorgaben zur Ver- und Entschlüsselung von Daten
+### Vorgaben für JSON Web Keys zur Verschlüsselung
+
+Eine Verschlüsselung erfolgt in FIT-Connect auf Basis des Standards JSON Web Encryption gemäß [RFC 7516](https://tools.ietf.org/html/rfc7516).
+
+Zur Nutzung von Zertifikaten in FIT-Connect müssen diese in das JSON Web Key (JWK)-Format konvertiert werden. Das eingesetzte Zertifikat, alle Zertifikate im Zertifizierungspfad und das Wurzelzertifikat MÜSSEN dabei im Attribut `x5c` des JSON Web Key hinterlegt werden.
+
+Die Auswahl, welcher JSON Web Key aus der Liste der zur Verfügung gestellten Keys bei der Verschlüsselung verwendet werden muss, wird anhand der `kid` (Key ID) entschieden. Deshalb MUSS im JSON Web Key eine Key-ID angegeben sein.
+
+Der JSON Web Key muss über die folgenden Attribute gemäß [RFC 7517](https://tools.ietf.org/html/rfc7517#section-4) verfügen:
+
+
+| Feld | Inhalt | Erläuterung |
+| --------- | ----------------------------------------- | ----------- |
+| `kty` | `"RSA"` | Keytype gemäß [RFC 7517, Abschnitt 4](https://tools.ietf.org/html/rfc7517#section-4) |
+| `key_ops` | `["wrapKey"]` | Funktion des Keys (Verschlüsselung des symmetrischen Verschlüsselungskeys) gemäß [RFC 7517, Abschnitt 4.3](https://tools.ietf.org/html/rfc7517#section-4.3) |
+| `alg` | `"RSA-OAEP-256"` | Vorgesehener Algorithmus zur Ver- und Entschlüsselung in Kombination mit diesem JWK. Vorgabe gemäß [BSI TR-02102-1, Abschnitt 3.6](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) |
+| `x5c` | *Die gemäß RFC kodierte Zertifikatskette* | Zertifikatskette vom Teilnehmer:innen-Zertifikat bis zum Wurzelzertifikat einschließlich aller Zwischenzertifikate gemäß [Abschnitt 4.7 RFC 7518](https://tools.ietf.org/html/rfc7517#section-4.7). Hinweis: Gemäß RFC muss das erste Zertifikat der hinterlegten Zertifikatskette dem Teilnehmer:innen-Zertifikat entsprechen. |
+| `kid` | *Eindeutige ID des Keys* | Eindeutige ID zur Referenzierung des JSON Web Key gemäß [RFC 7516, Abschnitt 4.1.6](https://tools.ietf.org/html/rfc7516#section-4.1.6) dar. Es wird empfohlen, hierfür eine UUID gemäß [RFC 4122](https://tools.ietf.org/html/rfc4122) zu verwenden. |
+| `n` | *Modulus des Public Key zum Zertifikat* | Der Modulus des Public Key gemäß [RFC 7518, Abschitt 6.3.1.1](https://tools.ietf.org/html/rfc7518.html#section-6.3.1.1) ("Base64urlUInt" enkodiert) |
+| `e` | `"AQAB"` | Der Exponent des Public Key gemäß [RFC 7518, Abschitt 6.3.1.2](https://tools.ietf.org/html/rfc7518.html#section-6.3.1.2)) |
+
+Das bedeutet, der JSON Web Key zur Verschlüsselung muss diesem Format entsprechen:
+
+```json
+{
+ "kty": "RSA",
+ "key_ops": [
+ "wrapKey"
+ ],
+ "alg": "RSA-OAEP-256",
+ "n": "……(Public Key)……",
+ "e": "AQAB",
+ "kid": "……(Key ID)……",
+ "x5c": [
+ "……(base64 encoded cert)……",
+ "……(base64 encoded intermediate cert)……",
+ "……(base64 encoded root cert)……"
+ ]
+}
+```
+
+### Algorithmen zur Verschlüsselung des Antragsinhalts mit JSON Web Encryption
+
+Zur Verschlüsselung des eigentlichen Antragsinhalts wird ein symmetrisches Verschlüsselungsverfahren mit symmetrischem Schlüssel verwendet. Dieser symmetrische Schlüssel wird mit den asymmetrischen JSON Web Keys, die vom **Fachverfahren** generiert werden und die Verwendungsart **"wrapKey"** haben müssen, asymmetrisch verschlüsselt.
+
+Der Content im verschlüsselten JSON Web Encryption Objekt muss mit den folgenden Methoden verschlüsselt werden:
+
+- Symmetrisches Verschlüsselungsverfahren zur Verschlüsselung der Formularinhalts- sowie der Metadaten ("Payload"): AES-256 mit der Betriebsart Galois/Counter-Mode (GCM) gemäß [TR-02102, Abschnitt 2.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html)
+- Asymmetrisches Verschlüsselungsverfahren, um den symmetrischen Schlüssel zu verschlüsseln: RSA-OAEP-256 (RSA mit Optimal Asymmetric Encryption Padding (OAEP) unter Verwendung der Mask Generation Function MGF1 und der Hashfunktion SHA-256). Vorgabe gemäß [BSI TR-02102-1, Abschnitt 3.6](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html)
+
+Zu Übermittlung der verschlüsselten Daten wird das in [RFC 7516 Abschnitt 7.1](https://tools.ietf.org/html/rfc7516#section-7.1) beschriebene Verfahren "JWE Compact Serialization" verwendet.
+
+#### JSON Web Encryption Header
+Im Header des JSON Web Encryption Objektes werden die Verschlüsselungs-Metadaten zu den verschlüsselten Inhaltsdaten übergeben. Header-Attribute werden in [RFC 7516](https://tools.ietf.org/html/rfc7516) definiert.
+
+Die folgenden Attribute müssen im JOSE-Header bei der Übertragung verschlüsselter Daten zwingend definiert sein:
+
+| Feld | Inhalt | Erläuterung |
+| ------ | ------------------ | ----------- |
+| `alg` | `"RSA-OAEP-256"` | Asymmetrisches Verschlüsselungsverfahren, um den "Content Encryption Key" (CEK) zu verschlüsseln, mit dem der Payload über das in "enc" angegebene Verfahren symmetrisch verschlüsselt wurde. Hierfür wird der im Header per "kid" referenzierte öffentliche Schlüssel genutzt. Bezeichner des Algorithmus gemäß [RFC 7518, Abschnitt 4.1](https://tools.ietf.org/html/rfc7518#section-4.1). Vorgabe gemäß [BSI TR-02102-1, Abschnitt 3.6](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) |
+| `enc` | `"A256GCM"` | Symmetrisches Verschlüsselungsverfahren zur Verschlüsselung des Payloads. Bezeichner gemäß [RFC 7518 5.1](https://tools.ietf.org/html/rfc7518#section-5.1). Vorgabe gemäß [TR-02102, Abschnitt 2.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) |
+| `zip` | `"DEF"` | Der Komprimieriungsalgorithmus für die Inhaltsdaten nach [RFC 7516 Abschnit 4.1.3](https://tools.ietf.org/html/rfc7516#section-4.1.3) |
+| `kid` | *ID des Public Keys* | Die ID des JSON Web Keys mit dem Attribute "wrapKey", der zur Verschlüsselung des symmetrischen Keys verwendet wurde. Gemäß [RFC 7516, Abschnitt 4.1.6](https://tools.ietf.org/html/rfc7516#section-4.1.6)). Als Format der ID wird UUID nach [RFC 4122](https://tools.ietf.org/html/rfc4122) empfohlen. |
+| `cty` | *MIME-Type der Inhaltsdaten* | MIME-Type der Inhaltsdaten (Fachdaten, Medatadaten) nach [RFC 7516, Abschnitt 4.1.12](https://tools.ietf.org/html/rfc7516#section-4.1.12) |
+
+## Vorgaben zur Signaturerstellung und -prüfung
+### Vorgaben für JSON Web Keys zur Signaturprüfung
+Eine Signaturprüfung erfolgt in FIT-Connect auf Basis des Standards JSON Web Signature gemäß [RFC 7515](https://tools.ietf.org/html/rfc7515).
+
+Zur Nutzung von Zertifikaten in FIT-Connect müssen diese in das JSON Web Key-Format konvertiert werden. Das eingesetzte Zertifikat, alle Zertifikate im Zertifizierungspfad und das Wurzelzertifikat müssen dabei im Attribut `x5c` des JSON Web Key hinterlegt werden.
+
+Der JSON Web Key muss über die folgenden Attribute gemäß [RFC 7515](https://tools.ietf.org/html/rfc7515#section-4) verfügen.
+
+| Feld | Inhalt | **Erläuterung** |
+| --------- | ----------------------------------------- | ------------------------------------------------------------ |
+| `kty` | `"RSA"` | Keytype gemäß [RFC 7517, Abschnitt 4](https://tools.ietf.org/html/rfc7517#section-4) |
+| `key_ops` | `["verify"]` | Funktion des Keys (Prüfung von digitalen Signaturen) gemäß [RFC 7517, Abschnitt 4.3](https://tools.ietf.org/html/rfc7517#section-4.3) |
+| `alg` | `"PS512"` | Vorgesehener Algorithmus zur Erstellung und Prüfung von Signaturen in Kombination mit diesem JWK. Vorgabe gemäß [BSI TR-02102-1, Abschnitt 5.4.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) |
+| `x5c` | *Die gemäß RFC kodierte Zertifikatskette* | Zertifikatskette vom Teilnehmer:innen-Zertifikat bis zum Wurzelzertifikat einschließlich aller Zwischenzertifikate gemäß [Abschnitt 4.7 RFC 7518](https://tools.ietf.org/html/rfc7517#section-4.7). Hinweis: Gemäß RFC muss das erste Zertifikat der hinterlegten Zertifikatskette dem Teilnehmer:innen-Zertifikat entsprechen. |
+| `kid` | *Eindeutige ID des Keys* | Eindeutige ID zur Referenzierung des JSON Web Key gemäß [RFC 7515, Abschnitt 4.1.4](https://tools.ietf.org/html/rfc7515#section-4.1.4) dar. Es wird empfohlen, hierfür eine UUID gemäß [RFC 4122](https://tools.ietf.org/html/rfc4122) zu verwenden. |
+| `n` | *Modulus des Public Key zum Zertifikat* | Der Modulus des Public Key gemäß [RFC 7518, Abschitt 6.3.1.1](https://tools.ietf.org/html/rfc7518.html#section-6.3.1.1) ("Base64urlUInt" enkodiert) |
+| `e` | `"AQAB"` | Der Exponent des Public Key gemäß [RFC 7518, Abschitt 6.3.1.2](https://tools.ietf.org/html/rfc7518.html#section-6.3.1.2)) |
+
+Das bedeutet, der JSON Web Key zur Prüfung von digitalen Signaturen muss dem folgenden Format entsprechen:
+
+```json
+{
+ "kty": "RSA",
+ "key_ops": ["verify"],
+ "alg": "PS512",
+ "n": "……(Public Key)……",
+ "e": "AQAB",
+ "kid": "……(Key ID)……",
+ "x5t": "……(Fingerprint)……",
+ "x5c": [
+ "……(base64 encoded cert)……"
+ "……(base64 encoded intermediate cert)……",
+ "……(base64 encoded root cert)……",
+ ]
+}
+```
+
+Nicht mehr verwendete JSON Web Keys für Signaturen müssen nach Ende der Verwendung weiterhin bis zum Ende ihrer Gültigkeitsdauer über die Submission API abrufbar sein. Das soll sicherstellen, das auch der Antragsstatus bereits versendeter Anträgen weiterhin verifiziert werden kann.
+
+### Algorithmen zur Signaturerstellung
+Für die Bereitstellung von signierten Statusinformationen über Security Event Tokens gemäß [RFC 8417](https://tools.ietf.org/html/rfc8417) wird der Standard [JSON Web Signature](https://tools.ietf.org/html/rfc7515) eingesetzt.
+
+Zur Signatur der Event Tokens verfügt der Server, der die Tokens ausstellt, über einen Signaturschlüssel. Bei der Verwaltung der Signaturschlüssel sind insbesondere die Hinweise in [BSI TR-03116-4, Abschnitt 6](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03116/BSI-TR-03116-4.html) und [BSI TR-02102-1, Abschnitt 8](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) zu beachten. Der zu dem auf dem Server verwendeten Signaturschlüssel zugehörige Public Key muss als JSON Web Key bereitgestellt werden.
+
+Als Algorithmus für die Signatur MUSS RSASSA-PSS in Verbindung mit SHA-512 eingesetzt werden (`"PS512"`). Das entspricht dem Standard beschrieben in [RFC 7518 Abschnitt 3.5](https://tools.ietf.org/html/rfc7518.html#section-3.5) und wird vom BSI als Signaturverfahren in [BSI TR-02102-1 Abschnitt 5.4.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html) empfohlen.
+
+Zu Ãœbermittlung der Signatur wird das in [RFC 7515, Abschnitt 7.1](https://tools.ietf.org/html/rfc7515#section-7.1) beschriebene Verfahren "JWS Compact Serialization" verwendet.
+
+#### JSON Web Signature Header
+Die folgenden Attribute müssen im JOSE-Header bei der Übertragung signierter Daten zwingend definiert sein:
+
+| Feld | Inhalt | Erläuterung |
+| ----- | ------------------ | ----------- |
+| `alg` | `"PS512"` | Legt RSASSA-PSS mit SHA512 als Algorithmus für die Signatur fest. Bezeichner gemäß [RFC 7518, Abschnitt 3.5](https://tools.ietf.org/html/rfc7518.html#section-3.5) |
+| `kid` | *ID des Public Keys* | Die ID des JSON Web Keys mit dem Attribute "verify" aus dem von der Submission API und Routing API bereitgestellten Keysets, der zur Verifizierung der Signatur dient. Gemäß [RFC7515, Abschnitt 4.1.4](https://tools.ietf.org/html/rfc7515#section-4.1.4). |
+| `cty` | *MIME-Type der Inhaltsdaten* | MIME-Type der Inhaltsdaten (Fachdaten, Medatadaten) nach [RFC 7515, Abschnitt 4.1.10](https://tools.ietf.org/html/rfc7515#section-4.1.10) |
+
+#### JSON Web Signature Payload
+Die zu signierenden Daten werden gemäß [RFC 8259](https://datatracker.ietf.org/doc/html/rfc8259) JSON-kodiert im Signatur-Payload hinterlegt.
+
+Vor der Signaturanbringung MÃœSSEN alle semantisch unbedeutenden nicht-druckbaren Zeichen (Leerzeichen, Tabs, Line Feed `\n`, Carriage Return '\r') vor und nach den strukturierenden Zeichen (`[`, `{`, `]`, `}`, `:`, `,`) aus dem JSON-Payload entfernt werden.
+
+## Vorgaben für JSON Web Tokens (JWTs)
+Alle generierten JWT-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 |
+| ----- | ------- | ----------- |
+| `alg` | `PS512` | Zur Signaturerstellung wird der Signaturalgorithmus RSASSA-PSS mit SHA-512 und MGF1 mit SHA-512 verwendet. |
diff --git a/versioned_docs/version-0.14/details/destination-management.mdx b/versioned_docs/version-0.14/details/destination-management.mdx
new file mode 100644
index 0000000000000000000000000000000000000000..c283e4240f23e72d614f102287fbbe9608376747
--- /dev/null
+++ b/versioned_docs/version-0.14/details/destination-management.mdx
@@ -0,0 +1,74 @@
+---
+title: Zustellpunktverwaltung
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+import useBaseUrl from '@docusaurus/useBaseUrl';
+import ApiLink from '@site/src/components/ApiLink';
+
+# Zustellpunktverwaltung
+
+## Bearbeiten eines Zustellpunktes
+
+Für die Aktualisierung eines Zustellpunktes existieren aktuell folgende Endpunkte:
+
+* Vollständige Aktualisierung eines Zustellpunktes: <ApiLink to="/destinations/{destinationId}" withMethod="put" />
+* Partielle Aktualisierung eines Zustellpunktes: <ApiLink to="/destinations/{destinationId}" withMethod="patch" />
+
+Für die Aktualisierung der Schlüssel des Zustellpunktes gibt es folgenden Endpunkt:
+
+* <ApiLink to="/destinations/{destinationId}/keys" withMethod="post"/>
+
+Die Details sind der API-Spec zu entnehmen.
+
+### Beispiele
+
+<Tabs
+ defaultValue="curl"
+ values={[
+ {label: 'curl', value: 'curl',},
+ {label: 'Self-Service-Portal', value: 'ssp',},
+ ]}>
+ <TabItem value="curl" label="foo">
+
+#### Aktualisierung des Verschlüsselungsschlüssels eines Zustellpunktes
+
+```shell
+$ SERVICE_URL=...
+$ JWT_TOKEN=...
+$ DESTINATION_ID=...
+
+# Hinzufügen eines Schlüssels zu einer Destination
+$ curl -X POST \
+ -H "Content-Type: application/json" \
+ -H "Authorization: Bearer $JWT_TOKEN" \
+ --data '{"kty": "RSA", "kid": "new-encryption-key", "alg": "RSA-OAEP-256", "key_ops": ["wrapKey"], "x5c": ["..."], "e": "AQAB", "n": "..."}' \
+ "$SERVICE_URL/destinations/$DESTINATION_ID/keys"
+
+# Setzen der Schlüssel-ID als Verschlüsselungsschlüssel
+$ curl -X PATCH \
+ -H "Content-Type: application/json" \
+ -H "Authorization: Bearer $JWT_TOKEN" \
+ --data '{"encryptionKid": "new-encryption-key"}' \
+ "$SERVICE_URL/destinations/$DESTINATION_ID"
+```
+ </TabItem>
+
+ <TabItem value="ssp">
+
+:::caution Hinweis
+Über das Self-Service-Portal können Zustellpunkte aktuell noch nicht aktualisiert werden.
+:::
+ </TabItem>
+</Tabs>
+
+## Zustellpunkt löschen
+
+Das Löschen von Zustellpunkten kann im Self-Service-Portal durchgeführt werden.
+Ein Zustellpunkt kann nur gelöscht werden, wenn kein Client mit diesem verknüpft ist.
+Durch einen Klick auf die `Destination-ID` in der Zustellpunktverwaltung öffnet sich die Detailansicht für den ausgewählten Zustellpunkt.
+
+<div class="center">
+ <img width="600" alt="Detailansicht Zustellpunkt" src={useBaseUrl('/images/ssp/19-Destination-Detailansicht.png')}/>
+</div>
diff --git a/versioned_docs/version-0.14/details/infrastructure-docs/_index.md b/versioned_docs/version-0.14/details/infrastructure-docs/_index.md
new file mode 100644
index 0000000000000000000000000000000000000000..b37561419d60ec37ececb2b4b099c1f16d94f363
--- /dev/null
+++ b/versioned_docs/version-0.14/details/infrastructure-docs/_index.md
@@ -0,0 +1,25 @@
+# Ãœberblick
+
+Treten die Schlüsselwörter "MUSS"/"MÜSSEN", "DARF NICHT"/"DÜRFEN NICHT", "SOLLTE"/"SOLLTEN", "SOLLTE NICHT"/"SOLLTEN
+NICHT" und "KANN"/"KÖNNEN" in Großbuchstaben auf, handelt es sich um Implementierungsvorgaben, die entsprechen den
+Begriffen "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" und "MAY" gemäß [RFC 2119](https://tools.ietf.org/html/rfc2119) zu
+interpretieren sind.
+
+## Regex zur Validierung der OAuth-Scopes
+
+Der folgende reguläre Ausdruck erfasst alle möglichen OAuth-Scopes:
+
+```regex
+^((?:subscribe|manage):destination:[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-4[0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|(send:region:DE[0-9]{0,12})(?:\+(send:service:urn:[a-z0-9][a-z0-9-]{0,31}:[a-z0-9()+,.:=@;$_!*'%/?#-]+))?|create:destination)$
+```
+
+## Validierung der JWT-Tokens beim Zugriff auf den Zustelldienst
+
+Der Zustelldienst bzw. ein vorgelagertes System muss überprüfen, ob der JWT-Token valide ist. Dafür sollten mindestens
+folgende Überprüfungen durchgeführt werden:
+
+1. JWT muss mit **RSASSA-PSS (PS512)** signiert sein.
+2. JWT muss noch gültig sein.
+3. JWT muss maximal für 2h valide ausgestellt sein (`exp - iat <= 2 * 60 * 60`).
+4. JWT muss korrekt signiert sein. Die Prüfung erfolgt mit dem Public Key des Autorisierungsservers.
+5. Zustellberechtigungs-Scopes (`scope`) müssen Zugriff auf die Einreichung / Zustellpunkt erlauben.
diff --git a/versioned_docs/version-0.14/details/infrastructure-docs/scopes-internal.md b/versioned_docs/version-0.14/details/infrastructure-docs/scopes-internal.md
new file mode 100644
index 0000000000000000000000000000000000000000..877d28cd23c3ddad7128039bcf823e58bb96a6c0
--- /dev/null
+++ b/versioned_docs/version-0.14/details/infrastructure-docs/scopes-internal.md
@@ -0,0 +1,7 @@
+# OAuth Berechtigungen für infrastrukturinterne API-Aufrufe
+
+## Scope für die Anlage neuer Destinations durch das Self-Service-Portal
+
+| Typ | Beispielwert | Erläuterung |
+| --- | ------------ | ----------- |
+| Erstellen von Zustellpunkten | `create:destination` | Mit dieser Berechtigung ist das Erstellen von neuen Zustellpunkten bei einem Zustelldienst möglich. Diese Berechtigung wird durch das Self-Service-Portal für die Erstellung von Zustellpunkten genutzt. |
diff --git a/versioned_docs/version-0.14/details/infrastructure-docs/sender.md b/versioned_docs/version-0.14/details/infrastructure-docs/sender.md
new file mode 100644
index 0000000000000000000000000000000000000000..aff123687580117335ce9051817ece687f2090db
--- /dev/null
+++ b/versioned_docs/version-0.14/details/infrastructure-docs/sender.md
@@ -0,0 +1,39 @@
+# Token Validierung bei sendenden Systemen
+
+**Achtung: Die folgende Dokumentation ist für Softwareentwickler:innen und Betreiber der zentralen Übertragungsinfrastruktur gedacht. Diese Unterlagen befinden sich in einer Überarbeitung und spiegeln nicht den aktuellen Stand wieder.**
+
+Die Authentifizierung von sendenden Systemen erfolgt bei FIT-Connect auf Basis von OAuth 2.0 Client Credentials gemäß [RFC 6749](https://tools.ietf.org/html/rfc6749) und Access Tokens auf Basis von JSON Web Tokens gemäß [RFC 7519](https://datatracker.ietf.org/doc/html/rfc7519). Im Folgenden sollen die nötigen Schritte zur Registrierung und zum Zugriff auf die Schnittstelle des FIT-Connect Zustelldienstes (Submission API) beschrieben werden. Dieses Dokument dokumentiert die implementierten Authentifizierungsmechanismen und macht Vorgaben zur Implementierung der Authentifizierung von sendenden Systemen. Bei der Umsetzung der Authentifizierung kann darüber hinaus auf das vom Projekt FIT-Connect bereitgestellte Software Development Kit (SDK) zurückgegriffen werden, dass die Vorgaben aus diesem Dokument umsetzt bzw. bei deren Umsetzung unterstützt.
+
+
+
+## Zugriff auf die API mittels Access Token
+Wenn ein Online-Antragsservice einer Antragsteller:in ermöglichen möchte, eine Einreichung an die FIT-Connect Submission API zu übermitteln, muss dieser zunächst mithilfe der OAuth Client-Credentials beim OAuth-Server einen Berechtigungstoken (im Folgenden "Access Token") nach dem Standard *JSON Web Token* gemäß [RFC 7519](https://tools.ietf.org/html/rfc7519)) abrufen. Dieser vom OAuth-Server signierte Access Token enthält den Public-Key des Online-Antragsdienstes, der bei der Registrierung im Self-Service-Portal festgelegt wurde. Aus Sicht von API-Clients sind die Inhalte des Tokens gemäß OAuth-Spezifikation als bedeutungslos anzusehen und SOLLTEN daher NICHT interpretiert werden. Eine Prüfung des Access Token auf Korrektheit und Gültigkeit erfolgt intern.
+
+### Payload des Access Tokens
+Der hier beschriebene Payload des Access Tokens dient lediglich der Dokumentation/Spezifikation. Im Payload des signierten Access Token werden vom Autorisierungsdienst die folgenden [standardisierten Felder](https://www.iana.org/assignments/jwt/jwt.xhtml) gesetzt:
+
+| Feld | Inhalt | Erläuterung |
+| ---------------- | ------------------------------------- | --------------- |
+| `sub` (Subject) | Client ID des sendenden Systems | Beim gewählten Client Credential Flow wird hier die Client ID des System eingetragen.|
+| `aud` (Audience) | URL der Submission API | Die URL der API des Zustelldienstes, für den der Token ausgestellt wurde, gemäß [RFC 7519, Abschnitt 4.1.3](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3). |
+| `scope` | Zustellberechtigungs-Scopes | Eine Liste der Zustellberechtigungs-Scopes, separiert mit Leerzeichen gemäß [RFC 6749, Abschnitt 3.3](https://datatracker.ietf.org/doc/html/rfc6749#section-3.3). Für sendende System sind [folgende Scopes](/details/authentication/scopes-sender.md) zu nutzen. |
+| `iss` (Issuer) | URL des Autorisierungsservers | Die URL des Autorisierungsservers, der das Token ausgestellt hat. |
+| `exp` | Unix Timestamp | Zeitpunkt, wann der Token abläuft, als Unix Timestamp (Token DARF max. 24 Stunden gültig sein; vgl. [BSI APP.3.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Kompendium_Einzel_PDFs/06_APP_Anwendungen/APP_3_1_Webanwendungen_Edition_2020.pdf?__blob=publicationFile&v=1)) |
+| `iat` | Unix Timestamp | Zeitpunkt, wann der Token vom Autorisierungsdienst ausgestellt wurde, als Unix Timestamp |
+| `jti` (JWT ID) | ID des Tokens | Eindeutige ID des ausgestellten Tokens. |
+| `client_id` | Identisch mit `sub` | |
+
+**Beispiel-Payload eines Access Tokens:**
+
+```json
+{
+ "sub": "lxnsidjbdd6bk",
+ "aud": "https://api.zustelldienst-01.example.com",
+ "scope": "send:region:DE01010 send:region:DE010109990",
+ "iss": "https://auth.fitko.de",
+ "exp": 1627044703,
+ "iat": 1627042903,
+ "jti": "bU9uS7fTLbQ",
+ "client_id": "lxnsidjbdd6bk"
+}
+```
diff --git a/versioned_docs/version-0.14/details/infrastructure-docs/subscriber.md b/versioned_docs/version-0.14/details/infrastructure-docs/subscriber.md
new file mode 100644
index 0000000000000000000000000000000000000000..a95ec2370136880ce00c20ee3d1972ab846b24d3
--- /dev/null
+++ b/versioned_docs/version-0.14/details/infrastructure-docs/subscriber.md
@@ -0,0 +1,89 @@
+# Token Validierung bei empfangenden Systemen
+
+**Achtung: Die folgende Dokumentation ist für Softwareentwickler:innen und Betreiber der zentralen
+Ãœbertragungsinfrastruktur gedacht. Diese Unterlagen befinden sich in einer Ãœberarbeitung und spiegeln nicht den
+aktuellen Stand wieder.**
+
+Die Authentifizierung von empfangenden Systemen erfolgt bei FIT-Connect auf Basis von OAuth 2.0 Client Credentials
+gemäß [RFC 6749](https://tools.ietf.org/html/rfc6749) und Access Tokens auf Basis von JSON Web Tokens
+gemäß [RFC 7519](https://datatracker.ietf.org/doc/html/rfc7519). Zum Abruf von Anträgen müssen sich empfangende Systeme
+mithilfe von OAuth 2.0 Client-Credentials beim Autorisierungsdienst authentifizieren. Die hierfür nötigen Client
+erhalten Behörden und andere Abrufberechtigte, nach einer Anmeldung im Self-Service-Portal der FITKO. (TODO: link)
+
+Zum Abruf von Anträgen müssen sich empfangende Systeme zunächst mithilfe der OAuth Client-Credentials beim OAuth-Server
+ein Berechtigungstoken (im Folgenden "Access Token") nach dem Standard JSON Web Token
+gemäß [RFC 7519](https://tools.ietf.org/html/rfc7519) abrufen. Dieser vom OAuth-Server signierte Token kann anschließend
+genutzt werden, um sich gegenüber der Submission API eines Zustelldienstes zu authentifizieren.
+
+Bei erfolgreicher Registrierung erhält die für den Zustellpunkt verantwortliche Behörde OAuth2-Zugangsdaten für den
+Authentifizierungstyp "Client-Credentials" (`client_id` und `client_secret`). Mit diesen kann sich das empfangende
+System beim Authentifizuerungsdienst authentifizieren und erhält einen Access Token im JSON Web Token-Format (JWT). Mit
+diesem Access Token ist anschließend ein Abruf der im Zustelldienst hinterlegten Anträge möglich.
+
+## Zugriff auf die API mittels Access Token
+
+Das Access Token für empfangende Systeme wird vom Autorisierungsdienst erzeugt und DARF vom empfangenden System NIEMALS
+an dritte Systeme (mit Außnahme des Zustelldienstes zum Zwecke der Authentifizierung) weitergegeben werden. Das Access
+Token für empfangende Systeme wird beim Zugriff auf die Submission API im `Authorization`-Header mit `Bearer`
+-Authentifizierungsschema gemäß [RFC 6750](https://datatracker.ietf.org/doc/html/rfc6750) an den Zustelldienst
+übermittelt:
+
+**Beispiel**
+
+```http
+POST /applications HTTP/1.1
+Host: api.zustelldienst-01.example.com
+Authorization: Bearer ey...
+```
+
+### Header des Access Tokens für empfangende Systeme
+
+Im Header des Access Tokens für empfangende Systeme werden vom Autorisierungsdienst gemäß den Vorgaben
+aus [RFC 7519](https://tools.ietf.org/html/rfc7519) die folgende Header-Attribute gesetzt:
+
+| Feld | Inhalt | Erläuterung |
+| ----- | -------- | --------------- |
+| `typ` | `at+jwt` | Es handelt sich um ein Access Token im JSON Web Token (JWT) Format. |
+| `alg` | `PS512` | Zur Signaturerstellung wird der Signaturalgorithmus RSASSA-PSS mit SHA-512 und MGF1 mit SHA-512 verwendet. |
+| `kid` | String | ID des Schlüssels mit dem das Access Tokens ausgestellt wurde. |
+
+**Beispiel**
+
+```json
+{
+ "kid": "CXup",
+ "typ": "at+jwt",
+ "alg": "PS512"
+}
+```
+
+### Payload des Access Tokens für empfangende Systeme
+
+Im Payload des signierten Access Token MÃœSSEN mindestens die
+folgenden [standardisierten Felder](https://www.iana.org/assignments/jwt/jwt.xhtml) gesetzt sein:
+
+| Feld | Inhalt | Erläuterung |
+| ---------------- | ----------------------------- | --------------- |
+| `sub` (Subject) | ID des empfangenden Systems | Identifiziert ein empfangendes System. Festgelegt im Autorisierungsdienst. |
+| `aud` (Audience) | URL der Submission API | Die URL der API des Zustelldienstes, für den der Token ausgestellt wurde, gemäß [RFC 7519, Abschnitt 4.1.3](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3). |
+| `scope` | Zustellberechtigungs-Scopes | Eine Liste der Zustellberechtigungs-Scopes, separiert mit Leerzeichen gemäß [RFC 6749, Abschnitt 3.3](https://datatracker.ietf.org/doc/html/rfc6749#section-3.3). Für sendende System sind [folgende Scopes](/details/authentication/scopes-subscriber.md) zu nutzen. |
+| `iss` (Issuer) | URL des Autorisierungsservers | URL des Autorisierungsservers der das Access Token ausgestellt hat. |
+| `exp` | Unix Timestamp | Ablaufzeitpunkt des Access Tokens (DARF max. 2 Stunden gültig sein; vgl. [BSI APP.3.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Kompendium_Einzel_PDFs/06_APP_Anwendungen/APP_3_1_Webanwendungen_Edition_2020.pdf?__blob=publicationFile&v=1)) |
+| `iat` | Unix Timestamp | Ausstellungszeitpunkt des Access Tokens. |
+| `jti` (JWT ID) | ID des Tokens | Eindeutige ID des ausgestellten Tokens. |
+| `client_id` | Identisch mit `sub` | |
+
+**Beispiel-Payload eines Access Tokens:**
+
+```json
+{
+ "sub": "epie1quee7eeR",
+ "aud": "https://api.zustelldienst-01.example.com",
+ "scope": "subscribe:destination:36141427-d405-40a4-8f8b-3592d544e85b manage:destination:36141427-d405-40a4-8f8b-3592d544e85b",
+ "iss": "https://auth.fitko.de",
+ "exp": 1627045703,
+ "iat": 1627043903,
+ "jti": "aeveeSa3ohl",
+ "client_id": "epie1quee7eeR"
+}
+```
diff --git a/versioned_docs/version-0.14/details/jwk-creation.md b/versioned_docs/version-0.14/details/jwk-creation.md
new file mode 100644
index 0000000000000000000000000000000000000000..bad3a80b42b70035c589f4b59ec4b20c645febb7
--- /dev/null
+++ b/versioned_docs/version-0.14/details/jwk-creation.md
@@ -0,0 +1,86 @@
+# Erstellen von JSON Web Keys für Testzwecke
+FIT-Connect verwendet zur Übertragung von Antragsdaten und Metadaten mit direktem Bezug zu Anträgen eine Ende-zu-Ende-Verschlüsselung. Diese ist auf Basis des Standards [JSON Web Encryption (JWE)](https://tools.ietf.org/html/rfc7516) unter Verwendung von Schlüsseln gemäß des Standards [JSON Web Keys (JWK)](https://tools.ietf.org/html/rfc7517) umgesetzt.
+Im Folgenden soll die Erstellung von JWKs mithilfe eines einfachen in Python geschriebenen Skriptes unter Windows und Linux erläutert werden.
+
+## Voraussetzungen
+Die Ausführung des Skriptes setzt eine installierte Version von [Python]( https://www.python.org/) voraus. Zum Nachinstallieren von benötigten Paketen wird Paketverwaltungsprogramm **pip** benötigt. Bei Versionen vor 3.4 ist ggf. noch eine manuelle Installation erforderlich.
+
+### Windows
+Eine Anleitung zur Installation und Einrichtung unter Windows finden Sie unter [Installationsanleitung Python Windows]( https://docs.microsoft.com/de-de/windows/python/beginners).
+
+### Linux
+Der Ablauf und die Befehle zur Installation und Einrichtung von Python unter Linux unterscheiden sich je nach verwendeter Distribution.
+
+#### Für Ubuntu
+[Installationsanleitung Python Ubuntu]( https://docs.python-guide.org/starting/install3/linux/)
+
+Installation von **pip**
+```console
+foo@bar:~$ sudo apt install python3-pip
+```
+
+#### Für Debian
+[Installationsanleitung Python Debian]( https://linuxize.com/post/how-to-install-python-3-9-on-debian-10/)
+
+Installation von **pip**
+```console
+foo@bar:~$ sudo apt install python3-pip
+```
+
+#### Für Fedora
+[Installationsanleitung Python Fedora]( https://developer.fedoraproject.org/tech/languages/python/multiple-pythons.html)
+
+```console
+foo@bar:~$ yum -y install python-pip
+```
+
+### Erforderliche Python Pakete installieren
+Um das Skript zur Erstellung von JSON Web Keys auszuführen, werden zusätzliche Python Pakete benötigt. Diese lassen sich jedoch sehr einfach mithilfe von **pip** nach-installieren. Dazu kann unter Windows die **PowerShell** sowie **Terminal** unter Linux verwendet werden.
+
+Windows PowerShell:
+```console
+PS C:\> pip install jwcrypto pyOpenSSL
+```
+
+Linux:
+```console
+foo@bar:~$ pip install jwcrypto pyOpenSSL
+```
+
+macOS:
+```console
+> pip install jwcrypto pyOpenSSL
+```
+
+### Herunterladen des Python-Skrips
+Das Skript zur Erstellung der JSON Web Keys können Sie unter [Python Skript zur JWK-Erstellung](https://git.fitko.de/fit-connect/fit-connect-tools/-/blob/main/set-jwkset-gen.py) herunterladen. Speichern Sie es in einem Verzeichnis, in dem Sie das Skript später wiederfinden.
+
+## Ausführung des Skripts
+Navigieren Sie zum Verzeichnis in dem Sie das Python-Skript hinterlegt haben und öffnen Sie dort unter Windows eine **PowerShell** bzw. unter Linux ein **Terminal**. Alternativ können Sie auch innerhalb der **PowerShell** oder des **Terminals** zum Verzeichnis navigieren.
+Mit dem folgenden Befehl kann das Python-Skript zur Erstellung der JSON Web Keys ausgeführt werden.
+
+Windows PowerShell:
+```console
+PS C:\> python3 set-jwkset-gen.py
+```
+
+Linux:
+```console
+foo@bar:~$ python3 .\set-jwkset-gen.py
+```
+In der Konsole wird dann im Erfolgsfall der Speicherort der Schlüssel ausgegeben
+
+```console
+Wrote JWK representation of encryption public key (key_use=wrapKey) to C:\Users\username\AppData\Local\Temp\tmpx8gi90tq\publicKey_encryption.json
+Wrote JWK representation of signature validation public key (key_use=verify) to C:\Users\username\AppData\Local\Temp\tmpx8gi90tq\publicKey_signature_verification.json
+Please upload these keys when creating a destination in the self service portal.
+
+Wrote JWKS of Public Keys to C:\Users\username\AppData\Local\Temp\tmpx8gi90tq\set-public-keys.json
+This key set can be used to update (rotate) keys via the Submission-API (PUT /destinations/\{destinationID\})
+
+Wrote JWK representation of decryption private key (key_use=unwrapKey) to C:\Users\username\AppData\Local\Temp\tmpx8gi90tq\privateKey_decryption.json
+Wrote JWK representation of signing private key (key_use=sign) to C:\Users\username\AppData\Local\Temp\tmpx8gi90tq\privateKey_signing.json
+These keys can be used to sign and decrypt in your client application.
+
+
+```
diff --git a/versioned_docs/version-0.14/details/pgp-export.md b/versioned_docs/version-0.14/details/pgp-export.md
new file mode 100644
index 0000000000000000000000000000000000000000..98ac50c26fd635ac396cbcbe862042e928747a2b
--- /dev/null
+++ b/versioned_docs/version-0.14/details/pgp-export.md
@@ -0,0 +1,29 @@
+# PGP Export
+
+:::note Hinweis
+Diese Beschreibung bezieht sich auf das Feld `replyChannel.e-mail.pgpPublicKey` im [Metadatenschema](../getting-started/metadata.md#rückkanal-replychannel)
+:::
+
+Der Inhalt des Feldes ist ein durch `gpg --export --armor "$KEY_ID"` erzeugter ASCII-String
+in dem Zeilenumbrüche durch die Escape-Sequenz (`\n`) ersetzt wurden.
+
+Die Kodierung erfolgt wie folgt:
+
+```shell
+$ KEY_ID='EEADEDE070FA9658F0BE084AC20D38DB3EA14B59'
+$ gpg --export --armor "$KEY_ID" | python3 -c 'import sys; print(sys.stdin.read().replace("\n", "\\n"))'
+-----BEGIN PGP PUBLIC KEY BLOCK-----\n\nmQINBEBEADSlS<snip>9jlG\n-----END PGP PUBLIC KEY BLOCK-----\n
+```
+
+Die Dekodierung ist obiger Schritt in Gegenrichtung:
+
+```shell
+$ KEY_ASCII='-----BEGIN PGP PUBLIC KEY BLOCK-----\n\nmQINBEBEADSlS<snip>9jlG\n-----END PGP PUBLIC KEY BLOCK-----\n'
+$ echo "$KEY_ASCII" | python3 -c 'import sys; print(sys.stdin.read().replace("\\n", "\n"))'
+-----BEGIN PGP PUBLIC KEY BLOCK-----
+
+mQINBEBEADSlS<snip>9jlG
+-----END PGP PUBLIC KEY BLOCK-----
+```
+
+Möchte man den eben ausgegebenen Schlüssel auch direkt importieren kann man hinter dem Dekodierungssnippet noch ein `| pgp --import` setzen.
diff --git a/versioned_docs/version-0.14/details/schema-reference.md b/versioned_docs/version-0.14/details/schema-reference.md
new file mode 100644
index 0000000000000000000000000000000000000000..d424f37af5abc438aa43584c57ba69639141c13c
--- /dev/null
+++ b/versioned_docs/version-0.14/details/schema-reference.md
@@ -0,0 +1,71 @@
+# Fachschemarefenzen auf Fachstandards und Rahmenwerke abbilden
+
+Im Folgenden wird aufgezeigt, wie Fachschemarerenzen für Fachdatensätze auf bestehende Fachstandards und Rahmenwerke abgebildet werden. Aktuell
+werden folgende Fachstandards und Rahmenwerke beschrieben:
+- FIM Übertragungsschemata für Anträge auf Basis von FIM Datenfelder
+- XÖV Nachrichten auf Basis von XÖV-konformen Fachstandards
+
+Soll ein anderer Fachstandard mit der FIT-Conect Submission API übermittelt werden, können wir gerne die Beschreibung dieser Schemareferenz hier aufnehmen,
+um diese Informationen einem breiteren Nutzerkreis zugänglich zu machen. Hierzu bitte einfach Issue [hier](https://git.fitko.de/fit-connect/docs) aufmachen
+und gerne schon einen konkreten Vorschlag zuliefern.
+
+## Aufbau Fachschemareferenz
+
+Eine Fachschemareferenz besteht aus zwei Angaben.
+- Die `schemaURI` referenziert das zu verwendende Fachschema.
+- Der `mimeType` gibt den Datentyp (JSON oder XML) der Fachdaten vor.
+
+Bitte beachten Sie, dass manche Fachschema nur JSON oder XML als Datentyp zulassen.
+
+## FIM Fachschemareferenz
+
+Um ein FIM Fachschema eindeutig zu referenzieren sind folgende Angaben notwendig:
+
+- **ID** des Stammdatenschemas mit kleinem "S" ("s00000000009" im Beispiel)
+- **Version** des Stammdatenschemas ("1.0.0" im Beispiel)
+- **Art** des Schemas (JSON oder XML Schema)
+
+Für ein JSON Schema wird die schemaURI wird wie folgt gebildet:
+`https://schema.fitko.de/fim/{ID}_{Version}.schema.json`
+
+Für ein XML Schema wird die schemaURI wird wie folgt gebildet:
+`https://schema.fitko.de/fim/{ID}_{Version}.xsd`
+
+### Beispiel für eine FIM Fachschemareferenz
+
+JSON Schema:
+```json
+ {
+ "schemaURI": "https://schema.fitko.de/fim/s00000000009_1.0.0.schema.json",
+ "mimeType": "application/json"
+ }
+```
+
+XML Schema:
+```json
+ {
+ "schemaURI": "https://schema.fitko.de/fim/s00000000009_1.0.0.xsd",
+ "mimeType": "application/xml"
+ }
+```
+
+## XÖV Fachschemareferenz
+
+Ein XÖV Fachschema wird über folgende Angaben referenziert:
+- **Kennung** (ID) des Fachschemas ("urn:xoev-de:bmk:standard:xbau" im Beispiel)
+- **Version** des Fachschemas ("2.2" im Beispiel)
+- Verwendete **Nachricht** aus dem Fachschema ("baugenehmigung.antrag.0200" im Beispiel)
+
+Beispiel: `urn:xoev-de:bmk:standard:xbau_2.2#baugenehmigung.antrag.0200`
+
+Die schemaURI wird wie folgt gebildet:
+`{Kennung}_{Version}#{Nachricht}`
+
+### Beispiel für eine XÖV Fachschemareferenz
+
+```json
+ {
+ "schemaURI": "urn:xoev-de:bmk:standard:xbau_2.2#baugenehmigung.antrag.0200",
+ "mimeType": "application/xml"
+ }
+```
diff --git a/versioned_docs/version-0.14/getting-started/authentication.mdx b/versioned_docs/version-0.14/getting-started/authentication.mdx
new file mode 100644
index 0000000000000000000000000000000000000000..31ad91de07a239928eb193e6ecd21c947f31fb0e
--- /dev/null
+++ b/versioned_docs/version-0.14/getting-started/authentication.mdx
@@ -0,0 +1,117 @@
+# Authentifizierung
+
+import Tabs from '@theme/Tabs'
+import TabItem from '@theme/TabItem'
+
+Nachfolgend wird der Abruf von Access Tokens beim OAuth-Dienst sowie der Zugriff auf die FIT-Connect Submission API mittels Access Tokens beschrieben.
+
+:::note Hinweis
+Als Voraussetzungen hierfür ist es notwendig, Accounts für [API-Clients im Self-Service-Portal zu registrieren](../account.mdx).
+:::
+
+## Abruf von Access Tokens beim OAuth-Dienst
+
+Fast alle Anfragen an die FIT-Connect Submission API müssen authentifiziert werden.
+Hierfür ist ein Access Token notwendig, das beim OAuth-Dienst über die hierfür vorgesehene `Token URL` abgerufen werden kann (siehe Abschnitt `AUTHENTICATION` in der [Schnittstellenspezifikation](../apis/submission-api)).
+Für den Abruf von Access Tokens ist die [Konfiguration eines API-Client im Self-Service-Portal](../account.mdx) nötig.
+
+Das Token kann anschließend bei Anfragen über den `Authorization` Header mitgeschickt werden.
+Da ein Token **max. 30 Minuten** gültig ist, muss dieses rechtzeitig erneuert werden.
+Wenn keine spezifischer Scope angefragt wird (siehe nächster Abschnitt), enthält der Access Token alle Scopes, die zu diesem Zeitpunkt beim Client im Self-Service-Portal hinterlegt wurden.
+
+<Tabs
+ defaultValue="curl"
+ values={[
+ { label: 'curl', value: 'curl', },
+ { label: 'Java (Spring)', value: 'java', },
+ { label: 'C#', value: 'csharp', },
+ { label: 'JavaScript', value: 'js', },
+ ]
+}>
+<TabItem value="java">
+
+```java
+// TBD
+```
+
+</TabItem>
+
+<TabItem value="csharp">
+
+```csharp
+// TBD
+```
+
+</TabItem>
+
+<TabItem value="js">
+
+```js
+// TBD
+```
+
+</TabItem>
+
+<TabItem value="curl">
+
+```bash
+$ export OAUTH_URL=<URL>
+$ export CLIENT_ID=<client_id>
+$ export CLIENT_SECRET=<client_secret>
+$ curl \
+ -H "Content-Type: application/x-www-form-urlencoded" \
+ --data "grant_type=client_credentials&client_id=$CLIENT_ID&client_secret=$CLIENT_SECRET" \
+ -X POST $OAUTH_URL
+{
+ "access_token": "eyJraWQi...",
+ "expires_in": 1800,
+ "scope": "send:region:DE01010",
+ "token_type": "Bearer"
+}
+```
+
+</TabItem>
+</Tabs>
+
+### Abfrage von Access Tokens mit spezifischen Scopes
+
+Es ist möglich den Scope des Access Tokens zu beschränken.
+Hier im Beispiel hat der angelegte OAuth Client weitreichende Berechtigungen: `send:region:DE`.
+Wir beschränken allerdings diesen konkreten Access Token auf `send:region:DE01010`.
+
+```bash
+$ export OAUTH_URL=<URL>
+$ export CLIENT_ID=<client_id>
+$ export CLIENT_SECRET=<client_secret>
+$ curl \
+ -H "Content-Type: application/x-www-form-urlencoded" \
+ --data "grant_type=client_credentials&client_id=$CLIENT_ID&client_secret=$CLIENT_SECRET&scope=send:region:DE01010" \
+ -X POST $OAUTH_URL
+{
+ "access_token": "eyJraWQi...",
+ "expires_in": 1800,
+ "scope": "send:region:DE01010",
+ "token_type": "Bearer"
+}
+```
+
+Wie in der Anfrage zu erkennen ist, wurde der Token entsprechend beschränkt.
+Dies funktioniert nur wenn der angefragte `scope` innerhalb der Berechtigungen des API-Clients liegen.
+
+Weiterführende Details zu den Scopes finden sich hier:
+
+* [Scopes für empfangende Systeme](../details/authentication/scopes-subscriber.md)
+* [Scopes für sendende Systeme](../details/authentication/scopes-sender.md)
+
+## Zugriff auf die API mittels Access Token
+
+Access Tokens werden vom OAuth-Dienst erzeugt und DÜRFEN NIEMALS an dritte Systeme (mit Außnahme des Zustelldienstes zum Zwecke der Authentifizierung) weitergegeben werden.
+Beim Zugriff auf die Submission API wird muss ein Access Token im `Authorization`-Header mit `Bearer`-Authentifizierungsschema gemäß [RFC 6750](https://datatracker.ietf.org/doc/html/rfc6750) an den Zustelldienst übermittelt werden:
+
+**Beispiel**
+
+```http
+POST /applications HTTP/1.1
+Host: api.zustelldienst-01.example.com
+Authorization: Bearer ey...
+```
diff --git a/versioned_docs/version-0.14/getting-started/encryption.mdx b/versioned_docs/version-0.14/getting-started/encryption.mdx
new file mode 100644
index 0000000000000000000000000000000000000000..dcea24602723e026e04d0143f36cac9a88d3f3de
--- /dev/null
+++ b/versioned_docs/version-0.14/getting-started/encryption.mdx
@@ -0,0 +1,28 @@
+# Verschlüsselte Übertragung
+
+import useBaseUrl from '@docusaurus/useBaseUrl';
+
+FIT-Connect verwendet zur Übertragung von Antragsdaten und Antragsmetadaten, abgesehen von den für die Übermittlung zwingend notwendigen Daten, eine Ende-zu-Ende-Verschlüsselung.
+Diese ist auf Basis der Standards [JSON Web Encryption (JWE)](https://tools.ietf.org/html/rfc7516) und [JSON Web Keys (JWK)](https://tools.ietf.org/html/rfc7517) umgesetzt. Bei der Implementierung der Ende-zu-Ende-Verschlüsselung MÜSSEN die [Vorgaben für kryptographische Verfahren](details/crypto.md) beachtet werden.
+
+## Warum ist Ende-zu-Ende-Verschlüsselung wichtig?
+Im Kontext von Anträgen an Behörden werden häufig höchstsensible Daten übermittelt, die im Rahmen von [Vorgaben des BSI](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03107/TR-03107-1.pdf?__blob=publicationFile&v=4) nur Ende-zu-Ende-verschlüsselt übertragen werden dürfen.
+Zielsetzung von FIT-Connect ist ein möglichst einfaches, sicheres und klar definiertes Vorgehen zur Einreichung von Antragsdaten zu etablieren. Deshalb ist die verschlüsselte Übertragung von Antragsdaten ein integraler Bestandteil von FIT-Connect. Eine Übertragung von Antragsdaten erfolgt mit FIT-Connect ausschließlich verschlüsselt.
+
+## Grundlagen zur sicheren Implementierung von FIT-Connect
+### Ende-zu-Ende-Verschlüsselung
+FIT-Connect verfolgt den Ansatz einer Ende-zu-Ende-Verschlüsselung. Das bedeutet, dass Daten immer vom Endgerät der Nutzer:in bis in die Zielbehörde bzw. das Fachverfahren asymmetrisch verschlüsselt sind.
+
+<img src={useBaseUrl('/images/encryption/tls-no-tls.png')} alt="Grafik zur Veranschaulichung einer Ende-zu-Ende-Verschlüsselung" width="600" />
+
+Zur Realisierung einer Ende-zu-Ende-Verschlüsselung vom Endgerät der Anwender:in bis zum Fachverfahren einer Behörde, dürfen Daten nicht unverschlüsselt oder nur per TLS gesichert an ein Backend übermittelt und erst dort die für FIT-Connect spezifizierte Verschlüsselung angewendet werden. Sollte eine längerfristige Speicherung der Antragsdaten nötig sein, so muss diese immer clientseitig (z.B. in der IndexDB des Browsers, per Download, …) erfolgen.
+
+### Zertifikate von Zustellpunkten müssen der Verwaltungs-PKI entstammen
+Jeder verwendete Public Key (idR. in Form eines JSON Web Keys) muss einem digitalen Zertifikat entstammen und von einer Zertifizierungsstelle innerhalb der Verwaltungs-PKI signiert werden. JSON Web Keys müssen immer mit der komplette Zertifikatskette bis zum Wurzelzertifikat ausgeliefert werden, um clientseitig korrekt validierbar zu sein.
+
+### Kryptografisches Material muss vor der Verwendung immer geprüft werden
+Die für die Verschlüsselung verwendeten JSON Web Keys müssen vor Verwendung anhand des zugehörigen Zertifikats aus der Verwaltungs-PKI auf Gültigkeit überprüft werden.
+
+<img src={useBaseUrl('/images/encryption/pki-check.png')} alt="Grafik zur Veranschaulichung der Einbindung einer PKI zur Verhinderung von Man-in-the-Middle-Angriffen" width="600" />
+
+Nicht vertrauenswürdige Schlüssel dürfen nicht für die Verschlüsselung von Anträgen verwendet werden. Das soll Angriffe wie Man-in-the-middle-Attacken verhindern.
diff --git a/versioned_docs/version-0.14/getting-started/event-log.mdx b/versioned_docs/version-0.14/getting-started/event-log.mdx
new file mode 100644
index 0000000000000000000000000000000000000000..c12348ea2c51674974e73db1620cc9acba0eb97d
--- /dev/null
+++ b/versioned_docs/version-0.14/getting-started/event-log.mdx
@@ -0,0 +1,302 @@
+---
+title: Event Log
+---
+
+import ApiLink from '@site/src/components/ApiLink'
+
+Im Ereignisprotokoll (Event Log) werden relevante Ereignisse (events) aufgezeichnet.
+Beim Abruf des Ereignisprotokolls liefert die API ein Array von JSON Web Token (JWT) gemäß [RFC 7519](https://datatracker.ietf.org/doc/html/rfc7519).
+Der JWT ist einen Security-Event-Token (SET) gemäß [RFC 8417](https://datatracker.ietf.org/doc/html/rfc8417).
+Wie mit den Security-Event-Token (SET) umgegangen wird, wird in diesem Abschnitt beschrieben.
+
+## Hintergrund
+
+Für die Übermittlung von Einreichungen zwischen Sendern und Empfängern soll gewährleistet werden, dass alle Schritte nachweissicher dokumentiert werden, um im Streitfall den Ablauf eines erfolgten Übermittlungsvorgang zweifelsfrei zu dokumentieren.
+Zudem sollen diese Nachweise außerhalb der Submission API und der damit verbundenen Systeme genutzt werden können, damit diese Dritten einfach zur Verfügung gestellt werden können.
+SETs erfüllen diese Anforderungen durch folgende Merkmale:
+
+- Für jedes SET wird ein eindeutiger Herausgeber definiert (`iss`)
+- Jedes SET kann eindeutig einem konkreten fachlichen Kontext zugeordnet werden (`sub`)
+ - Mehrere SETs aus unterschiedliche fachlichen Kontexten können zu einem gemeinsamen Vorgang zusammengeführt werden (`txn`)
+- SETs können für unterschiedliche Ereignisse ausgeprägt werden und innerhalb dieser Ereignisse können Detailinformationen ergänzt werden, die diese Ereignisse näher beschreiben
+ - Über ein Zeitstempel (`iat`) können diese Ereignisse zudem konkreten Zeitpunkt zugeordnet werden
+- Durch eine Signatur im JWS Format wird sichergestellt, dass alle SETs ihre Integrität erhalten und eindeutig dem Schlüsselinhaber als Ersteller zugeordnet werden können.
+
+Die Nutzung ist aber nicht auf die Klärung von Streitigkeiten zu technischen Übermittlungen beschränkt. SETs können aufgrund dieser Merkmale unter anderem auch für folgende Zwecke genutzt werden:
+- Als Auditinstrument, dass bei Prüfungen oder Sicherheitsvorfällen durch Dritte (bspw. Datenschutz- oder Sicherheitsbeauftragte) genutzt wird,
+- oder als Nachweis für den Start von Fristen in Verwaltungsverfahren, die in der Regel dann beginnen, wenn eine zuständige Stelle Kenntnis von einer Einreichung hat oder wenn diese Einreichung in den Hoheitsbereich der empfangenden Stelle gelangt.
+
+In der Submission API werden SETs durch den Zustelldienst und das empfangende System erstellt.
+Während die SETs des Zustelldienstes dazu dienen, die korrekte Übermittlung an den Zustelldienst und die Inkenntnissetzung von empfangende Systemen über neue Einreichungen dokumentieren, sollen SETs des empfangenden Systems die Bestätigung oder Ablehnung der technische Verarbeitbarkeit einer Einreichung nachweisen.
+
+## Events
+
+Das folgende Statusdiagramm zeigt die Status und Ereignisse einer Einreichung. Die Status sind als orange Ovale dargestellt.
+Rechtecke stehen für Ereignisse. Blau dargestellte Ereignisse werden vom Zustelldienst, grüne vom empfangenden System erstellt und signiert.
+
+
+
+Das Akzeptieren oder Zurückweisen von Einreichungen auf einer rein technischen Ebene und trifft keine Aussage über die fachliche Korrektheit der Einreichungen.
+Gründe für technische Rückweisungen wären beispielsweise Probleme bei der Entschlüsselung oder Validierungsfehler der Datenstrukturen.
+In der folgenden Tabelle sind die möglichen Ereignisse, ihre Beschreibungen und die Autoren aufgeführt und beschrieben.
+
+| Event | Autor | Bedeutung |
+|-----------------------------------------------------------------|---------------------|-------------------------------|
+| `https://schema.fitko.de/fit-connect/events/create-submission` | Zustelldienst | Die Einreichung wurde durch den Sender angelegt. |
+| `https://schema.fitko.de/fit-connect/events/submit-submission` | Zustelldienst | Die Einreichung wurde durch den Sender abgesendet. |
+| `https://schema.fitko.de/fit-connect/events/notify-submission` | Zustelldienst | Der Empfänger wurde per Webhook über die Einreichung informiert. |
+| `https://schema.fitko.de/fit-connect/events/forward-submission` | Empfangendes System | Ein nachgelagertes System hat die Einreichung zur Weiterleitung übernommen. |
+| `https://schema.fitko.de/fit-connect/events/reject-submission` | Empfangendes System | Die Einreichung wurde durch den Empfänger zurückgewiesen. |
+| `https://schema.fitko.de/fit-connect/events/accept-submission` | Empfangendes System | Die Einreichung wurde durch den Empfänger akzeptiert. |
+| `https://schema.fitko.de/fit-connect/events/delete-submission` | Zustelldienst | Die Einreichung wurde durch den Zustelldienst gelöscht. |
+
+## Prüfung eines Security-Event-Token (SET) {#set-validation}
+
+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.
+
+### 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 |
+|--------|------------------------------------------------|---------------------------------------------------------------|
+| `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. |
+| `jti` | UUID des Token | Die JWT ID ist eine eindeutige ID des SET bzw. JWT. Es wird eine zufällige UUID verwendet. |
+| `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. |
+| `events` | JSON-Objekt der Events in diesem Event-Token | Das Objekt "events" beschreibt eine oder mehrere Ereignisse 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. |
+| `txn` | URI, die den Vorgang identifiziert | Als "Transaction Identifier" wird die Vorgangsreferenz `caseId` angegeben. |
+
+:::note SET Beispiel
+
+```json title="SET Header"
+{
+ "typ": "secevent+jwt",
+ "alg": "PS512",
+ "kid": "dd0409e5-410e-4d98-85b6-f81a40b8d980",
+}
+```
+
+```json title="SET Payload"
+{
+ "iss": "https://api.fitko.de/fit-connect/",
+ "iat": 1622796532,
+ "jti": "0BF6DBF6-CE7E-44A3-889F-82FE74C3E715",
+ "sub": "submission:F65FEAB2-4883-4DFF-85FB-169448545D9F",
+ "events": {
+ "https://schema.fitko.de/fit-connect/events/accept-submission": {}
+ },
+ "txn": "case:F73D30C6-8894-4444-8687-00AE756FEA90"
+}
+```
+
+:::
+
+Im folgenden Beispiel kann die allgemeine Struktur eines SET über folgenden Code validiert werden.
+
+```java
+SignedJWT securityEventToken = SignedJWT.parse(eventToken);
+JWTClaimsSet payload = securityEventToken.getJWTClaimsSet();
+UUID keyId = UUID.fromString(securityEventToken.getHeader().getKeyID());
+
+validateTokenStructure(securityEventToken);
+
+verifyZustelldienstSignature(securityEventToken, keyId)
+// bzw.
+verifyClientSignature(securityEventToken, keyId);
+```
+
+```java
+boolean validateTokenStructure(SignedJWT securityEventToken) {
+ try {
+ validateHeader(signedJWT.getHeader());
+ validatePayload(signedJWT.getJWTClaimsSet());
+ } catch (ParseException e) {
+ throw new RuntimeException("The payload of the SET could not get parsed properly.");
+ }
+}
+
+private void validateHeader(JWSHeader header) {
+ validateTrueOrElseThrow(header.getAlgorithm() == JWSAlgorithm.PS512, "The provided alg in the SET header is not allowed.");
+ validateTrueOrElseThrow(header.getType().toString().equals("secevent+jwt"), "The provided typ in the SET header is not secevent+jwt");
+ validateTrueOrElseThrow(header.getKeyID() != null, "The kid the SET was signed with is not set.");
+}
+
+private void validatePayload(JWTClaimsSet payload) throws ParseException {
+ validateTrueOrElseThrow(payload.getClaim("iss") != null, "The claim iss is missing in the payload of th SET.");
+ validateTrueOrElseThrow(payload.getClaim("iat") != null, "The claim iat is missing in the payload of th SET.");
+ validateTrueOrElseThrow(payload.getClaim("jti") != null, "The claim jti is missing in the payload of th SET.");
+ validateTrueOrElseThrow(payload.getClaim("sub") != null, "The claim sub is missing in the payload of th SET.");
+ validateTrueOrElseThrow(payload.getClaim("txn") != null, "The claim txn is missing in the payload of the SET.");
+ validateTrueOrElseThrow(payload.getClaim("events") != null, "The claim events is missing in the payload of the SET.");
+ validateTrueOrElseThrow(payload.getJSONObjectClaim("events").keySet().size() == 1, "Only exactly one event is allowed.");
+
+ String uuidPattern = "[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-4[0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}";
+
+ String subject = payload.getStringClaim("sub");
+ validateTrueOrElseThrow(subject.matches("(submission|case|reply):" + uuidPattern), "The provided subject does not match the allowed pattern.");
+
+ String transactionId = payload.getStringClaim("txn");
+ validateTrueOrElseThrow(transactionId.matches("case:" + uuidPattern), "The provided txn does not match the allowed pattern.");
+}
+
+private void validateTrueOrElseThrow(boolean expression, String msg) {
+ if (!expression) {
+ throw new RuntimeException(msg);
+ }
+}
+```
+
+### Signaturprüfung eines vom Zustelldienst ausgestellten SET
+
+Um die Signatur eines SET zu überprüfen, welches vom Zustelldienst ausgestellt wurde, ist es notwendig auf die verwendeten Schlüssel zugreifen zu können.
+Der Zustelldienst stellt ein JSON Web Key Set (JWKS) öffentlich zugänglich über den Endpunkt <ApiLink to="/.well-known/jwks.json" /> bereit.
+Ein Beispiel für ein JWKS ist in folgendem Ausschnitt dargestellt:
+
+```json
+{
+ "keys": [
+ {
+ "alg": "PS512",
+ "e": "AQAB",
+ "key_ops": [
+ "verify"
+ ],
+ "kid": "6508dbcd-ab3b-4edb-a42b-37bc69f38fed",
+ "kty": "RSA",
+ "n": "65rmDz943SDKYWt8KhmaU…ga16_y9bAdoQJZRpcRr3_v9Q"
+ },
+ {
+ "alg": "PS512",
+ "e": "AQAB",
+ "key_ops": [
+ "verify"
+ ],
+ "kid": "14a70431-01e6-4d67-867d-d678a3686f4b",
+ "kty": "RSA",
+ "n": "wnqKgmQHSqJhvCfdUWWyi8q…yVv3TrQVvGtsjrJVjvJR-s_D7rWoBcJVM"
+ }
+ ]
+}
+```
+
+Mit diesem JWK Set kann die Signatur eines Security-Event-Tokens überprüft werden.
+Hierfür muss der Schlüssel mit der passenden `kid` aus dem Header des SET’s im JWK Set gesucht werden.
+Dann kann man mit diesem und einer entsprechenden Bibliothek eine Signaturprüfung durchführen.
+Im folgenden Beispiel wird die Bibliothek [nimbus-jose-jwt](https://connect2id.com/products/nimbus-jose-jwt) für die Prüfung genutzt.
+
+```java
+static final ZUSTELLDIENST_BASE_URL = "https://zustelldienst.example.com";
+
+boolean verifyZustelldienstSignature(SignedJWT securityEventToken, String keyId) {
+ JWKSet jwks = JWKSet.load(ZUSTELLDIENST_BASE_URL + "/.well-known/jwks.json");
+ JWK publicKey = jwks.getKeyByKeyId(keyId)
+
+ if (publicKey.getAlgorithm() != JWSAlgorithm.PS512) {
+ throw new RuntimeException("The key specified for signature verification doesn't use/specify PS512 as algorithm.")
+ }
+
+ JWSVerifier jwsVerifier = new RSASSAVerifier(publicKey.toRSAKey());
+ return signedJWT.verify(jwsVerifier);
+}
+```
+
+### Signaturprüfung eines vom empfangenden System ausgestellten SET
+
+Um die Signatur eines von einem empfangenden System ausgestellen SET zu überprüfen ist es notwendig, auf den verwendeten Schlüssel zugreifen zu können.
+Der bzw. die Schlüssel sind öffentlich verfügbar und können über die Submission API abgerufen werden.
+
+#### Ausgangslage: Das SET
+Als Ausgangslage dient das folgende SET.
+Aus dem Header wird die Schlüssel-ID aus dem Feld `kid` benötigt.
+Aus dem Payload benötigen wir das Feld `submissionId`.
+Konkret sind das hier:
+
+- kid: `dd0409e5-410e-4d98-85b6-f81a40b8d980`
+- submissionId: `F65FEAB2-4883-4DFF-85FB-169448545D9F`
+
+```json title="SET Header"
+{
+ "typ": "secevent+jwt",
+ "alg": "PS512",
+ "kid": "dd0409e5-410e-4d98-85b6-f81a40b8d980",
+}
+```
+
+```json title="SET Payload"
+{
+ "iss": "https://api.fitko.de/fit-connect/",
+ "iat": 1622796532,
+ "jti": "0BF6DBF6-CE7E-44A3-889F-82FE74C3E715",
+ "sub": "submission:F65FEAB2-4883-4DFF-85FB-169448545D9F",
+ "events": {
+ "https://schema.fitko.de/fit-connect/events/accept-submission": {}
+ },
+ "txn": "case:F73D30C6-8894-4444-8687-00AE756FEA90"
+}
+```
+
+#### Abruf des JWK zur Gültigkeitsprüfung des SET
+
+Mit der `submissionId` kann über den Endpunkt <ApiLink to="/submissions/{submissionId}" /> die zugehörige `destinationId` ermittelt werden.
+Hier ist das konkret der Wert `92f2f581-c89d-44a5-b834-1fe3f6fa48d5`.
+
+```http title="Abfrage der destinationId einer Submission"
+GET /submissions/F65FEAB2-4883-4DFF-85FB-169448545D9F
+{
+ "destinationId": "92f2f581-c89d-44a5-b834-1fe3f6fa48d5",
+ // ...
+}
+```
+
+Mit den zwei Informationen `kid` und `destinationid` kann nun der JWK zur Signaturprüfung abgerufen werden:
+
+```shell title="Beispiel: Abruf des JWK eines Zustellpunktes"
+$ KID=...
+$ SERVICE_URL=...
+$ DESTINATION_ID=...
+$ curl -X GET \
+ "$SERVICE_URL/destinations/$DESTINATION_ID/keys/$KID"
+---
+{
+ "kty": "RSA",
+ "e": "AQAB",
+ "keyops": ["verify"],
+ "x5c": [
+ "LS0tLS1CRUdJTiBDRVJU...jN1NGKzQKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo="
+ ],
+ "x5t": "MTg6NTU6RUY6ME...MEM6QzM6ODQ6QjA6MkE6RkMK",
+ "kid": "787f3a1c-7da7-44d7-9b79-9783b1ea9be8",
+ "alg": "RSA-OAEP-256",
+ "n": "sX2DX7rG5BoJd23...FlxHZt8T6ZqjRa1QcFnkq3_M4-tk"
+}
+```
+
+#### Validierung des SET mit Hilfe des JWK
+
+Die Verifikation des SET mit dem eben abgerufenen JWK ist dann ziemlich geradlinig.
+Es wird zunächst geprüft ob der Schlüssel den passenden Algorithmus hat. Anschließend wird die eigentliche Verifikation durch die Bibliothek durchgeführt.
+
+```java
+boolean verifyClientSignature(SignedJWT securityEventToken, String keyId) {
+ JWK publicKey = getKeyForSET(securityEventToken, keyId);
+
+ if (publicKey.getAlgorithm() != JWSAlgorithm.PS512) {
+ throw new RuntimeException("The key specified for signature verification doesn't use/specify PS512 as algorithm.")
+ }
+
+ JWSVerifier jwsVerifier = new RSASSAVerifier(publicKey.toRSAKey());
+ return signedJWT.verify(jwsVerifier);
+}
+```
+
diff --git a/versioned_docs/version-0.14/getting-started/metadata.md b/versioned_docs/version-0.14/getting-started/metadata.md
new file mode 100644
index 0000000000000000000000000000000000000000..a14fd20dee86c69e07b28e6570ef9f01d3896899
--- /dev/null
+++ b/versioned_docs/version-0.14/getting-started/metadata.md
@@ -0,0 +1,262 @@
+# Metadatensatz
+
+Metadaten sind ein zentraler Bestandteil einer Einreichung. Sie beschreiben die Struktur der Einreichung und deren
+Inhalte, wie beispielsweise Anlagen oder die Fachdaten. Zusätzlich können weitere Informationen über d:ie Verwaltungskund:in
+hinterlegt werden. Eine genaue Definition ist in der [Schema-Definition](../apis/metadata.mdx)
+zu finden. Im Folgenden werden nun die großen Bereiche, die im Metadatenschema aufgeführt werden, grob beschrieben.
+
+:::note Beispiele
+Ein Beispiel für den Metadatensatz eines Kindergeldantrags findet sich in der [Dokumentation für sendende Systeme](./sending/metadata.mdx)
+:::
+
+Das Metadaten-Schema validiert gegen und orientiert sich an der [JSON Schema Spezifikation 2020-12](https://json-schema.org/specification-links.html#2020-12)
+in der Version von 2020. Es besteht primär aus den fünf Bereichen Authentifizierungsinformationen, Inhaltsstruktur,
+Bezahlinformationen, Verwaltungsleistung und Rückkanal.
+
+```json
+{
+ "authenticationInformation": [
+ …
+ ],
+ "paymentInformation": {
+ …
+ },
+ "publicServiceType": {
+ …
+ },
+ "contentStructure": {
+ …
+ },
+ "replyChannel": {
+ …
+ }
+}
+```
+
+## Authentifizierungsinformationen (`authenticationInformation`)
+
+In den Authentifizierungsinformationen wird eine Liste aller Identifikationsnachweise hinterlegt, die für die
+Einreichung notwendig sind. Die Identifikationsnachweise können dabei unterschiedliche Typen innehaben, wie
+beispielsweise ein `IdentficationReport` durch eID oder eine Bestätigung durch Elster.
+
+```json
+{
+ "authenticationInformation": [
+ {
+ "type": "identificationReport",
+ "content": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXBvcnRJRCI6ImJlNGY5ODA2LTBiNWYtNDVjMy1hMDA4LTk2ZmQyNzUwZjhjYiIsInNlcnZlcklkZW50aXR5IjoiaHR0cHM6Ly90ZXN0LmdvdmVybmlrdXMtZWlkLmRlL2dvdl9hdXRlbnQvYXN5bmMiLCJyZXBvcnRUaW1lIjoiMjAyMC0wNi0yNVQxMDoyMDozOSswMjowMCIsImlkZW50aWZpY2F0aW9uRGF0ZSI6IjIwMjAtMDYtMjVUMTA6MTk6NTQrMDI6MDAiLCJpZFN0YXR1cyI6InN1Y2Nlc3MiLCJzdWJqZWN0UmVmIjp7ImZpcnN0TmFtZSI6IkpvaG4iLCJsYXN0TmFtZSI6IkRvZSJ9LCJjb250ZXh0SW5mb3JtYXRpb24iOlsiQW50cmFnIGF1ZiBLaW5kZXJnZWxkOiAwODE1Lzc2Mzc2MyJdLCJpZFN0YXRlbWVudCI6InN1Y2Nlc3NmdWwgaWRlbnRpZmljYXRpb24gc2VudCBieSBTQU1MLUFzc2VydGlvbiIsImRvY3VtZW50UmVmZXJlbmNlcyI6W3siZG9jdW1lbnROYW1lIjoidGVzdC5wZGYiLCJoYXNoQWxnbyI6IlNIQS0yNTYiLCJkaWdlc3QiOiIwYzI3MjA2MzFiOTI3ZTI1ZDVjYjhiNWNhMmI5NDA4YzU1MmVhNzY3OTdlMzQxOTI0NTkzMTI5NjczMmZkMGQyIn1dLCJsb2FTZW50IjoiaHR0cDovL2VpZGFzLmV1cm9wYS5ldS9Mb0EvbG93In0.t4meB51GeSPSSlQ_tvamSE9FmMD5O9HBJw0oo6iTaSjEsq4rLJ27uqcEp9l4VBleH5JW7p-Tu0qf0DuySdznTxj7iSbl43h0geLMzy2NgwMlBhu4U1-sorlqAsxRjIFDvY2z-RD1D1kqqVTtf2FJWQ5tOJ70hHEiZOtVYNjKdn_tZe2nD54KbzujIg4jW36P17wivZ6vCjagk6VjJk4LWhCO-T5L13RXR5jgq14TMCu5DFhdPA8b7v4iShD5j12Z3WBCqRCb2UWCoLtHs7nPDQ8facxymFMDGm8RQineU18OtgTClkmq4JyifNRWN6jYlPMmvQN499wfkf7VlJ8_OQ"
+ },
+ {
+ "type": "identificationReport",
+ "content": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXBvcnRJRCI6ImJlNGY5ODA2LTBiNWYtNDVjMy1hMDA4LTk2ZmQyNzUwZjhjYiIsInNlcnZlcklkZW50aXR5IjoiaHR0cHM6Ly90ZXN0LmdvdmVybmlrdXMtZWlkLmRlL2dvdl9hdXRlbnQvYXN5bmMiLCJyZXBvcnRUaW1lIjoiMjAyMC0wNi0yNVQxMDoyMDozOSswMjowMCIsImlkZW50aWZpY2F0aW9uRGF0ZSI6IjIwMjAtMDYtMjVUMTA6MTk6NTQrMDI6MDAiLCJpZFN0YXR1cyI6InN1Y2Nlc3MiLCJzdWJqZWN0UmVmIjp7ImZpcnN0TmFtZSI6IkpvaG4iLCJsYXN0TmFtZSI6IkRvZSJ9LCJjb250ZXh0SW5mb3JtYXRpb24iOlsiQW50cmFnIGF1ZiBLaW5kZXJnZWxkOiAwODE1Lzc2Mzc2MyJdLCJpZFN0YXRlbWVudCI6InN1Y2Nlc3NmdWwgaWRlbnRpZmljYXRpb24gc2VudCBieSBTQU1MLUFzc2VydGlvbiIsImRvY3VtZW50UmVmZXJlbmNlcyI6W3siZG9jdW1lbnROYW1lIjoidGVzdC5wZGYiLCJoYXNoQWxnbyI6IlNIQS0yNTYiLCJkaWdlc3QiOiIwYzI3MjA2MzFiOTI3ZTI1ZDVjYjhiNWNhMmI5NDA4YzU1MmVhNzY3OTdlMzQxOTI0NTkzMTI5NjczMmZkMGQyIn1dLCJsb2FTZW50IjoiaHR0cDovL2VpZGFzLmV1cm9wYS5ldS9Mb0EvbG93In0.t4meB51GeSPSSlQ_tvamSE9FmMD5O9HBJw0oo6iTaSjEsq4rLJ27uqcEp9l4VBleH5JW7p-Tu0qf0DuySdznTxj7iSbl43h0geLMzy2NgwMlBhu4U1-sorlqAsxRjIFDvY2z-RD1D1kqqVTtf2FJWQ5tOJ70hHEiZOtVYNjKdn_tZe2nD54KbzujIg4jW36P17wivZ6vCjagk6VjJk4LWhCO-T5L13RXR5jgq14TMCu5DFhdPA8b7v4iShD5j12Z3WBCqRCb2UWCoLtHs7nPDQ8facxymFMDGm8RQineU18OtgTClkmq4JyifNRWN6jYlPMmvQN499wfkf7VlJ8_OQ"
+ }
+ ]
+}
+```
+
+## Inhaltsstruktur (`contentStructure`)
+
+Im Objekt der Inhaltsstruktur werden alle zusätzlichen Inhalte, die zu der Einreichung gehören, wie Anlagen oder
+Fachdaten, beschrieben.
+
+```json
+{
+ ...,
+ "contentStructure": {
+ "data": {
+ "schema": {
+ "schemaURI": "urn:de:fim:leika:leistung:99015004037000",
+ "mimeType": "application/json"
+ }
+ },
+ "attachments": [
+ {
+ "filename": "file_91571892B610A9E3556491BCC6844BAD582.jpg",
+ "purpose": "attachment",
+ "attachmentId": "82050376-a506-4d25-8fad-ebfbb74e2f10",
+ "description": "Passbild (F99000582)",
+ "mimeType": "image/jpeg"
+ },
+ {
+ "filename": "file_403672D5970CD33C9E0AE12D2B38FE07393.png",
+ "purpose": "attachment",
+ "attachmentId": "45413e64-6635-4836-a46f-162e5abe6731",
+ "description": "Nachweis über vorherige Antragsstellungen bei Berufsgenossenschaften oder Behörden (G03000159.G03000161.G03000158.F99000393)",
+ "mimeType": "image/png"
+ },
+ {
+ "filename": "file_846E243838246ADCD66E4372EE60616D374.pdf",
+ "purpose": "attachment",
+ "attachmentId": "36a6f99b-b251-40b3-b20f-d32af8108351",
+ "description": "Nachweis/Kopie Unterschriebene Schweigepflichtsentbindung (G03000221.G99000373.F99000374)",
+ "mimeType": "application/pdf",
+ "signature": {
+ "type": "pdf"
+ }
+ },
+ {
+ "filename": "print.pdf",
+ "purpose": "form",
+ "attachmentId": "653dc130-305d-49a7-983f-c757e37f820a",
+ "description": "Antragsformular",
+ "mimeType": "application/pdf",
+ "signature": {
+ "type": "pdf-detached",
+ "content": "TG9yZW1JcHN1bVNpbmVEb2xvckFtZXRIaXBzZXIgU2F5IFdPT1AgQk9PUGJpQmFtCg=="
+ }
+ },
+ {
+ "filename": "deckblatt.pdf",
+ "purpose": "report",
+ "attachmentId": "383cc3e6-9c9b-41fb-a8e7-57160197ac3d",
+ "description": "Deckblatt mit Antrags-Metadaten",
+ "mimeType": "application/pdf"
+ }
+ ]
+ },
+ ...
+}
+```
+
+## Bezahlinformationen (`paymentInformation`)
+
+Dieses Objekt enthält die Bezahlinformationen, die von einem Onlineservice an den Zustellpunkt übergeben werden sollen.
+Darin sind Informationen zur Rechnungsstellung zu finden, sowie Informationen über den Bezahlvorgang, falls er über einen
+externen Bezahldienstleister abgewickelt wurde.
+
+Die Bezahlinformationen sind ein optionales Feld und die Bedeutung fehlender Bezahlinformation ist, dass d:er Verwaltungskund:in
+die Leistung noch in Rechnung gestellt werden muss oder die Leistung kostenfrei ist.
+
+```json
+{
+ ...,
+ "paymentInformation": {
+ "transactionUrl": "https://payment.bundesland.zzzz/api/v1/paymenttransaction/12002312/MELD-ANT-FORM-4711/2ec6dad2-5606-4a85-82bc-19521ed5e192",
+ "transactionReference": "KA-2021-5678",
+ "transactionId": "2ec6dcc2-5606-4a95-82bc-19521fd5e192",
+ "paymentMethod": "GIROPAY",
+ "status": "BOOKED",
+ "grossAmount": 15.00
+ },
+ ...
+}
+```
+
+## Verwaltungsleistung (`publicServiceType`)
+
+Beschreibung der Art der Verwaltungsleistung. Eine Verwaltungsleistung sollte immer mit einem LeiKa-Schlüssel beschrieben werden (siehe [Leistungskatalog im FIM-Portal](https://fimportal.de/kataloge#download-leistungen)).
+Ist für die gegebene Verwaltungsleistung kein LeiKa-Schlüssel vorhanden, kann die Verwaltungsleistung übergangsweise über die Angabe einer anderen Leistungs-ID in Form einer eindeutigen URN beschrieben werden.
+Auf diese Option sollte allerdings nach Möglichkeit verzichtet werden.
+
+```json
+{
+ ...,
+ "publicServiceType": {
+ "identifier": "urn:de:fjd:s03000025",
+ "name": "Antrag auf Feststellung einer Behinderung und Zuerkennung von Merkzeichen",
+ "description": "Menschen, die körperliche, seelische, geistige oder Sinnesbeeinträchtigungen haben, die sie über mindestens 6 Monate an der gleichberechtigten Teilhabe an der Gesellschaft hindern, können einen Antrag auf Feststellung einer Behinderung nach dem Sozialgesetzbuch - Neuntes Buch (SGB IX ) stellen. Das Landesamt für Soziales, Jugend und Familie prüft den Grad der Behinderung (GdB) und erteilt ab einem GdB von 20 einen Feststellungsbescheid. Als Nachweis der Behinderung kann dann ein Schwerbehindertenausweis ausgestellt werden. Dieser wird ausgestellt, wenn der festgestellte GdB wenigstens 50 beträgt. Werden zudem bestimmte gesundheitliche Merkmale festgestellt (z.B. Blindheit, Hör- oder Bewegungseinschränkungen) können Merkzeichen in den Schwerbehindertenausweis eingetragen werden. Diese Merkzeichen berechtigen zur Inanspruchnahme von Nachteilsausgleichen zum Beispiel steuerliche Vorteile oder unentgeltliche Beförderung mit Bus und Bahn und werden im Schwerbehindertenausweis mit aufgeführt. \r\n\r\nFür die Antragsstellung benötigen Sie Informationen zur betroffenen Person sowie ggf. zu vertretenden Personen, die den Antrag stellvertretend für die betroffene Person stellen. Für die Bearbeitung sind im Weiteren Informationen zu bisherigen Antragsstellungen auf Feststellung einer Behinderung, Rentenanträge, Pflegegrade sowie dauerhafte gesundheitliche Beeinträchtigungen und ärztliche Behandlungen erforderlich. Nähere Informationen können Sie dem beigefügten [Merkblatt zum Antrag nach dem Sozialgesetzbuch - Neuntes Buch - SGB IX (PDF)](https://soziales.niedersachsen.de/download/160332/Merkblatt_zum_Antrag_nach_dem_Sozialgesetzbuch_-_Neuntes_Buch_-_SGB_IX_.pdf \"Merkblatt zum Antrag nach dem Sozialgesetzbuch - Neuntes Buch - SGB IX (PDF, externe Seite)\") entnehmen.\r\n\r\nÜber die Online-Ausweisfunktion Ihres Personalausweises können Sie sich im Laufe des Antrags außerdem digital ausweisen. Hierfür können Sie den neuen Personalausweis, der einen Chip enthält und die Identifikation im Internet sicherstellen kann, verwenden.\r\n\r\n\r\n* Ihren Personalausweis mit eingeschalteter Online-Ausweisfunktion\r\n* Ihre 6-stellige PIN\r\n* Ein geeignetes Smartphone oder einen Kartenleser \r\n* Die AusweisApp des Bundes\r\n\r\nWeitere Informationen zur AusweisApp finden Sie auf der [Homepage der AusweisApp](https://www.ausweisapp.bund.de/ausweisapp2/ \"Homepage der AusweisApp (externe Seite)\").\r\n\r\n**Sie haben die Möglichkeit Anlagen im Antrag hochzuladen oder in Kopie an die Zentrale Postanschrift des Niedersächsischen Landesamt für Soziales, Jugend und Familie in 31120 Hildesheim übersenden. Bitte versehen Sie Ihre Unterlagen beim Versenden per Post mit Ihrem Aktenzeichen und übersenden Sie bis auf Fotos bitte nur Fotokopien und keine Originale, da diese im Zuge der Digitalisierung vernichtet werden.**"
+ },
+ ...
+}
+```
+
+## Rückkanal (`replyChannel`)
+
+Der Rückkanal beschreibt einen Kommunikationskanal, um zwischen der zuständigen Stelle und d:er Verwaltungskund:in digital zu kommunizieren.
+Eine zuständige Stelle kommuniziert über den Zustellpunkt, welche Kommunikationskanäle unterstützt werden und
+d:ie Verwaltungskund:in wählt einen gewünschten Kommunikationskanal daraus heraus.
+
+Für die Adressierung d:er Autor:in werden alle für den Kommunikationskanal notwendigen Verbindungs- und Adressparameter
+(einschließlich ggf. notwendiger Schlüssel/Zertifikate) im Metadatensatz mitgeliefert.
+
+```json
+{
+ "type": "object",
+ "minProperties": 1,
+ "properties": {
+ "eMail": {
+ "type": "object",
+ "properties": {
+ "address": {
+ "type": "string",
+ "format": "email"
+ },
+ "pgpPublicKey": {
+ "type": "string",
+ "description": "Hilfe zur Erstellung gibt es in der Dokumentation unter TODO.",
+ "pattern": "^-----BEGIN PGP PUBLIC KEY BLOCK-----\\n\\n"
+ }
+ },
+ "required": [
+ "address"
+ ]
+ },
+ "deMail": {
+ "type": "object",
+ "description": "Akkreditierte Anbieter siehe https://www.bsi.bund.de/DE/Themen/Oeffentliche-Verwaltung/Moderner-Staat/De-Mail/Akkreditierte-DMDA/akkreditierte-dmda_node.html",
+ "properties": {
+ "address": {
+ "type": "string",
+ "format": "email"
+ }
+ },
+ "required": [
+ "address"
+ ]
+ },
+ "fink": {
+ "type": "object",
+ "description": "Postfachadresse in einem interoperablen Servicekonto (FINK.PFISK)",
+ "properties": {
+ "finkPostfachRef": {
+ "type": "string",
+ "description": "FINK Postfachadresse",
+ "examples": [
+ "hh/by/12345"
+ ],
+ "maxLength": 150,
+ "pattern": "^[-._a-z0-9~\/]*$"
+ },
+ "host": {
+ "type": "string",
+ "description": "URL des Servicekontos, in dem das Ziel-Postfach liegt",
+ "format": "uri",
+ "examples": [
+ "https://servicekonto1.example.com/"
+ ]
+ }
+ },
+ "required": [
+ "finkPostfachRef"
+ ]
+ },
+ "elster": {
+ "type": "object",
+ "description": "Siehe https://www.elster.de/elsterweb/infoseite/elstertransfer_hilfe_schnittstellen",
+ "properties": {
+ "accountId": {
+ "type": "string",
+ "pattern": "^\\d{10}$"
+ },
+ "lieferTicket": {
+ "type": "string"
+ },
+ "geschaeftszeichen": {
+ "type": "string",
+ "maxLength": 10
+ }
+ },
+ "required": [
+ "accountId"
+ ]
+ }
+ }
+}
+```
+
+## Zusätzliche Informationen (`additionalReferenceInfo`)
+
+In diesem Objekt können zusätzliche Informationen, eine Einreichung betreffend hinterlegt werden. Spezifizierte
+Möglichkeiten sind Informationen, wie Informationen zum Sender (`senderReference`) oder das Versanddatum (`submissionDate`) der Einreichung
+aufseiten des sendenden Systems. Allerdings können hier noch weitere eigene Informationen hinterlegt bzw. mitgesendet werden,
+die jedoch nicht automatisch von einem empfangenden System genutzt werden müssen.
diff --git a/versioned_docs/version-0.14/getting-started/overview.md b/versioned_docs/version-0.14/getting-started/overview.md
new file mode 100644
index 0000000000000000000000000000000000000000..7886a3f042b5664128efb0761ee133edd6cc0313
--- /dev/null
+++ b/versioned_docs/version-0.14/getting-started/overview.md
@@ -0,0 +1,12 @@
+# Erste Schritte
+
+Im folgenden "Getting Started"-Guide wird beschrieben, wie die ersten Interaktionen mit FIT-Connect ablaufen und FIT-Connect integriert werden kann.
+In den nächsten Abschnitten wird beschrieben, wie man sich [gegenüber FIT-Connect authentifiziert](./authentication.mdx), Daten für die Übertragung [ver- und entschlüsselt](./encryption.mdx) werden, sowie welche Schritte für das [Einreichen](./sending/overview.mdx) bzw. [Empfangen](./receiving/overview.mdx) von Einreichungen notwendig sind.
+
+:::note Zielgruppe
+Die folgenden Seiten beinhalten teils sehr technische Detailinformationen zur Umsetzung einer Anbindung an die FIT-Connect-Schnittstellen. Zielgruppe der folgenden Seiten sind vorangig Entwickler:innen.
+:::
+
+Kern von FIT-Connect ist der Zustelldienst, der sendende und empfangende Systeme einer Einreichung verbindet.
+
+Jedes empfangende System (Fachverfahren / virtuelle Poststelle) verfügt über einen oder mehrere Zustellpunkte (Destinations), an die Einreichungen (Anträge oder Berichte) gesendet werden. Zustellpunkte können von empfangenden Systemen konfiguriert und von sendenden Systemen adressiert werden.
diff --git a/versioned_docs/version-0.14/getting-started/receiving/certificate.mdx b/versioned_docs/version-0.14/getting-started/receiving/certificate.mdx
new file mode 100644
index 0000000000000000000000000000000000000000..e78077d548926c80741fa7dffe080e679634a3a0
--- /dev/null
+++ b/versioned_docs/version-0.14/getting-started/receiving/certificate.mdx
@@ -0,0 +1,56 @@
+---
+title: Zertifikatsbeantragung
+sidebar_position: 2
+---
+
+Bei der verschlüsselten Übertragung in FIT-Connect werden JSON Web Keys (JWK) gemäß [RFC 7517](https://tools.ietf.org/html/rfc7517) eingesetzt. Die JSON Web Keys werden aus Zertifikaten abgeleitet. Der öffentlichen Schlüssel eines Schlüsselpaares wird in einem Zustellpunkt hinterlegt.
+Es können mehrere JWKs hinterlegt werden, welche entweder für die Verschlüsselung oder Signaturprüfung verwendet werden können.
+
+## Zertifikatsbeantragung
+:::note Hinweis
+In der Testumgebung ist die Absicherung der öffentlichen Schlüssel eines Zustellpunktes durch Zertifikate optional.
+:::
+
+Die Voraussetzung, damit sendende Systeme Daten verschlüsseln bzw. Signaturen prüfen können, ist die Hinterlegung eines gültiges X.509-Zertifikats aus der Verwaltungs-PKI in einem Zustellpunkt.
+Bei der Erstellung von Zertifikaten und der Zertifikatsprüfung sind die Regelungen und Standards aus BSI [TR-02103](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02103/BSI-TR-02103.pdf?__blob=publicationFile&v=4) zu beachten.
+
+Weitere Vorgaben für die eingesetzten X.509-Zertifikate sind unter [Vorgaben für kryptographische Verfahren in FIT-Connect](https://docs.fitko.de/fit-connect/docs/details/crypto#vorgaben-f%C3%BCr-eingesetzte-x509-zertifikate) dokumentiert.
+
+:::note Hinweis
+Der Ablauf der Zertifikatsbeantragung ist je nach zuständiger Registrierungsstelle unterschiedlich. Details zur Beantragung von Zertifikaten werden an dieser Stelle noch ergänzt.
+:::
+
+:::note Hinweis
+Die Zertifikate und damit verbundene JWKs haben eine begrenzte Gültigkeitsdauer und müssen gemäß den Vorgaben der Zertifikatsinfrastruktur in regelmäßigen Intervallen erneuert werden.
+:::
+
+### Ableitung eines FIT-Connect-kompatiblen JSON Web Keys aus einem Zertifikat
+JSON Web Keys sind das Austauschformat in dem kryptografische Schlüssel in FIT-Connect zwischen der Destination und dem
+Onlinedienst ausgetauscht werden. Private Schlüssel sollten nach Möglichkeit dort generiert werden, wo sie am Ende eingesetzt werden.
+Ein Übertragen von privaten Schlüsseln zwischen Servern/Computern sollte vermieden werden.
+Sollte dies doch notwendig sein, so muss die Übermittlung nur verschlüsselt erfolgen.
+
+Im Folgenden eine beispielhafte Schritt-für-Schritt-Anleitung, um aus einem Zertifikat aus der Verwaltungs-PKI einen
+JSON-Web-Key zu erzeugen:
+
+1. Das von der Verwaltungs-PKI signierte Zertifikat muss nun in einen JWK umgewandelt werden:
+
+ ```bash
+ openssl x509 -in certificate.pem -pubkey -noout
+ ```
+
+2. :construction: :warning: *wird noch ergänzt*
+
+ ```bash
+ # pubkey --[into]--> JWK
+ ```
+
+Die JSON Web Keys müssen vor der Verwendung in einem Client immer auf Gültigkeit geprüft werden. Das umfasst
+insbesondere folgende Punkte:
+
+- Überprüfung gegen eine Certificate Revocation List und/oder einen OCSP-Endpunkt mit signierten Antworten.
+- Überprüfung der Zertifikats-Kette bis zum Wurzelzertifikat (BSI) über das Attribut `x5c` im JWK
+
+Weitere Informationen zur Gültigkeitsprüfung finden sich im
+BSI [TR-02103](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02103/BSI-TR-02103.pdf?__blob=publicationFile&v=4)
+und im Abschnitt "[Anforderungen an das kryptografische Material](#Vorgaben-für-kryptographische-Verfahren)" .
diff --git a/versioned_docs/version-0.14/getting-started/receiving/decrypt.mdx b/versioned_docs/version-0.14/getting-started/receiving/decrypt.mdx
new file mode 100644
index 0000000000000000000000000000000000000000..49a5b1691c6855f74da9d7f2dda84463e6a0b209
--- /dev/null
+++ b/versioned_docs/version-0.14/getting-started/receiving/decrypt.mdx
@@ -0,0 +1,66 @@
+---
+sidebar_position: 6
+title: Entschlüsseln
+---
+
+import Tabs from '@theme/Tabs'
+import TabItem from '@theme/TabItem'
+
+Um eine Einreichung korrekt verarbeiten und überprüfen zu können müssen zuerst alle verschlüsselten Informationen entschlüsselt werden.
+Darunter fallen beispielsweise die Metadaten, die Fachdaten (falls vorhanden) oder Anlagen (falls vorhanden).
+
+## Entschlüsseln von Daten in empfangenden Systemen
+
+<Tabs
+ defaultValue="java"
+ values={[
+ { label: 'Java (Spring)', value: 'java', },
+ { label: 'C#', value: 'csharp', },
+ ]
+}>
+<TabItem value="java">
+
+Wenn ein empfangendes System (z.B. eine Fachanwendung oder virtuelle Poststelle) einen Einreichung erhält, kann es diese
+mithilfe des privaten Schlüssels und der Java-Bibliothek [`nimbus-jose-jwt`](https://connect2id.com/products/nimbus-jose-jwt) entschlüsseln.
+
+```xml
+<dependency>
+ <groupId>com.nimbusds</groupId>
+ <artifactId>nimbus-jose-jwt</artifactId>
+ <version>9.X.X</version>
+</dependency>
+```
+
+Hierfür muss zuerst der private Schlüssel eingelesen werden. Bei `nimbus-jose-jwt` gibt es für RSA Schlüssel die Klasse `RSAKey`, um diese zu lesen:
+
+```java
+// ⤹ InputStream
+String keyStr = new String(existingPrivateKey.readAllBytes());
+RSAKey jwk = RSAKey.parse(keyStr);
+```
+
+Nach dem Einlesen können die verschlüsselten Daten (repräsentiert als Base64URL-kodierter String) mithilfe des Schlüssels entschlüsselt werden.
+Auch hier wird wieder abhängig vom Schlüssel eine entsprechende Klasse für die Entschlüsselung verwendet, im Falle der RSA Schlüssel die Klasse `RSADecrypter`.
+
+```java
+// ⤹ InputStream
+String encryptedStr = new String(jweString.readAllBytes());
+JWEObject jweObject = JWEObject.parse(encryptedStr);
+
+jweObject.decrypt(new RSADecrypter(jwk));
+```
+
+Abschließend kann die entschlüsselte Payload weiterverarbeitet oder, wie in diesem Fall, einfach ausgegeben werden.
+
+```java
+System.out.println(jweObject.getPayload().toString());
+```
+</TabItem>
+<TabItem value="csharp">
+
+```csharp
+// TBD
+```
+
+</TabItem>
+</Tabs>
diff --git a/versioned_docs/version-0.14/getting-started/receiving/destination.mdx b/versioned_docs/version-0.14/getting-started/receiving/destination.mdx
new file mode 100644
index 0000000000000000000000000000000000000000..7f310080e6bace15a4be7e5e65738713a1c98dc1
--- /dev/null
+++ b/versioned_docs/version-0.14/getting-started/receiving/destination.mdx
@@ -0,0 +1,121 @@
+---
+sidebar_position: 3
+title: 🚧 Zustellpunkt anlegen
+---
+
+
+import useBaseUrl from '@docusaurus/useBaseUrl';
+
+Um Einreichungen über FIT-Connect zu empfangen, muss zunächst ein Zustellpunkt (Destination) angelegt werden.
+Dies wird über das Self-Service-Portal umgesetzt.
+
+:::caution
+
+In der finalen API wird eine explizite Aktivierung des Zustellpunkts (über die API oder das Self-Service-Portal) notwendig sein.
+Damit soll sichergestellt werden, dass ein API-Client mit dem Scope `subscribe:destination:<id>` für diese `destinationId` angelegt und technisch empfangsbereit ist.
+Entsprechende organisatorische und technische Hinweise zu Aktivierung werden an dieser Stelle noch ergänzt.
+:::
+
+## Zustellpunkt anlegen
+
+Unter einem Zustellpunkt versteht sich ein technisch eindeutig adressierbarer Endpunkt zur Einreichung von Anträgen oder Berichten an die Verwaltung über die FIT-Connect Übermittlungsinfrastruktur.
+Jeder Zustellpunkt muss einem Subscriber-API-Client zugeordnet werden.
+Ein Zustellpunkt repräsentiert dabei typischerweise einen Subscriber-Client (Fachverfahren oder virtuelle Poststelle).
+Es ist jedoch möglich einem empfangenden System (API-Client) multiple Zustellpunkte zuzuordnen.
+
+Über die Zustellpunktverwaltung lassen sich neue Zustellpunkte anlegen, bereits hinzugefügt Zustellpunkte verwalten und auch wieder entfernen.
+
+<div class="center">
+ <img width="600" alt="Zustellpunktverwaltung"
+ src={useBaseUrl('/images/ssp/7-Destinationverwaltung.png')}/>
+</div>
+
+Über den Menüpunkt `Zustellpunkt hinzufügen` können neue Zustellpunkte zu Ihrem Konto hinzugefügt werden.
+
+<div class="center">
+ <img width="800" alt="Formular zum Anlegen eines neuen Zustellpunktes"
+ src={useBaseUrl('/images/ssp/8-Destination-hinzufuegen.png')}/>
+</div>
+
+Ein Zustellpunkt benötigt zur Erstellung eine Vielzahl von Angaben, die sich im Wesentlichen auf Kontaktdaten, technische Angaben und Service aufteilen.
+
+Unter den unter dem Punkt Kontaktdaten abgefragten Informationen werden Details zum antragsempfangenden System erfasst.
+Sämtliche Felder sind dabei aktuell noch Fließtext.
+Unter der Funktionspostfachadresse wird eine E-Mail-Adresse erwartet.
+
+Unter den unter dem Punkt „Technische Angaben“ abgefragten Informationen werden neben einer Callback-URL auch öffentliche Schlüssel zur Signaturprüfung und Verschlüsselung erwartet.
+Beide Schlüssel müssen im JSON-Format vorliegen und den Anforderungen aus
+[Vorgaben für kryptographische Verfahren](https://docs.fitko.de/fit-connect/docs/details/crypto) entsprechen.
+Ein Tool und die zugehörige Anleitung um schnell und einfach passende Schlüssel für Testzwecke zu generieren finden Sie unter
+[Tool zur Erstellung von JSON Web Keys](https://docs.fitko.de/fit-connect/docs/details/jwk-creation/).
+
+Unter den unter dem Punkt „Service“ abgefragten Informationen werden ein eindeutiger Leistungsindikator, eine Region aus der eine Anfrage zulässig ist sowie die URI des verwendeten Fachschemas erwartet.
+
+<div class="center">
+ <img width="800" alt="Zustellpunkt mit Beispieldaten befüllt"
+ src={useBaseUrl('/images/ssp/9-Destination-hinzufuegen-befuellt.png')}/>
+</div>
+
+Wurden alle Informationen und Schlüssel in korrekter Form übergeben wird der Zustellpunkt erstellt.
+
+<div class="center">
+ <img width="600" alt="Destination wurde erfolgreich angelegt"
+ src={useBaseUrl('/images/ssp/11-Destination-erfolgreich-angelegt.png')}/>
+</div>
+
+:::caution
+Alle neu angelegten Zustellpunkte haben nach der Erstellung den Status `created` und sind für sendende Systeme nicht sichtbar und adressierbar.
+Hiermit soll verhindert werden, dass Einreichungen an den Zustellpunkt übersendet werden, ohne das ein empfangsbereites System vorliegt, dass die Einreichungen für diesen Zustellpunkt an der API abrufen kann.
+
+Daher ist zwingend vor der Aktivierung eines Zustellpunktes [ein API-Client anzulegen](https://docs.fitko.de/fit-connect/docs/account) und diesem Zustellpunkt zuzuweisen (siehe nächster Abschnitt).
+:::
+
+
+## Zugriff auf Zustellpunkte einrichten
+Clients vom Typ **Subscriber** können Zustellpunkten zugeordnet werden.
+Der Client empfängt dann die für den Zustellpunkt bestimmten Anfragen.
+Durch einen Klick auf die Client-ID eines Clients vom Typ **Subscriber** in der Client-Verwaltung öffnet sich die Detailansicht.
+
+<div class="center">
+ <img width="600" alt="Zustellpunkte zu einem Client hinzufügen"
+ src={useBaseUrl('/images/ssp/16-Destination-zu-Client-hinzufuegen.png')}/>
+</div>
+
+Unter `Zustellpunkte` werden alle verfügbaren oder bereits verknüpften Zustellpunkte angezeigt.
+Durch Aktivieren des Kontrollkästchens vor dem Zustellpunkt öffnet sich der Bestätigungsdialog, um dem Client Zugriff auf den Zustellpunkt zu geben.
+
+<div class="center">
+ <img width="600" alt="Bestätigungsdialog um einen Zustellpunkt zu einem Client hinzufügen"
+ src={useBaseUrl('/images/ssp/16b-Destination-zu-Client-hinzufuegen.png')}/>
+</div>
+
+Im Anschluss wird der hinzugefügte Zustellpunkt durch ein Häkchen im Kontrollkästchen gekennzeichnet.
+Zusätzlich wurde der Zustellpunkt im Scope des Clients hinzugefügt.
+
+<div class="center">
+ <img width="600" alt="Aktualisierter Scope des Clients"
+ src={useBaseUrl('/images/ssp/16c-Destination-zu-Client-hinzufuegen.png')}/>
+</div>
+
+## Zugriff auf Zustellpunkte entfernen
+
+Bei Clients vom Typ **Subscriber** können zugeordnete Zustellpunkte auch wieder entfernt werden.
+Durch einen Klick auf das derzeit noch aktive und mit einem Häkchen gekennzeichnete Kontrollkästchen des zu entfernenden Zustellpunktes, öffnet sich ein Kontrolldialog, in dem das Löschen bestätigt werden muss.
+
+<div class="center">
+ <img width="600" alt="Kontrolldialog zum Entfernen des Zugriffs auf einen Zustellpunkt"
+ src={useBaseUrl('/images/ssp/17-Destination-vom-Client-entfernen.png')}/>
+</div>
+
+Im Anschluss wird der entfernte Zustellpunkt nicht länger durch ein Häkchen im Kontrollkästchen gekennzeichnet.
+Zusätzlich wurde der Zustellpunkt im Scope des Clients entfernt.
+
+<div class="center">
+ <img width="600" alt="Aktualisierter Scope des Clients"
+ src={useBaseUrl('/images/ssp/17b-Destination-vom-Client-entfernen.png')}/>
+</div>
+
+## Bearbeiten und Löschen von Zustellpunkten
+
+Weiterführende Informationen zum Bearbeiten und Löschen von Zustellpunkten finden sich im Artikel
+[Verwalten eines Zustellpunktes](/docs/details/destination-management).
diff --git a/versioned_docs/version-0.14/getting-started/receiving/download-submission.mdx b/versioned_docs/version-0.14/getting-started/receiving/download-submission.mdx
new file mode 100644
index 0000000000000000000000000000000000000000..c327409140c60d79ad288c97abeac70b927951be
--- /dev/null
+++ b/versioned_docs/version-0.14/getting-started/receiving/download-submission.mdx
@@ -0,0 +1,52 @@
+---
+sidebar_position: 5
+title: Einreichung herunterladen
+---
+
+import ApiLink from '@site/src/components/ApiLink'
+
+## Abruf von Metadaten und Fachdaten
+Der Abruf einer Einreichung ist über den Endpunkt <ApiLink to="/submissions/{submissionId}" /> möglich. Liegen zur Einreichung neben den verschlüsselten Metadaten (`encryptedMetadata`) und Fachdaten (`encryptedData`) zusätzlich weitere Anlagen vor, so sind die IDs der Anlagen im Feld `attachments` zu finden. Anlagen müssen separat heruntergeladen werden (siehe nächster Abschnitt).
+
+Anschließend können die Metadaten und Fachdaten [entschlüsselt](./decrypt.mdx) sowie deren Schemata [validiert](./validate.mdx) werden.
+
+```bash title="Abfrage der Einreichung inkl. Fachdaten und Metadaten"
+$ export SERVICE_URL=<URL>
+$ export JWT_TOKEN=eyJhbGciOiJIUzI1NiJ9.eyJJc3N1Z...NL-MKFrDGvn9TvkA
+$ export SUBMISSION_ID=9d618546-0ff7-4e93-9f15-714e5dd1bf12
+$ curl \
+ -H "Authorization: Bearer $JWT_TOKEN" \
+ -H "Content-Type: application/json" \
+ -X GET $SERVICE_URL/submissions/$SUBMISSION_ID
+> {
+ "destinationId": "879ee109-a690-4db8-ab32-424284184d7d",
+ "submissionId": "ce75a6b8-d72f-4b94-b09e-af6be35bc2ae",
+ "caseId": "e89e107e-ed79-40e6-ad34-4e770f9df26d",
+ "attachments": [
+ "879ee109-a690-4db8-ab32-424284184d7d",
+ "2046f9f1-dc89-4440-9c24-c76a8f40d668"
+ ],
+ "encryptedMetadata": "eyJlbmMiOiJ...VBHJ00FyDTYjOA_OYfiz5g",
+ "`encryptedData`": "eyJlbmMiOiJ...VBHJ00FyDTYjOA_OYfiz5g",
+ "serviceType": {
+ "name": "Bauantrag",
+ "identifier": "urn:de:fim:leika:leistung:99010003001006"
+ }
+}
+```
+
+## Abruf von Anlagen
+Anlagen können über den Endpunkt <ApiLink to="/submissions/{submissionId}/attachments/{attachmentId}" /> abgerufen werden. Anschließend können auch die Anlagen [entschlüsselt werden](./decrypt.mdx).
+
+
+```bash title="Herunterladen einer Anlage"
+$ export SERVICE_URL=<URL>
+$ export JWT_TOKEN=eyJhbGciOiJIUzI1NiJ9.eyJJc3N1Z...NL-MKFrDGvn9TvkA
+$ export SUBMISSION_ID=9d618546-0ff7-4e93-9f15-714e5dd1bf12
+$ export ATTACHMENT_ID=122668ad-3081-497c-9358-7ce4b6144b02
+$ curl \
+ -H "Authorization: Bearer $JWT_TOKEN" \
+ -H "Content-Type: application/jose" \
+ -X GET $SERVICE_URL/submissions/$SUBMISSION_ID/attachments/$ATTACHMENT_ID
+> 6r4H2H_WIzCv8Pd-uetmcbK...iVBKF3ylHRUahmZ
+```
diff --git a/versioned_docs/version-0.14/getting-started/receiving/overview.mdx b/versioned_docs/version-0.14/getting-started/receiving/overview.mdx
new file mode 100644
index 0000000000000000000000000000000000000000..e6593c0bc74a62bde0d101dd35f8f7a38558b3b4
--- /dev/null
+++ b/versioned_docs/version-0.14/getting-started/receiving/overview.mdx
@@ -0,0 +1,28 @@
+---
+sidebar_position: 1
+title: Ãœberblick
+---
+
+import Mermaid from '@site/src/components/Mermaid'
+
+Für den Empfang von Einreichungen und die Verarbeitung dieser werden in diesem und den folgenden Abschnitten alle notwendigen Aktionen beschrieben, um schnell die ersten Schritte machen zu können.
+Als Leitlinie dafür ist der unten dargestellte Prozessablauf heranzuziehen, dessen Schritte im Folgenden beschrieben werden.
+
+<Mermaid>
+sequenceDiagram
+ participant C as Client;
+ participant F as FIT Connect;
+ C->>F: Zustellpunkt anlegen;
+ alt Callback;
+ F->>C: Ãœber neue Einreichung benachrichtigen;
+ else Polling;
+ loop;
+ C->>F: Vorhandensein neuer Einreichungen abfragen;
+ end;
+ end;
+ C->>F: Einreichung abfragen;
+ F->>C: Metadaten, Fachdaten erhalten;
+ C->>C: Anlagen herunterladen;
+ C->>C: Metadaten, Fachdaten & Anlagen entschlüsseln;
+ C->>F: Empfang & Validität der Einreichung bestätigen;
+</Mermaid>
diff --git a/versioned_docs/version-0.14/getting-started/receiving/process-and-acknowledge.mdx b/versioned_docs/version-0.14/getting-started/receiving/process-and-acknowledge.mdx
new file mode 100644
index 0000000000000000000000000000000000000000..291fac49e2f480314549f7fa99106480ff51afc9
--- /dev/null
+++ b/versioned_docs/version-0.14/getting-started/receiving/process-and-acknowledge.mdx
@@ -0,0 +1,127 @@
+---
+sidebar_position: 8
+title: Empfangsbestätigung
+---
+
+import Tabs from '@theme/Tabs'
+import TabItem from '@theme/TabItem'
+
+import ApiLink from '@site/src/components/ApiLink'
+
+
+Der letzte Schritt zum Empfang einer Einreichung ist die Bestätigung des Empfangs und damit auch der Gültigkeit der Einreichung.
+Mit Gültigkeit ist hier gemeint, dass alle Informationen erfolgreich heruntergeladen, entschlüsselt und im Falle der Metadaten validiert werden konnten.
+
+Wie auf der [Event Log Übersichtsseite](../event-log.mdx#events) zu sehen, gibt es für ein empfangendes System ein festes Set an Events, die dem Zustelldienst gesendet werden können.
+
+| Event | Autor | Bedeutung |
+|-----------------------------------------------------------------|---------------------|-------------------------------|
+| `https://schema.fitko.de/fit-connect/events/forward-submission` | | Ein nachgelagertes System hat die Einreichung zur Weiterleitung übernommen. |
+| `https://schema.fitko.de/fit-connect/events/reject-submission` | Empfangendes System | Die Einreichung wurde durch den Empfänger zurückgewiesen. |
+| `https://schema.fitko.de/fit-connect/events/accept-submission` | Empfangendes System | Die Einreichung wurde durch den Empfänger akzeptiert. |
+
+Um diese Events bzw. ein entsprechendes Event korrekt an den Zustelldienst zu versenden, muss es in Form eines SETs an diesen gesendet werden.
+
+## Erstellung und Versand eines Security-Event-Token (SET)
+
+Um ein SET zu erstellen, MUSS ein JWK verwendet werden, der den [Vorgaben für Signaturschlüssel](../../details/crypto.md#signature-key) entspricht.
+Weiterhin ist es notwendig, dass die Id der Einreichung und des zugehörigen Vorgangs bekannt ist.
+
+<Tabs
+ defaultValue="java"
+ values={[
+ { label: 'Java', value: 'java', },
+ { label: 'C#', value: 'csharp', },
+ ]
+ }>
+<TabItem value="java">
+
+ ```java title=Annahmen
+ JWK key;
+ String subject = "submission:f65feab2-4883-4dff-85fb-169448545d9f";
+ String event ="https://schema.fitko.de/fit-connect/events/accept-submission";
+ String transactionId = "case:f73d30c6-8894-4444-8687-00ae756fea90";
+ ```
+
+ Die Payload- und Header-Attribute des SET müssen wie oben beschrieben definiert werden (siehe markierte Zeilen).
+ Im dritten markierten Block wird das SET mit dem Schlüssel signiert und danach kann der serialisierte Wert an den [Zustelldienst](../../apis/submission-api.mdx#post-/submissions/-submissionId-/events) gesendet werden.
+
+ ```java {3-10,12-16,22-24}
+ try {
+ JWSSigner signer = new RSASSASigner(key.toRSAKey());
+ JWTClaimsSet claimsSet = new JWTClaimsSet.Builder()
+ .issuer("https://my-custom-identifiable-service.domain")
+ .issueTime(new Date())
+ .jwtID(UUID.randomUUID().toString())
+ .subject(subject)
+ .claim("events", Map.of(event, Map.of()))
+ .claim("txn", transactionId)
+ .build();
+
+ JWSHeader header = JWSHeader.parse(Map.of(
+ "typ", "secevent+jwt",
+ "kid", key.getKeyID(),
+ "alg", "PS512"
+ ));
+
+ SignedJWT signedJWT = new SignedJWT(
+ header,
+ claimsSet);
+
+ signedJWT.sign(signer);
+
+ String signedAndSerializedSET = signedJWT.serialize(); // => SET, serialized as Base64 encoded string
+ } catch (JOSEException e) {
+ throw new RuntimeException("Could not generate SET");
+ }
+ ```
+ </TabItem>
+</Tabs>
+
+Dies kann dann über ein <ApiLink to="/submissions/{submissionId}/events" withMethod="post" /> erreicht werden.
+Hier wird das Event über den Request-Body übertragen und vom Zustelldienst syntaktisch und auf eine korrekte Signatur geprüft.
+Sind alle Prüfungen erfolgreich durchlaufen, wird das SET im Event Log abgespeichert und der Zustand der Einreichung abhängig vom Event geändert.
+
+## Event Log abfragen
+
+Der Event Log einer Einreichung kann über <ApiLink to="/submissions/{submissionId}/events" /> abgefragt werden.
+Hierbei wird der Event Log der Einreichung zurückgeliefert, der die verschiedenen Statusübergänge bzw. abgelegten Ereignisse beinhaltet.
+Das Ergebnis könnte wie folgt aussehen:
+
+```json
+{
+ "eventLog": [
+ "eyJraWQiOiJkZDA0MDllNS00MTBlLTRkOTgtODViNi1mODFhNDBiOGQ5ODAiLCJ0eXAiOiJzZWNldmVudCtqd3QiLCJhbGciOiJQUzUxMiJ9.ewogICJpc3MiOiAiaHR0cHM6Ly9hcGkuZml0a28uZGUvZml0LWNvbm5lY3QvIiwKICAiaWF0IjogMTYyMjc5NDMxOSwKICAianRpIjogIkVEQ0ZCRjIxLTVCMTYtNEQwNi05OUQwLURDNEMyNkY0RkI5RSIsCiAgInN1YiI6ICJzdWJtaXNzaW9uOkY2NUZFQUIyLTQ4ODMtNERGRi04NUZCLTE2OTQ0ODU0NUQ5RiIsCiAgImV2ZW50cyI6IHsKICAgICJodHRwczovL3NjaGVtYS5maXRrby5kZS9maXQtY29ubmVjdC9ldmVudHMvY3JlYXRlLXN1Ym1pc3Npb24iOiB7fQogIH0sCiAgInR4biI6ICJjYXNlOkY3M0QzMEM2LTg4OTQtNDQ0NC04Njg3LTAwQUU3NTZGRUE5MCIKfQ.TQBR_CBsoULi3cGaGg4oqFelQ9GVn8G-cNokzTVDZgZf4D7x_8wjsDcgTd0aamiy8ErlnV1xoAoDcPw81vajrBCaYgf9KI4sNhsW78jlDi_ywK04YhFbkvloDMioGf_5zCNTBreN9bTnU_VYuWB23R_YrYGi2exONft-ZReN_crEvDaKLdG9hqnaCRFwKJ1t8TbLvIyBKLqQYEqP0Oh6m3WA9IRz3EB41S-PZgJCIzmz_GvXdRvw_1B8A_Q7aHr2SQ6Dc-c406UJ5P_7FuypE6tLyuYf5GkmFZSauQ51H4LLl8pLrsW2PJJ28cMavOEx0AWoRLwB7yKK5bAGtcALWw-0W7Wmw1QEX3DZGTpXbEUM0U_7iXeEFrdtfCCbFPMVbmlK-b66IyKK_6yeaOAEjQvCUOrALfa2sSOS6RWiNOKyA1l1L29VoIBXgQ8np72NMV8-AP7UnQO1NPBghBM6LW6tcXceWeP8ayy4eEaZQ639pqH4TJRRkQqnuoTeADpYL9sX2hM9173O4abWiE-Z8zW2AQ1jhUvVXJ8w9ddtMIyjZJZOqoy3TbHxUYpn4UqbedlDyahpUiKCT7-qU2jOjeXAXEPQvWlSzLigNtFvYCEq-fOe1lpeNktoQQrC3Y-szk2vNj5fT_KmJY1QG1bhyrUMoGbA-pe45c-FcCE7ErQ",
+ "eyJraWQiOiJkZDA0MDllNS00MTBlLTRkOTgtODViNi1mODFhNDBiOGQ5ODAiLCJ0eXAiOiJzZWNldmVudCtqd3QiLCJhbGciOiJQUzUxMiJ9.ewogICJpc3MiOiAiaHR0cHM6Ly9hcGkuZml0a28uZGUvZml0LWNvbm5lY3QvIiwKICAiaWF0IjogMTYyMjc5NTczMiwKICAianRpIjogIjkwRDlCMjlELUMwNUYtNEYwMy04MUMwLUUyMzMxMTZDNTZEOSIsCiAgInN1YiI6ICJzdWJtaXNzaW9uOkY2NUZFQUIyLTQ4ODMtNERGRi04NUZCLTE2OTQ0ODU0NUQ5RiIsCiAgImV2ZW50cyI6IHsKICAgICJodHRwczovL3NjaGVtYS5maXRrby5kZS9maXQtY29ubmVjdC9ldmVudHMvc3VibWl0LXN1Ym1pc3Npb24iOiB7fQogIH0sCiAgInR4biI6ICJjYXNlOkY3M0QzMEM2LTg4OTQtNDQ0NC04Njg3LTAwQUU3NTZGRUE5MCIKfQ.THmHiZoYEMyyWCu2R4nEJtvgtB5PF0KAqtfu_Z-yVjfjSkXW7TtZnX96UAeCGsjpxkBJvXTXAgSB5n378KjZXebAtI7nbFE0gYgt3fwmxmpJitA-4e8v6KfvhwNcdqJHLKDzYRMq_yw7UiwLx1Cxz6nBiOKfR4piL707muKXTgD7DuP0kv-c6V9dGNQ4KzT_sJP5zDWogEzGWSVaLaJZrmDZHoUZMZ6C9kI7SvC-A7Q0ROkFznU_cpjjEAIG74_YCiICvjr91ueQWTdNyc1DBvxpEBtBWq6nWPTg0d91iQlhPUgNKbmC4QtG_tFctTYhX7stO-JbL-4VnAQjQHD5uw4SvvpPrTN4Z3Wz2IjMm8-ClI9imGKThfAqwTaWtJv7Bn_FDiN_nEuGyN2of-M2vZWa-DlZ2iPFct6ESp9PumaO_pIF5cUrX4IBoe3fcmg788-ClReytCMjD13uPVOVoIb3yimUdupOUROxb3MITowHP2-YG1gWqhQp22XSQXktugDHWezAuN0xuimwAJq_OvyoDxj4lsnn6BQkqZYdqD0hJghwqZIytg8PlIi76Cdvh8NFgVw48xZ0WUOFvBPJO2Qe8PiTSVX_P9CIIWxsKlYwg8vJ226qi0eYfD70ynjBDQIPmsOOSut6bFKgOLBFa9ZvCy6HmhyLa-EsgLhS4uc",
+ "eyJraWQiOiJkZDA0MDllNS00MTBlLTRkOTgtODViNi1mODFhNDBiOGQ5ODAiLCJ0eXAiOiJzZWNldmVudCtqd3QiLCJhbGciOiJQUzUxMiJ9.ewogICJpc3MiOiAiaHR0cHM6Ly9hcGkuZml0a28uZGUvZml0LWNvbm5lY3QvIiwKICAiaWF0IjogMTYyMjc5NjUzMiwKICAianRpIjogIjBCRjZEQkY2LUNFN0UtNDRBMy04ODlGLTgyRkU3NEMzRTcxNSIsCiAgInN1YiI6ICJzdWJtaXNzaW9uOkY2NUZFQUIyLTQ4ODMtNERGRi04NUZCLTE2OTQ0ODU0NUQ5RiIsCiAgImV2ZW50cyI6IHsKICAgICJodHRwczovL3NjaGVtYS5maXRrby5kZS9maXQtY29ubmVjdC9ldmVudHMvYWNjZXB0LXN1Ym1pc3Npb24iOiB7fQogIH0sCiAgInR4biI6ICJjYXNlOkY3M0QzMEM2LTg4OTQtNDQ0NC04Njg3LTAwQUU3NTZGRUE5MCIKfQ.blxz8Tw_Sl8_tomcqxezamX_DVGyGiu61iYGv3mA3yVLLSDlPscjcHm_MCNm5iq-ODUk-FCW1ljOexN2czZJic8wvLhWhcUt8U2kkkjis-CWz4oqhuB4ynAj7Yyn4H4xkLoH7Y6k9pqW9P2mN7984o_578mJJ4mQSNEGcPr_BDbRc2nUKcupG7iS-hx6VTjrRTP7LGPyOblDB8oL_QyT9qY0US7PT35QgiraUSK3RWhDpj6C0I4bOV5cQeSqlXT2xIfeO3sUPeWLYVmGjuB8QWvDsniKz6JqRN-v39FrAppsOufdiRim36wtBZt9o-3txjtz5wu0_eSfjOueGJbfqAeWsbd2TYwZtL-7Z-MPfoe3XInDNmmTfxo4KXkF1GkRnGnjniwrWBHeh18A04NNHYcX-vsoijEreqDN2lEKwks3pDK5Twe5O9RxJ0cYB8oeKB55rJzs15pfla69qVn9zFvCAc_ji_9WaAa_mIG0zimMucG3qA0KrUww88FaS4heh5-Gs1Ik35QoUOCCa7ZMJMKxYArFCgUqHw-gX60U5mp4hy7tVe3hD-RxIRnlTIkEkHgDGmslVc1t8fC9oPgljQirPcTIeWhVyLmk6rJLgR5nqizujz3hDUCdBuRF43fS6qedmYfHq1MyakJzEFe2ht1rpGw4ftAt0kcOBOf2jyQ"
+ ]
+}
+```
+
+Im Log dieser Einreichung wurden drei Events aufgezeichnet, wobei das letzte SET das aktuellste ist.
+Das letzte SET aus obigem Beispiel hat folgenden Payload.
+
+```json
+{
+ "iss": "https://api.fitko.de/fit-connect/",
+ "iat": 1622796532,
+ "jti": "0BF6DBF6-CE7E-44A3-889F-82FE74C3E715",
+ "sub": "submission:F65FEAB2-4883-4DFF-85FB-169448545D9F",
+ "events": {
+ "https://schema.fitko.de/fit-connect/events/accept-submission": {}
+ },
+ "txn": "case:F73D30C6-8894-4444-8687-00AE756FEA90"
+}
+```
+
+In dem SET ist folgende Information abgelegt:
+- Er wurde vom Zustelldienst https://api.fitko.de/fit-connect/ ausgestellt (iss = issuer)
+- Er wurde am 04.06.2021 um 08:48:52 GMT+0 (Unixzeit 1622796532) aufgezeichnet (iat = issued at)
+- Er hat die eindeutige ID `0BF6DBF6-CE7E-44A3-889F-82FE74C3E715` (jti = JWT ID)
+- Er betrifft die Einreichung `F65FEAB2-4883-4DFF-85FB-169448545D9F` (sub = subject)
+- Die Submission wurde angelegt "accept-submission" (events)
+- Die Submission gehört zur Vorgangsreferenz (case) `F73D30C6-8894-4444-8687-00AE756FEA90`
+
+Aus dem Event des SET lässt sich ableiten, dass der aktuelle Status der Einreichung `accepted` ist und der Zeitpunkt des Übergangs der 04.06.2021 um 08:48:52 GMT+0 war.
+Da alle SETs im Event Log signiert sind, kann diese Signatur auch noch überprüft werden.
+Die Überprüfung ist im Artikel zum [Event Log](../event-log.mdx#set-validation) beschrieben.
diff --git a/versioned_docs/version-0.14/getting-started/receiving/query.mdx b/versioned_docs/version-0.14/getting-started/receiving/query.mdx
new file mode 100644
index 0000000000000000000000000000000000000000..b56c19fb4c46f045c0303a12fa3845613d098092
--- /dev/null
+++ b/versioned_docs/version-0.14/getting-started/receiving/query.mdx
@@ -0,0 +1,58 @@
+---
+sidebar_position: 4
+title: Vorhandensein neuer Einreichungen prüfen
+---
+
+import ApiLink from '@site/src/components/ApiLink'
+
+Empfangende Systeme können sich über den Eingang neuer Einreichungen entweder durch periodische Anfragen informieren (Polling) oder vom Zustelldienst über Callbacks aktiv benachrichtigen lassen.
+Letzteres stellt die empfohle Umsetzungsvariante dar, da hierdurch unnötige Anfragen vermieden werden können, was zu einer insgesamt besseren Performance und zu einer schnelleren Benachrichtung empfangnder Systeme führt.
+
+## Callback
+Wenn eine Callback-URL im Zustellpunkt hinterlegt ist, kann der Zustelldienst den Zustellpunkt aktiv via Callback über neue Einriechungen informieren.
+Das Format, in welchem der Callback übertragen wird, ist im Endpunkt <ApiLink to="/destinations/{destinationId}" withMethod="put" /> definiert.
+Die Konfiguration und Prüfung von Callbacks ist im Aritkel [Verwendung von Callbacks](../../details/callbacks.mdx) beschrieben.
+
+Callbacks zur Benachrichtigung über neue Einriechungen haben das folgende Format:
+
+```http
+POST /callbacks/fit-connect
+callback-authentication: f4eig0ht6hdlsfz6DVqGjXi1j3RAombIQ7vjG1M2TFZx1fGurzg1nOEh00lPfLEulhio1RyTOav1e1aMi69SRg==
+callback-timestamp: 1672527599
+
+{"type":"https://schema.fitko.de/fit-connect/callbacks/new-submissions","submissionIds":["f39ab143-d91a-474a-b69f-b00f1a1873c2"]}
+```
+
+Wenn das empfangende System über den Eingang neuer Einreichungen benachrichtigt wurde, dann kann es diese wie im Artikel [Einreichung herunterladen](./download-submission.mdx) beschrieben herunterladen.
+
+## Polling
+Über Polling, d.h. regelmäßiges Abfragen des Endpuntes <ApiLink to="/submissions" /> , können alle Einreichungen abgefragt werden, die zum Abholen bereitstehen.
+Dies wird aus Performancegründen jedoch nicht empfohlen.
+
+Die abgerufene Liste der Submissions kann über den Parameter `destinationId` auf einzelne Zustellpunkte eingeschränkt werden.
+In diesem Fall werden nur die Submissions zurückgegeben, die zum angegebenen Zustellpunkt gehören.
+
+```bash
+$ export SERVICE_URL=<URL>
+$ export JWT_TOKEN=eyJhbGciOiJIUzI1NiJ9.eyJJc3N1Z...NL-MKFrDGvn9TvkA
+$ curl \
+ -H "Authorization: Bearer $JWT_TOKEN" \
+ -H "Content-Type: application/json" \
+ -X GET $SERVICE_URL/submissions
+> {
+ submissions: [
+ {
+ destinationId: "879ee109-a690-4db8-ab32-424284184d7d",
+ submissionId: "ce75a6b8-d72f-4b94-b09e-af6be35bc2ae"
+ },
+ {
+ destinationId: "19c8489b-29b8-422f-b7db-919852cfb04b",
+ submissionId: "e364430f-5a3b-4284-ba9a-f2867ba421e6"
+ },
+ {
+ destinationId: "80a0aac3-148d-42bb-9366-516ce6355348",
+ submissionId: "530ba588-2db9-4899-ab0d-0c0b57689271"
+ }
+ ]
+}
+```
diff --git a/versioned_docs/version-0.14/getting-started/receiving/validate.mdx b/versioned_docs/version-0.14/getting-started/receiving/validate.mdx
new file mode 100644
index 0000000000000000000000000000000000000000..4a571318878a7544024841a7f4fe324a41489414
--- /dev/null
+++ b/versioned_docs/version-0.14/getting-started/receiving/validate.mdx
@@ -0,0 +1,151 @@
+---
+sidebar_position: 7
+title: Schemavalidierung
+---
+
+## Validierung des Metadatensatzes
+
+:::caution
+Die Dokumentation wird noch um eine Validierung des Metadatenschema anhand eines Beispieldatensatzes und eines gängigen Open Source Validierungstools ergänzt.
+:::
+
+Im Metadatensatz muss mindestens eine Struktur der übermittelten Inhalte einer Einreichung (Fachdaten, Anlagen) im Feld `contentStructure` angegeben werden.
+Zusätzlich können noch die Felder `authenticationInformation`, `paymentInformation`, `publicServiceType` und `replyChannel` mit entsprechenden Unterobjekten angegeben werden, um den Weg einer Antwort bzw. die Bezahlinformationen der Einreichung genauer zu definieren.
+Die gültigen Formate, die die Felder des Schemas annehmen können, sind im [Metadatenschema selbst](../../apis/metadata.mdx) definiert und können mithilfe von Bibliotheken validiert werden.
+Eine Liste der zur Verfügung stehenden [Schmema-Validatoren](https://json-schema.org/implementations.html#validators) sowie [Code-Generatoren](https://json-schema.org/implementations.html#generators-from-schemas) für verschiedenste Programmiersprachen findet sich auf der offiziellen Seite von JSON-Schema.
+
+## Validierung des Fachdatensatz
+
+Danach erfolgt eine Prüfung des Fachdatensatzes:
+- Entspricht der Fachdatensatz dem vereinbarten Medientyp (JSON oder XML)?
+- Entspricht der Fachdatensatz dem vereinbarten Schema?
+
+Hierbei kann die im Metadatensatz enthaltene Schemareferenz genutzt werden, um das zu validierende Schema zu identifizieren, wenn im Zustellpunkt mehrere
+Schemata für Fachdatensätze unterschützt werden.
+
+Das Validierungsvorgehen wird im folgenden Anhand von Bespielen für FIM- und XÖV-Fachdatensätzen gezeigt.
+
+### Details zur Prüfung eines FIM-Fachdatensatzes (JSON Schema) {#fim-json}
+
+:::caution
+Das FITKO Schemarepository ist derzeit noch in Vorbereitung.
+Daher können die Fachschemata noch nicht wie beschrieben heruntergeladen werden.
+
+Die JSON-Variante des FIM Fachdatensatzes befindet sich ebenfalls noch in der Konzeption und kann noch nicht genutzt werden.
+:::
+
+Die FIM-Fachschemata werden im FITKO Schemarepository (`https://schema.fitko.de/`) abgelegt.
+Die Fachschemareferenz gibt an, welches Schema zu beziehen ist.
+
+```json
+"contentStructure": {
+ "data": {
+ "schema": {
+ "schemaURI": "https://schema.fitko.de/fim/s00000000009_1.0.0.schema.json",
+ "mimeType": "application/json"
+ }
+ }
+}
+```
+
+- Prüfen Sie, dass die `schemaURI` mit `https://schema.fitko.de/fim/` beginnt. Dies stellt sicher, dass das Fachschema aus dem FITKO Repository bezogen wird.
+- Laden Sie das Fachschema herunter
+
+```
+➜ wget -nv https://schema.fitko.de/fim/s00000000009_1.0.0.schema.json
+```
+
+- Nun können Sie den Fachdatensatz gegen das vorliegende Fachschema "s00000000009_1.0.0.schema.json" prüfen.
+
+### Details zur Prüfung eines FIM Fachdatensatzes (XML Schema) {#fim-xml}
+
+Die Fachschemata im FIM XML Übertragungsformat (XFall) können über das FIM-Portal bezogen werden.
+Zukünftig werden sie auch über das FITKO Schemarepository zur Verfügung stehen.
+
+```json
+"contentStructure": {
+ "data": {
+ "schema": {
+ "schemaURI": "https://schema.fitko.de/fim/s00000092_1.0.xsd",
+ "mimeType": "application/xml"
+ }
+ }
+}
+```
+
+- Prüfen Sie, dass die `schemaURI` mit `https://schema.fitko.de/fim/` beginnt.
+- Entnehmen Sie der URI die ID des Fachschemas (hier: "s00000092").
+- Öffnen Sie das FIM-Portal (https://fimportal.de/) und loggen Sie sich ein.
+- Öffnen Sie Sie Adresse `https://fimportal.de/detail/D/{ID}`, also z.B. https://fimportal.de/detail/D/S00000092.
+- Klicken Sie rechts auf den Downloadlink, der auf "_xfall.xsd" endet (hier: `S00000092V1.0_xfall.xsd`).
+- Das XFall-Schema wird Ihnen angezeigt und kann abgespeichert werden.
+- Nun können Sie den Fachdatensatz gegen das vorliegende Fachschema "S00000092V1.0_xfall.xsd" prüfen.
+
+### Details zur Prüfung eines XÖV Fachdatensatzes {#xoev}
+
+Die XÖV Standards werden im [XRepository](https://www.xrepository.de/) abgelegt.
+Auf die Inhalte des XRepository kann über eine [REST-API](https://www.xrepository.de/cms/hilfe.html#rest-api) zugegriffen werden.
+Entnehmen Sie der Fachschemareferenz die Angabe `schemaURI`. Diese besteht aus zwei durch ein Doppelkreuz (#) getrennten Teilen. Vor dem Doppelkreuz steht die Kennung, dahinter der Name der Nachricht.
+Um z.B. einen Bauantrag zu prüfen, gehen Sie wie folgt vor.
+- Im Metadatensatz finden Sie folgende Fachschemareferenz.
+
+```json
+"contentStructure": {
+ "data": {
+ "schema": {
+ "schemaURI": "urn:xoev-de:bmk:standard:xbau_2.2#baugenehmigung.antrag.0200",
+ "mimeType": "application/xml"
+ }
+ }
+}
+```
+
+- Die `schemaURI` enthält folgende Angaben:
+ - Kennung: `urn:xoev-de:bmk:standard:xbau_2.2`
+ - Nachrichtenname `baugenehmigung.antrag.0200`
+- Laden Sie das XML Schema herunter und entpacken Sie es.
+
+```
+➜ wget -nv -O xmlschema.zip https://www.xrepository.de/api/version_standard/urn:xoev-de:bmk:standard:xbau_2.2/xmlschema
+2021-06-25 15:17:54 URL:https://www.xrepository.de/api/version_standard/urn:xoev-de:bmk:standard:xbau_2.2/xmlschema [278585] -> "xmlschema.zip" [1]
+```
+
+```
+➜ unzip xmlschema.zip
+Archive: xmlschema.zip
+ inflating: xsd.zip
+ inflating: xsd_dev.zip
+```
+
+- Im Falle von XBau 2.2 enthält das XML-Schema zwei Dateien. Enpacken Sie die Datei `xsd.zip`. Dieser Schritt ist XBau-spezifisch und muss bei anderen Standards angepasst werden.
+
+```
+➜ unzip xsd.zip
+Archive: xsd.zip
+ inflating: xbau-basisdatentypen.xsd
+ inflating: xbau-baukasten.xsd
+ inflating: xbau-codes.xsd
+ inflating: xbau-nachrichten-abweichung.xsd
+ inflating: xbau-nachrichten-anzeige.xsd
+ inflating: xbau-nachrichten-baugenehmigung.xsd
+ inflating: xbau-nachrichten-baulasten.xsd
+ inflating: xbau-nachrichten-bautechnischeNachweise.xsd
+ inflating: xbau-nachrichten-bauzustand.xsd
+ inflating: xbau-nachrichten-beteiligung.xsd
+ inflating: xbau-nachrichten-genehmigungsfreistellung.xsd
+ inflating: xbau-nachrichten-informationsempfaenger.xsd
+ inflating: xbau-nachrichten-kammernverzeichnis.xsd
+ inflating: xbau-nachrichten-teilbaugenehmigung.xsd
+ inflating: xbau-nachrichten-ueberwachungspflichtigeAnlagen.xsd
+ inflating: xbau-nachrichten-vorbescheid.xsd
+ inflating: xbau-prozessnachrichten.xsd
+```
+
+- Suchen Sie nun nach der Datei, die die Elementdefinition der geforderten Nachricht enthält.
+
+```
+➜ grep -l 'name=.baugenehmigung.antrag.0200' *.xsd
+xbau-nachrichten-baugenehmigung.xsd
+```
+
+- Nun können Sie den Fachdatensatz gegen das vorliegende Fachschema "xbau-nachrichten-baugenehmigung.xsd" prüfen.
diff --git a/versioned_docs/version-0.14/getting-started/sending/attachments.mdx b/versioned_docs/version-0.14/getting-started/sending/attachments.mdx
new file mode 100644
index 0000000000000000000000000000000000000000..d2d6a9f092b2f549bbe61f315053a5596e8b492e
--- /dev/null
+++ b/versioned_docs/version-0.14/getting-started/sending/attachments.mdx
@@ -0,0 +1,78 @@
+---
+title: Anlagen
+sidebar_position: 5
+---
+
+import Tabs from '@theme/Tabs'
+import TabItem from '@theme/TabItem'
+
+Anlagen sind Bestandteil einer Einreichung, die nicht zwingend maschinenlesbar oder an Standards geknüpft sind.
+Sie können beim Anlegen einer Einreichung mit angekündigt und dann im weiteren Verlauf hochgeladen werden.
+
+In dem folgenden Ausschnitt wird dargestellt, wie eine bereits verschlüsselte Datei an eine Einreichung angehängt und hochgeladen werden kann.
+
+<Tabs
+ defaultValue="curl"
+ values={[
+ { label: 'curl', value: 'curl', },
+ { label: 'JavaScript', value: 'js', },
+ { label: 'Java (Spring)', value: 'java', },
+ { label: 'C#', value: 'csharp', },
+ ]
+}>
+<TabItem value="curl">
+
+ ```bash
+ $ export SERVICE_URL=...
+ $ export JWT_TOKEN=eyJhbGciOiJIUzI1NiJ9.eyJJc3N1Z...NL-MKFrDGvn9TvkA
+ $ export SUBMISSION_ID=63f0c991-0635-4e18-8a4b-fb0c01de9f5c
+ $ export ATTACHMENT_ID=90ae8309-2102-4e81-a325-ceda480d0e9d
+ $ export ENC_FILE_CONTENT=6r4H2H_WIzCv8Pd-uetmcbK...iVBKF3ylHRUahmZ
+ $ curl \
+ -H "Authorization: Bearer $JWT_TOKEN" \
+ -H "Content-Type: application/jose" \
+ --data "$ENC_FILE_CONTENT" \
+ -X PUT $SERVICE_URL/submissions/$SUBMISSION_ID/attachments/$ATTACHMENT_ID
+ ```
+
+</TabItem>
+<TabItem value="js">
+
+ ```js
+ import axios from 'axios'
+
+ const baseUrl=...
+ const token="eyJhbGciOiJIUzI1NiJ9.eyJJc3N1Z...NL-MKFrDGvn9TvkA"
+ const submissionId="63f0c991-0635-4e18-8a4b-fb0c01de9f5c"
+ const attachmentId="90ae8309-2102-4e81-a325-ceda480d0e9d"
+ const data="6r4H2H_WIzCv8Pd-uetmcbK...iVBKF3ylHRUahmZ"
+
+ axios.put(
+ `/submissions/${submissionId}/attachments/${attachmentId}`,
+ data
+ {
+ baseURL,
+ timeout: 2000,
+ headers: {
+ 'Content-Type': 'application/jose',
+ 'Authorization': `Bearer ${token}`,
+ }
+ }
+ )
+ ```
+
+
+</TabItem>
+
+<TabItem value="java">
+ ```java
+ // TBD
+ ```
+</TabItem>
+
+<TabItem value="csharp">
+ ```java
+ // TBD
+ ```
+</TabItem>
+</Tabs>
diff --git a/versioned_docs/version-0.14/getting-started/sending/encrypt.mdx b/versioned_docs/version-0.14/getting-started/sending/encrypt.mdx
new file mode 100644
index 0000000000000000000000000000000000000000..fde30879e423ae56383c8768042bfa55ab525fa2
--- /dev/null
+++ b/versioned_docs/version-0.14/getting-started/sending/encrypt.mdx
@@ -0,0 +1,175 @@
+---
+title: Verschlüsseln
+sidebar_position: 4
+---
+
+import Tabs from '@theme/Tabs'
+import TabItem from '@theme/TabItem'
+
+Über FIT-Connect versendete Daten sind oft schützenswert und müssen daher verschlüsselt werden.
+
+Eine Übertragung über FIT-Connect besteht aus
+
+* einem Metadatensatz
+* einem Fachdatensatz (optional)
+* beliebig vielen Anlagen (optional)
+
+Alle drei Datensatzarten müssen mit [JSON Web Encryption (JWE)](https://tools.ietf.org/html/rfc7516) verschlüsselt und mit [JWE-Compact Serialisierung](https://tools.ietf.org/html/rfc7516#section-7.1) serialisiert werden.
+Dokumente müssen als Binärdateien und nicht als Zeichenketten kodiert verschlüsselt werden.
+
+Der [vorher abgerufene Zustellpunkt](./get-destination.mdx#informationen-des-zustellpunktes-erhalten) beinhaltet die Schlüssel-ID des Verschlüsselungsschlüssels unter dem Feld `encryptionKid`.
+Damit können wir den JWK des Zustellpunktes abrufen um Daten zu verschlüsseln.
+
+```shell title="Beispiel: Abruf des JWK eines Zustellpunktes"
+$ KID=... # Wert des Feldes `encryptionKid`
+$ SERVICE_URL=...
+$ DESTINATION_ID=...
+$ curl -X GET \
+ "$SERVICE_URL/destinations/$DESTINATION_ID/keys/$KID"
+---
+{
+ "kty": "RSA",
+ "e": "AQAB",
+ "keyops": ["wrapKey"],
+ "x5c": [
+ "LS0tLS1CRUdJTiBDRVJU...jN1NGKzQKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo="
+ ],
+ "x5t": "MTg6NTU6RUY6ME...MEM6QzM6ODQ6QjA6MkE6RkMK",
+ "kid": "787f3a1c-7da7-44d7-9b79-9783b1ea9be8",
+ "alg": "RSA-OAEP-256",
+ "n": "sX2DX7rG5BoJd23...FlxHZt8T6ZqjRa1QcFnkq3_M4-tk"
+}
+```
+
+Mit diesem Schlüssel könnten jetzt die oben genannten Datenssätze verschlüsselt werden.
+Die so verschlüsselten Daten können ausschließlich von diesem Zustellpunkt gelesen werden.
+
+Bevor wir mit der Verschlüsselung loslegen können müssen wir den eben abgerufenen JWK noch auf Gültigkeit überprüfen.
+
+## Überprüfen des öffentlichen Schlüssel (Zertifikatsprüfung)
+
+:::note Hinweis
+In der Testumgebung ist die Absicherung der öffentlichen Schlüssel eines Zustellpunktes durch Zertifikate optional.
+Eine Prüfung der Zertifikate kann in diesem Fall zu Testzwecken entfallen.
+:::
+
+JWKs MÜSSEN vor der Verwendung zwingend im Client auf Gültigkeit geprüft werden. Diese Prüfung umfasst folgende Schritte:
+
+- Überprüfung, dass der JSON Web Key für die Verschlüsselung geeignet ist (`"keyops": ["wrap_key"]`)
+- Überprüfung, dass der öffentliche Schlüssel mit dem im JSON Web Key hinterlegten Zertifikat übereinstimmt (Attribute `n` und `e`)
+- Überprüfung der Zertifikats-Kette bis zum Wurzelzertifikat (BSI)
+- Überprüfung gegen eine Certificate Revocation List und/oder einen OCSP-Endpunkt mit signierten Antworten
+
+Weitere Informationen zur Gültigkeitsprüfung finden sich in der technischen Richtlinie [BSI TR-02103](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02103/BSI-TR-02103.pdf?__blob=publicationFile&v=4) des BSI.
+
+:::note Hinweis
+An dieser Stelle werden noch detailliertere Informationen und konkrete Implementierungsbeispiele zur Prüfung der JSON Web Keys ergänzt.
+:::
+
+## Nutzung von JSON Web Keys zur Verschlüsselung
+
+<Tabs
+ defaultValue="js"
+ values={[
+ { label: 'JavaScript', value: 'js', },
+ { label: 'Java', value: 'java', },
+ ]
+}>
+<TabItem value="js">
+
+Die Umwandelung des JWK in eine Struktur, die für die Bibliothek [panva/jose](https://github.com/panva/jose) nutzbar ist, kann mithilfe einer Methode aus dieser Bibliothek durchgeführt werden.
+
+```js
+import { parseJwk } from "jose/jwk/parse"
+import { CompactEncrypt } from "jose/jwe/compact/encrypt"
+
+const publicKey = await parseJwk({
+ "kty": "RSA",
+ "e": "AQAB",
+ "keyops": ["wrapKey"],
+ "x5c": [
+ "LS0tLS1CRUd...LS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo="
+ ],
+ "x5t": "MTg6NTU6RUY6ME...M6MEM6QzM6ODQ6QjA6MkE6RkMK",
+ "kid": "787f3a1c-7da7-44d7-9b79-9783b1ea9be8",
+ "alg": "RSA-OAEP-256",
+ "n": "sX2DX7rG5BoJd23A0...6ZqjRa1QcFnkq3_M4-tk"
+})
+```
+
+## Verschlüsselung von Inhaltsdaten
+Mit dem zuvor eingelesenen Schlüssel können nun Zeichenketten und Binärdaten verschlüsselt werden.
+
+Für die verschlüsselung von Zeichenketten (z.B. serialisierte JSON- oder XML-Objekte) kann die in Browser verfügbare [TextEncoder-API](https://developer.mozilla.org/en-US/docs/Web/API/TextEncoder) verwendet werden, die den String UTF8-kodiert in ein `Uint8Array` umwandelt.
+
+```javascript
+const data = {
+ config: 'option1',
+ age: 42
+}
+
+const encodedText = new TextEncoder().encode(JSON.stringify(data))
+const encryptedText = await new CompactEncrypt(encodedText)
+ .setProtectedHeader({ alg: "RSA-OAEP-256", enc: "A256GCM" })
+ .encrypt(publicKey)
+```
+
+Anhänge wie PDF-Dateien, Bilder o. ä. liegen meist in einem `Uint8Array` vor bzw. können einfach darin umgewandelt werden.
+Im Folgenden Beispiel wird eine Datei aus einem HTML-File-Input direkt heraus verschlüsselt.
+
+```javascript
+// .arrayBuffer() => https://developer.mozilla.org/en-US/docs/Web/API/Blob/arrayBuffer
+// Verschlüsselung der ersten Datei aus einem Datei-Input: <input type="file" id="my-file-input" />
+const buffer = await document.getElementById("my-file-input").files[0].arrayBuffer()
+const encryptedText = await new CompactEncrypt(buffer)
+ .setProtectedHeader({ alg: "RSA-OAEP-256", enc: "A256GCM" })
+ .encrypt(publicKey)
+```
+
+</TabItem>
+<TabItem value="java">
+
+Wenn ein sendendes System Daten einer Einreichung verschlüsseln möchte, kann es dies mithilfe der Java-Bibliothek [`nimbus-jose-jwt`](https://connect2id.com/products/nimbus-jose-jwt) durchführen.
+
+```xml
+<dependency>
+ <groupId>com.nimbusds</groupId>
+ <artifactId>nimbus-jose-jwt</artifactId>
+ <version>9.X.X</version>
+</dependency>
+```
+
+Da in FIT-Connect ausschließlich RSA-Schlüssel erlaubt sind, muss der RSAKey-Parser aus der Bibliothek verwendet werden, um den JWK einzulesen.
+
+```java
+// ⤹ InputStream
+String publicKeyAsString = new String(existingPublicKey.readAllBytes());
+RSAKey publicKey = RSAKey.parse(publicKeyAsString).toRSAPublicKey();
+```
+
+Mit diesem umgewandelten Schlüssel können nun Zeichenketten und Binärdaten verschlüsselt werden.
+Über die [Payload-Klasse](https://www.javadoc.io/doc/com.nimbusds/nimbus-jose-jwt/latest/com/nimbusds/jose/Payload.html) können verschiedene Typen, wie `byte[]` oder `String`, verschlüsselt werden.
+
+```java
+JWEHeader header = new JWEHeader(JWEAlgorithm.RSA_OAEP_256, EncryptionMethod.A256GCM);
+
+// Zeichenkette
+Payload payload = new Payload("{ \"Hello\": \"World\"}");
+
+// InputStream (z.B. für Datei)
+Payload payload = new Payload(aFileInputStream.readAllBytes());
+
+JWEObject jweObject = new JWEObject(header, payload);
+
+try {
+ jweObject.encrypt(new RSAEncrypter(publicKey));
+ String encrypted = jweObject.serialize();
+
+ System.out.println("Encrypted Text");
+ System.out.println(encrypted);
+} catch (JOSEException e) {
+ e.printStackTrace();
+}
+```
+</TabItem>
+</Tabs>
diff --git a/versioned_docs/version-0.14/getting-started/sending/get-destination.mdx b/versioned_docs/version-0.14/getting-started/sending/get-destination.mdx
new file mode 100644
index 0000000000000000000000000000000000000000..09b063bae7db3fa408c000b0d6b29cdc56834f30
--- /dev/null
+++ b/versioned_docs/version-0.14/getting-started/sending/get-destination.mdx
@@ -0,0 +1,70 @@
+---
+sidebar_position: 2
+title: Zustellpunkt ermitteln
+---
+
+import Tabs from '@theme/Tabs'
+import TabItem from '@theme/TabItem'
+import ApiLink from '@site/src/components/ApiLink'
+
+## Zustellpunkt und `destinationId` ermitteln
+
+Um eine Einreichung an die fachlich korrekte Stelle sicherzustellen und die technischen Parameter des richtigen Zustellpunkt zu ermitteln, muss die `destinationId` der zuständigen Stelle ermittelt werden. Zukünftig wird die Ermittlung der `destinationId` und die Ermittlung der technischen Parameter über die FIT-Connect Routing API möglich sein. Sobald die Routing API umgesetzt ist (voraussichtlich Ende Q3 2021), wird diese Möglichkeit hier beschrieben.
+
+## Informationen des Zustellpunktes erhalten
+
+Um an einen Zustellpunkt eine Einreichung korrekt zu übermitteln, ist es notwendig, die im Zustellpunkt hinterlegten technischen Parameter für die Einreichung zu ermitteln.
+Diese Informationen sind:
+- Die Verwaltungsleistungen (`services`), die über diesen Zustellpunkt abgebildet werden, bestehend aus:
+ - einem Identifikator der Verwaltungsleitung (`identifier`): Typischerweise entspricht dieser einem LeiKa-Schlüssel (siehe [Leistungskatalog im FIM-Portal](https://fimportal.de/kataloge#download-leistungen)).
+ - einer Liste an zulässigen Fachdatenschemata (`submissionSchemas`): Hiermit legt das empfangende System fest, welchem Schema die übergebenen Fachdatensätze entsprechen müssen. Welches der angebenen Schemata verwendet werden muss, bestimmt das sendende System aus dem eigenen fachlichen Kontext heraus. Wenn bspw. ein Antrag für einen Schwerbehindertenausweis gestellt wird, muss der Fachdatensatz aus den dort hinterlegten Schemata gemäß dem dortigen Schema für den Schwerbehindertausweis (bspw. ein FIM/XFall Schema) entsprechen.
+ - einer Liste an Regionen (`regions`), für die die Verwaltungsleistung angeboten wird.
+- Schlüssel-ID des öffentlichen Verschlüsselungsschlüssels (`encryptionKid`): Empfangende Systeme veröffentlichen die Schlüssel-ID ihres Verschlüsselungsschlüssels für die Verschlüsselung von Einreichungen. Der dazugehörige JSON Web Key (JWK) kann anschließend über den Endpunkt <ApiLink to="/destinations/{destinationId}/keys/{keyId}" /> abgefragt werden.
+
+:::caution Hinweis
+Der Mechanismus zum Abruf der Verschlüsselungsschlüssel wird sich bis zur Veröffentlichung der finalen API-Spezifikation noch einmal ändern.
+:::
+
+Zum Abruf der Zustellpunkt-Informationen stellt die Submission API einen Endpunkt bereit, der über Angabe des Parameters `destinationId` die technischen Parameter der Einreichung für den jeweiligen Zustellpunkt ausgibt.
+
+<Tabs
+ defaultValue="curl"
+ values={[
+ { label: 'curl', value: 'curl', },
+ ]
+ }>
+<TabItem value="curl">
+
+Über `curl` können diese Information mit dem Folgenden Aufruf erhalten werden.
+
+```bash
+$ export SERVICE_URL=...
+$ export JWT_TOKEN=eyJhbGciOiJIUzI1NiJ9.eyJJc3N1Z...NL-MKFrDGvn9TvkA
+$ export DESTINATION_ID=7a2668ad-3081-407c-9358-7ce4b6144b02
+$ curl \
+ -H "Authorization: Bearer $JWT_TOKEN" \
+ -H "Content-Type: application/json" \
+ -X GET $SERVICE_URL/destinations/$DESTINATION_ID
+
+> {
+ "destinationId": "7881dba9-4055-4854-8b6d-11ea5b7f3047",
+ "services": [
+ {
+ "identifier": "urn:de:fim:leika:leistung:99010003001006",
+ "submissionSchemas": [
+ {
+ "schemaURI": "https://schema.fitko.de/fim/s00000121_1.0.0.schema.json",
+ "mimeType": "application/json"
+ }
+ ],
+ "regions": [
+ "DE094750156156",
+ "DE09330411"
+ ]
+ }
+ ],
+ "encryptionKid": "c66e4423-e28d-4a1f-911d-818f9ab60221"
+}
+```
+</TabItem>
+</Tabs>
diff --git a/versioned_docs/version-0.14/getting-started/sending/metadata.mdx b/versioned_docs/version-0.14/getting-started/sending/metadata.mdx
new file mode 100644
index 0000000000000000000000000000000000000000..b164b11eb75865c88cac756e45d48dfb9a072cba
--- /dev/null
+++ b/versioned_docs/version-0.14/getting-started/sending/metadata.mdx
@@ -0,0 +1,83 @@
+---
+title: Metadatensatz
+sidebar_position: 7
+---
+
+Die Antragsmetadaten beschreiben die Struktur der Einreichung und dessen Inhalte, wie beispielsweise Anhänge oder die
+Fachdaten. Zusätzlich können weitere Informationen über Verwaltungskund:innen hinterlegt werden. Eine genaue Definition
+ist in der [Schema-Beschreibung](../../apis/metadata.mdx) zu finden. Im Folgenden wird nun beschrieben, wie für das
+Versenden einer Einreichung das Schema aufgebaut und befüllt wird.
+
+Das Minimum, was an Information in den Metadaten vorhanden sein muss, sind die Felder `authenticationInformation` und `contentStructure`.
+In der Beschreibung der Struktur (`contentStructure`) muss angegeben werden, ob und in welchem Format ein Fachdatensatz
+mit versendet wird. Des Weiteren können Anhänge mit ihren Metainformationen beschrieben werden, die der Einreichung
+beigefügt sind. Sollte ein Rückkanal gewünscht sein oder Bezahlinformationen notwendig sein, können die weiteren Felder,
+die im Metadatenschema definiert sind, befüllt und mitversendet werden. Ob diese jedoch ausgewertet werden oder nicht
+hängt u. a. von der vom Empfängers unterstützten Version des Metadatenschemas ab.
+
+Ein Beispiel für das Metadatenschema eines Kindergeldantrags ist unten dargestellt:
+
+```json
+{
+ "$schema": "https://schema.fitko.de/fit-connect/metadata/0.9.2/metadata.schema.json",
+ "authenticationInformation": [
+ {
+ "type": "identificationReport",
+ "content": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXBvcnRJRCI6ImJlNGY5ODA2LTBiNWYtNDVjMy1hMDA4LTk2ZmQyNzUwZjhjYiIsInNlcnZlcklkZW50aXR5IjoiaHR0cHM6Ly90ZXN0LmdvdmVybmlrdXMtZWlkLmRlL2dvdl9hdXRlbnQvYXN5bmMiLCJyZXBvcnRUaW1lIjoiMjAyMC0wNi0yNVQxMDoyMDozOSswMjowMCIsImlkZW50aWZpY2F0aW9uRGF0ZSI6IjIwMjAtMDYtMjVUMTA6MTk6NTQrMDI6MDAiLCJpZFN0YXR1cyI6InN1Y2Nlc3MiLCJzdWJqZWN0UmVmIjp7ImZpcnN0TmFtZSI6IkpvaG4iLCJsYXN0TmFtZSI6IkRvZSJ9LCJjb250ZXh0SW5mb3JtYXRpb24iOlsiQW50cmFnIGF1ZiBLaW5kZXJnZWxkOiAwODE1Lzc2Mzc2MyJdLCJpZFN0YXRlbWVudCI6InN1Y2Nlc3NmdWwgaWRlbnRpZmljYXRpb24gc2VudCBieSBTQU1MLUFzc2VydGlvbiIsImRvY3VtZW50UmVmZXJlbmNlcyI6W3siZG9jdW1lbnROYW1lIjoidGVzdC5wZGYiLCJoYXNoQWxnbyI6IlNIQS0yNTYiLCJkaWdlc3QiOiIwYzI3MjA2MzFiOTI3ZTI1ZDVjYjhiNWNhMmI5NDA4YzU1MmVhNzY3OTdlMzQxOTI0NTkzMTI5NjczMmZkMGQyIn1dLCJsb2FTZW50IjoiaHR0cDovL2VpZGFzLmV1cm9wYS5ldS9Mb0EvbG93In0.t4meB51GeSPSSlQ_tvamSE9FmMD5O9HBJw0oo6iTaSjEsq4rLJ27uqcEp9l4VBleH5JW7p-Tu0qf0DuySdznTxj7iSbl43h0geLMzy2NgwMlBhu4U1-sorlqAsxRjIFDvY2z-RD1D1kqqVTtf2FJWQ5tOJ70hHEiZOtVYNjKdn_tZe2nD54KbzujIg4jW36P17wivZ6vCjagk6VjJk4LWhCO-T5L13RXR5jgq14TMCu5DFhdPA8b7v4iShD5j12Z3WBCqRCb2UWCoLtHs7nPDQ8facxymFMDGm8RQineU18OtgTClkmq4JyifNRWN6jYlPMmvQN499wfkf7VlJ8_OQ"
+ },
+ {
+ "type": "identificationReport",
+ "content": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJyZXBvcnRJRCI6ImJlNGY5ODA2LTBiNWYtNDVjMy1hMDA4LTk2ZmQyNzUwZjhjYiIsInNlcnZlcklkZW50aXR5IjoiaHR0cHM6Ly90ZXN0LmdvdmVybmlrdXMtZWlkLmRlL2dvdl9hdXRlbnQvYXN5bmMiLCJyZXBvcnRUaW1lIjoiMjAyMC0wNi0yNVQxMDoyMDozOSswMjowMCIsImlkZW50aWZpY2F0aW9uRGF0ZSI6IjIwMjAtMDYtMjVUMTA6MTk6NTQrMDI6MDAiLCJpZFN0YXR1cyI6InN1Y2Nlc3MiLCJzdWJqZWN0UmVmIjp7ImZpcnN0TmFtZSI6IkpvaG4iLCJsYXN0TmFtZSI6IkRvZSJ9LCJjb250ZXh0SW5mb3JtYXRpb24iOlsiQW50cmFnIGF1ZiBLaW5kZXJnZWxkOiAwODE1Lzc2Mzc2MyJdLCJpZFN0YXRlbWVudCI6InN1Y2Nlc3NmdWwgaWRlbnRpZmljYXRpb24gc2VudCBieSBTQU1MLUFzc2VydGlvbiIsImRvY3VtZW50UmVmZXJlbmNlcyI6W3siZG9jdW1lbnROYW1lIjoidGVzdC5wZGYiLCJoYXNoQWxnbyI6IlNIQS0yNTYiLCJkaWdlc3QiOiIwYzI3MjA2MzFiOTI3ZTI1ZDVjYjhiNWNhMmI5NDA4YzU1MmVhNzY3OTdlMzQxOTI0NTkzMTI5NjczMmZkMGQyIn1dLCJsb2FTZW50IjoiaHR0cDovL2VpZGFzLmV1cm9wYS5ldS9Mb0EvbG93In0.t4meB51GeSPSSlQ_tvamSE9FmMD5O9HBJw0oo6iTaSjEsq4rLJ27uqcEp9l4VBleH5JW7p-Tu0qf0DuySdznTxj7iSbl43h0geLMzy2NgwMlBhu4U1-sorlqAsxRjIFDvY2z-RD1D1kqqVTtf2FJWQ5tOJ70hHEiZOtVYNjKdn_tZe2nD54KbzujIg4jW36P17wivZ6vCjagk6VjJk4LWhCO-T5L13RXR5jgq14TMCu5DFhdPA8b7v4iShD5j12Z3WBCqRCb2UWCoLtHs7nPDQ8facxymFMDGm8RQineU18OtgTClkmq4JyifNRWN6jYlPMmvQN499wfkf7VlJ8_OQ"
+ }
+ ],
+ "contentStructure": {
+ "data": {
+ "submissionSchema": {
+ "schemaURI": "urn:de:fim:leika:leistung:a38",
+ "mimeType": "application/json"
+ }
+ },
+ "attachments": [
+ {
+ "attachmentId": "8a603c7a-ce54-45d1-90a7-bbeae09c5e50",
+ "purpose": "form",
+ "mimeType": "application/pdf"
+ },
+ {
+ "attachmentId": "706f5a33-c019-4062-bd21-23b3e72a4d09",
+ "purpose": "attachment",
+ "mimeType": "application/pdf",
+ "filename": "Kopie Personalausweis Ezb 1",
+ "signature": {
+ "type": "cms"
+ }
+ },
+ {
+ "attachmentId": "d0433493-6ee0-4e03-97d9-e4016a43a327",
+ "purpose": "attachment",
+ "mimeType": "application/pdf",
+ "description": "Eine Kopie eines Personalausweises, Vorder- und Rückseite.",
+ "filename": "Personalausweis Ezb 2"
+ }
+ ]
+ },
+ "paymentInformation": {
+ "transactionUrl": "https://payment.bundesland.zzzz/api/v1/paymenttransaction/12002312/MELD-ANT-FORM-4711/2ec6dad2-5606-4a85-82bc-19521ed5e192",
+ "transactionRedirectUrl": "https://portal.bundesland.zzzz/ui/doPayment/2ec6dad2-5606-4a85-82bc-19521ed5e192-CHECKSUM",
+ "transactionReference": "KA-2021-5678",
+ "transactionId": "2ec6dad2-5606-4a85-82bc-19521ed5e192",
+ "paymentMethod": "PAYPAL",
+ "status": "BOOKED"
+ },
+ "publicServiceType": {
+ "name": "Kindergeld",
+ "identifier": "urn:de:fim:leika:leistung:a38"
+ },
+ "replyChannel": {
+ "eMail": {
+ "address": "ezb1@mail-provider.magic",
+ "pgpPublicKey": "-----BEGIN PGP PUBLIC KEY BLOCK-----\n\n"
+ }
+ }
+}
+```
diff --git a/versioned_docs/version-0.14/getting-started/sending/overview.mdx b/versioned_docs/version-0.14/getting-started/sending/overview.mdx
new file mode 100644
index 0000000000000000000000000000000000000000..29a991cce1d3f0f0418920462372f57f1499d38a
--- /dev/null
+++ b/versioned_docs/version-0.14/getting-started/sending/overview.mdx
@@ -0,0 +1,37 @@
+---
+sidebar_position: 1
+title: Ãœberblick
+---
+
+import Tabs from '@theme/Tabs'
+import TabItem from '@theme/TabItem'
+import Mermaid from '@site/src/components/Mermaid'
+
+Bei einer Einreichung z. B. eines Antrags reicht ein Onlineservice im Namen und Auftrag eines Endnutzers Fachdaten und/oder Anlagen bei einem Zustellpunkt ein.
+Hierfür benötigt der Onlinedienst die öffentlich verfügbaren Informationen eines Zustellpunktes, wie beispielsweise die Zustellpunkt-Id (`destinationId`) oder den JWK des Zustellpunktes.
+Wie man an diese Informationen gelangt ist unter [Zustellpunkt ermitteln](get-destination.mdx) genauer beschrieben.
+
+:::caution
+Wie der Zustellpunkt der zuständigen empfangenden Stelle technisch ermittelt wird, wird aktuell noch nicht beschrieben. Die Ermittelung wird zukünftig über die Routing API ermöglicht, die sich aktuell noch in der Umsetzung (voraussicht bis Ende Q3 2021) befindet. Sobald Routing API spezifiziert ist und technisch bereitsteht, wird die Ermittlung des korrekten Zustellpunkt über die Routing API hier beschrieben. Bis dahin wird davon ausgegangen, dass der Zustellpunkt bzw. deren `destinationId` über einem bilateralen Mechanismus in Erfahrung gebracht wird.
+:::
+
+FIT-Connect möchte einen sehr sicheren Übermittlungsweg bereitstellen, weswegen alle Daten immer vom Browser des Users bis in die Behörde Ende-zu-Ende-Verschlüsselt übertragen werden müssen.
+Das dafür benötigte Schlüsselmaterial wird auch über die Submission API und Routing API bereitgestellt und der Umgang damit im Weiteren erklärt.
+
+Während der Einreichung erhält man von der API eine `submissionId`, mithilfe welcher man nach der Abgabe den Event Log der Einreichung abrufen kann.
+Dieser Event Log enthält eine Liste von Ereignissen, ähnlich wie im Interface einer Paketverfolgung, mit denen der aktuelle Zustellungsstatus der Einreichung transparent wird.
+
+## Prozessablauf
+
+<Mermaid>
+sequenceDiagram;
+ participant C as Client;
+ participant F as FIT Connect;
+ C->>F: Einreichung anlegen & ankündigen;
+ C->>C: Anlagen verschlüsseln;
+ C->>F: Anlagen hochladen;
+ C->>C: Metadaten befüllen & verschlüsseln;
+ C->>C: Fachdaten verschlüsseln;
+ C->>F: Fachdaten & Metadaten hochladen und Einreichung absenden;
+</Mermaid>
+
diff --git a/versioned_docs/version-0.14/getting-started/sending/query-status.mdx b/versioned_docs/version-0.14/getting-started/sending/query-status.mdx
new file mode 100644
index 0000000000000000000000000000000000000000..a4fc50e72444567d84f332ad7d31b1afc6fa6bf0
--- /dev/null
+++ b/versioned_docs/version-0.14/getting-started/sending/query-status.mdx
@@ -0,0 +1,71 @@
+---
+title: Status abfragen
+sidebar_position: 9
+---
+
+import ApiLink from '@site/src/components/ApiLink'
+
+Nachdem die Einreichung versendet worden ist, kann der Status dieser abgefragt werden.
+Der Status ist für das sendende System relevant, da hierüber das empfangende System mitteilt, ob es die Einreichung technisch korrekt verarbeiten konnte.
+Bis zu einer Bestätigung über den Status *Accepted* sollte das System sämtliche Inhalte einer Einreichung vorhalten.
+Dies sollte es tun, damit es im Falle eines Fehlers (aufgrund eines inkorrekten Schemas oder eines falschen Public Keys), den Fehler eventuell korrigieren kann und Informationen korrekt übermitteln kann, ohne den Nutzer (bspw. einen Antragssteller) zu einer erneuten Dateneingabe aufzufordern.
+
+Zudem stellt der Status in Form des signierten Security-Event-Tokens einen sicheren Nachweis der Übermittlung und des Empfangs dar, der gegenüber Dritten genutzt werden kann.
+
+Das Statusmodell einer Einreichung ist in der folgenden Grafik dargestellt und enthält fünf Zustände (in orange), die in der darunterliegenden Tabelle beschrieben sind.
+
+
+
+| Status | Bedeutung |
+|---------------|---------------------------------------------------------------------------------------------------------|
+| `incomplete` | Das sendende System hat begonnen, die Einreichung zu übermitteln. Sie jedoch noch nicht abgesendet. |
+| `submitted` | Das sendende System hat die Einreichung vollständig übermittelt und abgesendet. |
+| `forwarded` | Ein vermittelndes System hat die Einreichung übernommen, sie aber noch nicht dem Zielsystem zugestellt. |
+| `rejected` | Die Einreichung wurde durch den Empfänger zurückgewiesen. |
+| `accepted` | Die Einreichung wurde durch den Empfänger akzeptiert. |
+
+Der Status wird über <ApiLink to="/submissions/{submissionId}/events" /> abgefragt.
+Hierbei wird der Event Log der Einreichung zurückgeliefert, der die verschiedenen Statusübergänge bzw. abgelegten Ereignisse beinhaltet.
+Das Ergebnis könnte wie folgt aussehen:
+
+```json
+{
+ "eventLog": [
+ "eyJraWQiOiJkZDA0MDllNS00MTBlLTRkOTgtODViNi1mODFhNDBiOGQ5ODAiLCJ0eXAiOiJzZWNldmVudCtqd3QiLCJhbGciOiJQUzUxMiJ9.ewogICJpc3MiOiAiaHR0cHM6Ly9hcGkuZml0a28uZGUvZml0LWNvbm5lY3QvIiwKICAiaWF0IjogMTYyMjc5NDMxOSwKICAianRpIjogIkVEQ0ZCRjIxLTVCMTYtNEQwNi05OUQwLURDNEMyNkY0RkI5RSIsCiAgInN1YiI6ICJzdWJtaXNzaW9uOkY2NUZFQUIyLTQ4ODMtNERGRi04NUZCLTE2OTQ0ODU0NUQ5RiIsCiAgImV2ZW50cyI6IHsKICAgICJodHRwczovL3NjaGVtYS5maXRrby5kZS9maXQtY29ubmVjdC9ldmVudHMvY3JlYXRlLXN1Ym1pc3Npb24iOiB7fQogIH0sCiAgInR4biI6ICJjYXNlOkY3M0QzMEM2LTg4OTQtNDQ0NC04Njg3LTAwQUU3NTZGRUE5MCIKfQ.TQBR_CBsoULi3cGaGg4oqFelQ9GVn8G-cNokzTVDZgZf4D7x_8wjsDcgTd0aamiy8ErlnV1xoAoDcPw81vajrBCaYgf9KI4sNhsW78jlDi_ywK04YhFbkvloDMioGf_5zCNTBreN9bTnU_VYuWB23R_YrYGi2exONft-ZReN_crEvDaKLdG9hqnaCRFwKJ1t8TbLvIyBKLqQYEqP0Oh6m3WA9IRz3EB41S-PZgJCIzmz_GvXdRvw_1B8A_Q7aHr2SQ6Dc-c406UJ5P_7FuypE6tLyuYf5GkmFZSauQ51H4LLl8pLrsW2PJJ28cMavOEx0AWoRLwB7yKK5bAGtcALWw-0W7Wmw1QEX3DZGTpXbEUM0U_7iXeEFrdtfCCbFPMVbmlK-b66IyKK_6yeaOAEjQvCUOrALfa2sSOS6RWiNOKyA1l1L29VoIBXgQ8np72NMV8-AP7UnQO1NPBghBM6LW6tcXceWeP8ayy4eEaZQ639pqH4TJRRkQqnuoTeADpYL9sX2hM9173O4abWiE-Z8zW2AQ1jhUvVXJ8w9ddtMIyjZJZOqoy3TbHxUYpn4UqbedlDyahpUiKCT7-qU2jOjeXAXEPQvWlSzLigNtFvYCEq-fOe1lpeNktoQQrC3Y-szk2vNj5fT_KmJY1QG1bhyrUMoGbA-pe45c-FcCE7ErQ",
+ "eyJraWQiOiJkZDA0MDllNS00MTBlLTRkOTgtODViNi1mODFhNDBiOGQ5ODAiLCJ0eXAiOiJzZWNldmVudCtqd3QiLCJhbGciOiJQUzUxMiJ9.ewogICJpc3MiOiAiaHR0cHM6Ly9hcGkuZml0a28uZGUvZml0LWNvbm5lY3QvIiwKICAiaWF0IjogMTYyMjc5NTczMiwKICAianRpIjogIjkwRDlCMjlELUMwNUYtNEYwMy04MUMwLUUyMzMxMTZDNTZEOSIsCiAgInN1YiI6ICJzdWJtaXNzaW9uOkY2NUZFQUIyLTQ4ODMtNERGRi04NUZCLTE2OTQ0ODU0NUQ5RiIsCiAgImV2ZW50cyI6IHsKICAgICJodHRwczovL3NjaGVtYS5maXRrby5kZS9maXQtY29ubmVjdC9ldmVudHMvc3VibWl0LXN1Ym1pc3Npb24iOiB7fQogIH0sCiAgInR4biI6ICJjYXNlOkY3M0QzMEM2LTg4OTQtNDQ0NC04Njg3LTAwQUU3NTZGRUE5MCIKfQ.THmHiZoYEMyyWCu2R4nEJtvgtB5PF0KAqtfu_Z-yVjfjSkXW7TtZnX96UAeCGsjpxkBJvXTXAgSB5n378KjZXebAtI7nbFE0gYgt3fwmxmpJitA-4e8v6KfvhwNcdqJHLKDzYRMq_yw7UiwLx1Cxz6nBiOKfR4piL707muKXTgD7DuP0kv-c6V9dGNQ4KzT_sJP5zDWogEzGWSVaLaJZrmDZHoUZMZ6C9kI7SvC-A7Q0ROkFznU_cpjjEAIG74_YCiICvjr91ueQWTdNyc1DBvxpEBtBWq6nWPTg0d91iQlhPUgNKbmC4QtG_tFctTYhX7stO-JbL-4VnAQjQHD5uw4SvvpPrTN4Z3Wz2IjMm8-ClI9imGKThfAqwTaWtJv7Bn_FDiN_nEuGyN2of-M2vZWa-DlZ2iPFct6ESp9PumaO_pIF5cUrX4IBoe3fcmg788-ClReytCMjD13uPVOVoIb3yimUdupOUROxb3MITowHP2-YG1gWqhQp22XSQXktugDHWezAuN0xuimwAJq_OvyoDxj4lsnn6BQkqZYdqD0hJghwqZIytg8PlIi76Cdvh8NFgVw48xZ0WUOFvBPJO2Qe8PiTSVX_P9CIIWxsKlYwg8vJ226qi0eYfD70ynjBDQIPmsOOSut6bFKgOLBFa9ZvCy6HmhyLa-EsgLhS4uc",
+ "eyJraWQiOiJkZDA0MDllNS00MTBlLTRkOTgtODViNi1mODFhNDBiOGQ5ODAiLCJ0eXAiOiJzZWNldmVudCtqd3QiLCJhbGciOiJQUzUxMiJ9.ewogICJpc3MiOiAiaHR0cHM6Ly9hcGkuZml0a28uZGUvZml0LWNvbm5lY3QvIiwKICAiaWF0IjogMTYyMjc5NjUzMiwKICAianRpIjogIjBCRjZEQkY2LUNFN0UtNDRBMy04ODlGLTgyRkU3NEMzRTcxNSIsCiAgInN1YiI6ICJzdWJtaXNzaW9uOkY2NUZFQUIyLTQ4ODMtNERGRi04NUZCLTE2OTQ0ODU0NUQ5RiIsCiAgImV2ZW50cyI6IHsKICAgICJodHRwczovL3NjaGVtYS5maXRrby5kZS9maXQtY29ubmVjdC9ldmVudHMvYWNjZXB0LXN1Ym1pc3Npb24iOiB7fQogIH0sCiAgInR4biI6ICJjYXNlOkY3M0QzMEM2LTg4OTQtNDQ0NC04Njg3LTAwQUU3NTZGRUE5MCIKfQ.blxz8Tw_Sl8_tomcqxezamX_DVGyGiu61iYGv3mA3yVLLSDlPscjcHm_MCNm5iq-ODUk-FCW1ljOexN2czZJic8wvLhWhcUt8U2kkkjis-CWz4oqhuB4ynAj7Yyn4H4xkLoH7Y6k9pqW9P2mN7984o_578mJJ4mQSNEGcPr_BDbRc2nUKcupG7iS-hx6VTjrRTP7LGPyOblDB8oL_QyT9qY0US7PT35QgiraUSK3RWhDpj6C0I4bOV5cQeSqlXT2xIfeO3sUPeWLYVmGjuB8QWvDsniKz6JqRN-v39FrAppsOufdiRim36wtBZt9o-3txjtz5wu0_eSfjOueGJbfqAeWsbd2TYwZtL-7Z-MPfoe3XInDNmmTfxo4KXkF1GkRnGnjniwrWBHeh18A04NNHYcX-vsoijEreqDN2lEKwks3pDK5Twe5O9RxJ0cYB8oeKB55rJzs15pfla69qVn9zFvCAc_ji_9WaAa_mIG0zimMucG3qA0KrUww88FaS4heh5-Gs1Ik35QoUOCCa7ZMJMKxYArFCgUqHw-gX60U5mp4hy7tVe3hD-RxIRnlTIkEkHgDGmslVc1t8fC9oPgljQirPcTIeWhVyLmk6rJLgR5nqizujz3hDUCdBuRF43fS6qedmYfHq1MyakJzEFe2ht1rpGw4ftAt0kcOBOf2jyQ"
+ ]
+}
+```
+
+Im Log dieser Einreichung wurden drei Events aufgezeichnet.
+Das letzte, aktuellste Security-Event-Token hat folgenden Payload.
+
+```json
+{
+ "iss": "https://api.fitko.de/fit-connect/",
+ "iat": 1622796532,
+ "jti": "0BF6DBF6-CE7E-44A3-889F-82FE74C3E715",
+ "sub": "submission:F65FEAB2-4883-4DFF-85FB-169448545D9F",
+ "events": {
+ "https://schema.fitko.de/fit-connect/events/accept-submission": {}
+ },
+ "txn": "case:F73D30C6-8894-4444-8687-00AE756FEA90"
+}
+```
+
+In dem SET ist folgende Information abgelegt:
+- Er wurde vom Zustelldienst https://api.fitko.de/fit-connect/ ausgestellt (iss = issuer)
+- Er wurde am 04.06.2021 um 08:48:52 GMT+0 (Unixzeit 1622796532) aufgezeichnet (iat = issued at)
+- Er hat die eindeutige ID `0BF6DBF6-CE7E-44A3-889F-82FE74C3E715` (jti = JWT ID)
+- Er betrifft die Einreichung `F65FEAB2-4883-4DFF-85FB-169448545D9F` (sub = subject)
+- Die Submission wurde angelegt "accept-submission" (events)
+- Die Submission gehört zur Vorgangsreferenz (case) `F73D30C6-8894-4444-8687-00AE756FEA90`
+
+Aus dem Event des SET lässt sich ableiten, dass der aktuelle Status der Einreichung `accepted` ist und der Zeitpunkt des Übergangs der 04.06.2021 um 08:48:52 GMT+0 war.
+Da alle SETs im Event Log signiert sind, kann diese Signatur auch noch überprüft werden.
+Die Überprüfung ist im Artikel zum [Event Log](../event-log.mdx#set-validation) beschrieben.
+
+:::caution Hinweis
+Der Mechanismus zum Abrufen von kryptografischen Schlüsseln des empfangenden Systems zur Signaturprüfung wird sich bis zur Veröffentlichung der finalen API-Spezifikation noch einmal ändern.
+:::
\ No newline at end of file
diff --git a/versioned_docs/version-0.14/getting-started/sending/start-submission.mdx b/versioned_docs/version-0.14/getting-started/sending/start-submission.mdx
new file mode 100644
index 0000000000000000000000000000000000000000..d6b8689b2f2794c5b50a3e3045bc485fdf95b21a
--- /dev/null
+++ b/versioned_docs/version-0.14/getting-started/sending/start-submission.mdx
@@ -0,0 +1,96 @@
+---
+sidebar_position: 3
+title: Einreichung anlegen
+---
+
+import Tabs from '@theme/Tabs'
+import TabItem from '@theme/TabItem'
+
+## Eine neue Einreichung anlegen
+Das Anlegen einer neuen Einreichung über die API erfordert den Versand einer [HTTP-POST-Nachricht](../../apis/submission-api.mdx#post-/submissions), die definiert, an welchen Zustellpunkt der Einreichung versendet werden soll und welche Inhalte übermittelt werden sollen.
+Die Inhalte umfassen hierbei die Identifikatoren der Anlagen als UUIDs und die Information, ob Fachdaten mit versendet werden oder nicht.
+Die UUIDs der Anlagen müssen eindeutig sein und werden vom sendenden System festgelegt.
+
+:::note Hinweis
+Die Struktur von Einreichungen und die Referenzierung von Fachdatenschemata ist im Artikel [Aufbau einer Einreichung](../submission-structure.md) näher beschrieben.
+:::
+
+<Tabs
+ defaultValue="curl"
+ values={[
+ { label: 'curl', value: 'curl', },
+ { label: 'Java (Spring)', value: 'java', },
+ { label: 'JavaScript', value: 'js', },
+ { label: 'C#', value: 'csharp', },
+ ]
+}>
+<TabItem value="curl">
+
+```bash
+$ export SERVICE_URL=...
+$ export JWT_TOKEN=eyJhbGciOiJIUzI1NiJ9.eyJJc3N1Z...NL-MKFrDGvn9TvkA
+$ export DESTINATION_ID=7a2668ad-3081-407c-9358-7ce4b6144b02
+$ curl \
+ -H "Authorization: Bearer $JWT_TOKEN" \
+ -H "Content-Type: application/json" \
+ --data "{ \"destinationId\": \"$DESTINATION_ID\", \"announcedContentStructure\": { \"data\": true, \"attachments\": [\"1da99641-2067-4e8b-b049-91b2a6c90544\", \"538a1365-092e-4d80-93b9-90eb8c1f5982\"] }, \"serviceType\": { \"name\": \"Bauantrag\", \"identifier\": \"urn:de:fim:leika:leistung:99010003001006\" } }" \
+ -X POST $SERVICE_URL/submissions
+
+> {
+ "destinationId": "7a2668ad-3081-407c-9358-7ce4b6144b02",
+ "submissionId": "9d618546-0ff7-4e93-9f15-714e5dd1bf12"
+}
+```
+
+</TabItem>
+<TabItem value="java">
+
+```java
+// TBD
+```
+
+</TabItem>
+<TabItem value="js">
+
+```js
+import axios from 'axios'
+
+const url = '/submissions'
+const data = {
+ "destinationId": "879ee109-a690-4db8-ab32-424284184d7d",
+ "announcedContentStructure": {
+ "data": true,
+ "attachments": [
+ "123ee109-a690-4db8-ab32-424284184d7d",
+ "456ee109-a690-4db8-ab32-424284184d7d"
+ ]
+ },
+ "serviceType": {
+ "name": "Bauantrag",
+ "identifier": "urn:de:fim:leika:leistung:99010003001006"
+ }
+}
+const token = 'eyJhbGciOiJIUzI1NiJ9.eyJyYW5kb20iOiJyYW5kb20ifQ.lXckRWoWCUBGM4ACZ6wIhYqplJeSw0HMEfE91jD1JPU'
+
+axios.post(
+ url,
+ data
+ {
+ baseURL,
+ timeout: 2000,
+ headers: {
+ 'Authorization': `Bearer ${token}`
+ }
+ }
+)
+```
+
+</TabItem>
+<TabItem value="csharp">
+
+```chsarp
+TBD
+```
+
+</TabItem>
+</Tabs>
diff --git a/versioned_docs/version-0.14/getting-started/sending/submit.mdx b/versioned_docs/version-0.14/getting-started/sending/submit.mdx
new file mode 100644
index 0000000000000000000000000000000000000000..23938c44692606160af61957787fba9bdca5017b
--- /dev/null
+++ b/versioned_docs/version-0.14/getting-started/sending/submit.mdx
@@ -0,0 +1,74 @@
+---
+title: Einreichung versenden
+sidebar_position: 8
+---
+
+import Tabs from '@theme/Tabs'
+import TabItem from '@theme/TabItem'
+
+Die Einreichung kann abgeschlossen werden, indem mit einem PUT auf den Endpunkt [/submissions/{submissionId}](../../apis/submission-api.mdx#put-/submissions/-submissionId-) der Metadatensatz und der Fachdatensatz hochgeladen wird.
+
+Diese PUT Methode kann nur folgreich durchgeführt werden, wenn folgende Bedingungen vorliegen:
+- Es muss immer ein Metadatensatz hochgeladen werden
+- Wenn über den initialen POST in der `announcedContentStructure` ein Fachdatensatz angekündigt wurde, muss dieser ebenfalls hochgeladen werden
+- Sowohl der Metadatensatz als auch der Fachdatensatz müssen verschlüsselt im JWE Format vorliegen
+
+Wenn die Nutzung dieses Endpunkts erfolgreich war, wechselt die Einreichung in den Status `submitted` und die vollständige Einreichung (Anlagen, Metadatensatz und Fachdatz) liegt nun für das empfangende System zum Abruf bereit.
+
+Ein Beispiel für die Nutzung des Endpunkt ist im Folgenden Ausschnitt dargestellt:
+
+<Tabs
+ defaultValue="curl"
+ values={[
+ { label: 'curl', value: 'curl', },
+ { label: 'Java (Spring)', value: 'java', },
+ { label: 'JavaScript', value: 'js', },
+ ]
+}>
+<TabItem value="curl">
+
+```bash
+$ export SERVICE_URL=...
+$ export JWT_TOKEN=eyJhbGciOiJIUzI1NiJ9.eyJJc3N1Z...NL-MKFrDGvn9TvkA
+$ export SUBMISSION_ID=63f0c991-0635-4e18-8a4b-fb0c01de9f5c
+$ curl \
+ -H "Authorization: Bearer $JWT_TOKEN" \
+ -H "Content-Type: application/json" \
+ --data '{ "encryptedMetadata": "6r4H2H_WIzCv8Pd-uetmcbK...iVBKF3ylHRUahmZ" }' \
+ -X PUT $SERVICE_URL/submissions/$SUBMISSION_ID
+```
+
+</TabItem>
+
+<TabItem value="js">
+
+```js
+import axios from 'axios'
+
+const data = {
+ encryptedMetadata: 'mt2w8Pd-uetmcbKq0MqCw7zyBYj5HHDV1I7F0...',
+ encryptedData: 'eyJlbmMiOiJB...'
+}
+const token = 'eyJhbGciOiJIUzI1NiJ9.eyJyYW5kb20iOiJyYW5kb20ifQ.lXckRWoWCUBG...w0HMEfE91jD1JPU'
+
+axios.put(
+ '/submissions/63f0c991-0635-4e18-8a4b-fb0c01de9f5c',
+ data
+ {
+ baseURL,
+ timeout: 2000,
+ headers: {
+ 'Content-Type': 'application/json',
+ 'Authorization': `Bearer ${token}`,
+ }
+ }
+)
+```
+
+</TabItem>
+<TabItem value="java">
+ ```java
+ TBD
+ ```
+</TabItem>
+</Tabs>
diff --git a/versioned_docs/version-0.14/getting-started/submission-structure.md b/versioned_docs/version-0.14/getting-started/submission-structure.md
new file mode 100644
index 0000000000000000000000000000000000000000..9d423c3cc27eaba2bc4ace848ac96523273e76a1
--- /dev/null
+++ b/versioned_docs/version-0.14/getting-started/submission-structure.md
@@ -0,0 +1,93 @@
+# Aufbau einer Einreichung
+
+Der zentrale Anwendungsfall der Submission API besteht darin, Daten im Rahmen von Verwaltungsverfahren an hoheitliche Stellen (Behörden, Handelskammern, etc.) zu übermitteln.
+Diese Daten werden durch Kunden und Verfahrenspartner übermittelt, um Verfahren (bspw. über einen Antrag) zu starten oder um Berichtspflichten zu erfüllen.
+
+Diese Datenübermittlung wird in der Submission API als Einreichung (`submission`) bezeichnet und besitzt eine festgelegte Struktur aus Datenobjekten, die über die Ressourcen
+der Submission API abgebildet werden. Mit dieser Struktur soll eine standardisierte Verarbeitung und Interpretation der einzelnen Bestandteile einer Einreichung ermöglicht werden.
+
+Einreichung können aus fachlicher Sicht Anträge (bspw. ein strukturierter Datensatz mit den Daten eines Wohngeldantrags und Anlagen in beliebigen Datenformaten wie einer Urkunde als PDF), Berichte (bspw. ein Datensatz wie eine elektronische Bilanz in einem festlegten Berichtsformat für Statistik- oder Sozialmeldenungen) oder sonstige prozessauslösende Datensätze sein, die an Systeme von hoheitlichen Stellen übermittelt werden.
+
+## Wie ist eine Einreichung aufgebaut?
+
+
+
+Eine Einreichung, die über die Submission API übermittelt wird, besteht aus drei Bestandteilen:
+- Ein optionaler Fachdatensatz (`data`), der die Daten eines Antrags oder Berichts enthält und einem im Zustellpunkt vorgegebenen Datenschema (`submissionSchema`) entspricht.
+- Eine oder mehrere optionale Anlagen (`attachments`) ergänzend zum Fachdatensatz. Die können Nachweise in Form von PDF-Urkunden, Bauanlagen wie XPlanGML-basierte Baupläne oder auch technische Laufzettel vom sendenden System sein.
+- Ein obligatorischer Metadatensatz `metadata`), der die Einreichung beschreibt und zusammen mit der Submission API im Rahmen von FIT-Connect standardisiert wird.
+Dieser enthält Strukturinformationen zum Fachdatensatz und Anlagen sowie prozessrelevante Informationen wie die Authentizierung des Absenders, Zahlungsinformationen (z.B. von Verfahrensgebühren) oder Rückkanalwünschen.
+
+## Wie stimmen sich sendende und empfangende Systeme beim Inhalt einer Einreichung ab?
+
+In der Submission API wird durch das empfangende System über eine Schemaferenz im Zustellpunkt ein konkretes Schema für den Fachdatensatz festgelegt, den das sendende System übersenden darf. Eine Fachschemareferenz besteht aus zwei Angaben:
+- Die `schemaURI` referenziert das zu verwendende Fachschema.
+- Der `mimeType` gibt den Datentyp (JSON oder XML) des Fachdatensatzes vor.
+
+In den Angaben eines Zustellpunkts befindet sich die Fachschemareferenz immer innerhalb eines Service-Objekts innerhalb des `services` Arrays.
+Die Fachschemarefenz ist im Zustellpunkt daher immer einer dazugehörigen Leistung zugeordnet.
+
+```json
+"services":[
+ {
+ "identifier":"urn:de:fim:leika:leistung:99010003001006",
+ "submissionSchemas":[
+ {
+ "schemaURI":"https://schema.fitko.de/fim/s00000121_1.0.0.schema.json",
+ "mimeType":"application/json"
+ }
+ ],
+ "regions":[
+ "DE094750156156",
+ "DE09330411"
+ ]
+ },
+ {
+ ...
+ "submissionSchemas":[
+ {
+ "schemaURI":"https://schema.fitko.de/fim/s00000000009_1.1.0.schema.json",
+ "mimeType":"application/json"
+ },
+ {
+ "schemaURI":"https://schema.fitko.de/fim/s00000000010_1.0.0.schema.json",
+ "mimeType":"application/json"
+ }
+ ],
+ ...
+ }
+ ]
+
+```
+
+Wenn ein sendendes System die Angaben eines Zustellpunkts ermittelt (bspw. über [GET /destinations/{destinationId}](../apis/submission-api.mdx#get-/destinations/-destinationId-) oder zukünftig die Routing API), so muss der Fachdatensatz diesem Schema entsprechen.
+Wenn mehrere Schemata (bspw. innerhalb des `submissionSchemas` Array) im Zustellpunkt referenziert werden, so muss der Fachdatensatz einem dieser referenzierten Schemata entsprechen.
+
+## Warum muss das sendende System über den Metadatensatz eine Fachschemareferenz mitliefern?
+
+Zusätzlich muss das sendende System eine identische Fachschemareferenz in den Metadatensatz der Einreichung für das Schema angeben, dem der übersendete Fachdatensatz entspricht.
+
+```json
+"contentStructure": {
+ "data": {
+ "submissionSchema": {
+ "schemaURI": "https://schema.fitko.de/fim/s00000000009_1.0.0.schema.json",
+ "mimeType": "application/json"
+ }
+ }
+}
+```
+
+Insbesondere wenn ein empfangendes System viele unterschiedliche Schemata über den Zustellpunkt unterstützt, hilft diese Angabe bei der effizienten Validierung des Fachdatensatzes. Dies ist insbesondere dann relevant, wenn keine eindeutige Schemareferenz im Fachdatensatz enthalten ist.
+
+## Sind Vorgaben für die Anzahl der Anlagen und deren Format möglich?
+
+Aktuell sind keine konkreten Vorgaben für die Anzahl und das Format der Anlagen durch ein empfangendes Sytem über die Angaben im Zustellpunkt möglich.
+Aktuell existieren lediglich Vorgaben für die Gesamtgröße einer Einreichung (Fachdatensatz+Anlagen), die den Umfang der Anlagen hinsichtlich der Datengrößen begrenzen.
+Für sonstige technische Vorgaben für Anlagen wird aktuell davon ausgegangen, dass die Fachstandards, zu denen ein genutzter Fachdatensatz gehört, technische Vorgaben für Anlagen machen. Ansonsten sollte ein empfangendes System im Mimimum PDF als Format für Anlagen akzeptieren.
+
+Es wird für sendende Systeme empfohlen, auf den Versand eigener proprietärer Anlagen zu verzichten, wenn deren Nutzung nicht explizit mit den empfangenden Stellen abgestimmt wurde.
+
+## Meine Software übermittelt oder empfängt nach Standard XYZ Fachdatensätze, wie kann ich das jeweils genutzte Fachschema korrekt referenzieren?
+
+Eine Erläuerung der Schemareferenzen für die gängigsten Fachstandards der Verwaltung findet sich [hier](/details/schema-reference.md).
diff --git a/versioned_docs/version-0.14/glossary.md b/versioned_docs/version-0.14/glossary.md
new file mode 100644
index 0000000000000000000000000000000000000000..e72de0a4294ffbf5fdfe6d97360e5f2ad5f75f15
--- /dev/null
+++ b/versioned_docs/version-0.14/glossary.md
@@ -0,0 +1,32 @@
+---
+title: Glossar
+hide_table_of_contents: true
+---
+
+| Begriff | Beschreibung |
+|---------|--------------|
+| Angekündige Anlage | Angabe gegenüber den Zustelldienst, was übermittelt wird. Teilmenge der Angaben in der contentStructure im verschlüsselten Metadatensatz. |
+| Anlage (attachment) | Sind Anlagen zu einer Einreichung. Diese sind nicht zwingend maschinenlesbar oder an Standards geknüpft. |
+| Antragsteller:in (applicant) | Bezeichnung der Person, die den Onlinedienst benutzt. Z.B. eine Verwaltungskund:in, die einen Einreichung absendet. |
+| Antwort (reply) | Alle auf eine Einreichung (submission) folgende Übertragungen, egal in welche Richtung (sender → subscriber oder subscriber → sender) |
+| API-Client | Ein technisches System, dass auf die FIT-Connect-Schnittstellen zugreift. Dieser Begriff kann verwendet werden, wenn eine Unterscheidung zwischen Fachverfahren, virtueller Poststelle, Onlineservice oder Endgerät der antragstellenden Person nicht nötig ist. |
+| API-Gateway | Das API-Gateway ist eine technische Komponente, die die Prüfung von OAuth-Tokens prüft und nicht oder falsch authentifizierte Anfragen blockiert. Ein Zugriff auf die Schnittstellen des Zustelldienstes ist ausschließlich über das API-Gateway möglich. |
+| Autorisierungsdienst | Der Autorisierungsdienst / OAuth-Dienst stellt via Client-Credentials-Flow OAuth-Tokens an API-Clients aus, mit denen diese sich anschließend gegenüber den FIT-Connect-Schnittstellen (d.h. gegenüber dem API-Gateway) authentifizieren können. |
+| Einreichungsstatus (submission status) | Beschreibt den fachlichen Status einer Einreichung für das einreichende System. |
+| Einreichung (submission) | Ist eine Einreichung bei einer zuständigen Stelle über die FIT-Connect Übermittlungsinfrastruktur. Eine solche Einreichung kann ein Antrag (bspw. ein Antrag nach dem Onlinezugangsgesetz), ein Bericht (bspw. Statistikmeldung eines Unternehmens) oder eine sonstige Einreichung für die Initiierung eines Bearbeitungsvorgangs in einem Verwaltungsverfahren sein. Eine Einreichung besteht aus mindestens aus einem Metadatensatz und einem Fachdatensatz und / oder einem oder mehreren Anlagen. Eine Einreichung besitzt immer eine systemübergreifend eindeutige ID (submissionId), um dauerhaft den Einreichungsvorgang zu referenzieren oder zu dokumentieren. Diese ID wird bei jedem Einreichungsvorgang durch ein sendendes System vergeben. |
+| empfangendes System (subscriber) | Das technische System, das Einreichungen auf Verwaltungsseite entgegennimmt. (z.B. Fachanwendung / virtuelle Poststelle) |
+| Ereignis (event) | Als [Security Event Token](https://datatracker.ietf.org/doc/html/rfc8417) aufgezeichnetes Ereignis eines im Zustelldienst abgelegten Objekts. Dies kann z.B. das Absenden einer Einreichung sein. |
+| Ereignisprotokoll (event log) | Der Zustelldienst bündelt alle einem Object zugeordneten Ereignisse in einem Ereignisprotokoll. |
+| Fachdatensatz (data) | Ist ein strukturierter Fachdatensatz im Rahmen der Einreichung. Kann JSON, XML oder ein anderes in verwaltungseigenen Datenstandards genutztes Datenformat sein. |
+| Fachschemareferenz (submission schema) | Das referenzierte Fachschema aus FIM oder XÖV. Eine Liste der möglichen Fachschemata wird im Zustellpunkt angegeben. Das verwendete Fachschema steht im Metadatensatz. Siehe auch: Artikel [Fachschemarefenzen auf Fachstandards und Rahmenwerke abbilden](details/schema-reference) |
+| FIM | Föderales Informationsmanagement, bestehend aus den Bausteinen *FIM Leistungen* (siehe *Leistungsschlüssel*), FIM Datenfelder (siehe *Fachschema*) und FIM Prozesse (Prozessabbildungen zu einer Leistungserbringung). Weiterführende Informationen finden sich im [FIM-Portal](https://fimportal.de/) |
+| Kommunikationskanal (communication channel) | Beschreibt einen Kommunikationskanal, um zwischen der zuständigen Stelle und dem Autor der Einreichung (bspw. dem Verwaltungskund:in) zu digital zu kommunizieren. Kommunikationskanäle können sein: <ul> <li>E-Mail</li> <li>De-Mail</li> <li>FIT-Connect Rückkanal</li> <li>Interoperable Postfächer FINK (AS4)</li> <li>Elster Transfer des einheitlichen Unternehmenskontos</li> <li>Postfachplus (OSCI) des einheitlichen Unternehmenskontos</li> </ul>Eine zuständige Stelle kommuniziert über die Destination, welche Kommunikationskanäle unterstützt werden und der Autor der Einreichung legt fest, welche Kommunikationskanäle er sich hierfür wünscht. Für die Adressierung des Autors werden alle für den Kommunikationskanal notwendigen Verbindungs- und Adressparameter (einschließlich ggf. notwendiger Schlüssel/Zertifikate) im Metadatensatz mitgeliefert.|
+| Leistungsschlüssel, ehemals *LeiKa-Schlüssel* | Eindeutige Leistungskennung aus dem **Lei**stungs**ka**talog der öffentlichen Verwaltung. Manchmal wird zur Abgrenzung zwischen dem *Leistungsschlüssel* (beginnt immer mit `99`) und der LeiKa-intern verwendeten *LeiKa-ID* unterschieden. Siehe auch: *Leistungs-ID* |
+| Leistungs-ID | Eindeutige Kennung des Typs einer Verwaltungsleistung. Eine Identifikation des Leistungtypen erfolgt z.B. über eine aus einem Leistungsschlüssel abgeleitete eindeutige URN (z.B. `urn:de:fim:leika:leistung:99010003001006`) |
+| Metadatensatz (metadata) | Ein Metadatensatz beschreibt: <ul> <li>Fachunabhängige Metadaten der Einreichung: Authentifizierung des Autors einer Einreichung oder Berichts (bspw. über einen eID-Laufzettel, Identifikation Report, Informationen über Signaturnutzung einschließlich Angabe des Signaturformats und ggf. separater Signaturdateien.), Ergebnisse eines Bezahlvorgangs oder digitale Verbindungs- und Adressparameter für die Verfahrensinformationen (falls vom Verwaltungskund:in gewünscht).</li> <li>Strukturbeschreibung der Einreichung: Art der Leistung oder Einreichungsbestandteile.</li> </ul> |
+| Onlineservice | Ein Onlineservice kann entweder von einer Behörde, einem Unternehmen oder einer zivilgesesellschaftlichen Organisation betrieben wird. Er interagiert in der Art mit FIT-Connect, dass er Anträge im Namen bzw. Auftrag eines Endnutzers verschlüsselt übermittelt. |
+| Self-Service-Portal | Das Self-Service-Portal ist Teil des Autorisierungsdienst und ermöglicht es, Accounts/Berechtigungen für die Anbindung von Onlinediensten und Fachverfahren/virtuellen Poststellen anzulegen. |
+| sendendes System (sender) | Das technische System, das eine Einreichung über die Submission API vornimmt. (z.B. Online-Antragsservice oder Unternehmenssystem). Dies ist in der Regel ein Online-Antragsservice (spezialisiertes Webportal für eine bestimmte Fachlichkeit), das Endgerät der Antragsteller:in oder auch ein Verwaltungsportal, das typischerweise mehrere Fachlichkeiten / Antragstypen unterstützt. Perspektivisch wären hier auch andere API-Clients denkbar, z.B. spezialisierte Anwendungen zur Antragseinreichung ohne Webinterface oder Fachverfahren der Verwaltung, über die beim Behördengang durch eine Sachbearbeiter:in stellvertretend für die Antragsteller:in ein Einreichung eingereicht wird. |
+| Vorgangsreferenz (caseID) | Systemübergreifend eindeutige ID für einen langlaufenden Kommunikationsvorgang zwischen dem einreichenden System und der Empfangsseite, wenn über die FIT-Connect kommuniziert werden sollen. Innerhalb einem Kommunikationsvorgang können weitere Fachdatensätze und Anlagen zwischen beiden Parteien ausgetauscht werden. |
+| Zustellberechtigungs-Scope | Beschreibt die Scopes aus den OAuth-Tokens (JWT), die im Zustelldienst dazu dienen, um zu überprüfen, ob ein Onlinedienst Einreichungen bei einer Destination vornehmen darf. |
+| Zustellpunkt (Destination) | Technisch eindeutig adressierbarer Endpunkt zur digitalen Einreichung von Anträgen oder Berichten an die Verwaltung über die FIT-Connect Übermittlungsinfrastruktur. Ein Zustellpunkt repräsentiert typischerweise ein konkretes empfangendes System (Fachverfahren oder virtuelle Poststelle). Für ein empfangendes System können jedoch multiple Zustellpunkte angelegt werden. In der Konfiguration eines Zustellpunkts sind interne und öffentliche Teile hinterlegt. Interne Angaben sind solche, die zu Administrationszwecken dienen. Öffentliche Angaben legen z. B. fest, in welcher Form der Empfänger Einreichungen akzeptiert. Die öffentlichen Angaben sind: <ul> <li>Zulässige Schemata für einen Fachdatensatz (und die Pflicht, einen Fachdatensatz mit dem definierten Fachdatensatz in einer Einreichung zu nutzen)</li> <li>Öffentlicher Schlüssel zur Verschlüsselung von Fachdatensatz, Anlage und Metadatensatz</li> </ul> |
diff --git a/versioned_docs/version-0.14/intro.md b/versioned_docs/version-0.14/intro.md
new file mode 100644
index 0000000000000000000000000000000000000000..b4c3a9592301adf500b635ea6b70a13dc51398bb
--- /dev/null
+++ b/versioned_docs/version-0.14/intro.md
@@ -0,0 +1,113 @@
+---
+title: Einführung in FIT-Connect
+slug: /
+---
+
+Willkommen im FIT-Connect-Dokumentationsportal der FITKO.
+Auf den folgenden Seiten werden die nötigen Schritte zur Anbindung an FIT-Connect und die FIT-Connect-Schnittstellen (APIs) beschrieben.
+Die FIT-Connect Submission API baut auf dem bestehenden IT-Planungsrat Standard XFall auf und bietet Lösungsverantwortlichen von sendenden und empfangenden Systemen eine einfache Möglichkeit, ihre Software schnell und wirtschaftlich in länder- und ebenenübergreifende Antragsprozesse zu integrieren.
+Die FIT-Connect Routing API soll es bundesweit ermöglichen, die richtigen Empfangspunkte für jeden Leistungs- und Zuständigkeitskontext zu ermitteln und soll die Submission API ergänzen.
+
+## Was ist die FIT-Connect Submission API und was unterscheidet diese API vom bisherigen XFall-Standard?
+
+Die FIT-Connect Submission API baut auf den bisherigen Konzepten und Erfahrungen des bestehenden IT-Planungsrats Standards XFall
+auf.
+
+> Die übergreifende Zielstellung des Standards XFall besteht darin, Anträge und Berichte, die aus vorgelagerten Systemen (bspw. Onlineantragsdienste, Fachportale oder Berichtssysteme) erstellt werden, in die unterschiedlichen Systeme der elektronischen Verfahrensbearbeitung (bspw. Fachverfahren, Dokumentenmanagementsystem oder Prozessplattformen) zu übergeben.
+
+Bei der Entwicklung der Submission API wurden viele Konzepte mit Hinblick auf die neuen Erfordernisse des
+Onlinezugangsgesetzes, der SDG-Verordnung sowie den Anforderungen digitaler Geschäftsmodelle weiterentwickelt. Technisch
+setzt die FIT-Connect Submission API auf einen leichtgewichtigen RESTful-Architekturstil und baut auf der föderalen
+Antragsübertragungsarchitektur von FIT-Connect auf. Bereitgestellt wird diese API durch einen zentral gemanagten Intermediär
+(`FIT-Connect Zustelldienst`), der für Nutzer der API einen Aufbau eigener Infrastruktur unnötig macht.
+
+## Was macht die FIT-Connect Submission API und wie kann diese genutzt werden?
+
+Die FIT-Connect Submission API ist als ein universelles Eingangstor für digitale Einreichungen an die Verwaltung ausgelegt:
+
+- Empfangende Systeme (bspw. Fachverfahren oder E-Akte Systeme) können einen digitalen Zugang (Zustellpunkt) eröffnen und hierüber beliebige Einreichungen (Anträge,
+Berichtsmeldung, etc. ) erhalten. Was empfangen wird, kann über eindeutige Schema Referenzen auf Fachstandards festgelegt werden.
+- Sendende Systeme (bspw. Antragsdienste) können Einreichungen an alle existierenden Zustellpunkte senden.
+Um die richtigen Zustellpunkte für den jeweiligen Leistungskontext und die jeweilige Zuständigkeit zu finden, wird sendenden Systemen eine Routing API bereitgestellt.
+Mit der Routing API können sendende Systeme auf Basis des Leistungs- und Ortsbezugs der Einreichung den richtigen Zustellpunkt ermitteln und alle technischen Verbindungsparameter ermitteln.
+
+Die Vertraulichkeit der Übermittlung ist jederzeit gewährt, da eine Ende-zu-Ende-Verschlüsselung standardmäßig für alle übermittelten Daten vorgesehen ist und bis in den Browser oder das Endgerät der Antrag- oder Berichtssteller:in möglich ist.
+
+### Zusammenspiel der Infrastruktur bei der Ãœbermittlung von Einreichungen
+
+
+
+Über die Submission API können die zuständigen Stellen für ihre Systeme einen Zustellpunkt eröffnen, der
+über eine `destination-Id` eindeutig adressierbar ist. Für diese Zustellpunkte legen die zuständigen Stellen alle
+fachlichen Vorgaben (Zulässige Fachstandards, Verschlüsselung, Datenformate etc.) fest, damit eine medienbruchfreie
+Weiterverarbeitung in ihren Systemen gewährleistet ist. Über die Angabe der `destination-Id` in
+der Submission API können sendende Systemen Einreichungen an die zuständige Stelle senden.
+
+Dieser Zustellpunkt ist jedoch vorab für eine Verwaltungsleistung und den jeweiligen örtlichen Antragskontext (bspw. Ort
+der Antragsstellung) korrekt zu ermitteln. Damit die Ermittlung des korrekten Zustellpunkts skalierbar für das ganze
+Bundesgebiet funktioniert, ist es vorgesehen, die `destinationId` in den Leistungs- und
+Zuständigkeitsinformationen des lokalen FIM Leistungsredaktionssystems zu hinterlegen. Diese dezentral gepflegten
+IDs werden durch das Online-Gateway (<https://www.onlinezugangsgesetz.de/Webs/OZG/DE/umsetzung/portalverbund/online-gateway/online-gateway-node.html>)
+gebündelt. Fragt nun ein sendendes System über die Routing API an, ermittelt der FIT-Connect Routingdienst die korrekte `destination-Id` im Onlinegateway,
+ruft auf Basis dieser ID die technischen Verbindungsparameter im DVDV ab und sendet diese Informationen an das sendende System zurück.
+
+## Für wen ist die FIT-Connect Submission API gedacht und warum sollte ich sie nutzen?
+
+Die FIT-Connect Submission API ist für alle Hersteller, Entwickler und Verfahrensverantwortliche von sendenden und empfangenden
+Systemen gedacht. Insbesondere folgende Systeme mit bundesweiten Nutzungsszenarien sollen mit der FIT-Connect Submission API
+unterstützt werden:
+
+- **Einer für alle (EfA) Verfahren**: Länderübergreifend entwickelte Antragsverfahren für eine bestimmte
+ Verwaltungsleistung oder ein Leistungsbündel, die entweder in verschiedenen Ländern nachnutzbar betrieben werden oder
+ länderübergreifend als gemeinsamer Antragsdienst für alle zuständigen Stellen betrieben werden.
+- **Antragsgeneratoren / Antragsmanagementsysteme**: Standardsoftware zur Erstellung und dem Betrieb von direkt
+ nutzbaren Onlineantragsdiensten, die im ganzen Bundesgebiet bei einzelnen Stellen oder Gebietskörperschaften (bspw.
+ als Basiskomponente) im Einsatz sind.
+- **Als Standardsoftware bereitgestellte Fachverfahrenssoftware, Prozessplattformen oder Dokumentenmanagementsysteme**:
+ Bundesweit angebotene und eingesetzte Standardsoftware, die von den zuständigen Stellen für die Antragsbearbeitung
+ eingesetzt wird.
+
+Für diese Systeme bietet die FIT-Connect bei der schnellen und wirtschaftlichen Realisierung medienbruchfreier
+Antragsprozesse eine Reihe von Mehrwerten:
+
+- **Plug and Play Anbindung an die föderale Antragsübermittlung**: Durch die zentral bereitgestellten APIs und die
+ Nutzung der bestehenden Zuständigkeitsfinderinfrastruktur können Systeme schnell an eine föderale
+ Antragsübermittlungsinfrastruktur angebunden werden, ohne eigene Infrastrukturen hierfür zu beauftragen oder
+ aufzubauen.
+- **Leichgewichtige APIs und Industriestandards**: Die FIT-Connect-Schnittstellen bauen auf leichgewichtigen RESTful API-Ansätzen
+ auf und nutzt verbreitete Industriestandards wie den OpenAPI-Spezifikationsstandard und das OAuth-2.0-Autorisierungsframework, sodass kein spezialisiertes
+ Know-How und spezifische Softwarekomponenten für die Anbindung erforderlich sind.
+- **Flexibilität in der Antragsübermittlung**: Die FIT-Connect APIs verbinden Flexibilität und Standardisierung. Während
+ die FIT-Connect Submission API eine einheitliche Metadatenstruktur festlegt, um Einreichungen strukturiert zu verarbeiten, können
+ beliebige Fachstandards und Anhänge übertragen werden. Auch die Übertragung von Einreichungen im PDF-Format ist möglich,
+ solange für die Antragsdaten noch kein FIM-Schema vorhanden ist.
+ **Nutzung bestehender Prozesse und Strukturen für die Pflege von Adressierungsinformationen**: Langjährig erprobte
+ Prozesse und Strukturen zur Pflege der Zuständigkeitsinformationen, können in den zuständigen Stellen beibehalten
+ werden. Technische Adressierungsparameter werden über die gleichen Systeme und Prozesse gepflegt,
+ die schon heute bei Informationen zu Anschriften, Rufnummern, E-Mail-Adressen oder Ansprechpartnern genutzt werden.
+- **Machine2Machine Ready**: Die FIT-Connect Submission API und die FIT-Connect Antragsübermittlungsarchitektur sind von Grund auf
+ als offene API-Plattform konzipiert. Dadurch können auch verwaltungsexterne Antrags- und Berichtssysteme wie
+ Drittsoftware oder Unternehmenssysteme direkt eingebunden werden, ohne das hierfür eine gesonderte Infrastruktur
+ notwendig ist.
+
+### Ist die FIT-Connect Submission API nur für länder- und behördenübergreifende Antragskontexte gedacht?
+
+Durch die einfache Anbindung und Nutzung bietet sich die Submission API auch dort an, wo das behördeneigene
+Antragsverfahren mit dem behördeneigenen Fachverfahren verbunden wird. Durch die Nutzung der Submission API werden
+diese Systeme standardisiert verbunden, ohne das die Behörde in Abhängigkeiten zu proprietären Technologien und
+Schnittstellen gerät. Dies ermöglicht es der Behörde, ihre Systeme auf beiden Seiten flexibel auszutauschen und
+weiterzuentwickeln, um somit auf neue technische Trends und Möglichkeit schnell zu reagieren.
+
+## In welchem Stand befindet sich FIT-Connect Submission API und wann kann man diese nutzen?
+
+Ein Zugang für interessierte Enwickler zur einer Testinfrastruktur ist seit August 2021 möglich.
+Um auf diese Testumgebung zuzugreifen, können interessierte Entwickler ihre Anwendungen das Self-Service-Portal vorab registrieren.
+Projektpartner können die API und Infrastruktur für produktive Datenübermittlungen ab September 2021 nutzen.
+Detailerte Zeitpläne können der [Roadmap](https://docs.fitko.de/fit-connect/docs/roadmap) entnommen werden.
+Updates werden regelmäßig im Bereich [News](https://docs.fitko.de/fit-connect/news) mitgeteilt.
+
+## Ich habe einen Fehler in der Dokumentation oder in der API-Spezifikation gefunden. Wo kann ich diesen melden? {#found-bug}
+
+Vielen Dank für das Interesse an unserer Entwickler:innendokumentation! Wir freuen uns immer über Feedback und
+Anregungen über unser Funktionspostfach fit-connect ät fitko.de. Zudem können wir bei Interesse gerne einen Zugang zu
+unserem GitLab zur Eröffnung von Issues oder Einreichung von Merge-Requests einrichten.
diff --git a/versioned_docs/version-0.14/rate-limiting.md b/versioned_docs/version-0.14/rate-limiting.md
new file mode 100644
index 0000000000000000000000000000000000000000..f8ad8d57cdb41b4feed50c32a2d4592962af832f
--- /dev/null
+++ b/versioned_docs/version-0.14/rate-limiting.md
@@ -0,0 +1,9 @@
+---
+title: Begrenzung von Abrufen (Rate-Limiting & Throttling)
+---
+
+...
+
+**Noch in Arbeit**
+
+...
\ No newline at end of file
diff --git a/versioned_docs/version-0.14/roadmap.md b/versioned_docs/version-0.14/roadmap.md
new file mode 100644
index 0000000000000000000000000000000000000000..1c49a7380a885b0e84bcbbccce434e5160b3f5ea
--- /dev/null
+++ b/versioned_docs/version-0.14/roadmap.md
@@ -0,0 +1,120 @@
+# Roadmap
+
+**Stand 26.07.2021**
+
+Die FIT-Connect Submission API, die Routing API und die dazugehörige Infrastruktur wird in einem Projekt des IT-Planungsrats im Jahr
+2021 zu einer Produktreife entwickelt. Die Umsetzung der Projektliefergegenstände erfolgt iterativ, um eine schnelle
+Erprobung und Feedback zu ermöglichen.
+
+Die Roadmap soll daher einen Überblick verschaffen, wann das FIT-Connect Team für die folgenden Projektliefergegenstände
+neue Features anstrebt:
+
+- **API-Spezifikation:** In der OpenAPI geschriebene Spezifikation der FIT-Connect Submission API.
+- **Entwicklerdokumentation- und tools:** Weiterführende Dokumentationsartikel zur technischen Anbindung an der API für
+ sendende und empfangende Systeme udn Bereitstellung von Tools für technische Querschnittsaufgaben wie Tokenhandling,
+ Signaturprüfung oder Verschlüsselung.
+- **Infrastruktur:** Bereitstellung von Infrastrukturkomponenten für die Durchführung von Anbindungstests oder
+ Validierungsaufgaben sowie die produktive Bereitstellung der API für Datenübermittlungen.
+
+Die Roadmap wird laufend aktualisiert und erweitert. Unser Team versucht weitestgehend verbindliche Termine zu benennen,
+jedoch passen wir die Umsetzungen den aktuellen Bedarfen des Projekts an, wodurch es zu Verzögerungen bei manchen
+Liefergegenständen kommen kann. Umgekehrt kann es auch sein, das Features früher fertiggestellt werden, falls die
+Prioritäten ändern oder freie Kapazitäten zur Verfügung stehen.
+
+Wir nehmen gerne neue Wünsche & Anregungen für die FIT-Connect APIs als Issue auf unserem
+Projekt (https://git.fitko.de/fit-connect/api) entgegen und versuche diese Issues nach einer Umsetzungsprüfung in unsere
+Roadmap aufzunehmen.
+
+> Wünsche & Anregungen oder Fehler können über den [hier](intro.md#found-bug) beschriebenen Prozess abgegeben werden können.
+
+## Überblick über die Zeitplanung
+
+- **Seit 24.06.2021:** Preview der API-Spezifikation und der Entwicklerdokumentaion für die Version 1.0 der Submission API ist
+ online und ist für alle interessierten Entwickler zugänglich.
+- **Anfang August 2021:** Bis zu diesem Zeitpunkt werden alle Kernfeatures der Submission API spezifiziert und als stabile API
+ Spezifikation veröffentlicht. Für die Evaluierung und Entwicklung durch interessierte Entwickler wird ein öffentlicher
+ Testserver bereitgestellt.
+- **Bis September 2021:** Die Submission API wird als Produktivinfrastruktur für erste Pilotantragsverfahren und deren Systeme
+ bereitstellt. Zudem werden noch neue abwärtskompatible Features und zusätzliche Entwicklerangebote bereitgestellt.
+- **Bis Q2 2022:** Alle Beschlüsse zur weiteren Pflege der API und dem Betrieb der Infrastruktur liegen vor.
+
+## Detailplanung bis Mitte August 2021
+
+### API-Spezifikation
+
+Die Submission API wird mit folgenden Änderungen und Erweiterung in der Form einer V1 finalisiert:
+- **Bereitstellung und Ãœbermittlung des Security Event Logs:** Der bisherige Ãœbermittlungsstatus wird durch einen
+ Security Event Log ersetzt, der aus signierten Security Event Tokens besteht und die einzelnen Ãœbermittlungsschritte
+ beweissicher dokumentiert. Die jeweiligen Security Event Tokens sind durch die jeweils verantwortlichen Systeme (
+ Zustelldienst bzw. das empfangende System) zu erstellen und zu signieren. Dieser Security Event Log kann über die API
+ von beiden Parteien abgerufen werden und dient späteren Nachweisen über die korrekte Zustellung.
+- **Callbacks zur Benachrichtigung sendender Systeme:** Sendende Systeme bekommen die Möglichkeit für Submissions einen
+ Callback einzurichten. Über diesen Callback informiert der Zustelldienst sendende Systeme, sobald es Änderungen im
+ Zustellstatus. Durch den Callback soll ein regelmäßiges Polling des Security Event Log zur Prüfung des Zustellstatus
+ unnötig gemacht werden.
+- **Neuumsetzung von Features:** Einige Features aus der Beta7 Version der API wie die Abfrage von Destination
+ Informationen und die Abfrage von abholbereiten Anträgen werden neu konzipiert und sind in der aktuellen Preview noch
+ nicht enthalten.
+- **Neues Client Autorisierungskonzept auf Basis des bestehen Client Credentials Flows:** Ein neues OAuth Konzept soll
+ umgesetzt werden, da detailierte Berechtigung für den API-Zugriff ermöglicht und höhere Sicherheit für die Nutzung von
+ Access Token gewährleistet.
+- **Anlegen neuer Zustellpunkte nur über das Self-Service-Portal:** Aufgrund des neuen Autorisierungskonzepts werden neue Zustellpunkte aktuell nur noch über das Self-Service-Portal angelegt. Änderungen an Zustellpunkten (bspw. Hinterlegung von Zertifikaten oder Fachschemareferenzen) werden weiterhin über die API möglich sein.
+
+### Entwicklerdokumentation- und tools
+
+### Infrastruktur
+
+- **Testinfrastruktur:** Es wird eine Testinfrastruktur bereitgestellt, über die alle Funktionen der API angesprochen
+ und getestet werden können.
+- **Self-Service-Portal:** Es wird ein Self-Service-Portal eingerichtet, über das Entwickler ihre API-Clients am OAuth
+ Server selbst anlegen können. Als weiteres Feature wird es für Betreiber von empfangenden Systemen möglich sein, über
+ das Self-Service-Portal Destinations anzulegen und zu konfigurieren. Das Self-Service-Portal wird mit dem Start des Testserver bereitgestellt.
+
+## Detailplanung bis September 2021
+
+### API-Spezifikation
+
+- Im Rahmen der Produktivstellungen werden Erweiterungen an der API zurückgestellt und nur bei dringenden Bedarf bzw.
+ kritischen Fehlern Fixes an der API durchgeführt.
+
+### Entwicklerdokumentation- und tools
+
+- **Bereitstellung von SDKs für erste Querschnittsfunktionen:** Es ist geplant, erste Unterstützungsfunktionen für
+ Querschnittsaufgaben bereitzustellen.
+
+### Infrastruktur
+
+- **Sandbox Systeme**: Über eine Portaloberfläche werden generische API-Clients angeboten, um bei Versand oder Empfang
+ von Submissions die jeweilige Gegenseite zu simulieren.
+
+## Detailplanung bis Ende 2021
+
+### API-Spezifikation
+
+- **Routing API:** Über die Routing API wird zukünftig möglich sein, Destinations und deren technische Parameter über
+ eine API Anfrage anhand technische Zuständigkeitskriterien zu ermitteln.
+- **Hinterlegung einer OSCI-Weiterleitung:** Um bestehende OSCI Intermediärsinfrastrukturen einzubinden, wird eine
+ Hinterlegung von OSCI-Kommunikationsparametern möglich sein. Hierdurch werden abgebeben Submissions durch den
+ Zustelldienst automatisch an den vorgesehen OSCI Intermediär weitergeleitet.
+- **Erweiterung um einen Rückkanal für Prozessstandards:** Als abwärtskompatible Erweiterung wird über die API
+ ermöglich, eine bilaterale Antragskommunikation auf Basis von Fachstandards wie XBau umzusetzen. API-Nutzer, die
+ FIT-Connect nur für Einreichungen nutzen, sind von diesen Änderungen nicht betroffen.
+- **Weiterentwicklung von FIM/XFall Schemata**: Um die Nutzung von FIM für die Antragsübermittlung zu vereinfachen,
+ werden in Zusammenarbeit mit FIM neue technologische Ansätze und Verbesserung in der Schema Nutzung angestrebt.
+
+### Entwicklerdokumentation- und tools
+
+- **Vollumfängliche Bereitstellung von SDKs**: In der zweiten Jahreshälfte werden SDKs in verschiedenen
+ Programmiersprachen für alle zentralen FIT-Connect Anforderungen angeboten.
+- **FIM Entwicklungstools**: Um die Nutzung von FIM für Antragsschemata sollen diverse Entwicklungstools für die
+ Generierung und Validierung von FIM/XFall Nachrichten angeboten werden.
+
+### Infrastruktur
+
+- **Validierungsumgebung:** Um gegenüber Auftraggebern oder anderen Stellen nachzuweisen, dass die eigene Software
+ FIT-Connect nutzen kann, soll eine Validierungsumgebung geschaffen werden, die die API-Umsetzung gegenüber
+ festgelegten Testfällen prüfen und hierfür einen signierten Nachweis an den Verfahrenbetreiber ausstellt.
+
+## Bis Q2 2022
+
+... TBD ...
diff --git a/versioned_docs/version-0.14/sdk/c-sharp.mdx b/versioned_docs/version-0.14/sdk/c-sharp.mdx
new file mode 100644
index 0000000000000000000000000000000000000000..6d9b20ce3c3319819d29c7fb0905c4115488c11f
--- /dev/null
+++ b/versioned_docs/version-0.14/sdk/c-sharp.mdx
@@ -0,0 +1,3 @@
+# C & .NET #
+
+TBD
\ No newline at end of file
diff --git a/versioned_docs/version-0.14/sdk/java.mdx b/versioned_docs/version-0.14/sdk/java.mdx
new file mode 100644
index 0000000000000000000000000000000000000000..526e9b11903a99f62fc7a80312094986041435ed
--- /dev/null
+++ b/versioned_docs/version-0.14/sdk/java.mdx
@@ -0,0 +1 @@
+# Java
\ No newline at end of file
diff --git a/versioned_docs/version-0.14/sdk/javascript.mdx b/versioned_docs/version-0.14/sdk/javascript.mdx
new file mode 100644
index 0000000000000000000000000000000000000000..0cde967e8393c85f9bc0cf00f5ddacffec36bca2
--- /dev/null
+++ b/versioned_docs/version-0.14/sdk/javascript.mdx
@@ -0,0 +1,3 @@
+# JavaScript
+
+TBD
diff --git a/versioned_docs/version-0.14/sdk/overview.mdx b/versioned_docs/version-0.14/sdk/overview.mdx
new file mode 100644
index 0000000000000000000000000000000000000000..709e341ef8d988c4f37a453c294343cb9d8f2111
--- /dev/null
+++ b/versioned_docs/version-0.14/sdk/overview.mdx
@@ -0,0 +1,3 @@
+# SDK
+
+TBD
\ No newline at end of file
diff --git a/versioned_docs/version-0.14/sdk/python.mdx b/versioned_docs/version-0.14/sdk/python.mdx
new file mode 100644
index 0000000000000000000000000000000000000000..2ad3d8ac800eeb7ca4abbc2fde6b50dba8e7ec6e
--- /dev/null
+++ b/versioned_docs/version-0.14/sdk/python.mdx
@@ -0,0 +1,2 @@
+# Python
+
diff --git a/versioned_docs/version-0.14/sidebar.js b/versioned_docs/version-0.14/sidebar.js
new file mode 100644
index 0000000000000000000000000000000000000000..799822474902f8180991998de24fa7e400de0b21
--- /dev/null
+++ b/versioned_docs/version-0.14/sidebar.js
@@ -0,0 +1,113 @@
+/**
+ * Creating a sidebar enables you to:
+ - create an ordered group of docs
+ - render a sidebar for each doc of that group
+ - provide next/previous navigation
+
+ The sidebars can be generated from the filesystem, or explicitly defined here.
+
+ Create as many sidebars as you want.
+ */
+
+module.exports = {
+ defaultSidebar: [
+ 'intro',
+ 'roadmap',
+ 'changelog',
+ 'glossary',
+ 'account',
+ 'status-and-error-codes',
+ /*{
+ type: 'link',
+ label: 'Terms of Service',
+ href: 'https://www.fitko.de/',
+ },*/
+ {
+ type: 'category',
+ label: 'Getting Started',
+ items: [
+ 'getting-started/overview',
+ 'getting-started/authentication',
+ 'getting-started/submission-structure',
+ 'getting-started/metadata',
+ 'getting-started/encryption',
+ 'getting-started/event-log',
+ {
+ type: 'category',
+ label: 'Versenden',
+ items: [
+ {
+ type: 'autogenerated',
+ dirName: 'getting-started/sending',
+ },
+ ],
+ },
+ {
+ type: 'category',
+ label: 'Empfangen',
+ items: [
+ {
+ type: 'autogenerated',
+ dirName: 'getting-started/receiving',
+ },
+ ],
+ },
+ ],
+ },
+ // {
+ // type: 'category',
+ // label: 'SDK',
+ // items: [{
+ // type: 'autogenerated',
+ // dirName: 'sdk'
+ // }]
+ // },
+ {
+ type: 'category',
+ label: 'Spezifikationen/Schemata',
+ items: [
+ {
+ type: "autogenerated",
+ dirName: "apis",
+ },
+ ],
+ },
+ {
+ type: 'category',
+ label: 'Detailinformationen',
+ items: [
+ 'details/crypto',
+ 'details/destination-management',
+ 'details/jwk-creation',
+ 'details/callbacks',
+ 'details/schema-reference',
+ 'details/pgp-export',
+ {
+ type: 'category',
+ label: 'Authentifizierung',
+ items: [
+ {
+ type: 'autogenerated',
+ dirName: 'details/authentication',
+ },
+ ],
+ },
+ {
+ type: 'category',
+ label: 'Authentifizierung (intern)',
+ items: [
+ {
+ type: 'autogenerated',
+ dirName: 'details/infrastructure-docs',
+ },
+ ],
+ },
+ ],
+ },
+ {
+ type: 'link',
+ label: 'Impressum',
+ href: 'https://www.fitko.de/Impressum',
+ },
+ ],
+}
diff --git a/versioned_docs/version-0.14/status-and-error-codes.md b/versioned_docs/version-0.14/status-and-error-codes.md
new file mode 100644
index 0000000000000000000000000000000000000000..7619015d9e88dea491fb14f1dce140d17d744110
--- /dev/null
+++ b/versioned_docs/version-0.14/status-and-error-codes.md
@@ -0,0 +1,77 @@
+---
+id: status-and-error-codes
+sidebar_position: 1
+title: Fehlerverhalten und Statuscodes
+---
+
+> Wo 200 Licht ist, ist auch 403 Schatten. -Göthe
+
+Diese Seite gibt einen Überblick über Fehlerhandling in der FIT-Connect Submission API (nachfolgend nur noch *API* genannt).
+
+## Features
+
+* Liefert zu allen Fehlerantworten einen HTTP Statuscode
+ laut [RFC 7231 (Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content)](https://datatracker.ietf.org/doc/html/rfc7231#section-6)
+ zurück.
+* Liefert Fehler (4xx und 5xx HTTP Statuscodes) im JSON Format
+ nach [RFC 7807 (Problem Details for HTTP APIs)](https://datatracker.ietf.org/doc/html/rfc7807) aus.
+ * Fehler besitzen **immer** folgende Felder:
+ * `type`: Eine URI (möglicherweise als Website aufrufbar) die den Typ des Fehlers eindeutig klassifiziert.
+ Beispiel: `https://schema.fitko.de/fit-connect/problems/submission-not-found`
+ * `title`: Ein kurzer und menschenlesbarer Titel des Fehlers. Beispiel: `Application not found`
+ * `status`: Eine Kopie des HTTP Statuscodes
+ * Fehler können **optional** weitere Felder beinhalten. API Clients **müssen** hiermit umgehen können.
+* Unterscheidet zwischen technischen und fachlichen Fehlern
+
+## Liste von Fehlercodes
+
+Wir versuchen bei Fehlern stets sinnvolle Fehlermeldungen bereitzustellen um eine Fehleranalyse zu vereinfachen. Wir
+sind aber auch Menschen und daher nicht perfekt. Falls euch ein Fehler oder eine Inkonsistenz auffällt,
+[erstellt bitte ein Issue](https://git.fitko.de/fit-connect/api/-/issues/new).
+
+Wir unterscheiden zwischen technischen und fachlichen Fehlern. Technische Fehler sind nicht explizit in der API-Spec
+abgebildet. Fachliche schon.
+
+### Technische Fehler
+
+| `type` des technischen Fehlers | Titel laut [httpstatus.es](https://httpstatuses.com/) | Beschreibung |
+|------------------------------------------------------------------------|---------------------------------------------------------|--------------|
+| https://schema.fitko.de/fit-connect/submission-api/problems/constraint-violation | 400 Bad Request | |
+| https://schema.fitko.de/fit-connect/submission-api/problems/request-binding-error | 400 Bad Request | |
+| https://schema.fitko.de/fit-connect/submission-api/problems/no-handler-found | 404 Not Found | |
+| https://schema.fitko.de/fit-connect/submission-api/problems/missing-request-part | 400 Bad Request | |
+| https://schema.fitko.de/fit-connect/submission-api/problems/missing-request-parameter | 400 Bad Request | |
+| https://schema.fitko.de/fit-connect/submission-api/problems/socket-timeout | 504 Gateway Timeout | |
+| https://schema.fitko.de/fit-connect/submission-api/problems/type-mismatch | 400 Bad Request | |
+| https://schema.fitko.de/fit-connect/submission-api/problems/multipart-error | 400 Bad Request | |
+| https://schema.fitko.de/fit-connect/submission-api/problems/message-not-readable | 400 Bad Request | |
+| https://schema.fitko.de/fit-connect/submission-api/problems/method-not-supported | 405 Method Not Allowed | |
+| https://schema.fitko.de/fit-connect/submission-api/problems/media-type-not-supported | 415 Unsupported Media Type | |
+| https://schema.fitko.de/fit-connect/submission-api/problems/media-type-not-acceptable | 406 Not Acceptable | |
+| https://schema.fitko.de/fit-connect/submission-api/problems/unsupported-operation | 501 Not Implemented | |
+| https://schema.fitko.de/fit-connect/submission-api/problems/invalid-state-transition | 500 Internal Server Error | |
+
+### Fachliche Fehler
+
+| `type` des fachlichen Fehlers | Titel laut [httpstatus.es](https://httpstatuses.com/) | Beschreibung |
+|---------------------------------------------------------------------------|---------------------------------------------------------|--------------|
+| https://schema.fitko.de/fit-connect/submission-api/problems/access-forbidden | 403 Forbidden | |
+| https://schema.fitko.de/fit-connect/submission-api/problems/submission-already-fetched | 410 Gone | |
+| https://schema.fitko.de/fit-connect/submission-api/problems/submission-incomplete | 422 Unprocessable Entity | |
+| https://schema.fitko.de/fit-connect/submission-api/problems/submission-not-found | 404 Not Found | |
+| https://schema.fitko.de/fit-connect/submission-api/problems/not-in-acknowledgeable-state | 422 Unprocessable Entity | |
+| https://schema.fitko.de/fit-connect/submission-api/problems/attachment-not-announced | 422 Unprocessable Entity | |
+| https://schema.fitko.de/fit-connect/submission-api/problems/attachment-not-found | 404 Not Found | |
+| https://schema.fitko.de/fit-connect/submission-api/problems/destination-not-found | 404 Not Found | |
+| https://schema.fitko.de/fit-connect/submission-api/problems/empty-attachment | 400 Bad Request | |
+| https://schema.fitko.de/fit-connect/submission-api/problems/jwk-not-valid | 422 Unprocessable Entity | JWK fachlich nicht zulässig. Details stehen im Feld `detail`. |
+
+## Verhalten von API Clients
+
+API-Clients sollten gemäß RFC 7231 so implementiert sein, dass auch unbekannte HTTP Statuscodes gemäß ihrer
+Statusklasse (`Axx, A=[1,5]`) interpretiert werden können:
+> "HTTP status codes are extensible. HTTP clients are not required to understand the meaning of
+> all registered status codes, though such understanding is obviously desirable. However, a client
+> MUST understand the class of any status code, as indicated by the first digit, and treat an
+> unrecognized status code as being equivalent to the x00 status code of that class, with the
+> exception that a recipient MUST NOT cache a response with an unrecognized status code."
diff --git a/versioned_sidebars/version-0.14-sidebars.json b/versioned_sidebars/version-0.14-sidebars.json
new file mode 100644
index 0000000000000000000000000000000000000000..59006c20fefa41ce34c2b9a3aa951a073ec3d8b1
--- /dev/null
+++ b/versioned_sidebars/version-0.14-sidebars.json
@@ -0,0 +1,150 @@
+{
+ "version-0.14/defaultSidebar": [
+ {
+ "type": "doc",
+ "id": "version-0.14/intro"
+ },
+ {
+ "type": "doc",
+ "id": "version-0.14/roadmap"
+ },
+ {
+ "type": "doc",
+ "id": "version-0.14/changelog"
+ },
+ {
+ "type": "doc",
+ "id": "version-0.14/glossary"
+ },
+ {
+ "type": "doc",
+ "id": "version-0.14/account"
+ },
+ {
+ "type": "doc",
+ "id": "version-0.14/status-and-error-codes"
+ },
+ {
+ "collapsed": true,
+ "type": "category",
+ "label": "Getting Started",
+ "items": [
+ {
+ "type": "doc",
+ "id": "version-0.14/getting-started/overview"
+ },
+ {
+ "type": "doc",
+ "id": "version-0.14/getting-started/authentication"
+ },
+ {
+ "type": "doc",
+ "id": "version-0.14/getting-started/submission-structure"
+ },
+ {
+ "type": "doc",
+ "id": "version-0.14/getting-started/metadata"
+ },
+ {
+ "type": "doc",
+ "id": "version-0.14/getting-started/encryption"
+ },
+ {
+ "type": "doc",
+ "id": "version-0.14/getting-started/event-log"
+ },
+ {
+ "collapsed": true,
+ "type": "category",
+ "label": "Versenden",
+ "items": [
+ {
+ "type": "autogenerated",
+ "dirName": "getting-started/sending"
+ }
+ ]
+ },
+ {
+ "collapsed": true,
+ "type": "category",
+ "label": "Empfangen",
+ "items": [
+ {
+ "type": "autogenerated",
+ "dirName": "getting-started/receiving"
+ }
+ ]
+ }
+ ]
+ },
+ {
+ "collapsed": true,
+ "type": "category",
+ "label": "Spezifikationen/Schemata",
+ "items": [
+ {
+ "type": "autogenerated",
+ "dirName": "apis"
+ }
+ ]
+ },
+ {
+ "collapsed": true,
+ "type": "category",
+ "label": "Detailinformationen",
+ "items": [
+ {
+ "type": "doc",
+ "id": "version-0.14/details/crypto"
+ },
+ {
+ "type": "doc",
+ "id": "version-0.14/details/destination-management"
+ },
+ {
+ "type": "doc",
+ "id": "version-0.14/details/jwk-creation"
+ },
+ {
+ "type": "doc",
+ "id": "version-0.14/details/callbacks"
+ },
+ {
+ "type": "doc",
+ "id": "version-0.14/details/schema-reference"
+ },
+ {
+ "type": "doc",
+ "id": "version-0.14/details/pgp-export"
+ },
+ {
+ "collapsed": true,
+ "type": "category",
+ "label": "Authentifizierung",
+ "items": [
+ {
+ "type": "autogenerated",
+ "dirName": "details/authentication"
+ }
+ ]
+ },
+ {
+ "collapsed": true,
+ "type": "category",
+ "label": "Authentifizierung (intern)",
+ "items": [
+ {
+ "type": "autogenerated",
+ "dirName": "details/infrastructure-docs"
+ }
+ ]
+ }
+ ]
+ },
+ {
+ "type": "link",
+ "label": "Impressum",
+ "href": "https://www.fitko.de/Impressum"
+ }
+ ]
+}
diff --git a/versions.json b/versions.json
index 0d4f101c7a37a4c875e6999bee1a287fdb733380..c8816c7f7bdff5c9f3881385e709d1f889130dc0 100644
--- a/versions.json
+++ b/versions.json
@@ -1,2 +1,3 @@
[
+ "0.14"
]