diff --git a/docs/Detailinformationen/Authentifizierung_von_Usern.md b/docs/Detailinformationen/Authentifizierung_von_Usern.md
index 4fd219735dddbf7065925c11acb76662bc12e7f2..d05256dd4712902926152ba3e8ff353f1642756c 100644
--- a/docs/Detailinformationen/Authentifizierung_von_Usern.md
+++ b/docs/Detailinformationen/Authentifizierung_von_Usern.md
@@ -30,7 +30,7 @@ Der Onlinedienst muss zur Registrierung bei FIT-Connect neben den Angaben dazu,
| Feld | Inhalt | **Erläuterung** |
| ------------------ | ---------- | ------------------------------------------------------------ |
-| Hashingalgorithmus | SHA-512 | Gibt den 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)) |
+| 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) |
@@ -44,11 +44,11 @@ Die vom Onlinedienst generierten JWT-Tokens müssen nach [RFC 7519](https://tool
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 HA-512. |
-| | | |
+| 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**
@@ -63,13 +63,14 @@ Entsprechend [RFC 7519 Abschnnitt 8](https://tools.ietf.org/html/rfc7519#section
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, 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 |
+| 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, 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) |
**Beispiel**
@@ -125,11 +126,13 @@ Nach dem Anlegen eines Antragsübertragungsprozesses kann auf diesen nur mit JWT
Das API-Gateway muss die JWT-Tokens validieren:
-1. Überprüfen, ob diese noch gültig sind und der JWT-Token maximal für 2h ausgestellt wurde.
+1. Ü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.
2. Mithilfe des Public Keys des Authentifizierungsservers die Signatur des Onlinedienst-JWT überprüfen.
3. Mithilfe des im JWT-Token des Onlinedienst enthaltenen Public Key die Signatur des User JWT überprüfen
4. Überprüfen, ob die Destination-ID teil der in den Scopes (**scope** Parameter in den JWT Tokens) beider JWT-Tokens ist. (Zugangsberechtigung des Onlinedienstes und des Users)
-5. Überprüfen, ob die Website (origin), von der der Antrag abgesendet wurde, für die jeweilige Session-ID freigegeben ist. (Verhindern von gefälschten Onlinediensten, die nicht den FIT-Connect-Standards entsprechen)
+5. Ü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)
Das API-Gateway kann aufgrund der folgenden Parameter Rate-Limiting für API-Calls (angepasst an die jeweiligen Use Cases des Onlineservices) betreiben:
diff --git a/docs/Detailinformationen/Encryption.md b/docs/Detailinformationen/Encryption.md
index 0b081b97e1453a2211ea68a8c015546bb1a4b095..6d3eb8d05605329127b33b4522a3025f601f3224 100644
--- a/docs/Detailinformationen/Encryption.md
+++ b/docs/Detailinformationen/Encryption.md
@@ -86,7 +86,7 @@ Das dabei entstandene Zertifikat muss zur dem Fachverfahren gehörende Destinati
### Anlegen eines Zustellpunktes
-Ein Zustellpunkt benötigt mindestens immer ein erlaubtes schema sowie einen Verschlüsselungs- und einen Signaturkey.
+Ein Zustellpunkt benötigt mindestens immer ein erlaubtes 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 Geist bereitgestellt werden.
#### Beispiel
diff --git a/docs/Detailinformationen/Encryption_Key_Requirements.md b/docs/Detailinformationen/Encryption_Key_Requirements.md
index 73318debdb06b3a3be67596f74ada48b92102805..eb56c824c93b5a6cd6bcd05033ba2be39a598269 100644
--- a/docs/Detailinformationen/Encryption_Key_Requirements.md
+++ b/docs/Detailinformationen/Encryption_Key_Requirements.md
@@ -40,10 +40,11 @@ Das generierte X.509 Zertifikat, alle Intermediate Zertifikate und das Wurzelzer
| ------- | ------------------------------------- | ------------------------------------------------------------ |
| kty | RSA | Gibt den Keytype nach [RFC 7517 Abschnitt 4](https://tools.ietf.org/html/rfc7517#section-4) an. |
| key_ops | [wrapKey] | Gibt die Funktion des Keys (Verschlüsselung des Verschlüsellungskeys) an. (nach [RFC 7517 Abschnitt 4.3](https://tools.ietf.org/html/rfc7517#section-4.3)) |
-| alg | PS512 | Gibt den Algorithmus der zur digitalen Signatur des Zertifikats verwendet werden muss an. Dieser muss im Fall von FIT-Connect immer PS512 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)) |
| x5c | die Zertifikatskette (base64 encoded) | Entspricht der Zertifikatskette vom Wurzelzertifikat bis zum Zertifikat selbst. ([Abschnitt 4.7 RFC 7518](https://tools.ietf.org/html/rfc7517#section-4.7)) |
| x5t | der Zertifikatsfingerprint | Der Fingerprint des Zertifikats selbst. ([Abschnitt 4.8 RFC 7518](https://tools.ietf.org/html/rfc7517#section-4.8)) |
| kid | eindeutige ID des Keys | Diese ID wird verwendet, um sie bei der Verschlüsselung des asymmetrischen Keys zur Verschlüsselung des Symetrischen Keys zur Inhaltsverschlüsselung zu referenzieren und somit darzustellen, welcher Key zur Entschlüsselung benötigt wird (siehe [RFC 7516 4.1.6](https://tools.ietf.org/html/rfc7516#section-4.1.6)) |
+| n | der Public Key zum Zertifikat | Der Modulus des Public Key zum Zertifikat (x5c) "Base64urlUInt" enkodiert. (vgl. [RFC 7518 - Abschitt 6.3.1.1](https://www.rfc-editor.org/rfc/rfc7518.html#section-6.3.1.1)) |
+| e | AQAB | Der Exponent des Public Key zum Zertifikat (x5c) (vgl. [RFC 7518 - Abschitt 6.3.1.2](https://www.rfc-editor.org/rfc/rfc7518.html#section-6.3.1.2)) |
Das bedeutet, der JSON Web Key zur Verschlüsselung muss diesem Format entsprechen:
@@ -74,10 +75,11 @@ Die Auswahl welcher JSON Web Key aus der Liste der zur Verfügung gestellten Key
| ------- | ------------------------------------- | ------------------------------------------------------------ |
| kty | RSA | Gibt den Keytype nach [RFC 7515 Abschnitt 4](https://tools.ietf.org/html/rfc7515#section-4) an. |
| key_ops | [verify] | Gibt die Funktion des Keys (Verschlüsselung des Verschlüsellungskeys) an. (nach [RFC 7517 Abschnitt 4.3](https://tools.ietf.org/html/rfc7517#section-4.3)) |
-| alg | PS512 | Gibt den Algorithmus der zur digitalen Signatur des Zertifikats verwendet werden muss an. Dieser muss im Fall von FIT-Connect immer PS512 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)) |
| x5c | die Zertifikatskette (base64 encoded) | Entspricht der Zertifikatskette vom Wurzelzertifikat bis zum Zertifikat selbst. ([Abschnitt 4.7 RFC 7518](https://tools.ietf.org/html/rfc7517#section-4.7)) |
| x5t | der Zertifikatsfingerprint | Der Fingerprint des Zertifikats selbst. ([Abschnitt 4.1.7 RFC 7515](https://tools.ietf.org/html/rfc7515#section-4.1.7)) |
| kid | eindeutige ID des Keys | Diese ID wird verwendet, um zur Prüfung der Signatur den richtigen Key auswählen zu können. (siehe [RFC 7515 4.1.4](https://tools.ietf.org/html/rfc7515#section-4.1.4)) Als Format der ID wird UUID nach [RFC 4122](https://tools.ietf.org/html/rfc4122) empfohlen. |
+| n | der Public Key zum Zertifikat | Der Modulus des Public Key zum Zertifikat (x5c) "Base64urlUInt" enkodiert. (vgl. [RFC 7518 - Abschitt 6.3.1.1](https://www.rfc-editor.org/rfc/rfc7518.html#section-6.3.1.1)) |
+| e | AQAB | Der Exponent des Public Key zum Zertifikat (x5c) (vgl. [RFC 7518 - Abschitt 6.3.1.2](https://www.rfc-editor.org/rfc/rfc7518.html#section-6.3.1.2)) |
Das bedeutet, der JSON Web Key zur Prüfung von digitalen Signaturen muss dem folgenden Format entsprechen:
@@ -107,7 +109,7 @@ Zur Verschlüsselung des eigentlichen Antragsinhalts wird ein s Schlüssel verwe
Verschlüsselugnsverfahren 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"- Feld im JSON: "enc"): "A256GCM" (definiert in [RFC 7518 Abschnitt 4.1](https://tools.ietf.org/html/rfc7518#section-4.1))
-- Asymmetrisches Verschlüsselungsverfahren, um den "Content Encryption Key" zu verschlüsseln ("alg"): "RSA-OAEP-256" (definiert in [RFC 7518 Abschnitt 4.3](https://tools.ietf.org/html/rfc7518#section-4.3)
+- Asymmetrisches Verschlüsselungsverfahren, um den "Content Encryption Key" zu verschlüsseln ("alg"): "RSA-OAEP-256" (definiert in [RFC 7518 Abschnitt 4.3](https://tools.ietf.org/html/rfc7518#section-4.3))
#### JSON Web Encryption Header (JOSE)
@@ -124,7 +126,7 @@ Im Header des JSON Web Encryption Objektes werden die Metadaten zu den verschlü
Für die Bereitstellung von signierten Statusinformationen über Security Event Tokens (vgl. [RFC 8417](https://tools.ietf.org/html/rfc8417)) wird das Verfahren [JSON Web Signature](https://tools.ietf.org/html/rfc7515) verwendet.
-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 Public Key, zu dem auf dem Server verwendeten Signaturschlüssel, muss über den JSON Web Key Endpunkt als Key mit der Funktion "verify" verfügbar sein.
+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 Public Key, zu dem auf dem Server verwendeten Signaturschlüssel, muss über den JSON Web Key Endpunkt (DVDV) als Key mit der Funktion "verify" verfügbar sein.
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://www.rfc-editor.org/rfc/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.