diff --git a/docs/apis/delivery-service.mdx b/docs/apis/delivery-service.mdx
index aad49317d95eec01f511599f3a3b98ea5c495ee1..a13bdabeab48982c46eb3be216f1f72bb49fd95f 100644
--- a/docs/apis/delivery-service.mdx
+++ b/docs/apis/delivery-service.mdx
@@ -1,6 +1,6 @@
---
-title: Zustelldienst
+title: Zustelldienst-API
---
import ApiSpec from '../../src/components/ApiSpec'
-<ApiSpec />
\ No newline at end of file
+<ApiSpec specUrl="https://fitko.uber.space/v1.0.0-alpha12/zustelldienst.yml"/>
\ No newline at end of file
diff --git a/docs/apis/routing.mdx b/docs/apis/routing.mdx
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..6537206527f269b6630d5a737139693918e7790e 100644
--- a/docs/apis/routing.mdx
+++ b/docs/apis/routing.mdx
@@ -0,0 +1,7 @@
+# Routing-API
+
+> Für diesen Dienst ist die API-Spezifikation noch ausstehend!
+
+import ApiSpec from '../../src/components/ApiSpec'
+
+<ApiSpec specUrl="https://restapi-v3-st.zfinder.de/swagger.json"/>
diff --git a/docs/authentication.md b/docs/authentication.md
index 71b1fdfab82611c40d43e50f2e7e2d337e6df000..b44adb7b18237abfface9e57b0ba01954867e2fa 100644
--- a/docs/authentication.md
+++ b/docs/authentication.md
@@ -1,32 +1,3 @@
# Registrierung und Client-Verwaltung
-Der bisherige Proof of Concept ist ausgelaufen und FIT-Connect wird nun als Projekt des IT-Planungsrats aufgebaut. Im Rahmen der Projektumsetzung wird die aktuelle API finalisiert und technisch umgesetzt.
-
-Bei Interesse an einem Zugang zu einem Testsystem zur technischen Evaluierung der Anbindung von Fachverfahren und Onlinediensten an FIT-Connect melden Sie sich gerne unter fit-connect@fitko.de.
-
-## Hinweise zum Aufruf der API mit OAuth2
-
-Um das von ihnen gewünschte API im Rahmen ihrer Anwendung aufzurufen, Gehen sie wie folgt vor:
-
-
-
-Verfahrensschritte:
-
-1) Die Clientanwendung sendet die Authentifizierungsanforderung an den Autorisierungsserver, um ein Zugriffstoken zu erhalten.
-
-2) Der Autorisierungsserver überprüft die Anforderung und generiert ein Zugriffstoken für den Client.
-
-3) Der Client verwendet dieses Zugriffstoken, um HTTP-Anforderungen an das API-Gateway zu senden.
-
-4) Das API-Gateway führt dann folgendes aus:
- - Identifiziert die Anwendung anhand der client_Id.
- - Überprüft das Token lokal oder remote, wenn es lokal nicht möglich ist.
- - Überprüft, ob die angeforderte Ressource Teil des Bereichs im Token ist.
-
-Wurden alle Prüfschritte erfolgreich absolviert, wird die Anfrage an den Zustelldienst übergeben.
-
-Nach Bearbeitung der Anfrage im Zustelldienst wird die Antwort des Zustelldienstes an den Client zurückgesendet.
-
-FÜr nähere Details und Beispiele siehe:
-âž¡ [OAuth](./Detailinformationen/OAuth.md)
-
+- Doku zur Nutzung von OAuth und ggf. Nutzung des Self-Service-Portals bzw. Kontaktmöglichkeiten
diff --git a/docs/event-log.mdx b/docs/event-log.mdx
new file mode 100644
index 0000000000000000000000000000000000000000..c6827a47fa9d189f9b9ac775944c30ee3c58d082
--- /dev/null
+++ b/docs/event-log.mdx
@@ -0,0 +1,5 @@
+# Eventlog
+
+TBD
+
+> Ein neuer Artikel aber nochmal etwas zielgerichteter und knackiger die Verwertung und den Nutzen für die API-Nutzer beschreiben. Ebenfalls sollte man dann auch die Verarbeitung der des Log mit kurzen Beispielen/technischen Erläuterungen beschreiben (Erläuterungen Validierung von einzelner Claims und der Signatur, Hinweis das der Log ein Array aus JWTs mit Compact Serialization mit Base64 ist, weshalb jedes Objekt entnommen und dekodiert werden muss, etc.).
\ No newline at end of file
diff --git a/docs/getting-started/account.mdx b/docs/getting-started/account.mdx
index e69de29bb2d1d6434b8b29ae775ad8c2e48c5391..cf608721db752a138a83a45435219dd9cdabaffd 100644
--- a/docs/getting-started/account.mdx
+++ b/docs/getting-started/account.mdx
@@ -0,0 +1,124 @@
+# OAuth Authentifizierung
+
+- Abgleichen mit Dokumentation von Lilith, ob Code-Beispiele vorhanden, ansonsten kann das weg
+
+Das folgende Dokument beschreibt wie die OAuth-basierte Authentifizierung mithilfe des FIT-Connect Commandline-Tools funktioniert. Dafür werden entweder OAuth-Credentials (Client-ID, Client-Secret) sowie die Adresse des OAuth-Token-Endpunktes oder ein Zugang zum FIT-Connect Developer Portal benötigt. Weitere Informationen dazu wie die OAuth-Authentifizierung selbst implementiert werden kann befinden sich in [Authentifizierung von Fachanwendungen](Authentifizierung_von_Fachanwendungen.md) und [Authentifizierung von Usern an Zustelldiensten](Authentifizierung_von_Usern.md) - außerdem ist hier das Konzept zu [Zustellberechtiungs-Scopes](Zustellberechtigungs-Scopes.md) zu beachten.
+
+## Installation CLI-Tool
+
+Das CLI-Tool kann über den Python Paketmanager pip installiert werden. Dafür muss Python 3.6 oder neuer installiert sein.
+
+```bash
+pip install fitconnect-cli
+```
+
+Nach der Installation von fitconnect-cli kann mithilfe des folgenden Kommandos eine neue FIT-Connect API-Konfiguration angelegt werden.
+
+```bash
+ fitconnect create_config --config=test_sender.json
+```
+
+Hierbei muss ausgewählt werden, ob ein Sende- oder Empfangsdienst betrieben werden und ob automatisch RSA-Keys für die Generierung von JWTs angelegt werden sollen.
+
+```bash
+ fitconnect create_config --config=test_sender.json
+? Do you want to setup a config for a sender (e.g. onlineservice) or receiver? sender
+? Oauth Token URL: https://fit-connect.de/oauth/token
+? Client id: nnXVC6DSPG9BkoMw5NXOur4RPOkEpLMMwYFbycIo
+? Client secret: Yj9PduOSsjGzwsIDXGRLrzDarZdKE4QPXuil21FqJGlVnZTDqcM7S5FruJA4kv1L3K4PCmAqAuK11y2fwu2MDVBiDUgWTBLc1e3H8tV0sD5PzlEiV7nCUAYBP7u8tG01
+? Do you want to create a jwt signature key? yes
+-----BEGIN PUBLIC KEY-----
+MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAv6ixhhwQm8nTAAtgSBRP
+gNUuucb4e9Y0G2n8SBy4aEflIfrqKqqM1LRzLLnqvFiiiXI8heTx6AvMjQsqScHt
+0SDONWliz2s+lA80xyW+nJRKI/WUxXOZX0xqQD8XL6ZksE+nhZ9bKo7o5lXwQF6C
+p3BGV30kPgfGOCNPg4P5QpsP9UUfGvz1OXNNUPoMKovyXHAd7k4gI6TWZSqCbJwG
+3Y3v7WZKIb/1PGhkc7oR+SJ3t0jYJByRnhTyQAoMpODBlPz27/MOkozoNaAkjf6b
+pKcnasYCJHkuAcCS7pI5VZz7YNZPl3dm0g4woOsJeEdV2B2fyv4E0uYw2eRFsxlu
+/TdAid6UAf1fMz4JVoJ3dsca+1zySX7S4P+pVjNXQW0cGVO4hksvQSFwhBpnEAEw
+rHBdVV15UVT98cFEfhlv3utI6KdXJqpnWBm8g9K3tFSAoTNXz81XAnFnZgLqA4If
+bws0R7Zu8fXYMQuGS2APzhH4QWVcqrgWizzg0P39W0f+44DIUgc6LJ344Iog3f2j
+ix3WeKi/VrKfJCLCisZyDUJNze9WfWVersGVMsgnND84y9+EG2Pp/m99jF+asrDi
+gJa7FZjjoXRJVhTBcGQ1eW95G+Vm/oKkAp+unFBCqNtS610vQzviM147KtIvUrpj
+q1r1v0Vzj+qk9WEGVz/Gl4MCAwEAAQ==
+-----END PUBLIC KEY-----
+```
+
+Nachdem der Assistent abgeschlossen wurde, sollte im aktuellen Verzeichnis eine JSON-Datei mit allen benötigten Konfigurationen angelegt worden sein. Diese lässt sich nun mit einem FIT-Connect-API-Client oder dem fitconnect-cli weiterbenutzten.
+
+## Generierung von JWTs
+
+Mithilfe der fitconnect-cli können JWTs zum Abrufen von bzw. Versenden von Anträgen generiert werden. Dabei wird zuerst über das OAuth 2 Client Credentials Verfahren ein JWT abgerufen und dann falls Antreäge versendet werden sollen der sogenannte Online-Service-Token mit eingeschränkten Berechtigungen davon abgeleitet.
+
+### Abrufen von JWTs für antragssendene Systeme (Onlineservices)
+
+Für die Generierung von JWTs zum Versenden von Anträgen muss neben der Konfiguration außerdem über den Parameter *destination* angegeben werden, an welche Destination-IDs Anträge gesendet werden sollen.
+
+```bash
+fitconnect get_jwt --config=test_sender.json --destination "d771f1d8-6967-4740-9668-82c5a910a29b"
+```
+
+Bei erfolgreicher Generierung erhält man ein JSON-Objekt mit einem User-Token und einen Online-Service-Token zurück. Diese können dann dazu verwendet werden um mithilfe eines FIT-Connect-API-Client oder CURL einen Antrag versenden.
+
+```json
+{
+ "online-service-token": "..online-service-token...",
+ "token": "...token..."
+}
+```
+
+Der dekodierte Inhalt eines Online-Service-Tokens sieht z.B. so aus:
+
+```json
+{
+ "iss": "FITCONNECT",
+ "exp": 1623275003,
+ "iat": 1623260603,
+ "domains": [],
+ "publicKey": {
+ "n": "...RSA Token...",
+ "e": "AQAB",
+ "kty": "RSA"
+ },
+ "scope": [
+ "leika:991080082520",
+ "region:03254021",
+ "leika:991080082520+region:03254021"
+ ],
+ "clientType": "sender"
+}
+```
+
+Und der eines Tokens so:
+
+```json
+{
+ "iss": "Onlineservice",
+ "exp": 1623267803,
+ "iat": 1623260603,
+ "domains": [],
+ "scope": [
+ "destination:d771f1d8-6967-4740-9668-82c5a910a29b"
+ ],
+ "clientType": "user-sender"
+}
+```
+
+Ein CURL-Request um dann mit diesen Tokens auf die API zuzugreifen, könnte z.B. so aussehen:
+
+```bash
+curl -i -H "Accept: application/json" -H "Content-Type: application/json" -H "token: ...token..." -H "online-service-token: ...online-service-token..." https://fit-connect-url.einfügen
+```
+
+### Abrufen von JWTs für antragsempfangende Systeme (Fachverfahren / virtuelle Poststellen
+
+Wenn ein JWT zum Abrufen von Anträgen generiert werden soll, kann auf den Parameter destination verzichtet werden.
+
+```bash
+fitconnect get_jwt --config=test_receiver.json
+```
+
+Als Antwort erhält man einen (vom Authentifizierungsserver via OAuth Client Credentials abgerufenen) JWT, welchen man zur Authentifizierung beim Abrufen von Anträgen verwenden kann.
+
+```bash
+curl -i -H "Accept: application/json" -H "Content-Type: application/json" -H "token: ...token..." https://fit-connect-url.einfügen
+```
diff --git a/docs/getting-started/authentication/applications.mdx b/docs/getting-started/authentication/applications.mdx
new file mode 100644
index 0000000000000000000000000000000000000000..df605e5a838f6c8e97db105433eefd61055ffe15
--- /dev/null
+++ b/docs/getting-started/authentication/applications.mdx
@@ -0,0 +1,84 @@
+# Authentifizierung von Fachanwendungen
+
+**=> Beschreibt Zielkonzept, aber nich von v1, dadurch in Konzeption-Repo verschieben**
+
+Fachanwendungen haben die Möglichkeit FIT-Connect Anträge abzurufen. Dafür müssen sie sich mithilfe von oauth2 "Client-Credentials" authentifizieren. Diese erhalten Behörden und andere Abrufberechtigte, nach einer Anmeldung im Self-Service-Portal der FITKO. (TODO: link)
+
+Für jede Destination müssen folgende Informationen im Self-Service-Portal bereitgestellt werden
+
+Entweder:
+
+- Liste der [LeiKa-IDs](https://www.it-planungsrat.de/DE/Projekte/Anwendungen/LeiKaPlus/leiKaPlus.html) und [Amtlicher Gemeindeschlüssel](https://www.statistikportal.de/de/gemeindeverzeichnis)
+
+Oder:
+
+- Name und Bezeichung der angeboteten Leistungen, wenn diese nicht Teil des Leistungskataloges sind
+
+Außerdem
+
+- Der Public Key zur Verschlüsselung der Antragsdaten
+- Der Public Key der Fachanwendung zur Signaturprüfung
+- Callback Endpunkte
+- Referenzen zu allen von diesem Endpunkt unterstützen Schemas
+
+Nach anlegen einer Destination erhält die Behörde, die für die Destination verantwortlich ist die OAuth Client Credentials. Mit diesen kann sich das Fachverfahren authentifizieren und erhält dafür einen JWT. Mit diesem JWT ist dann ein Abruf der hinterlegten Anträge möglich
+
+
+
+<img src="../../assets/images/oauth/JWT-Konzept-Fachanwendung.png" alt="JWT Konzept" width="400"/>
+
+### Anforderung an die JWT-Tokens
+
+Die vom Auth Server generierten JWTs müssen nach [RFC 7519](https://tools.ietf.org/html/rfc7519) über folgende Attribute verfügen:
+
+#### Header
+
+Entsprechend [RFC 7519 Abschnnitt 8](https://tools.ietf.org/html/rfc7519#section-8):
+
+| Feld | Inhalt | **Erläuterung** |
+| ---- | ------ | ----------------------------------------- |
+| typ | JWT | Es handelt sich um einen JWT. |
+| alg | RS512 | Der JWT verwendet RSASSA-PSS und SHA-512. |
+
+**Beispiel**
+
+```json
+{
+ "typ":"JWT",
+ "alg":"HS256"
+}
+```
+
+#### Body des User-JWT-Tokens
+
+Entsprechend den [standartisierten Feldern](http://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms):
+
+| Feld | Inhalt | **Erläuterung** |
+| ---------- | ------------------------------------- | ------------------------------------------------------------ |
+| iat | Unix Timestamp | Zeitpunkt wann der Token ausgestellt wurde als Unix Timestamp. |
+| exp | Unix Timestamp | Zeitpunkt wann der Token abläuft als Unix Timestamp (Token sollte 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)). |
+| scope | Liste von Zustellberechtigungs-Scopes | Eine Liste der Zustellberechtigungs-Scopes, für die der JWT einen Abruf erlaubt. |
+| clientType | subscriber | Gibt an, das es sich um einen Token für ein antragsempfangendes System (Fachanwendung oder virtuelle Poststelle) handelt. |
+
+**Beispiel**
+
+```json
+{
+ "iat":"1620072619",
+ "exp":"1620079819",
+ "scope": ["36141427-d405-40a4-8f8b-3592d544e85b", "655c6eb6-e80a-4d7b-a8d2-3f3250b6b9b1"],
+ "clientType": "subscriber"
+}
+
+```
+
+## Validierung der JWT-Tokens durch den Zustelldienst
+
+Beim Abruf am Zustelldienst muss dieser bzw. das API-Gateway überprüfen, ob der JWT-Token valide ist. Dafür sollten mindestes folgende Überprüfungen durchgeführt werden:
+
+1. Überprüfen, ob es sich um einen JWT mit einer **RSASSA-PSS (PS512)** Signatur handelt.
+2. Überprüfen, ob der JWT noch gültig ist.
+3. Überprüfen, ob der JWT für max. 4h ausgestellt wurde.
+3. Mithilfe des Public Keys des Authentifizierungsservers die Signatur des JWT überprüfen.
+4. Überprüfen, ob die Destination-ID, die abgerufen werden soll teil der in den Zustellberechtigungs-Scopes (**scope** Parameter in den JWTs) des JWTs ist. (Zugangsberechtigung der Fachanwendung).
+
diff --git a/docs/getting-started/authentication/users.mdx b/docs/getting-started/authentication/users.mdx
new file mode 100644
index 0000000000000000000000000000000000000000..25fe95b90ba941fadd294f45bdca9c23f0f2c6bc
--- /dev/null
+++ b/docs/getting-started/authentication/users.mdx
@@ -0,0 +1,148 @@
+# Authentifizierung von Usern an Zustelldiensten
+
+**=> Beschreibt Zielkonzept, aber nich von v1, dadurch in Konzeption-Repo verschieben**
+
+Jeder Onlineantragsdienst muss bei FIT-Connect registriert sein, um FIT-Connect Formulare darstellen und übermitteln zu können. Bei der Registrierung von Onlinediensten wird festgelegt, welche Anträge die Onlinedienste auf welchen Domains ausspielen dürfen. Im Rahmen dieses Prozesses wird für jeden Onlinedienst außerdem ein Public Key hinterlegt. Nach der Anmeldung erhält jeder Onlineantragsdienst OAuth2-Credentials für den Authentifizierungstyp "Client-Credentials".
+
+Eine Registrierung eines Onlinedienstes ist über das Self-Service-Portal der FITKO möglich. (TODO: link) Dort müssen folgende Informationen über einen Onlinedienst hinterlegt werden:
+
+- Freigegebene Domains, von denen der Onlinedienst Formulare übermittelt.
+- Erlaubte Zustellberechtigungs-Scopes, an die Anträge übermittelt werden dürfen.
+- Ein Public Key des Onlinedienstes, die er für die Erstellung von JWTs benutzt.
+
+Wenn ein Onlinedienst einem User ermöglichen möchte, einen Antrag zu übermitteln, muss er mithilfe seiner Client-Credentials beim FIT-Connect-Authentifizierungsserver einen JWT-Access-Token (Onlinedienst-Token) abrufen. Dieser Onlinedienst-Token enthält den Public-Key, der für den Onlinedienst bei der Anmeldung festgelegt wurde, im signierten Datensatz.
+
+Nun muss der Onlinedienst auf Basis des zum Public Key gehörenden Private Key einen weiteren JWT Token (User-Token) erzeugen, der Informationen dazu enthält, das der Onlinedienst dem User erlaubt, einen Antrag an eine spezifische Destinationen zu übermitteln.
+
+Wenn der User nun einen Antrag an den Onlinedienst übermittelt, muss dieser sowohl den User-Token als auch den Onlinedienst-Token im Header mitübermitteln. Mithilfe der beiden Tokens kann das FIT-Connect API-Gateway nachvollziehen, von wo ein Antrag zu welcher Destination übermittelt wird und kann somit überprüfen, ob der User/Onlinedienst dafür autorisiert ist.
+
+<img src="../../assets/images/oauth/JWT_konzept.png" alt="JWT Konzept" width="400"/>
+
+### Warum ist die anonyme Authentifizierung notwendig?
+
+Im Rahmen von FIT-Connect soll das massenhafte absenden (spammen) von Anträgen über Ratelimiting verhindert werden und es sollen nur vertrauenswürdige Webseiten, die dem FIT-Connect-Standards entsprechen, die Möglichkeit bekommen, Anträge über FIT-Connect zu übermitteln. Um diese Maßnahmen umsetzen und einen User über mehrere Requests hinweg sicher identifizieren zu können, ist eine Form der anonymen Authentifizierung notwendig.
+
+## Generierung der JWT-Tokens
+
+Jedes Backend eines FIT-Connect Onlineantragsdienstes muss über ein System verfügen, welches JWT-Tokens für diese Instanz erzeugen und an den Browser des Users übermitteln kann. Es sollte dabei eine geeignete Form von Rate-Limiting, für die Ausstellung der Public Keys passend zum Usecase des Onlinedienstes implementieren. Es sollte die Menge der mit einem JWT-Token freigegebenen Destinationen minimieren. **Es dürfen in denen vom Onlineservice generierten JWT-Tokens keinen Informationen hinterlegt werden, die zur Identifikation des Users führen könnten.**
+
+### Anforderungen an die Keypairs
+
+Der Onlinedienst muss zur Registrierung bei FIT-Connect neben den Angaben dazu, welche Destinationen er unter welchen Domains verwendenden möchte, auch noch einen Public Key eines Keypairs, das nach folgenden Standards erzeugt wurde, übermitteln:
+
+| Feld | Inhalt | **Erläuterung** |
+| ------------------ | ---------- | ------------------------------------------------------------ |
+| Hashingalgorithmus | SHA-512 | Algorithmus der zur digitalen Signatur des Keys verwendet werden muss an. Dieser muss im Fall von FIT-Connect immer SHA-512 sein. (vgl. [BSI TR-02102-1 Tabelle 4.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html)) |
+| Keylänge | 4096 | Länge des zugrundeliegenden RSA-Keys. Diese entspricht der Empfehlung des BSIs für ab dem Jahr 2023. (vgl. [BSI TR-02102-1 Tabelle 3.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.html)) |
+| Signaturstandard | 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) |
+
+Bei der Erstellung und Signierung des Keys sind alle Regeln 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.
+
+### Anforderung an die JWT-Tokens
+
+Die vom Onlinedienst generierten JWT-Tokens müssen nach [RFC 7519](https://tools.ietf.org/html/rfc7519) über folgende Attribute verfügen:
+
+#### Header
+
+Entsprechend [RFC 7519 Abschnnitt 8](https://tools.ietf.org/html/rfc7519#section-8):
+
+| Feld | Inhalt | **Erläuterung** |
+| ---- | ------ | ----------------------------------------------- |
+| typ | JWT | Es handelt sich um einen JWT-Token. |
+| alg | RS512 | Der JWT Token verwendet RSASSA-PSS und SHA-512. |
+| | | |
+
+**Beispiel**
+
+```json
+{
+ "typ":"JWT",
+ "alg":"PS512"
+}
+```
+
+#### Body des User-JWT-Tokens
+
+Entsprechend den [standartisierten Feldern](http://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms):
+
+| Feld | Inhalt | **Erläuterung** |
+| ---------- | ------------------------- | ------------------------------------------------------------ |
+| iat | Unix Timestamp | Zeitpunkt wann der Token ausgestellt wurde als Unix Timestamp. |
+| exp | Unix Timestamp | Zeitpunkt wann der Token abläuft als Unix Timestamp (Token sollte 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)). |
+| scope | Liste von Destination-IDs | Eine Liste der Destination-IDs (im Stile der Zustellberechtigungs-Scopes geprefixed), für die der JWT eine Übermittlung erlaubt. |
+| sid | UUID4 der Session | Eine unique ID zur Identifizierung der Session (muss garantiert für jede Übermittlung anders sein) |
+| iss | ID des Onlinedienstes | Wird bei der Anmeldung des Onlinedienstes festgelegt und dient zur Identifizierung am API-Gateway |
+| domains | Liste von Domains | Eine Liste der Domains, von denen der Onlineservice Anträge übermitteln kann. Sie muss einem Subset der Domains entsprechen, die im domains Feld des Onlinedienst-JWT angegeben wurden. (Subdomains müssen explizit angegeben werden) |
+| clientType | user-sender | Gibt an, das es sich um denn abgeleiteten User Token eines Onlineservices handelt, mit dem Anträge eingereicht werden können. |
+
+**Beispiel**
+
+```json
+{ Â
+ "iat":"1620072619", Â
+ "exp":"1620079819",
+ "scope": ["destination:655c6eb6-e80a-4d7b-a8d2-3f3250b6b9b1"],
+ "sid": "8d4dcbfd-a528-4e9b-abc3-477c4cc857aa",
+ "iss": "639c5be8-eb9c-4741-834e-4ad11629898a",
+ "clientType": "user-sender",
+}
+
+```
+
+#### Body des Onlinedienst-JWT-Tokens
+
+Entsprechend den [standartisierten Feldern](http://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms):
+
+| Feld | Inhalt | **Erläuterung** |
+| ---------- | ------------------------------------- | ------------------------------------------------------------ |
+| iat | Unix Timestamp | Zeitpunkt wann der Token ausgestellt wurde als Unix Timestamp. |
+| exp | Unix Timestamp | Zeitpunkt wann der Token abläuft als Unix Timestamp (Token sollte 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)). |
+| scope | Liste von Zustellberechtigungs-Scopes | Eine Liste der Zustellberechtigungs-Scopes oder Präfixes, für die der JWT eine Übermittlung erlaubt. |
+| publlicKey | Public Key des Onlinedienstes | Der Public Key, der dem Onlinedienst bei der Anmeldung zugeordnet wurde im JWK Format nach [RFC-7517](https://tools.ietf.org/html/rfc7517) |
+| aud | ID des Onlinedienstes | Wird bei der Anmeldung des Onlinedienstes festgelegt und dient zur Identifizierung des Onlineservices |
+| domains | Liste von Domains | Eine Liste der Domains, von denen der Onlineservice Anträge übermitteln kann. (Subdomains müssen explizit angegeben werden) |
+| clientType | sender | Gibt an, das es sich um einen Token für einen Onlineservice handelt, der Anträge versenden kann. |
+
+**Beispiel**
+
+```json
+{ Â
+ "iat":"1620072619", Â
+ "exp":"1620079819",
+ "scope": ["leika:99108008252000", "leika:99108008252000+region:08110000"],
+ "clientType": "sender",
+ "publicKey": {
+ "kty": "RSA",
+ "e": "AQAB",
+ "key_ops": ["verify"],
+ "alg": "PS512",
+ "n": "...Public Key..."
+ },
+ "aud": "639c5be8-eb9c-4741-834e-4ad11629898a",
+ "domains": ["example.com", "sub.example.com"]
+}
+
+```
+
+## Validierung der JWT-Tokens durch die Sender-API/API-Gateway
+
+Bei jedem eingegangen Antrag muss der JWT-Token des Users validiert werden, um so Missbrauch der Antragsübermittlungsschnittstelle zu verhindern und nur korrekt implementierten FIT-Connect-Clients Zugang zur Antragsübermittlung zu geben.
+
+Nach dem Anlegen eines Antragsübertragungsprozesses kann auf diesen nur mit JWT-Tokens von demselben Onlinedienst und mit derselben Session-ID zugegriffen werden.
+
+Das API-Gateway muss die JWT-Tokens validieren:
+
+1. Überprüfen ob es sich um einen JWT mit einer **RSASSA-PSS (PS512)** Signatur handelt.
+2. Überprüfen, ob diese noch gültig sind und
+ 1. der User-JWT-Token maximal für 2h ausgestellt wurde.
+ 2. der Onlinedienst-JWT-Token für max. 24h ausgestellt wurde.
+3. Mithilfe des Public Keys des Authentifizierungsservers die Signatur des Onlinedienst-JWT überprüfen.
+4. Mithilfe des im JWT-Token des Onlinedienst enthaltenen Public Key die Signatur des User JWT überprüfen
+5. Überprüfen, ob die Destination-ID teil der in den Zustellberechtigungs-Scopes (**scope** Parameter in den JWT Tokens) beider JWT-Tokens ist. (Zugangsberechtigung des Onlinedienstes und des Users). Bzw. ob die LeiKa/Region entsprechend der Destination freigegeben ist.
+6. Überprüfen, ob die Website (origin), von der der Antrag abgesendet wurde, im domain Feld beider JWKs verzeichnet ist. (Verhindern von gefälschten Onlinediensten, die nicht den FIT-Connect-Standards entsprechen)
+7. Das API-Gateway kann aufgrund der folgenden Parameter Rate-Limiting für API-Calls (angepasst an die jeweiligen Use Cases des Onlineservices) betreiben:
+
+- sid
+- IP-Addresse des Users
+- Website von der der Antrag übermittelt wird bzw. das Fehlen eines Referers
+- Onlineservice-ID
diff --git a/docs/getting-started/encryption.mdx b/docs/getting-started/encryption.mdx
new file mode 100644
index 0000000000000000000000000000000000000000..e43dc2913a601fe31df13a7e7bb0bd72acadb567
--- /dev/null
+++ b/docs/getting-started/encryption.mdx
@@ -0,0 +1,358 @@
+---
+title: Verschlüsselung
+---
+
+# Verschlüsselte Übertragung
+
+## Einleitung
+
+FIT-Connect verwendet zur Übertragung von Antragsdaten und Antragsmetadaten (abgesehen von den für die Übermittlung zwingend notwendigen Daten, z.B. Destination-ID) 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.
+
+Die Informationen auf dieser Seite sind relevant, wenn man:
+
+- ein **Fachverfahren** mit FIT-Connect-Anbindung entwickelt oder aufsetzt
+- einen **Onlinedienst** mit FIT-Connect-Anbindung entwickelt oder aufsetzt
+
+### 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.
+Bei FIT-Connect ist die Zielsetzung einen möglichst einfachen, sicheren und klar definierten Standard 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 basiert auf dem Ansatz von 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 sein müssen.
+
+<img src="/images/encryption/tls-no-tls.png" alt="Ende-zu-Ende-Verschlüsselung Bedeutung" width="400" height="320" />
+
+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="/images/encryption/pki-check.png" alt="PKI-um Man-in-the-Middle zu verhindern" width="400" height="320" />
+
+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.
+
+## Architektur
+
+Kern von FIT-Connect ist der Zustelldienst, der über die beiden APIs "Application Sender API" und "Application Subscriber API" den Absender (Sender) und Empfänger (Subscriber) eines Antrags verbindet.
+
+Jedes antragsempfangende System (Fachverfahren / virtuelle Poststelle) verfügt über einen oder mehrere Endpunkt, an den Anträge gesendet werden (Zustellpunkt) und einen oder mehrere Endpunkte von denen Anträge verschlüsselt versendet werden (in der Regel: Onlinedienst, App, …).
+
+Ein Antrag wird an einen Zustellpunkt (Zielort) geschickt. Diesen Zustellpunkt legt der Empfänger über die "Application Subscriber API" an. Der Absender muss die Destination-ID des Zustellpunktes kennen und kann dann Anträge über die "Application Sender API" an diese Destination-ID senden.
+
+### Application Sender API
+
+Der Absender muss die Destination-ID vorliegen haben und erfagt über die Application Sender API die Informationen zum Zustellpunkt. Diesen entnimmt er die Liste der möglichen Schemas und wählt eines aus. Sofern es sich um eine verschlüsselte Übertragung handelt, wählt er einen öffentlichen Schlüssel.
+
+Derzeit muss die Destination-ID manuell vom Empfänger an den Absender übergeben werden. Dies soll in Zukunft automatisch mithilfe bestehender Mechanismen, z.B. XZufi oder DVDV passieren.
+
+Das gewählte Schema wird in den Metadaten des Antrags (Application Metadata) eingetragen und legt die Art der Übertragung fest.
+
+### Application Subscriber API
+
+Über die Application Subscriber API werden die Destinations verwaltet, an die die Anträge gesendet werden. Eine Destination enthält eine Liste von Schemas, welche Formate der Empfänger akzeptiert.
+
+Der Empfänger kann in der Destination mehrere Schemas und mehrere öffentliche Schlüssel hinterlegen. Der Absender sucht sich davon für die Übertragung ein Schema und einen öffentlichen Schlüssel aus. Es wird empfohlen, genau ein Schema und genau einen öffentlichen Schlüssel anzubieten.
+
+Es ist geplant, dass die hinterlegten öffentlichen Schlüssel so organisiert werden, dass ein kontrolliertes Key-Rollover stattfinden kann. Dazu werden zu den Schlüsseln die Gültigkeitszeiträume ergänzt.
+
+### Ablauf eines Antrags aus Bürger*innen-Client-Perspektive
+
+Wenn eine Bürger*in nun einen Antrag im Web oder in einer App übermitteln möchte, läuft das in der Regel wie folgt ab:
+
+- Bürger*in findet den passenden Antrag über einen Zuständigkeitsfinder.
+- Die Applikation erhält aus dem Zuständigkeitsfinder die passende Destination-ID zum Antrag.
+- Die Applikation ruft über die Sender-API die Formular und Datenstruktur, Verschlüsselungszertifikat, … ab.
+- Die Applikation prüft das Verschlüsselungszertifikat.
+- Die Applikation übermittelt die Antragsdaten und optional einen Public Key des Users verschlüsselt an die Sender-API und erhält dafür einen Status-Token.
+- Mit dem Status-Token ruft die Applikation verschlüsselte Statusinformationen zum Antrag aus der Sender-API ab.
+
+**TODO: add here some doc links about oauth**
+
+## Bereitstellung eines Destination-Endpunktes
+
+### Erstellung eines FIT-Connect-kompatiblen JSON Web Keys
+
+JSON Web Keys sind das Austauschformat in dem kryptografische Schlüssel in FIT-Connect zwischen der Destination und dem Onlinedienst ausgetauscht werden. Die kryptografischen Anforderungen an die Keys findet man unter **TODO**. Die Keys sollten bereits dort generiert werden, wo sie am Ende eingesetzt werden. Ein unnötiges übertragen von Privat Keys zwischen Servern/Computern sollte vermieden werden. Sollte dies doch notwendig sein, so muss die Übermittlung wenn dann nur verschlüsselt erfolgen.
+
+Im folgenden eine beispielhafte Schritt-für-Schritt-Anleitung um einen JSON-Web-Key zu generieren:
+
+1. Lokale Generierung eines X.509 zugrundeliegenden RSA-Keys. `openssl genrsa -out fachverfahren1.meineverwaltung.de.key 4096`
+2. Generierung des Zertifikatsrequests `openssl req -new -sha256 -key fachverfahren1.meineverwaltung.de.key -out fachverfahren1.meineverwaltung.de.csr`
+3. Dieser Zertifikatsrequest muss nun von einer Verwaltungs-PKI signiert werden.
+4. Das von der Verwaltungs-PKI signierte Zertifikat muss nun in einen JWK umgewandelt werden: … **TODO(Lilith): einfügen nachdem wir das einmal gemacht haben**
+
+Das dabei entstandene Zertifikat muss zur dem Fachverfahren gehörende Destination hinzugefügt werden
+
+### Anlegen eines Zustellpunktes
+
+Ein Zustellpunkt benötigt mindestens immer ein erlaubtes Fachdaten-Schema sowie einen Verschlüsselungs- und einen Signaturkey. Diese müssen in das Format JSON Web Key konvertiert und über den Zustelldienst als JSON Web Key bereitgestellt werden.
+
+#### Beispiel
+
+```json
+{
+ "publicKeys": {
+ "keys": [
+ {
+ "kty": "RSA",
+ "key_ops": ["wrapKey"],
+ "n": "……(Public Key)……",
+ "e": "AQAB",
+ "alg": "PS512",
+ "kid": "……(Key ID)……",
+ "x5t": "……(Fingerprint)……",
+ "x5c": [
+ "……(base64 encoded root cert)……",
+ "……(base64 encoded intermediate cert)……",
+ "……(base64 encoded cert)……"
+ ]
+ },
+ {
+ "kty": "RSA",
+ "key_ops": ["verify"],
+ "n": "……(Public Key)……",
+ "e": "AQAB",
+ "alg": "PS512",
+ "kid": "……(Key ID)……",
+ "x5t": "……(Fingerprint)……",
+ "x5c": [
+ "……(base64 encoded root cert)……",
+ "……(base64 encoded intermediate cert)……",
+ "……(base64 encoded cert)……"
+ ]
+ }
+ ]
+ },
+ "schemas": [
+ {
+ "schemaSource": "none",
+ "mimeType": "json",
+ },
+ {
+ "schemaSource": "none",
+ "mimeType": "xml",
+ }
+ ],
+ "destinationId": "b444a551-74af-4a98-aa65-d1ffccd385d1"
+}
+```
+
+## Implementierung eines Onlinedienstes
+
+### Abrufen der Endpunktinformationen
+
+### Überprüfen der Json Web Keys
+
+Die JSON Web Keys müssen vor der Verwendung im Client 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).
+
+Weitere Informationen zur Glütigkeitsprü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](Encryption_Key_Requirements.md)" .
+
+### Aufbau der Ãœbertragung
+
+Eine Übertragung über FIT-Connect besteht aus einem Metadatensatz, optionalen Fachdaten und beliebig vielen (0-∞) Dokumenten (Anlagen). Ein Teil der Metadaten enthälten transportrelevante Informationen und werden deshalb unverschlüsselt übertragen. Alle nicht transportrelevanten Metadaten, die Fachdaten und Anlagen werden verschlüsselt übertragen.
+
+Die Metadaten, Fachdaten und Anlagen werden gemäß dem Standard JSON Web Encryption RFC 7516) verschlüsselt. Als Datenformat für die Übertragung wird die sogenannte [JWE-Compact Serialisierung](https://tools.ietf.org/html/rfc7516#section-7.1) verwendet. Alle angehängten Dokumente müssen als Binärdateien und nicht als Strings enkodiert verschlüsselt werden.
+
+Zur Verschlüsselung wird ein JSON Web Key mit dem Typ "wrap_key" verwendet.
+
+#### Beispiel (Metadaten)
+
+```json
+{
+ "contentStructure": {
+ "data": {
+ "schema": {
+ "schemaSource": "none",
+ "mimeType": "json",
+ }
+ },
+ "docs": [
+ {
+ "size": 13046,
+ "purpose": "attachment",
+ "docId": "1",
+ "mimeType": "application/pdf"
+ }
+ ]
+ },
+ "applicationId": "6f7b00f1-2f0c-46da-93c9-ca020aa1758f"
+}
+```
+
+#### Beispiel (Fachdaten)
+
+Bei der verschlüsselten Übertragung der Fachdaten und Anlagen wird der Content-Type "application/jose" (Achtung: jose, nicht json) verwendet.
+
+Beispiel:
+
+```text
+PUT /delivery-service-beta7/sender/destinations/e1009dea-d97e-4104-b389-bf653d8bd30e/applications/6f7b00f1-2f0c-46da-93c9-ca020aa1758f/data HTTP/1.1
+Content-Type: application/jose
+Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6IjM1ZTM2Nzk2LTM1NDAtNDUwMy1iYT...
+
+eyJlbmMiOiJBMjU2R0NNIiwiYWxnIjoiUlNBLU9BRVAtMjU2In0.yTSVS7re6hZKO46aDriHrRFOyc5-
+3TIIrvcKUf2qAfGdH7InufWPCrDyEnazSDI7HtOa5X2MU3iUnmmiEuP-Lef76xTPv2lmL4_lyhW5D8zq
+7zbrIaIaVhtg7ekF1r9Oy9nLsEBQWLD4EWda2PfAibV7iQbOVMn1rVk4DzKtCykj5RSrH96i-lbPVFl-
+Xw_E2G5XsL0gOHrdbAsjTF1h67bvh2hnojc9SH1GnlD0TlUO30n0GKLgC7tNNiLGtNrRo8ih3LUWYo-m
+34Q6NGjaNTycHnWMYZzXHbIcBzYr6WLTsrB07rKXEyrHGLaRL88y2c-ACyEzpgv4qR5DAp98Su2u45ar
+pfGU_7HxX4d-PLEoDfIRnh32nprarbaIesj9Ppgiu7QciWRApcyszk0a5rzZ7Dk_6-ydMfD92H2p3tdt
+OcFhj3XGUshVKec2nRhtCZPOMPTIjxFpozsiRetjZo9LFHzRcvr1eSS_hpteKJ3ltioY9nzt1IX2JqQm
+TGtY.VGOCnGM9LEZP5mUO.LQeKj4SKqsUNsBp4ZRN_56QbS8MQ01YTzRVFStk.Z0YMEua9kvCV7LkeJH
+kprA
+```
+
+
+# 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 des Antrags 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 Antrag 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)……",
+ "x5t": "……(Fingerprint)……",
+ "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)
+
+#### 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. 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.
+
+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 den Endpunkt (bzw. die Destination-ID) abrufbar sein. Das soll sicherstellen, das auch bei bereits versendete Anträgen weiterhin der Antragsstatus 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. 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.
+
+#### JSON Web Signature Header
+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.
+
+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 Subscriber-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) |
diff --git a/docs/getting-started/overview.mdx b/docs/getting-started/overview.mdx
new file mode 100644
index 0000000000000000000000000000000000000000..1755514d0b63d6cb211c189dae10b126f0a7b0f1
--- /dev/null
+++ b/docs/getting-started/overview.mdx
@@ -0,0 +1,41 @@
+# Ãœberblick
+
+## â‘ Account registrieren
+
+> Registrieren Sie sich für ein Zugriff, um mit Ihren Client auf die API zuzugreifen. Im Rahmen der Registrierung bekommen Sie für die gewünschte API die Client-ID und Zugriffdaten mitgeteilt. Da zum aktuellen Zeitpunkt keine Sandbox Umgebung bereitstellt, wird empfohlen, sich für beide Seiten zu registieren, um für komplexere Tests mit einem REST Client die API der Gegenseite anzusprechen (Siehe Postman Nutzung in Schritt 2). ➡ [Registrierung zur API Nutzung](./4_Authentifizierung_und_Autorisierung.md)
+
+## â‘¡ API ausprobieren
+
+> In der Navigation auf linken Seite finden Sie die jeweiligen API Referenzen für die Nutzung der APIs unter den Reitern `Application Sender API` und `Application Subscriber API`
+Für einen einfachen Einstieg zum Test der API können Sie die bereitgestellte Postman Collection nutzen und mit dem Postman REST Client die Anfragen an die API durchführen. Hiermit können Sie auch die Gegenseite (Sender oder Empfänger von Anträgen simulieren) (➡ [Testen mit Postman](./Detailinformationen/Postman.md). Nähere Informationen zu Postman siehe <https://www.postman.com/>)
+Alternativ können Sie die Anfragen auch mittels eigener Anwendungen oder alternativer REST Clients durchführen.
+
+## â‘¢ OAuth Token vor der API Nutzung abrufen
+
+> Für jede Anfrage an die API Endpunkte ist ein gültiger JWT-Token mit der Anfrage mitzusenden. Für nähere Informationen zum Abruf eines JWT-Token siehe ➡ [OAuth Details](./Detailinformationen/OAuth.md)
+
+## â‘£ Spezifikation lokal nutzen
+
+> Sofern Sie einen lokalen Zugriff auf die Quellen der Spezifikation im OpenAPI Format (bspw. für Code Generatoren) benötigen, finden Sie diese hier: ➡[FIT-Connect-API-Spec.yml](https://fitko.uber.space/API_VERSION/zustelldienst.yml)
+
+## Beispiel mit `curl`
+
+Token holen und in `$TOKEN` speichern:
+
+```bash
+TOKEN=$(curl --silent --location --request POST https://sender-test-token.fiep-poc.de/auth/realms/test/protocol/openid-connect/token \
+--header 'Content-Type: application/x-www-form-urlencoded' \
+--data-urlencode 'client_id=beispiel' \
+--data-urlencode 'client_secret=29e03d25-7999-4e4c-aa9a-bb2b99404d09' \
+--data-urlencode 'scope=destination:send' \
+--data-urlencode 'grant_type=client_credentials' \
+| jq -r .access_token)
+```
+
+Sie können das Token mit `echo ${TOKEN}` ausgeben lassen.
+
+Server Version abfragen (API Test):
+
+```bash
+curl --silent --header "Authorization: Bearer ${TOKEN}" https://sender-test.fiep-poc.de/beta7/info
+```
\ No newline at end of file
diff --git a/docs/getting-started/receiving/decrypt.mdx b/docs/getting-started/receiving/decrypt.mdx
index 5a659c6f97330df86858a100e11135b709154bcc..daeff517d26536690629117801b5912bd1d0418a 100644
--- a/docs/getting-started/receiving/decrypt.mdx
+++ b/docs/getting-started/receiving/decrypt.mdx
@@ -5,4 +5,36 @@ sidebar_position: 4
Um den Antrag korrekt verarbeiten und überprüfen zu können müssen zuerst alle verschlüsselten Informationen entschlüsselt werden. Darunter fallen beispielsweise die Antragsmetadaten, die Fachdaten (falls vorhanden) oder Dokumente (falls vorhanden).
-Die Entschlüsselung eines solchen Objektes mit Hilfe von JWE ist im Bereich "[Verschlüsselte Übertragung](#overview--verschlüsselte-übertragung)" genauer beschrieben und kann dort nachgelesen werden.
\ No newline at end of file
+## Entschlüsseln von Daten im antragsempfangenden System (Java)
+
+Wenn ein antragsempfangendes System (z.B. eine Fachanwendung oder virtuelle Poststelle) einen Antrag erhält, kann es diesen mit Hilfe des privaten Schlüssels und der Java-Bibliothek `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
+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) mit Hilfe des Schlüssels entschlüsselt werden. Auch hier wird wieder abhängig vom Schlüssel eine entsprechende Klasse für die Entschlüsselung verwendet.
+
+```java
+String encryptedStr = new String(jweString.readAllBytes());
+JWEObject jweObject = JWEObject.parse(encryptedStr);
+
+jweObject.decrypt(new RSADecrypter(jwk));
+```
+
+Abschliessend kann die entschlüsselte Payload weiterverarbeitet oder, wie in diesem Fall, ausgegeben werden.
+
+```java
+System.out.println(jweObject.getPayload().toString());
+```
\ No newline at end of file
diff --git a/docs/getting-started/sending/encrypt.mdx b/docs/getting-started/sending/encrypt.mdx
index b5ade0d45e827975449ab73f04d646bb0afcb717..21478f88b2c5e787eddc1289ff61dc9b93771d75 100644
--- a/docs/getting-started/sending/encrypt.mdx
+++ b/docs/getting-started/sending/encrypt.mdx
@@ -3,3 +3,118 @@ title: Verschlüsseln
sidebar_position: 2
---
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+## Verschlüsseln von Daten
+
+Gegeben, dass ein öffentlicher Teil eines JWK eines Zustellpunktes vorhanden ist, können mit diesem Daten für diesen Zustellpunkt verschlüsselt werden. Ein Beispiel für den öffentlichen Teil eines JWK ist unten aufgeführt.
+
+```json
+{
+ "kty": "RSA",
+ "e": "AQAB",
+ "keyops": ["wrapKey"],
+ "x5c": [
+ "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUVtakNDQW9LZ0F3SUJBZ0lHQVhueVZNOFVNQTBHQ1NxR1NJYjNEUUVCQ3dVQU1BNHhEREFLQmdOVkJBTU0KQTJGelpEQWVGdzB5TVRBMk1Ea3hPVFV4TlRSYUZ3MHlNakEwTURVeE9UVXhOVFJhTUE0eEREQUtCZ05WQkFNTQpBMkZ6WkRDQ0FpSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnSVBBRENDQWdvQ2dnSUJBTEY5ZzErNnh1UWFDWGR0CndOSlcrN05oVW1NV1FXYTdFTlVpTlY0aTB2OTNubi8vVUdOYStFa25wdlk0czJVRVVhbnUvSWJLamRpb01MbE4KMzI1dFN0MW13TUpZS1cwT1N4VjVUU3hzdE9GK09OVG1QcDM3UUxRY1J4WVV2dGtPbTZnTCs2eDBuN3BLVlVpYQpORjd5N0NTZXFESWM3YmpQVE9iNDAwYXVGaVlRVlJQbmlWT2tHMWcwdkx5ZEEzU3N5dEhJUDRwa3JveXVFOTd3ClFXcDZqTnZacU5xUWZlNkJEQ21uSU56cFJDV2E1TWxkb1VJcUJsekpSVy9DSTNDcVhkVHRtZlhTeGwzSGF3WkIKQ2VLR3ZoQlRUN05pL0RpY1EwN05JdFYzUndZY2UveFptTHlvOCtPelF5L0k4WTZKU1hiNzR4VGo3OER6WEJvNgpVRUZodDJRVXIwaW80UVAxZTlxaFkwcmtGNDlUR2ZDSk9pUjNWWitzQ0hpNEE0a093VWVaNVM1bnh6SmFjVStpCjVINisrNUdKRkIrdEhmV0V2WWVRdzRsVlZqQkdPNHVvdW0xSVo1dHJyb0tJOHVVNXJ3ZjVHa1h2SkNTK1VyMC8KbVJLVHVQalJkWVEzYnk3NkpUMlR4WXZMRDR2ZzlwUjhVdmZTUW9yMFYzTDlXdE56RXhuMC9UK0pVN0g3cEtIVgp6UDNMT1QzbkgyTjZPbFY4YWd3USt0UlArUlJiVExWM2c0cmlMWHhMaEFMeDJQS1ZlRi92dk1BRFVZT2pnMFIrCndVa3ZRRkFqcGNBZXYwNnpNK1dDMm5FT2lBZVl6UVY5L1pudUdicEhuZWhXb3FJbjRXajQwYzY1b2Z1UEx1T3QKUlpjUjJiZkUrbWFvMFd0VUhCWjVLdC96T1ByWkFnTUJBQUV3RFFZSktvWklodmNOQVFFTEJRQURnZ0lCQUlaTwpXdWNXQWxYZm5OVGZ5eExvMEEzQXM3ZGs5Rno0bVBzK1h2MW1RYlJSN0F2VnNSQyszeDJQTEJTd09aMDIveXFVCllVbk9WcFgxd2U2b2JHamtGVjJrQUs1NXc2M1poU1B1eXlPOEhBdlkzY1Y1ell6MW9KcmNtenpQblBzRlhJbUoKZTBINXFBYjhwNWx5emovbkJ0RTRkUXRGMlUwUEdadXRqSE82ZDgybytOclhJL1lOOUV5aUtIWUxZNGJTZ0syOAo1TC9jdEJBMmorRDJ4NlJEcjJ3YzlhTjFOUzZ4MXdXWmRpMmkyTXUyeGg4Nmc4cXV1dFNBL2Q1VElIUXpKTnR1CmY1blRMc3lFL3BqZDVnT0dyeGV0REREbW9rQUR0YnV6REFUUUNkaVVnbEliamYvME1Kc3o5QTlMUGhUKzNURGQKWXFOWVVJQ2k2WEhiTTU3bk5FQldwc3doZnl3RDkvWCt1US81OUJoVkFKTEJRT1NQNTdpSHgwUXo1elY0eldTegowcUR5dzVUU3N0U25GNDZrVm0xeHcvdkxNK0FVOE9oZmRlODFyWElydCs5bkdEdUNBWXN4YTRpeWZ3Y2dXaUF4CmIrQm04OHIvL0dZSndvdFEwRnI3SUVkekNaVFM0cm5Sb0lodVpkQ00xQ3BXS0dMOFVjQU9nTnlpR0t1eEY3emcKZjd4NysrWmhBeXBOV2s5OEtxYnZLOG1hcTYzTkt5ck1tNG9KQ3VIVWRzdHMxOU1RODdnekFvRnd1QkYzSEF2eQowVXRvdGY0bGZWNllYay85b3orWHNiS2x4ZlIrV3JYN2J6RkNYcnZueC8zNk1zZEp3UTF3aXhWaGhsYWdnUFF3CnQzUU5iMnBDc0hXdkVLcExWZUk5aHl1L1BqOFIycEhaYUtjN1NGKzQKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo="
+ ],
+ "x5t": "MTg6NTU6RUY6MEY6RkI6NDM6QzM6QTY6QUE6QzI6Nzg6Q0U6Mzk6MDc6NEE6RDk6QjA6OTA6NjU6Qzc6ODE6OTc6RDI6RjQ6NTE6ODQ6MjM6MTA6Qjc6QUU6QjY6NkE6NDU6QTc6RjA6OTE6MUY6NjY6QUU6NEQ6MEM6MTg6RDI6MzI6REU6QzM6RDk6RjY6NTY6REM6MEU6NUM6Q0E6NDk6QkY6OUI6NkY6OUM6MEM6QzM6ODQ6QjA6MkE6RkMK",
+ "kid": "787f3a1c-7da7-44d7-9b79-9783b1ea9be8",
+ "alg": "RSA-OAEP-256",
+ "n": "sX2DX7rG5BoJd23A0lb7s2FSYxZBZrsQ1SI1XiLS_3eef_9QY1r4SSem9jizZQRRqe78hsqN2KgwuU3fbm1K3WbAwlgpbQ5LFXlNLGy04X441OY-nftAtBxHFhS-2Q6bqAv7rHSfukpVSJo0XvLsJJ6oMhztuM9M5vjTRq4WJhBVE-eJU6QbWDS8vJ0DdKzK0cg_imSujK4T3vBBanqM29mo2pB97oEMKacg3OlEJZrkyV2hQioGXMlFb8IjcKpd1O2Z9dLGXcdrBkEJ4oa-EFNPs2L8OJxDTs0i1XdHBhx7_FmYvKjz47NDL8jxjolJdvvjFOPvwPNcGjpQQWG3ZBSvSKjhA_V72qFjSuQXj1MZ8Ik6JHdVn6wIeLgDiQ7BR5nlLmfHMlpxT6Lkfr77kYkUH60d9YS9h5DDiVVWMEY7i6i6bUhnm2uugojy5TmvB_kaRe8kJL5SvT-ZEpO4-NF1hDdvLvolPZPFi8sPi-D2lHxS99JCivRXcv1a03MTGfT9P4lTsfukodXM_cs5PecfY3o6VXxqDBD61E_5FFtMtXeDiuItfEuEAvHY8pV4X--8wANRg6ODRH7BSS9AUCOlwB6_TrMz5YLacQ6IB5jNBX39me4Zuked6FaioifhaPjRzrmh-48u461FlxHZt8T6ZqjRa1QcFnkq3_M4-tk"
+}
+```
+
+
+
+<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 mit Hilfe einer Methode aus dieser durchgeführt werden.
+
+```javascript
+import { parseJwk } from "jose/jwk/parse"
+import { CompactEncrypt } from "jose/jwe/compact/encrypt"
+
+const publicKey = await parseJwk({
+ "kty": "RSA",
+ "e": "AQAB",
+ "keyops": ["wrapKey"],
+ "x5c": [
+ "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUVtakNDQW9LZ0F3SUJBZ0lHQVhueVZNOFVNQTBHQ1NxR1NJYjNEUUVCQ3dVQU1BNHhEREFLQmdOVkJBTU0KQTJGelpEQWVGdzB5TVRBMk1Ea3hPVFV4TlRSYUZ3MHlNakEwTURVeE9UVXhOVFJhTUE0eEREQUtCZ05WQkFNTQpBMkZ6WkRDQ0FpSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnSVBBRENDQWdvQ2dnSUJBTEY5ZzErNnh1UWFDWGR0CndOSlcrN05oVW1NV1FXYTdFTlVpTlY0aTB2OTNubi8vVUdOYStFa25wdlk0czJVRVVhbnUvSWJLamRpb01MbE4KMzI1dFN0MW13TUpZS1cwT1N4VjVUU3hzdE9GK09OVG1QcDM3UUxRY1J4WVV2dGtPbTZnTCs2eDBuN3BLVlVpYQpORjd5N0NTZXFESWM3YmpQVE9iNDAwYXVGaVlRVlJQbmlWT2tHMWcwdkx5ZEEzU3N5dEhJUDRwa3JveXVFOTd3ClFXcDZqTnZacU5xUWZlNkJEQ21uSU56cFJDV2E1TWxkb1VJcUJsekpSVy9DSTNDcVhkVHRtZlhTeGwzSGF3WkIKQ2VLR3ZoQlRUN05pL0RpY1EwN05JdFYzUndZY2UveFptTHlvOCtPelF5L0k4WTZKU1hiNzR4VGo3OER6WEJvNgpVRUZodDJRVXIwaW80UVAxZTlxaFkwcmtGNDlUR2ZDSk9pUjNWWitzQ0hpNEE0a093VWVaNVM1bnh6SmFjVStpCjVINisrNUdKRkIrdEhmV0V2WWVRdzRsVlZqQkdPNHVvdW0xSVo1dHJyb0tJOHVVNXJ3ZjVHa1h2SkNTK1VyMC8KbVJLVHVQalJkWVEzYnk3NkpUMlR4WXZMRDR2ZzlwUjhVdmZTUW9yMFYzTDlXdE56RXhuMC9UK0pVN0g3cEtIVgp6UDNMT1QzbkgyTjZPbFY4YWd3USt0UlArUlJiVExWM2c0cmlMWHhMaEFMeDJQS1ZlRi92dk1BRFVZT2pnMFIrCndVa3ZRRkFqcGNBZXYwNnpNK1dDMm5FT2lBZVl6UVY5L1pudUdicEhuZWhXb3FJbjRXajQwYzY1b2Z1UEx1T3QKUlpjUjJiZkUrbWFvMFd0VUhCWjVLdC96T1ByWkFnTUJBQUV3RFFZSktvWklodmNOQVFFTEJRQURnZ0lCQUlaTwpXdWNXQWxYZm5OVGZ5eExvMEEzQXM3ZGs5Rno0bVBzK1h2MW1RYlJSN0F2VnNSQyszeDJQTEJTd09aMDIveXFVCllVbk9WcFgxd2U2b2JHamtGVjJrQUs1NXc2M1poU1B1eXlPOEhBdlkzY1Y1ell6MW9KcmNtenpQblBzRlhJbUoKZTBINXFBYjhwNWx5emovbkJ0RTRkUXRGMlUwUEdadXRqSE82ZDgybytOclhJL1lOOUV5aUtIWUxZNGJTZ0syOAo1TC9jdEJBMmorRDJ4NlJEcjJ3YzlhTjFOUzZ4MXdXWmRpMmkyTXUyeGg4Nmc4cXV1dFNBL2Q1VElIUXpKTnR1CmY1blRMc3lFL3BqZDVnT0dyeGV0REREbW9rQUR0YnV6REFUUUNkaVVnbEliamYvME1Kc3o5QTlMUGhUKzNURGQKWXFOWVVJQ2k2WEhiTTU3bk5FQldwc3doZnl3RDkvWCt1US81OUJoVkFKTEJRT1NQNTdpSHgwUXo1elY0eldTegowcUR5dzVUU3N0U25GNDZrVm0xeHcvdkxNK0FVOE9oZmRlODFyWElydCs5bkdEdUNBWXN4YTRpeWZ3Y2dXaUF4CmIrQm04OHIvL0dZSndvdFEwRnI3SUVkekNaVFM0cm5Sb0lodVpkQ00xQ3BXS0dMOFVjQU9nTnlpR0t1eEY3emcKZjd4NysrWmhBeXBOV2s5OEtxYnZLOG1hcTYzTkt5ck1tNG9KQ3VIVWRzdHMxOU1RODdnekFvRnd1QkYzSEF2eQowVXRvdGY0bGZWNllYay85b3orWHNiS2x4ZlIrV3JYN2J6RkNYcnZueC8zNk1zZEp3UTF3aXhWaGhsYWdnUFF3CnQzUU5iMnBDc0hXdkVLcExWZUk5aHl1L1BqOFIycEhaYUtjN1NGKzQKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo="
+ ],
+ "x5t": "MTg6NTU6RUY6MEY6RkI6NDM6QzM6QTY6QUE6QzI6Nzg6Q0U6Mzk6MDc6NEE6RDk6QjA6OTA6NjU6Qzc6ODE6OTc6RDI6RjQ6NTE6ODQ6MjM6MTA6Qjc6QUU6QjY6NkE6NDU6QTc6RjA6OTE6MUY6NjY6QUU6NEQ6MEM6MTg6RDI6MzI6REU6QzM6RDk6RjY6NTY6REM6MEU6NUM6Q0E6NDk6QkY6OUI6NkY6OUM6MEM6QzM6ODQ6QjA6MkE6RkMK",
+ "kid": "787f3a1c-7da7-44d7-9b79-9783b1ea9be8",
+ "alg": "RSA-OAEP-256",
+ "n": "sX2DX7rG5BoJd23A0lb7s2FSYxZBZrsQ1SI1XiLS_3eef_9QY1r4SSem9jizZQRRqe78hsqN2KgwuU3fbm1K3WbAwlgpbQ5LFXlNLGy04X441OY-nftAtBxHFhS-2Q6bqAv7rHSfukpVSJo0XvLsJJ6oMhztuM9M5vjTRq4WJhBVE-eJU6QbWDS8vJ0DdKzK0cg_imSujK4T3vBBanqM29mo2pB97oEMKacg3OlEJZrkyV2hQioGXMlFb8IjcKpd1O2Z9dLGXcdrBkEJ4oa-EFNPs2L8OJxDTs0i1XdHBhx7_FmYvKjz47NDL8jxjolJdvvjFOPvwPNcGjpQQWG3ZBSvSKjhA_V72qFjSuQXj1MZ8Ik6JHdVn6wIeLgDiQ7BR5nlLmfHMlpxT6Lkfr77kYkUH60d9YS9h5DDiVVWMEY7i6i6bUhnm2uugojy5TmvB_kaRe8kJL5SvT-ZEpO4-NF1hDdvLvolPZPFi8sPi-D2lHxS99JCivRXcv1a03MTGfT9P4lTsfukodXM_cs5PecfY3o6VXxqDBD61E_5FFtMtXeDiuItfEuEAvHY8pV4X--8wANRg6ODRH7BSS9AUCOlwB6_TrMz5YLacQ6IB5jNBX39me4Zuked6FaioifhaPjRzrmh-48u461FlxHZt8T6ZqjRa1QcFnkq3_M4-tk"
+})
+```
+
+Mit diesem umgewandelten Schlüssel können nun Texte und Binärdaten verschlüsselt werden. Im großen und ganzen kann alles verschlüsselt werden, was vorher in ein `Uint8Array` umgewandelt wurde.
+
+Für Texte kann man hier den TextEncoder aus der Browser-Runtime nutzen, der den String in die UTF8-Bytes und damit in ein `Uint8Array` umwandelt.
+
+```javascript
+const encodedText = new TextEncoder().encode("{ \"Hello\": \"World\"}")
+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">
+
+```xml
+<dependency>
+ <groupId>com.nimbusds</groupId>
+ <artifactId>nimbus-jose-jwt</artifactId>
+ <version>9.X.X</version>
+</dependency>
+```
+
+```java
+String publicKeyAsString = new String(existingPublicKey.readAllBytes());
+// Only RSA keys with RSA-OAEP-256 and A256GCM are allowed
+// => Therefore we need to parse a RSAKey
+RSAKey publicKey = RSAKey.parse(publicKeyAsString).toRSAPublicKey();
+```
+
+```java
+JWEHeader header = new JWEHeader(JWEAlgorithm.RSA_OAEP_256, EncryptionMethod.A256GCM);
+
+Payload payload = new Payload("{ \"Hello\": \"World\"}");
+/// Alternativ, bei einer Datei
+Payload payload = new Payload(aFileInputStream.readAllBytes());
+
+JWEObject jweObject = new JWEObject(header, payload);
+
+try {
+ jweObject.encrypt(new RSAEncrypter(publicKey));
+ // Serialisierung gemäß JWE Compact Serialization, siehe https://datatracker.ietf.org/doc/html/rfc7516#section-3.1
+ String encrypted = jweObject.serialize();
+
+ System.out.println("Encrypted Text:");
+ System.out.println(encrypted);
+} catch (JOSEException e) {
+ e.printStackTrace();
+}
+```
+</TabItem>
+</Tabs>
\ No newline at end of file
diff --git a/docs/rate-limiting.mdx b/docs/rate-limiting.mdx
index 4b9d240d59c2c3472d55998cb0fa38662a01418e..f8ad8d57cdb41b4feed50c32a2d4592962af832f 100644
--- a/docs/rate-limiting.mdx
+++ b/docs/rate-limiting.mdx
@@ -1,5 +1,5 @@
---
-title: Begrenzung von Abrufen
+title: Begrenzung von Abrufen (Rate-Limiting & Throttling)
---
...
diff --git a/docusaurus.config.js b/docusaurus.config.js
index 0b497128bfb751b31498498144fbbfcf477076bd..c7f01cbf80336317f1e5114e7d8b6052a8386e64 100644
--- a/docusaurus.config.js
+++ b/docusaurus.config.js
@@ -1,52 +1,55 @@
/** @type {import('@docusaurus/types').DocusaurusConfig} */
module.exports = {
- title: 'Fit Connect APIs',
- tagline: 'Dokumentation für die APIs von Fit Connect',
- url: 'https://fitko.uber.space',
- baseUrl: '/',
- onBrokenLinks: 'throw',
- onBrokenMarkdownLinks: 'warn',
- favicon: 'img/favicon.ico',
- organizationName: 'fitko', // Usually your GitHub org/user name.
- projectName: 'api', // Usually your repo name.
+ title: "FIT-Connect APIs",
+ tagline: "Dokumentation für die APIs von FIT-Connect",
+ url: "https://fitko.uber.space",
+ baseUrl: "/",
+ onBrokenLinks: "throw",
+ onBrokenMarkdownLinks: "warn",
+ favicon: "img/favicon.ico",
+ organizationName: "fitko", // Usually your GitHub org/user name.
+ projectName: "api", // Usually your repo name.
i18n: {
- defaultLocale: 'de',
- locales: ['de']
+ defaultLocale: "de",
+ locales: ["de"],
},
themeConfig: {
colorMode: {
disableSwitch: true,
},
+ prism: {
+ additionalLanguages: ["java", "csharp"],
+ },
navbar: {
- title: 'Fit Connect API Dokumentation',
+ title: "FIT-Connect Dokumentation",
logo: {
- alt: 'FITKO',
- src: '/images/logo-fitko.svg',
+ alt: "FITKO",
+ src: "/images/logo-fitko.svg",
},
items: [
{
- href: 'https://git.fitko.de/fit-connect/api',
- label: 'Gitlab',
- position: 'right',
+ href: "https://git.fitko.de/fit-connect/api",
+ label: "Gitlab",
+ position: "right",
},
],
},
footer: {
- style: 'light',
+ style: "light",
copyright: `Copyright © ${new Date().getFullYear()} FITKO (Föderale IT-Kooperation) | Zum Gottschalkhof 3 | 60594 Frankfurt am Mail | E-Mail: poststelle@fitko.de | https://www.fitko.de | Die FITKO ist eine Anstalt des öffentlichen Rechts. Sie wird vertreten durch die Präsidentin Frau Dr. Annette Schmidt.`,
},
},
presets: [
[
- '@docusaurus/preset-classic',
+ "@docusaurus/preset-classic",
{
docs: {
- sidebarPath: require.resolve('./sidebars.js'),
- editUrl: 'https://git.fitko.de/fit-connect/api',
- routeBasePath: '/'
+ sidebarPath: require.resolve("./sidebars.js"),
+ editUrl: "https://git.fitko.de/fit-connect/api",
+ routeBasePath: "/",
},
theme: {
- customCss: require.resolve('./src/css/custom.css'),
+ customCss: require.resolve("./src/css/custom.css"),
},
},
],
diff --git a/sidebars.js b/sidebars.js
index e43a9229ee6909f876fca004e0b822b56357d561..ab1a9804a29b816a360e0e3b72c265e1829a847a 100644
--- a/sidebars.js
+++ b/sidebars.js
@@ -11,73 +11,84 @@
module.exports = {
defaultSidebar: [
- 'overview',
- 'rate-limiting',
- 'status-and-error-codes',
+ "overview",
+ "rate-limiting",
+ "status-and-error-codes",
{
- type: 'category',
- label: 'Getting Started',
+ type: "category",
+ label: "Getting Started",
items: [
+ "getting-started/overview",
+ "getting-started/account",
+ "getting-started/authentication/applications",
+ "getting-started/authentication/users",
+ "getting-started/encryption",
{
- type: 'category',
- label: 'Versenden',
- items: [{
- type: 'autogenerated',
- dirName: 'getting-started/sending'
- }]
+ 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: "Empfangen",
+ items: [
+ {
+ type: "autogenerated",
+ dirName: "getting-started/receiving",
+ },
+ ],
+ },
+ ],
},
+ // {
+ // type: 'category',
+ // label: 'SDK',
+ // items: [{
+ // type: 'autogenerated',
+ // dirName: 'sdk'
+ // }]
+ // },
{
- type: 'category',
- label: 'API Spezifikationen',
- items: [{
- type: 'autogenerated',
- dirName: 'apis'
- }]
+ type: "category",
+ label: "API Spezifikationen",
+ items: [
+ {
+ type: "autogenerated",
+ dirName: "apis",
+ },
+ ],
},
{
- type: 'category',
- label: 'Weiteres',
+ type: "category",
+ label: "Weiteres",
items: [
- {
- type: 'doc',
- label: 'Glossar',
- id: 'more/glossary'
+ {
+ type: "doc",
+ label: "Glossar",
+ id: "more/glossary",
},
{
- type: 'link',
- label: 'Feedback',
- href: 'https://jira.fiep-poc.de/servicedesk/customer/portal/1'
+ type: "link",
+ label: "Feedback",
+ href: "https://jira.fiep-poc.de/servicedesk/customer/portal/1",
},
{
- type: 'link',
- label: 'Terms of Service',
- href: 'https://www.fitko.de/'
+ type: "link",
+ label: "Terms of Service",
+ href: "https://www.fitko.de/",
},
{
- type: 'link',
- label: 'Impressum',
- href: 'https://www.fitko.de/Impressum'
- }
- ]
- }
+ type: "link",
+ label: "Impressum",
+ href: "https://www.fitko.de/Impressum",
+ },
+ ],
+ },
],
// anotherSidebar: [{
diff --git a/src/components/ApiSpec.js b/src/components/ApiSpec.js
index 1b930294850bf8a036ccabf7400dd3f546c95514..be9ed2075786e55b1bab4ef4acd82765a915ae70 100644
--- a/src/components/ApiSpec.js
+++ b/src/components/ApiSpec.js
@@ -1,21 +1,21 @@
import React from 'react'
import 'rapidoc'
-export default function ApiSpec() {
+export default function ApiSpec(props) {
return (
- <rapi-doc id="thedoc"
- render-style="focused"
-
+ <rapi-doc
+ render-style="view"
+ spec-url={props.specUrl}
theme="light"
+
xprimary-color="#11171a"
header-color="#263238"
nav-bg-color="#263238"
-
- show-info="true"
- show-header="true"
- show-components="true"
+ show-info="false"
+ show-header="false"
+ show-components="false"
allow-spec-file-load="false"
-
- info-description-headings-in-navbar="true"></rapi-doc>
- )
+ info-description-headings-in-navbar="false"
+ ></rapi-doc>
+ );
}
\ No newline at end of file