diff --git "a/docs/6_Architektur_\303\234bersicht.md" "b/docs/6_Architektur_\303\234bersicht.md"
new file mode 100644
index 0000000000000000000000000000000000000000..cb6018fc7645c9f94f8fb9d1f673ea3a8574a627
--- /dev/null
+++ "b/docs/6_Architektur_\303\234bersicht.md"
@@ -0,0 +1,27 @@
+# FIT-Connect Architektur Ãœbersicht
+
+FIT-Connect ist ein System das es ermöglicht, Anträge von einem Onlineservice, einer App oder einem anderen digitalen Medium über eine standartisierte Schnittstelle an die zuständige Person bzw. an ein Fachverfahren in der für diesen Antrag zuständigen Behörde zu versenden.
+
+Dafür gibt es zwei Schnittstellen zum FIT-Connect-System die Abgabepunkt-API und die Zustellpunkt-API.
+
+## Einen Antrag an die Abgabepunkt-API versenden
+
+An die Abgabepunkt-API kann ein Onlineservice, der entweder von einer Behörde, einem Unternehmen oder einer zivilgesesellschaftlichen Organisation betrieben wird, Anträge übermitteln. Der Onlineservice benötigt dazu die Destination-ID eines Antrages. Diese Destination-ID ist einfach eine UUID, die dem FIT-Connect-System sagt, wohin ein Antrag zugestellt werden soll. Die passende Destination-ID kann man über die Schnittstelle des Zuständigkeitsfinders herausbekommen (**todo: link**).
+
+Mithilfe der Destination-ID kann ein Onlineservice bei FIT-Connect anfragen, in welchem Format die Empfangsbehörde die Daten erwartet. Das können JSON oder XML-Schemata und manchmal auch Binärdateien sein.
+
+FIT-Connect möchte einen sehr sicheren Übermittlungsweg bereitstellen, deswegen müssen alle Daten immer vom Browser des Users bis in die Behörde Ende-zu-Ende-Verschlüsselt übertragen werden. Das dafür benötigte Schlüsselmaterial wird auch über die FIT-Connect-API bereitgestellt.
+
+Um Zugang zur Abgabepunkt-API für eine bestimmte Destination-ID zu bekommen, muss man OAuth Credentias über das Developer-Portal beantragen. Mit diesen kann man dann wiederum einen JWT Token bekommen, mit dem man sich gegenüber der Abgabepunkt-API authentifizieren kann.
+
+Nach Abgabe des Antrags erhält man von dieser API einen "Application ID". Mithilfe dieser Application ID kann man den Event Log des Antrags abrufen. Dieser Eventlog enthält eine Liste von Ereignes, ähnlich wie im Interface einer Paketverfolgung, mit denen der aktuelle Zustellungsstatus des Antrags transparent wird. Also ob und wann ein Antrag abgesendet, bei der Fachanwendung eingegangen bzw. bearbeitet wurde.
+
+Außerdem gibt es die Möglichkeit beim Absenden eines Antrages einen Verschlüsselungschlüssel mitzugeben. Wenn dieser vorhanden ist, dann können durch die Behörden Antworten auf Anträge im FIT-Connect-System hinterlegt werden. Wenn eine Antwort hinterlegt wird, kann der User per Webhook, E-Mail oder Push-Notification darüber benachtichtigt werden und die verschlüsselte Antwort über die verwendete App oder Onlineservice abrufen.
+
+## Einen Zustellpunkt bereitstellen
+
+Behörden können über das FIT-Connect-System Zustellpunkte für Anträge bereitstellen. In der Regel geben sie dabei an für welches Gebiet sie welchen Antrag aus den Leistungskatalog entgegennehmen. Darauf erhalten sie eine Destination ID, welche eine Eindeutige Zustelladresse für diese Leistung repräsentiert. Diese Destination ID wird im Diensteverzeichnis zusammen mit der LeiKa-ID und den Gemeindekennungen gelistet und wird somit für Antragsversender auffindbar.
+
+Beim Anlegen eines Zustellpunktes übermittelt die Behörde außerdem noch einen Verschlüsselungs- und einen Signatur-Key, Informationen ob und wie sie über einen neuen Antrag benachrichtigt werden soll und Datenschemas, denen die Antragsdaten, die an sie übermittelt werden, entsprechen müssen.
+
+Nachdem ein Zustellpunkt angelegt wurde, können über diesen Anträge empfangen werden. Wenn ein Antrag für die Destination-ID eingegangen ist, wird die Fachanwendung darüber über einen Webhook benachrichtig. Um den Antrag abzurufen muss die Fachanwendung sich zuerst via OAuth2 authentifizieren und kann sich dann mithilfe eines JWT gegenüber des Fachverfahrens autorisieren.
\ No newline at end of file
diff --git a/docs/Detailinformationen/Antrag_Event_Log.md b/docs/Detailinformationen/Antrag_Event_Log.md
index 4f4c9be20779538ac1e51f50ec51e47500503b76..975540a7986b30837e6e38d65ab142fe61f67d66 100644
--- a/docs/Detailinformationen/Antrag_Event_Log.md
+++ b/docs/Detailinformationen/Antrag_Event_Log.md
@@ -12,8 +12,8 @@ Alle Eventeinträge müssen nach dem in "[Anforderungen an das kryptografische M
| ------ | ----------------------------------------- | ------------------------------------------------------------ |
| iss | Identifizierungsmerkmal des Token Issuers | Dient dazu, um herauszufinden, wer den Token ausgestellt hat. Ist entweder client id der Fachanwendung oder "fitconnect" für den Übermittlungsdienst |
| iat | Timestamp | Zeitpunkt der Ausstellug des SETs |
-| sub | UUID des Antrags | Dient dazu um die |
-| events | Dict der Events in diesem Event-Token | Key Value mapping von schema zu Inhaltsdaten des eigentlichen Tokens. Liste der erlaubten Schemas findet sich hier. (**TODO**) |
+| sub | UUID des Antrags | Dient dazu um die Events dem Antrag zuzuordnen |
+| events | Dict der Events in diesem Event-Token | Key Value mapping von schema zu Inhaltsdaten des eigentlichen Tokens. Liste der erlaubten Schemas befindet sich hier. (**TODO**) |
### Beispiel
diff --git a/docs/Detailinformationen/Authentifizierung_von_Fachanwendungen.md b/docs/Detailinformationen/Authentifizierung_von_Fachanwendungen.md
index d5ebe1604e87515a65826d3217d614ada89a6b31..4c8a831aa2c591e4158eb847782daf1b34bdc6bd 100644
--- a/docs/Detailinformationen/Authentifizierung_von_Fachanwendungen.md
+++ b/docs/Detailinformationen/Authentifizierung_von_Fachanwendungen.md
@@ -52,11 +52,12 @@ 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 einen Abruf erlaubt. |
+| 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 einen Abruf erlaubt. |
+| clientType | receiver | Gibt an, das es sich um einen Token für eine Fachanwendung handelt, die Anträge empfangen kann. |
**Beispiel**
@@ -64,7 +65,8 @@ Entsprechend den [standartisierten Feldern](http://www.iana.org/assignments/jose
{ Â
"iat":"1620072619", Â
"exp":"1620079819",
- "scope": ["99108008252000:36141427-d405-40a4-8f8b-3592d544e85b", "655c6eb6-e80a-4d7b-a8d2-3f3250b6b9b1"]
+ "scope": ["36141427-d405-40a4-8f8b-3592d544e85b", "655c6eb6-e80a-4d7b-a8d2-3f3250b6b9b1"],
+ "clientType": "receiver"
}
```
@@ -73,8 +75,9 @@ Entsprechend den [standartisierten Feldern](http://www.iana.org/assignments/jose
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 diese noch gültig sind und
+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 JWT für max. 4h ausgestellt wurde.
-2. Mithilfe des Public Keys des Authentifizierungsservers die Signatur des JWT überprüfen.
-3. Überprüfen, ob die Destination-ID, die abgerufen werden soll teil der in den Scopes (**scope** Parameter in den JWTs) des JWTs ist. (Zugangsberechtigung der Fachanwendung).
+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 Scopes (**scope** Parameter in den JWTs) des JWTs ist. (Zugangsberechtigung der Fachanwendung).
diff --git a/docs/Detailinformationen/Authentifizierung_von_Usern.md b/docs/Detailinformationen/Authentifizierung_von_Usern.md
index 01a786b5a76077def800a6f8fac05e11ab34867d..dbc468f6762152ab01997d1d0de57be570e2be41 100644
--- a/docs/Detailinformationen/Authentifizierung_von_Usern.md
+++ b/docs/Detailinformationen/Authentifizierung_von_Usern.md
@@ -63,14 +63,15 @@ 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 Zustellberechtigungs-Scopes | Eine Liste der Zustellberechtigungs-Scopes, 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) |
+| 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 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**
@@ -80,7 +81,8 @@ Entsprechend den [standartisierten Feldern](http://www.iana.org/assignments/jose
"exp":"1620079819",
"scope": ["leika:99108008252000:36141427-d405-40a4-8f8b-3592d544e85b", "custom:15:655c6eb6-e80a-4d7b-a8d2-3f3250b6b9b1"],
"sid": "8d4dcbfd-a528-4e9b-abc3-477c4cc857aa",
- "iss": "639c5be8-eb9c-4741-834e-4ad11629898a"
+ "iss": "639c5be8-eb9c-4741-834e-4ad11629898a",
+ "clientType": "user-sender",
}
```
@@ -89,14 +91,15 @@ Entsprechend den [standartisierten Feldern](http://www.iana.org/assignments/jose
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. |
-| epk | 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) |
+| 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. |
+| epk | 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**
@@ -105,7 +108,8 @@ Entsprechend den [standartisierten Feldern](http://www.iana.org/assignments/jose
"iat":"1620072619", Â
"exp":"1620079819",
"scope": ["custom:15:655c6eb6-e80a-4d7b-a8d2-3f3250b6b9b1", "leika:99108008252000"],
- "epk": {
+ "clientType": "sender",
+ "publicKey": {
"kty": "RSA",
"e": "AQAB",
"key_ops": ["verify"],
@@ -126,13 +130,14 @@ 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
+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.
-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). Bzw. ob der im Präfix des Onlineservice-Tokens dem Präfix der Destination-ID(s) entspricht.
-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)
+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 Scopes (**scope** Parameter in den JWT Tokens) beider JWT-Tokens ist. (Zugangsberechtigung des Onlinedienstes und des Users). Bzw. ob der im Präfix des Onlineservice-Tokens dem Präfix der Destination-ID(s) entspricht.
+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)
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_Key_Requirements.md b/docs/Detailinformationen/Encryption_Key_Requirements.md
index c5c9387db9f3ecc39730a7e0e2e2813c71ad649f..ec94ea41b0e6d3acfc9bc14d9f886096ff76e41b 100644
--- a/docs/Detailinformationen/Encryption_Key_Requirements.md
+++ b/docs/Detailinformationen/Encryption_Key_Requirements.md
@@ -69,22 +69,47 @@ Das bedeutet, der JSON Web Key zur Verschlüsselung muss diesem Format entsprech
}
```
+## 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.
+
+### Verschlüsselungsverfahren
+
+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 Felder müssen im JOSE-Header bei der Übertragung verschlüsselter Daten in FIT-Connect 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 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) |
+| 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. |
-| x5t | Zertifikatsfingerprint | Der Fingerprint des Zertifikats gemäß [RFC 7517, Abschnitt 4.5](https://datatracker.ietf.org/doc/html/rfc7517#section-4.7) |
-| 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. |
+| x5t | Zertifikatsfingerprint | Der Fingerprint des Zertifikats gemäß [RFC 7517, Abschnitt 4.5](https://datatracker.ietf.org/doc/html/rfc7517#section-4.7) |
+| 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)) |
+| 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:
@@ -107,32 +132,6 @@ Das bedeutet, der JSON Web Key zur Prüfung von digitalen Signaturen muss dem fo
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 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.
-
-### Verschlüsselungsverfahren
-
-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 Felder müssen im JOSE-Header bei der Übertragung verschlüsselter Daten in FIT-Connect 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) |
-
-
## Algorithmen zur Signierung von Security Event Tokens
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.
diff --git a/docs/Detailinformationen/Zustellberechtigungs-Scopes.md b/docs/Detailinformationen/Zustellberechtigungs-Scopes.md
index fdd9b6ced01e4674ef18bb5e1c0b5d7b7630f7b5..460c8ae16113926abedfef91875da8123efb9969 100644
--- a/docs/Detailinformationen/Zustellberechtigungs-Scopes.md
+++ b/docs/Detailinformationen/Zustellberechtigungs-Scopes.md
@@ -31,7 +31,7 @@ leika:99108008252000:36141427-d405-40a4-8f8b-3592d544e85b
Eine Custom-Leistung:
```
-custom:15:655c6eb6-e80a-4d7b-a8d2-3f3250b6b9b1
+custom:1533:655c6eb6-e80a-4d7b-a8d2-3f3250b6b9b1
```
## Regex zur Validierung