diff --git a/docs/details/authentication/sender.md b/docs/details/authentication/sender.md
index 97602ab0a57479616e11433d65dd502f483c3a9b..f6b22e5af2455827692c65cdbce9a6c66580bb1c 100644
--- a/docs/details/authentication/sender.md
+++ b/docs/details/authentication/sender.md
@@ -13,7 +13,7 @@ Jedes antragssendende System (z.B. ein Online-Antragsservice) muss bei FIT-Conne
Bei der Registrierung eines antragssendenden Systems als API-Client über das Self-Service-Portal müssen die folgenden Informationen hinterlegt werden:
- Freigegebene Domains, von denen der Online-Antragsservice Formulare übermittelt
-- Eine Liste an [Zustellberechtigungs-Scopes](./scopes), die definiert, an welche Zustellpunkte Anträge durch den registrierten API-Client übermittelt werden dürfen.
+- Eine Liste an [Zustellberechtigungs-Scopes](./scopes.md), die definiert, an welche Zustellpunkte Anträge durch den registrierten API-Client übermittelt werden dürfen.
- Der Public Key des Onlineservice-Schlüsselpaar
## Schritt 2: Ausstellung von Berchtigungstokens für Onlineservices (Onlineservice-Token)
@@ -32,7 +32,7 @@ Im Payload des signierten Onlineservice-Token werden vom Authorisierungsdienst d
| `iss` (Issuer) | *URL des Authentifizierungsservers* | Die URL des Authentifizierungsservers, der das Token ausgestellt hat. |
| `sub` (Subject) | ID des Onlineservice | Wird bei der Registrierung des Online-Antragsdienstes im Self-Service-Portal durch den Autorisierungsdienst festgelegt und dient zur Identifizierung des antragssendenden Systems |
| `jti` (JWT ID) | *UUID des Tokens* | Eindeutige ID des ausgestellten Tokens. |
-| `scope` | *Liste von Zustellberechtigungs-Scopes* | Eine Liste der [Zustellberechtigungs-Scopes](./scopes), für die der Token eine Übermittlung erlaubt, separiert mit Leerzeichen gemäß [RFC 6749, Abschnitt 3.3](https://datatracker.ietf.org/doc/html/rfc6749#section-3.3). Die jeweiligen Zustellberechtigungs-Scopes werden im Self-Service-Portal bei der Registrierung des API-Client festgelegt. |
+| `scope` | *Liste von Zustellberechtigungs-Scopes* | Eine Liste der [Zustellberechtigungs-Scopes](./scopes.md), für die der Token eine Übermittlung erlaubt, separiert mit Leerzeichen gemäß [RFC 6749, Abschnitt 3.3](https://datatracker.ietf.org/doc/html/rfc6749#section-3.3). Die jeweiligen Zustellberechtigungs-Scopes werden im Self-Service-Portal bei der Registrierung des API-Client festgelegt. |
| `domains` | *Liste von Domains* | Eine Liste der Domains, von denen der Onlineservice Anträge übermitteln kann, separiert mit Leerzeichen (Subdomains müssen explizit aufgeführt werden) |
| `publicKey` | *Public Key des Onlineservice* | Der zum Schlüsselpaar des Online-Antragsservice gehörige Public Key, der dem Online-Antragsdienst bei der Registrierung im Self-Service-Portal zugeordnet wurde, im JSON Web Key-Format gemäß [RFC-7517](https://tools.ietf.org/html/rfc7517) |
| `token_type` | `sender` | Gibt an, das es sich um einen Token für ein antragssendendes System (typischerweise einen Onlineservice) handelt. |
@@ -62,7 +62,7 @@ Im Payload des signierten Onlineservice-Token werden vom Authorisierungsdienst d
## Schritt 3: Zugriff auf die Antrags-API mittels Access Tokens
-Für den Zugriff auf die Antrags-API des Zustelldienstes wird neben dem Onlineservice-Token immer auch ein sog. Access Token benötigt, der die generische [Zugriffsberechtigung des Onlinedienstes](./scopes) auf einen konkreten Zustellpunt (Destination) und/oder einen konkreten Antragsvorgang einschränkt. Dies ermöglicht die Weitergabe von eingeschränkten Berechtigungstokens an das Endgerät der Antragsteller:in (Browser bzw. App) und einen direkten, eingeschränkten Zugriff des Endgeräts auf die Antrags-API.
+Für den Zugriff auf die Antrags-API des Zustelldienstes wird neben dem Onlineservice-Token immer auch ein sog. Access Token benötigt, der die generische [Zugriffsberechtigung des Onlinedienstes](./scopes.md) auf einen konkreten Zustellpunkt (Destination) und/oder einen konkreten Antragsvorgang einschränkt. Dies ermöglicht die Weitergabe von eingeschränkten Berechtigungstokens an das Endgerät der Antragsteller:in (Browser bzw. App) und einen direkten, eingeschränkten Zugriff des Endgeräts auf die Antrags-API.
Access Token und Onlineservice-Token müssen beim Zugriff auf die Antrags-API via HTTP-Header an den Zustelldienst übermittelt werden. Mithilfe der beiden Tokens kann nachvollzogen werden, von welchem antragssendenden System ein Antrag an welchen Zustellpunkt übermittelt wird und ob das antragssendende System hierzu autorisiert ist.
@@ -90,7 +90,7 @@ Im Payload des signierten Access Tokens MÃœSSEN mindestens die folgenden [standa
| `iss` (Issuer) | ID des Onlineservice | Die ID des Onlineservice. Der angegebene Wert muss dem Feld `sub` des zugehörigen Onlineservice-Token entsprechen. |
| `jti` (JWT ID) | *UUID des Tokens* | Eindeutige ID des ausgestellten Tokens. |
| `aud` (Audience) | *URL der Zustelldienst-API* | Die URL der API des Zustelldienstes, für den der Token ausgestellt wurde, gemäß [RFC 7519, Abschnitt 4.1.3](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3). |
-| `scope` | Zustellberechtigungs-Scope | Eingeschränkte [Zustellberechtigung](./scopes) auf *eine* konkrete Destination-ID mit Präfix `destination:` (im Stile der Zustellberechtigungs-Scopes), für die der Token eine Antragseinreichung erlaubt. Der Zustellberechtigungs-Scope des zugehörigen Onlineservice-Token muss zur Antragseinreichung bei dieser Destination-ID berechtigen. |
+| `scope` | Zustellberechtigungs-Scope | Eingeschränkte [Zustellberechtigung](./scopes.md) auf *eine* konkrete Destination-ID mit Präfix `destination:` (im Stile der Zustellberechtigungs-Scopes), für die der Token eine Antragseinreichung erlaubt. Der Zustellberechtigungs-Scope des zugehörigen Onlineservice-Token muss zur Antragseinreichung bei dieser Destination-ID berechtigen. |
| `token_type` | *siehe unten* | Der Token-Typ gibt an, welche Funktion der ausgestellte Access Token erfüllt (siehe nächster Abschnitt). |
diff --git a/docs/getting-started/authentication.mdx b/docs/getting-started/authentication.mdx
index 95678bc66ce546e26eebbf8682956d874a152e1e..6e6ddc9b0ffcd06a7b54095fdd34b7fc3d233c73 100644
--- a/docs/getting-started/authentication.mdx
+++ b/docs/getting-started/authentication.mdx
@@ -4,7 +4,7 @@ import Tabs from '@theme/Tabs'
import TabItem from '@theme/TabItem'
Alle Anfragen an FIT-Connect müssen authentifiziert durchgeführt werden.
-Hierfür ist ein Access Token notwendig, den man beim OAuth-Dienst abholen kann. Hierfür ist ein entsprechender API-Client notwendig, der in "[Accountregistrierung](../account)" erstellt wird.
+Hierfür ist ein Access Token notwendig, den man beim OAuth-Dienst abholen kann. Hierfür ist ein entsprechender API-Client notwendig, der in "[Accountregistrierung](../account.md)" erstellt wird.
Das Token muss dann bei jeder Anfrage über den `Authentication`-Header mitgeschickt werden.
Da ein Token **max. 24h** gültig ist, muss dieses rechtzeitig erneuert werden.
@@ -12,8 +12,8 @@ Da ein Token **max. 24h** gültig ist, muss dieses rechtzeitig erneuert werden.
:::caution Generierung eines User-Tokens für sendende Systeme
Für sendende Systeme reicht der OAuth-Access-Token nicht aus, um Zugriff auf die API zu bekommen.
Sendende System müssen für den Zugriff auf die API ein User-Token generieren, welches Sie zusammen mit dem Access-Token an die API übermiteln müssen.
-Dieser Access-Token ist mit dem privaten Schlüssel des API Clients zu signieren, der dem öffentlichen Schlüssel des API-Clients entspricht (Siehe [Accountregistrierung](../account)).
-Für Aufbau und Beschreibung des User-Tokens siehe "[Generierung der JWT-Tokens](../details/authentication/sender#generierung-der-jwt-tokens)"
+Dieser Access-Token ist mit dem privaten Schlüssel des API Clients zu signieren, der dem öffentlichen Schlüssel des API-Clients entspricht (Siehe [Accountregistrierung](../account.md)).
+Für Aufbau und Beschreibung des User-Tokens siehe "[Generierung der JWT-Tokens](../details/authentication/sender.md#generierung-der-jwt-tokens)"
:::
<Tabs
diff --git a/docs/getting-started/encryption.md b/docs/getting-started/encryption.md
index 5effb1b6785262e61a64dd2c55e5911c8a10eab3..991347c11343efa683967ba18bbd22f83396cfeb 100644
--- a/docs/getting-started/encryption.md
+++ b/docs/getting-started/encryption.md
@@ -1,20 +1,33 @@
# Verschlüsselte Übertragung
-FIT-Connect verwendet zur Übertragung von Antragsdaten und Antragsmetadaten, abgesehen von den für die Übermittlung zwingend notwendigen Daten, eine Ende-zu-Ende-Verschlüsselung.
-Diese ist auf Basis der Standards [JSON Web Encryption (JWE)](https://tools.ietf.org/html/rfc7516) und [JSON Web Keys (JWK)](https://tools.ietf.org/html/rfc7517) umgesetzt.
+FIT-Connect verwendet zur Übertragung von Antragsdaten und Antragsmetadaten, abgesehen von den für die Übermittlung
+zwingend notwendigen Daten, eine Ende-zu-Ende-Verschlüsselung. Diese ist auf Basis der
+Standards [JSON Web Encryption (JWE)](https://tools.ietf.org/html/rfc7516)
+und [JSON Web Keys (JWK)](https://tools.ietf.org/html/rfc7517) umgesetzt.
-Die JSON Web Keys werden hierbei aber aus Zertifikaten abgeleitet und die öffentlichen Teile in einem Zustellpunkt für die Verwendung durch ein Fachverfahren hinterlegt.
-Es können mehrere JWKs hinterlegt werden, welche entweder für die Verschlüsselung oder Signaturprüfung verwendet werden können.
+Die JSON Web Keys werden hierbei aber aus Zertifikaten abgeleitet und die öffentlichen Teile in einem Zustellpunkt für
+die Verwendung durch ein Fachverfahren hinterlegt. Es können mehrere JWKs hinterlegt werden, welche entweder für die
+Verschlüsselung oder Signaturprüfung verwendet werden können.
-:::note Hinweis
-Die Zertifikate und damit verbundenen JWKs müssen in regelmäßigen Intervallen rolliert werden, was sich an der Gültigkeitsdauer der Zertifikate orientiert.
+:::note Hinweis Die Zertifikate und damit verbundenen JWKs müssen in regelmäßigen Intervallen rolliert werden, was sich
+an der Gültigkeitsdauer der Zertifikate orientiert.
:::
## Vorgaben für eingesetzte X.509-Zertifikate
-Die Voraussetzung, damit Clients Daten verschlüsseln bzw. Signaturen prüfen können, ist ein gültiges X.509-Zertifikat aus der Verwaltungs-PKI. 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 Voraussetzung, damit Clients Daten verschlüsseln bzw. Signaturen prüfen können, ist ein gültiges X.509-Zertifikat
+aus der Verwaltungs-PKI. 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.
-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.
+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 X.509-Zertifikate gelten in FIT-Connect die folgenden kryptografischen Vorgaben:
@@ -38,17 +51,22 @@ Ein entsprechendes Zertifikat kann über die folgenden Schritte erstellt werden:
openssl req -new -sha512 -key fachverfahren1.meineverwaltung.de.key -out fachverfahren1.meineverwaltung.de.csr
```
- :::note Hinweis
- Nicht alle Felder, die `openssl` hier erfragt müssen ausgefüllt werden. Jedoch sollten so viele wie möglich nach bestem Wissen ausgefüllt werden.
- :::
+:::note Hinweis Nicht alle Felder, die `openssl` hier erfragt müssen ausgefüllt werden. Jedoch sollten so viele wie
+möglich nach bestem Wissen ausgefüllt werden.
+:::
-3. Dieser Zertifikatsrequest muss nun von einer Verwaltungs-PKI signiert werden. Der Ablauf ist je nach zuständiger Verwaltungs-PKI unterschiedlich, wodurch den jeweiligen Anweisungen bzw. Schritten zur Beantragung zu folgen ist.
+3. Dieser Zertifikatsrequest muss nun von einer Verwaltungs-PKI signiert werden. Der Ablauf ist je nach zuständiger
+ Verwaltungs-PKI unterschiedlich, wodurch den jeweiligen Anweisungen bzw. Schritten zur Beantragung zu folgen ist.
## 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 Schlüssel sollten erst dort generiert werden, wo sie am Ende eingesetzt werden. Ein unnötiges Übertragen von privaten Schlüsseln zwischen Servern/Computern sollte vermieden werden. Sollte dies doch notwendig sein, so muss die Übermittlung nur verschlüsselt erfolgen.
+JSON Web Keys sind das Austauschformat in dem kryptografische Schlüssel in FIT-Connect zwischen der Destination und dem
+Onlinedienst ausgetauscht werden. Die Schlüssel sollten erst dort generiert werden, wo sie am Ende eingesetzt werden.
+Ein unnötiges Übertragen von privaten Schlüsseln zwischen Servern/Computern sollte vermieden werden. Sollte dies doch
+notwendig sein, so muss die Übermittlung nur verschlüsselt erfolgen.
-Im Folgenden eine beispielhafte Schritt-für-Schritt-Anleitung, um aus einem Zertifikat aus der Verwaltungs-PKI einen JSON-Web-Key zu erzeugen:
+Im Folgenden eine beispielhafte Schritt-für-Schritt-Anleitung, um aus einem Zertifikat aus der Verwaltungs-PKI einen
+JSON-Web-Key zu erzeugen:
1. Das von der Verwaltungs-PKI signierte Zertifikat muss nun in einen JWK umgewandelt werden:
@@ -62,25 +80,32 @@ Im Folgenden eine beispielhafte Schritt-für-Schritt-Anleitung, um aus einem Zer
# pubkey --[into]--> JWK
```
-Die JSON Web Keys müssen vor der Verwendung in einem Client immer auf Gültigkeit geprüft werden. Das umfasst insbesondere folgende Punkte:
+Die JSON Web Keys müssen vor der Verwendung in einem Client immer auf Gültigkeit geprüft werden. Das umfasst
+insbesondere folgende Punkte:
- Überprüfung gegen eine Certificate Revocation List und/oder einen OCSP-Endpunkt mit signierten Antworten.
- Überprüfung der Zertifikats-Kette bis zum Wurzelzertifikat (BSI) über das Attribut `x5c` im JWK
-Weitere Informationen zur Gültigkeitsprüfung finden sich im BSI [TR-02103](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02103/BSI-TR-02103.pdf?__blob=publicationFile&v=4) und im Abschnitt "[Anforderungen an das kryptografische Material](#Vorgaben-für-kryptographische-Verfahren)" .
+Weitere Informationen zur Gültigkeitsprüfung finden sich im
+BSI [TR-02103](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02103/BSI-TR-02103.pdf?__blob=publicationFile&v=4)
+und im Abschnitt "[Anforderungen an das kryptografische Material](#Vorgaben-für-kryptographische-Verfahren)" .
### Vorgaben für JSON Web Keys zur Verschlüsselung {#encryption-requirements}
-Der resultierende JWK muss, falls er für die Verschlüsselung genutzt werden soll, in FIT-Connect über die folgenden Attribute gemäß [RFC 7517](https://tools.ietf.org/html/rfc7517#section-4) verfügen:
+Der resultierende JWK muss, falls er für die Verschlüsselung genutzt werden soll, in FIT-Connect ü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) |
+| 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:
@@ -88,15 +113,17 @@ Das bedeutet, der JSON Web Key zur Verschlüsselung muss diesem Format entsprech
```json
{
"kty": "RSA",
- "key_ops": ["wrapKey"],
+ "key_ops": [
+ "wrapKey"
+ ],
"alg": "RSA-OAEP-256",
"n": "……(Public Key)……",
"e": "AQAB",
"kid": "……(Key ID)……",
"x5c": [
- "……(base64 encoded cert)……",
- "……(base64 encoded intermediate cert)……",
- "……(base64 encoded root cert)……"
+ "……(base64 encoded cert)……",
+ "……(base64 encoded intermediate cert)……",
+ "……(base64 encoded root cert)……"
]
}
```
diff --git a/docs/getting-started/receiving/destination.mdx b/docs/getting-started/receiving/destination.mdx
index 0cf132afc5943ba51dc9ca785256173e4c679920..5a229c7d66fa30823884f51274b256d6dc5e1753 100644
--- a/docs/getting-started/receiving/destination.mdx
+++ b/docs/getting-started/receiving/destination.mdx
@@ -66,10 +66,10 @@ der alle notwendigen Informationen beinhaltet. Ein exemplarischer Inhalt ist unt
}
```
-Wenn die JSON-Datei entsprechend befüllt ist und man ein [gültiges JWT](../authentication) hat, kann über den Befehl unten der Zustellpunkt angelegt werden.
+Wenn die JSON-Datei entsprechend befüllt ist und man ein [gültiges JWT](../authentication.mdx) hat, kann über den Befehl unten der Zustellpunkt angelegt werden.
:::note Hinweis
- Soll ein Zustellpunkt nur aktualisiert werden, muss anstelle eines POST-Befehls ein [PUT-Befehl](../../apis/delivery-service#put-/destinations/-destinationId-) für den entsprechenden Zustellpunkt gesendet werden.
+ Soll ein Zustellpunkt nur aktualisiert werden, muss anstelle eines POST-Befehls ein [PUT-Befehl](../../apis/delivery-service.mdx#put-/destinations/-destinationId-) für den entsprechenden Zustellpunkt gesendet werden.
:::
```bash
diff --git a/docs/getting-started/receiving/query.mdx b/docs/getting-started/receiving/query.mdx
index 251f311c1b8c5592c48214fe224bac50e0f108cf..2c62287494375b87ea236286076722cd0a7f3c67 100644
--- a/docs/getting-started/receiving/query.mdx
+++ b/docs/getting-started/receiving/query.mdx
@@ -9,7 +9,7 @@ Letzteres wäre die präferierte Variante, da dadurch unnötige Anfragen vermied
## Callback
Wenn eine neue Einreichung im Zustelldienst bereitsteht und eine Callback-URL im Zustellpunkt hinterlegt ist, kann der Zustelldienst den Zustellpunkt direkt informieren.
-Das Format, in welchem der Callback übertragen wird, ist in der [API-Spezifikation](../../apis/delivery-service#post-/destinations) beschrieben.
+Das Format, in welchem der Callback übertragen wird, ist in der [API-Spezifikation](../../apis/delivery-service.mdx#post-/destinations) beschrieben.
Im Endeffekt, ist es jedoch ein Array mit UUIDs für jede bereitstehende Einreichung, wie im Beispiel unten.
```json
diff --git a/docs/getting-started/receiving/validate.mdx b/docs/getting-started/receiving/validate.mdx
index f1d2467fd25f69380f055035a7e887ceb0aeaa2e..c8771e0d6b8e24ef66a427dd12b40efb4e1db9fd 100644
--- a/docs/getting-started/receiving/validate.mdx
+++ b/docs/getting-started/receiving/validate.mdx
@@ -3,7 +3,7 @@ sidebar_position: 6
title: Validierung
---
-Das Minimum, was an Information vorhanden sein muss sind die Felder `contentStructure` und `submissionId`. Zustäzlich können je nach Anwendungsfall oder Notwendigkeit weitere Felder auf Existenz überprüft werden. Die gültigen Formate sind im Schema definiert und können mit Hilfe von Bibliotheken für die Validierung einer Instanz von Antragsmetadaten verwendet werden. Beispiele für die Definition von Formaten für Felder sind unten aufgeführt.
+Das Minimum, was an Information vorhanden sein muss sind die Felder `contentStructure` und `submissionId`. Zusätzlich können je nach Anwendungsfall oder Notwendigkeit weitere Felder auf Existenz überprüft werden. Die gültigen Formate sind im Schema definiert und können mithilfe von Bibliotheken für die Validierung einer Instanz von Antragsmetadaten verwendet werden. Beispiele für die Definition von Formaten für Felder sind unten aufgeführt.
```json
{
diff --git a/docs/getting-started/sending/metadata.mdx b/docs/getting-started/sending/metadata.mdx
index ff19dad02ce5d7d7fb7eaddc53de1db0bddd9db7..8e1507612562d78e3036ee704945f7beeaed0096 100644
--- a/docs/getting-started/sending/metadata.mdx
+++ b/docs/getting-started/sending/metadata.mdx
@@ -3,7 +3,7 @@ title: Metadaten
sidebar_position: 5
---
-Die Antragsmetadaten beschreiben die Struktur der Einreichung und dessen Inhalte, wie beispielsweise Anhänge oder die Fachdaten. Zustätzlich können weitere Informationen über den/die AntragsstellerInnen hinterlegt werden. Eine genaue Definition ist unter XYZ zu finden bzw. direkt im [Schema](https://fitko.uber.space/0.9.0/antragsmetadaten.schema.json) zu finden.
+Die Antragsmetadaten beschreiben die Struktur der Einreichung und dessen Inhalte, wie beispielsweise Anhänge oder die Fachdaten. Zusätzlich können weitere Informationen über den/die AntragsstellerInnen hinterlegt werden. Eine genaue Definition ist unter XYZ zu finden bzw. direkt im [Schema](https://fitko.uber.space/0.9.2/antragsmetadaten.schema.json) zu finden.
Im Folgenden wird nun beschrieben, wie für das Versenden einer Einreichung das Schema aufgebaut und befüllt wird, sowie beim Empfangen einer Einreichung dieser entschlüsselt und gegen das Schema validiert wird.
diff --git a/docs/getting-started/sending/overview.mdx b/docs/getting-started/sending/overview.mdx
index a8137c8fcab4879b0b2518e82651fcffdf8ddbc8..85e9d2a8fdd16c8982bd0e218e7cfd1e5af64154 100644
--- a/docs/getting-started/sending/overview.mdx
+++ b/docs/getting-started/sending/overview.mdx
@@ -97,7 +97,7 @@ Das Self-Service-Portal befindet sich noch in der Konzeption und ist daher noch
## Eine neue Einreichung beginnen
-Das Beginnen einer neuen Einreichung über die API erfordert den Versand einer [HTTP POST Nachricht](../../apis/delivery-service#post-/applications), die definiert, an welchen Zustellpunkt der Einreichung versendet werden soll und welche Inhalte übermittelt werden sollen.
+Das Beginnen einer neuen Einreichung über die API erfordert den Versand einer [HTTP POST Nachricht](../../apis/delivery-service.mdx#post-/applications), die definiert, an welchen Zustellpunkt der Einreichung versendet werden soll und welche Inhalte übermittelt werden sollen.
Die Inhalte umfassen hierbei die Identifikatoren der Anhänge als UUIDs und die Information, ob Fachdaten mit versendet werden oder nicht.
<Tabs
diff --git a/docs/overview.md b/docs/overview.md
index 35c8a440e29a06734b84aa8e1f76ea4c7ad98e75..c2c5b856e8880cd2f2311b368bf793601de49abc 100644
--- a/docs/overview.md
+++ b/docs/overview.md
@@ -3,59 +3,113 @@ title: Ãœberblick
slug: /
---
-Willkommen auf der Dokumentation für die FIT-Connect API von FITKO. Die FIT-Connect API baut auf dem bestehenden IT-Planungsrat Standard FIT-Connect auf und bietet Lösungsverantwortlichen von sendenden und empfangenden Systemen eine einfache Möglichkeit, ihre Software schnell und wirtschaftlich in länder- und ebenenübergreifende Antragsprozesse zu integrieren.
+Willkommen auf der Dokumentation für die FIT-Connect API von FITKO. Die FIT-Connect API baut auf dem bestehenden
+IT-Planungsrat Standard FIT-Connect auf und bietet Lösungsverantwortlichen von sendenden und empfangenden Systemen eine
+einfache Möglichkeit, ihre Software schnell und wirtschaftlich in länder- und ebenenübergreifende Antragsprozesse zu
+integrieren.
## Was ist die FIT-Connect API und was unterscheidet diese API vom bisherigen XFall Standard?
-Die FIT-Connect API baut auf den bisherigen Konzepten und Erfahrungen des bestehenden IT-Planungsrats Standards XFall auf.
+Die FIT-Connect API baut auf den bisherigen Konzepten und Erfahrungen des bestehenden IT-Planungsrats Standards XFall
+auf.
> Die übergreifende Zielstellung des Standards FIT-Connect besteht darin, Anträge und Berichte, die aus vorgelagerten Systemen (bspw. Onlineantragsdienste, Fachportale oder Berichtssysteme) erstellt werden, in die unterschiedlichen Systeme der elektronischen Verfahrensbearbeitung (bspw. Fachverfahren, Dokumentenmanagementsystem oder Prozessplattformen) zu übergeben.
-Bei der Entwicklung der FIT-Connect API wurden viele Konzepte mit Hinblick auf die neuen Erfordernisse des Onlinezugangsgesetzes, der SDG-Verordnung sowie den Anforderungen digitaler Geschäftsmodelle weiterentwickelt. Technisch nutzt die FIT-Connect API auf einen leichtgewichtigen RESTful-Architekturstil und baut auf der föderalen Antragsübertragungsarchitektur von FIT-Connect auf.
+Bei der Entwicklung der FIT-Connect API wurden viele Konzepte mit Hinblick auf die neuen Erfordernisse des
+Onlinezugangsgesetzes, der SDG-Verordnung sowie den Anforderungen digitaler Geschäftsmodelle weiterentwickelt. Technisch
+nutzt die FIT-Connect API auf einen leichtgewichtigen RESTful-Architekturstil und baut auf der föderalen
+Antragsübertragungsarchitektur von FIT-Connect auf.
## Was macht die FIT-Connect API und wie kann diese genutzt werden?
Die FIT-Connect API besteht aus zwei getrennt nutzbaren APIs:
-- Für empfangende Systeme wird eine `Application Subscriber API` für den Empfang von Anträgen sowie eine `Callback` / Webhook Funktion für die technische Benachrichtigung über vorliegende Anträge angeboten.
-- Für sendende Systeme wird eine `Application Sender API` angeboten, um an beliebige empfangende Systeme Anträge zu senden, die sich mit einem Zustellpunkt registriert haben.
+- Für empfangende Systeme wird eine `Application Subscriber API` für den Empfang von Anträgen sowie eine `Callback` /
+ Webhook Funktion für die technische Benachrichtigung über vorliegende Anträge angeboten.
+- Für sendende Systeme wird eine `Application Sender API` angeboten, um an beliebige empfangende Systeme Anträge zu
+ senden, die sich mit einem Zustellpunkt registriert haben.
-Diese beiden APIs werden durch einen zentralen Intermediär (`FIT-Connect Zustelldienst`) bereitgestellt. Um auf diese APIs zuzugreifen, müssen interessierte Entwickler ihre Anwendungen beim FIT-Connect Autorisierungsdienst vorab registrieren.
+Diese beiden APIs werden durch einen zentralen Intermediär (`FIT-Connect Zustelldienst`) bereitgestellt. Um auf diese
+APIs zuzugreifen, müssen interessierte Entwickler ihre Anwendungen beim FIT-Connect Autorisierungsdienst vorab
+registrieren.
### Zusammenspiel der APIs in der Antragsübermittlung
-Über die `Application Subscriber API` können die zuständigen Stellen für ihre Systeme einen Zustellpunkt eröffnen, der über eine `destination-Id` eindeutig adressierbar ist. Für diese Zustellpunkte legen die zuständigen Stellen alle fachlichen Vorgaben (Zulässige Fachstandards, Verschlüsselung, Datenformate etc.) fest, damit eine medienbruchfreie Weiterverarbeitung in ihren Systemen gewährleistet ist. Über die Angabe der `destination-Id` in der `Application Sender API` können beliebige sendende Systemen Anträge an die zuständige Stelle senden.
-
-Dieser Zustellpunkt ist jedoch vorab für eine Verwaltungsleistung und den jeweiligen örtlichen Antragskontext (bspw. Ort der Antragsstellung) korrekt zu ermitteln. Damit die Ermittlung des korrekten Zustellpunkts skalierbar für das ganze Bundesgebiet funktioniert, ist langfristig vorgesehen, die `destination-Id` in den Leistungs- und Zuständigkeitsinformationen des jeweils bekannten Zuständigkeitsfinders zu hinterlegen. Diese dezentral gepflegten Informationen sollen durch das Online-Gateway (<https://www.onlinezugangsgesetz.de/Webs/OZG/DE/umsetzung/portalverbund/online-gateway/online-gateway-node.html>) gebündelt und über eine offene API im XZuFi Format (<https://www.xrepository.de/details/urn:xoev-de:fim:standard:xzufi>) nutzbar gemacht werden.
+Über die `Application Subscriber API` können die zuständigen Stellen für ihre Systeme einen Zustellpunkt eröffnen, der
+über eine `destination-Id` eindeutig adressierbar ist. Für diese Zustellpunkte legen die zuständigen Stellen alle
+fachlichen Vorgaben (Zulässige Fachstandards, Verschlüsselung, Datenformate etc.) fest, damit eine medienbruchfreie
+Weiterverarbeitung in ihren Systemen gewährleistet ist. Über die Angabe der `destination-Id` in
+der `Application Sender API` können beliebige sendende Systemen Anträge an die zuständige Stelle senden.
+
+Dieser Zustellpunkt ist jedoch vorab für eine Verwaltungsleistung und den jeweiligen örtlichen Antragskontext (bspw. Ort
+der Antragsstellung) korrekt zu ermitteln. Damit die Ermittlung des korrekten Zustellpunkts skalierbar für das ganze
+Bundesgebiet funktioniert, ist langfristig vorgesehen, die `destination-Id` in den Leistungs- und
+Zuständigkeitsinformationen des jeweils bekannten Zuständigkeitsfinders zu hinterlegen. Diese dezentral gepflegten
+Informationen sollen durch das
+Online-Gateway (<https://www.onlinezugangsgesetz.de/Webs/OZG/DE/umsetzung/portalverbund/online-gateway/online-gateway-node.html>)
+gebündelt und über eine offene API im XZuFi Format (<https://www.xrepository.de/details/urn:xoev-de:fim:standard:xzufi>)
+nutzbar gemacht werden.
## Für wen ist die FIT-Connect API gedacht und warum sollte ich sie nutzen?
-Die FIT-Connect API ist für alle Hersteller, Entwickler und Verfahrensverantwortliche von sendenden und empfangenden Systemen gedacht. Insbesondere folgende Systeme mit bundesweiten Nutzungsszenarien sollen mit der FIT-Connect API unterstützt werden:
-
-- **Einer für alle (EfA) Verfahren**: Länderübergreifend entwickelte Antragsverfahren für eine bestimmte Verwaltungsleistung oder ein Leistungsbündel, die entweder in verschiedenen Ländern nachnutzbar betrieben werden oder länderübergreifend als gemeinsamer Antragsdienst für alle zuständigen Stellen betrieben werden.
-- **Antragsgeneratoren / Antragsmanagementsysteme**: Standardsoftware zur Erstellung und dem Betrieb von direkt nutzbaren Onlineantragsdiensten, die im ganzen Bundesgebiet bei einzelnen Stellen oder Gebietskörperschaften (bspw. als Basiskomponente) im Einsatz sind.
-- **Als Standardsoftware bereitgestellte Fachverfahrenssoftware, Prozessplattformen oder Dokumentenmanagementsysteme**: Bundesweit angebotene und eingesetzte Standardsoftware, die von den zuständigen Stellen für die Antragsbearbeitung eingesetzt wird.
-
-Für diese Systeme bietet die FIT-Connect bei der schnellen und wirtschaftlichen Realisierung medienbruchfreier Antragsprozesse eine Reihe von Mehrwerten:
-
-- **Plug and Play Anbindung an die föderale Antragsübermittlung**: Durch die zentral bereitgestellten APIs und die Nutzung der bestehenden Zuständigkeitsfinderinfrastruktur können Systeme schnell an eine föderale Antragsübermittlungsinfrastruktur angebunden werden, ohne eigene Infrastrukturen hierfür zu beauftragen oder aufzubauen.
-- **Leichgewichtige APIs und Industriestandards**: Die FIT-Connect API baut auf leichgewichtigen RESTful API Ansätzen auf und nutzt verbreitete Industriestandards wie die OpenAPI Specification und OAuth 2.0, sodass kein spezialisiertes Know-How und spezifische Softwarekomponenten für die Anbindung erforderlich sind.
-- **Flexibilität in der Antragsübermittlung**: Die FIT-Connect API verbindet Flexibilität und Standardisierung. Während die FIT-Connect API eine einheitliche Metadatenstruktur festlegt, um Anträge strukturiert zu verarbeiten, können beliebige Fachstandards und Anhänge übertragen werden. Auch die Übertragung von Anträgen im PDF Format ist möglich, solange für die Antragsdaten noch kein FIM Schema vorhanden ist.
-**Nutzung bestehender Prozesse und Strukturen für die Pflege von Adressierungsinformationen**: Langjährig erprobte Prozesse und Strukturen zur Pflege der Zuständigkeitsinformationen, können in den zuständigen Stellen beibehalten werden. Technische Adressierungsparameter der FIT-Connect API werden über die gleichen Systeme und Prozesse gepflegt, die schon heute bei Informationen zu Anschriften, Rufnummern, E-Mail-Adressen oder Ansprechpartnern genutzt werden.
-- **Machine2Machine Ready**: Die FIT-Connect API und die FIT-Connect Antragsübertragungsarchitektur sind von Grund auf als offene API-Plattform konzipiert. Dadurch können auch verwaltungsexterne Antrags- und Berichtssysteme wie Drittsoftware oder Unternehmenssysteme direkt eingebunden werden, ohne das hierfür eine gesonderte Infrastruktur notwendig ist.
+Die FIT-Connect API ist für alle Hersteller, Entwickler und Verfahrensverantwortliche von sendenden und empfangenden
+Systemen gedacht. Insbesondere folgende Systeme mit bundesweiten Nutzungsszenarien sollen mit der FIT-Connect API
+unterstützt werden:
+
+- **Einer für alle (EfA) Verfahren**: Länderübergreifend entwickelte Antragsverfahren für eine bestimmte
+ Verwaltungsleistung oder ein Leistungsbündel, die entweder in verschiedenen Ländern nachnutzbar betrieben werden oder
+ länderübergreifend als gemeinsamer Antragsdienst für alle zuständigen Stellen betrieben werden.
+- **Antragsgeneratoren / Antragsmanagementsysteme**: Standardsoftware zur Erstellung und dem Betrieb von direkt
+ nutzbaren Onlineantragsdiensten, die im ganzen Bundesgebiet bei einzelnen Stellen oder Gebietskörperschaften (bspw.
+ als Basiskomponente) im Einsatz sind.
+- **Als Standardsoftware bereitgestellte Fachverfahrenssoftware, Prozessplattformen oder Dokumentenmanagementsysteme**:
+ Bundesweit angebotene und eingesetzte Standardsoftware, die von den zuständigen Stellen für die Antragsbearbeitung
+ eingesetzt wird.
+
+Für diese Systeme bietet die FIT-Connect bei der schnellen und wirtschaftlichen Realisierung medienbruchfreier
+Antragsprozesse eine Reihe von Mehrwerten:
+
+- **Plug and Play Anbindung an die föderale Antragsübermittlung**: Durch die zentral bereitgestellten APIs und die
+ Nutzung der bestehenden Zuständigkeitsfinderinfrastruktur können Systeme schnell an eine föderale
+ Antragsübermittlungsinfrastruktur angebunden werden, ohne eigene Infrastrukturen hierfür zu beauftragen oder
+ aufzubauen.
+- **Leichgewichtige APIs und Industriestandards**: Die FIT-Connect API baut auf leichgewichtigen RESTful API Ansätzen
+ auf und nutzt verbreitete Industriestandards wie die OpenAPI Specification und OAuth 2.0, sodass kein spezialisiertes
+ Know-How und spezifische Softwarekomponenten für die Anbindung erforderlich sind.
+- **Flexibilität in der Antragsübermittlung**: Die FIT-Connect API verbindet Flexibilität und Standardisierung. Während
+ die FIT-Connect API eine einheitliche Metadatenstruktur festlegt, um Anträge strukturiert zu verarbeiten, können
+ beliebige Fachstandards und Anhänge übertragen werden. Auch die Übertragung von Anträgen im PDF Format ist möglich,
+ solange für die Antragsdaten noch kein FIM Schema vorhanden ist.
+ **Nutzung bestehender Prozesse und Strukturen für die Pflege von Adressierungsinformationen**: Langjährig erprobte
+ Prozesse und Strukturen zur Pflege der Zuständigkeitsinformationen, können in den zuständigen Stellen beibehalten
+ werden. Technische Adressierungsparameter der FIT-Connect API werden über die gleichen Systeme und Prozesse gepflegt,
+ die schon heute bei Informationen zu Anschriften, Rufnummern, E-Mail-Adressen oder Ansprechpartnern genutzt werden.
+- **Machine2Machine Ready**: Die FIT-Connect API und die FIT-Connect Antragsübertragungsarchitektur sind von Grund auf
+ als offene API-Plattform konzipiert. Dadurch können auch verwaltungsexterne Antrags- und Berichtssysteme wie
+ Drittsoftware oder Unternehmenssysteme direkt eingebunden werden, ohne das hierfür eine gesonderte Infrastruktur
+ notwendig ist.
### Ist die FIT-Connect API nur für länder- und behördenübergreifende Antragskontexte gedacht?
-Durch die einfache Anbindung und Nutzung bietet sich die FIT-Connect API auch dort an, wo das behördeneigene Antragsverfahren mit dem behördeneigenen Fachverfahren verbunden wird. Durch die Nutzung der FIT-Connect API werden diese Systeme standardisiert verbunden, ohne das die Behörde in Abhängigkeiten zu proprietären Technologien und Schnittstellen gerät. Dies ermöglicht es der Behörde, ihre Systeme auf beiden Seiten flexibel auszutauschen und weiterzuentwickeln, um somit auf neue technische Trends und Möglichkeit schnell zu reagieren.
+Durch die einfache Anbindung und Nutzung bietet sich die FIT-Connect API auch dort an, wo das behördeneigene
+Antragsverfahren mit dem behördeneigenen Fachverfahren verbunden wird. Durch die Nutzung der FIT-Connect API werden
+diese Systeme standardisiert verbunden, ohne das die Behörde in Abhängigkeiten zu proprietären Technologien und
+Schnittstellen gerät. Dies ermöglicht es der Behörde, ihre Systeme auf beiden Seiten flexibel auszutauschen und
+weiterzuentwickeln, um somit auf neue technische Trends und Möglichkeit schnell zu reagieren.
## In welchem Stand befindet sich FIT-Connect API und wann kann man die API nutzen?
-Die Entwicklung und Bereitstellung der FIT-Connect API erfolgt im Rahmen eines Proof of Concepts für die geplante föderale Integrations- und Entwicklungsplattform FIT-Connect. Seit dem zweiten Quartal 2020 ist es interessierten Parteien möglich, einen Zugang zur FIT-Connect API zu bekommen und eine prototypische Anbindung von Verfahren umzusetzen.
+Die Entwicklung und Bereitstellung der FIT-Connect API erfolgt im Rahmen eines Proof of Concepts für die geplante
+föderale Integrations- und Entwicklungsplattform FIT-Connect. Seit dem zweiten Quartal 2020 ist es interessierten
+Parteien möglich, einen Zugang zur FIT-Connect API zu bekommen und eine prototypische Anbindung von Verfahren
+umzusetzen.
## Ich habe einen Fehler in der Dokumentation oder in der API-Spezifikation gefunden. Wo kann ich diesen melden?
-Vielen Dank für das Interesse an unserer Entwickler:innendokumentation! Wir freuen uns immer über Feedback und Anregungen über unser Funktionspostfach fit-connect ät fitko.de. Zudem können wir bei Interesse gerne einen Zugang zu unserem GitLab zur Eröffnung von Issues oder Einreichung von Merge-Requests einrichten.
+Vielen Dank für das Interesse an unserer Entwickler:innendokumentation! Wir freuen uns immer über Feedback und
+Anregungen über unser Funktionspostfach fit-connect ät fitko.de. Zudem können wir bei Interesse gerne einen Zugang zu
+unserem GitLab zur Eröffnung von Issues oder Einreichung von Merge-Requests einrichten.
diff --git a/docs/roadmap.md b/docs/roadmap.md
index b8d4de7f9d72cb790c39112ebc587658b6a2cba5..4ee5f2afcfa013f6dab6263b232d83a08b96b26c 100644
--- a/docs/roadmap.md
+++ b/docs/roadmap.md
@@ -1,67 +1,119 @@
# Roadmap
-Die FIT-Connect Einreichungs-API und die dazugehörige Infrastruktur wird in einem Projekt des IT-Planungsrats im Jahr 2021 zu einer Produktreife entwickelt. Die Umsetzung der Projektliefergegenstände erfolgt iterativ, um eine schnelle Erprobung und Feedback zu ermöglichen.
+Die FIT-Connect Einreichungs-API und die dazugehörige Infrastruktur wird in einem Projekt des IT-Planungsrats im Jahr
+2021 zu einer Produktreife entwickelt. Die Umsetzung der Projektliefergegenstände erfolgt iterativ, um eine schnelle
+Erprobung und Feedback zu ermöglichen.
-Die Roadmap soll daher einen Überblick verschaffen, wann das FIT-Connect Team für die folgende Projektliefergegenstände neue Features anstebt:
+Die Roadmap soll daher einen Überblick verschaffen, wann das FIT-Connect Team für die folgende Projektliefergegenstände
+neue Features anstebt:
- **API-Spezifikation:** In der OpenAPI geschriebene Spezifikation der FIT-Connect Einreichungs-API.
-- **Entwicklerdokumentation- und tools:** Weiterführende Dokumentationsartikel zur technischen Anbindung an der API für sendende und empfangende Systeme udn Bereitstellung von Tools für technische Querschnittsaufgaben wie Tokenhandling, Signaturprüfung oder Verschlüsselung.
-- **Infrastruktur:** Bereitstellung von Infrastrukturkomponenten für die Durchführung von Anbindungstests oder Validierungsaufgaben sowie die produktive Bereitstellung der API für Datenübermittlungen.
+- **Entwicklerdokumentation- und tools:** Weiterführende Dokumentationsartikel zur technischen Anbindung an der API für
+ sendende und empfangende Systeme udn Bereitstellung von Tools für technische Querschnittsaufgaben wie Tokenhandling,
+ Signaturprüfung oder Verschlüsselung.
+- **Infrastruktur:** Bereitstellung von Infrastrukturkomponenten für die Durchführung von Anbindungstests oder
+ Validierungsaufgaben sowie die produktive Bereitstellung der API für Datenübermittlungen.
-Die Roadmap wird laufend aktualisiert und erweitert. Unser Team versucht weitestgehend verbindliche Termine zu benennen, jedoch passen wir die Umsetzungen den aktuellen Bedarfen des Projekts an, wodurch es zu Verzögerungen bei manchen Liefergegenständen kommen kann. Umgekehrt kann es auch sein, das Features früher fertiggestellt werden, falls die Prioritäten ändern oder freie Kapazitäten zur Verfügung stehen.
+Die Roadmap wird laufend aktualisiert und erweitert. Unser Team versucht weitestgehend verbindliche Termine zu benennen,
+jedoch passen wir die Umsetzungen den aktuellen Bedarfen des Projekts an, wodurch es zu Verzögerungen bei manchen
+Liefergegenständen kommen kann. Umgekehrt kann es auch sein, das Features früher fertiggestellt werden, falls die
+Prioritäten ändern oder freie Kapazitäten zur Verfügung stehen.
-Wir nehmen gerne neue Wünsche & Anregungen für die FIT-Connect API als Issue auf unserem Projekt (https://git.fitko.de/fit-connect/api) entgegen und versuche diese Issues nach einer Umsetzungsprüfung in unsere Roadmap aufzunehmen.
+Wir nehmen gerne neue Wünsche & Anregungen für die FIT-Connect API als Issue auf unserem
+Projekt (https://git.fitko.de/fit-connect/api) entgegen und versuche diese Issues nach einer Umsetzungsprüfung in unsere
+Roadmap aufzunehmen.
> Wünsche & Anregungen oder Fehler können über den [hier](overview.md#ich-habe-einen-fehler-in-der-dokumentation-oder-in-der-api-spezifikation-gefunden-wo-kann-ich-diesen-melden) beschriebenen Prozess abgegeben werden können.
## Überblick über die Zeitplanung
-- **Seit 24.06.2021:** Preview der API-Spezifikation und der Entwicklerdokumentaion für die Version 1.0 der API ist online und ist für alle interessierten Entwickler zugänglich.
-- **Mitte Juli 2021:** Bis zu diesem Zeitpunkt werden alle Kernfeatures API spezifiziert und als stabile API Spezifikation veröffentlicht. Für die Evaluierung und Entwicklung durch interessierte Entwickler wird ein öffentlicher Testserver bereitgestellt.
-- **Mitte September 2021:** Die API wird als Produktivinfrastruktur für erste Pilotantragsverfahren und deren Systeme bereitstellt. Zudem werden noch neue abwärtskompatible Features und zusätzliche Entwicklerangebote bereitgestellt.
+- **Seit 24.06.2021:** Preview der API-Spezifikation und der Entwicklerdokumentaion für die Version 1.0 der API ist
+ online und ist für alle interessierten Entwickler zugänglich.
+- **Mitte Juli 2021:** Bis zu diesem Zeitpunkt werden alle Kernfeatures API spezifiziert und als stabile API
+ Spezifikation veröffentlicht. Für die Evaluierung und Entwicklung durch interessierte Entwickler wird ein öffentlicher
+ Testserver bereitgestellt.
+- **Mitte September 2021:** Die API wird als Produktivinfrastruktur für erste Pilotantragsverfahren und deren Systeme
+ bereitstellt. Zudem werden noch neue abwärtskompatible Features und zusätzliche Entwicklerangebote bereitgestellt.
- **Erste Jahreshälfte 2022:** Alle Beschlüsse zur weiteren Pflege der API und dem Betrieb der Infrastruktur liegen vor.
## Detailplanung bis Mitte Juli 2021
### API-Spezifikation
-- **Bereitstellung und Übermittlung des Security Event Logs:** Der bisherige Übermittlungsstatus wird durch einen Security Event Log ersetzt, der aus signierten Security Event Tokens besteht und die einzelnen Übermittlungsschritte beweissicher dokumentiert. Die jeweiligen Security Event Tokens sind durch die jeweils verantwortlichen Systeme (Zustelldienst bzw. das empfangende System) zu erstellen und zu signieren. Dieser Security Event Log kann über die API von beiden Parteien abgerufen werden und dient späteren Nachweisen über die korrekte Zustellung.
-- **Callbacks zur Benachrichtigung sendender Systeme:** Sendende Systeme bekommen die Möglichkeit für Submissions einen Callback einzurichten. Über diesen Callback informiert der Zustelldienst sendende Systeme, sobald es Änderungen im Zustellstatus. Durch den Callback soll ein regelmäßiges Polling des Security Event Log zur Prüfung des Zustellstatus unötig gemacht werden.
-- **Neuumsetzung von Features:** Einige Features aus der Beta7 Version der API wie die Abfrage von Destination Informationen und die Abfrage von abholbereiten Anträgen werden neu konzipiert und sind in der aktuellen Preview noch nicht enthalten.
-- **Neues Client Autorisierungskonzept auf Basis des bestehen Client Credentials Flows:** Ein neues OAuth Konzept soll umgesetzt werden, da detailierte Berechtigung für den API-Zugriff ermöglicht und höhere Sicherheit für die Nutzung von Access Token gewährleistet. Hieraus werden auch Änderungen in der Erstellung von neuen Destinations entstehen.
+
+- **Bereitstellung und Ãœbermittlung des Security Event Logs:** Der bisherige Ãœbermittlungsstatus wird durch einen
+ Security Event Log ersetzt, der aus signierten Security Event Tokens besteht und die einzelnen Ãœbermittlungsschritte
+ beweissicher dokumentiert. Die jeweiligen Security Event Tokens sind durch die jeweils verantwortlichen Systeme (
+ Zustelldienst bzw. das empfangende System) zu erstellen und zu signieren. Dieser Security Event Log kann über die API
+ von beiden Parteien abgerufen werden und dient späteren Nachweisen über die korrekte Zustellung.
+- **Callbacks zur Benachrichtigung sendender Systeme:** Sendende Systeme bekommen die Möglichkeit für Submissions einen
+ Callback einzurichten. Über diesen Callback informiert der Zustelldienst sendende Systeme, sobald es Änderungen im
+ Zustellstatus. Durch den Callback soll ein regelmäßiges Polling des Security Event Log zur Prüfung des Zustellstatus
+ unötig gemacht werden.
+- **Neuumsetzung von Features:** Einige Features aus der Beta7 Version der API wie die Abfrage von Destination
+ Informationen und die Abfrage von abholbereiten Anträgen werden neu konzipiert und sind in der aktuellen Preview noch
+ nicht enthalten.
+- **Neues Client Autorisierungskonzept auf Basis des bestehen Client Credentials Flows:** Ein neues OAuth Konzept soll
+ umgesetzt werden, da detailierte Berechtigung für den API-Zugriff ermöglicht und höhere Sicherheit für die Nutzung von
+ Access Token gewährleistet. Hieraus werden auch Änderungen in der Erstellung von neuen Destinations entstehen.
### Entwicklerdokumentation- und tools
### Infrastruktur
-- **Testinfrastruktur:** Es wird eine Testinfrastruktur bereitgestellt, über die alle Funktionen der API angesprochen und getestet werden können.
-- **Sandbox Systeme**: Über eine Portaloberfläche werden generische API-Clients angeboten, um bei Versand oder Empfang von Submissions die jeweilige Gegenseite zu simulieren.
- - Aktuell wird noch geprüft, ob dieses Feature aufgrund von Kapazitätsgründen in den Umsetzungszeitraum September 2021 verlagert wird.
+
+- **Testinfrastruktur:** Es wird eine Testinfrastruktur bereitgestellt, über die alle Funktionen der API angesprochen
+ und getestet werden können.
+- **Sandbox Systeme**: Über eine Portaloberfläche werden generische API-Clients angeboten, um bei Versand oder Empfang
+ von Submissions die jeweilige Gegenseite zu simulieren.
+ - Aktuell wird noch geprüft, ob dieses Feature aufgrund von Kapazitätsgründen in den Umsetzungszeitraum September 2021
+ verlagert wird.
## Detailplanung bis Mitte September 2021
### API-Spezifikation
-- Im Rahmen der Produktivstellungen werden Erweiterungen an der API zurückgestellt und nur bei dringenden Bedarf bzw. kritischen Fehler entsprechende Fixes an der API durchgeführt.
- - Falls Kapazitäten vorhanden sind, werden Preview von zukünftigen Features in der zweiten Jahreshälfte über das API Portal veröffentlicht
+
+- Im Rahmen der Produktivstellungen werden Erweiterungen an der API zurückgestellt und nur bei dringenden Bedarf bzw.
+ kritischen Fehler entsprechende Fixes an der API durchgeführt.
+ - Falls Kapazitäten vorhanden sind, werden Preview von zukünftigen Features in der zweiten Jahreshälfte über das API
+ Portal veröffentlicht
### Entwicklerdokumentation- und tools
-- **Bereitstellung von SDKs für erste Querschnittsfunktionen:** Es ist geplant, erste Unterstützungsfunktionen für Querschnittsaufgaben bereitzustellen.
+
+- **Bereitstellung von SDKs für erste Querschnittsfunktionen:** Es ist geplant, erste Unterstützungsfunktionen für
+ Querschnittsaufgaben bereitzustellen.
### Infrastruktur
-- **Self-Service Portal:** Es wird ein Self-Service Portal eingerichtet, über das Entwickler ihre API-Clients am OAuth Server selbst anlegen können. Als weiteres Feature wird es für Betreiber von empfangenden Systemen möglich sein, über das Self-Service Portal Destination anzulegen und zu konfigurieren.
+
+- **Self-Service Portal:** Es wird ein Self-Service Portal eingerichtet, über das Entwickler ihre API-Clients am OAuth
+ Server selbst anlegen können. Als weiteres Feature wird es für Betreiber von empfangenden Systemen möglich sein, über
+ das Self-Service Portal Destination anzulegen und zu konfigurieren.
## Detailplanung bis Ende 2021
### API-Spezifikation
-- **Routing API:** Über die Routing API wird zukünftig möglich sein, Destinations und deren technische Parameter über eine API Anfrage anhand technische Zuständigkeitskriterien zu ermitteln.
-- **Hinterlegung einer OSCI-Weiterleitung:** Um bestehende OSCI Intermediärsinfrastrukturen einzubinden, wird eine Hinterlegung von OSCI-Kommunikationsparametern möglich sein. Hierdurch werden abgebeben Submissions durch den Zustelldienst automatisch an den vorgesehen OSCI Intermediär weitergeleitet.
-- **Erweiterung um einen Rückkanal für Prozessstandards:** Als abwärtskompatible Erweiterung wird über die API ermöglich, eine bilaterale Antragskommunikation auf Basis von Fachstandards wie XBau umzusetzen. API-Nutzer, die FIT-Connect nur für Einreichungen nutzen, sind von diesen Änderungen nicht betroffen.
-- **Weiterentwicklung von FIM/XFall Schemata**: Um die Nutzung von FIM für die Antragsübermittlung zu vereinfachen, werden in Zusammenarbeit mit FIM neue technologische Ansätze und Verbesserung in der Schema Nutzung angestrebt.
+
+- **Routing API:** Über die Routing API wird zukünftig möglich sein, Destinations und deren technische Parameter über
+ eine API Anfrage anhand technische Zuständigkeitskriterien zu ermitteln.
+- **Hinterlegung einer OSCI-Weiterleitung:** Um bestehende OSCI Intermediärsinfrastrukturen einzubinden, wird eine
+ Hinterlegung von OSCI-Kommunikationsparametern möglich sein. Hierdurch werden abgebeben Submissions durch den
+ Zustelldienst automatisch an den vorgesehen OSCI Intermediär weitergeleitet.
+- **Erweiterung um einen Rückkanal für Prozessstandards:** Als abwärtskompatible Erweiterung wird über die API
+ ermöglich, eine bilaterale Antragskommunikation auf Basis von Fachstandards wie XBau umzusetzen. API-Nutzer, die
+ FIT-Connect nur für Einreichungen nutzen, sind von diesen Änderungen nicht betroffen.
+- **Weiterentwicklung von FIM/XFall Schemata**: Um die Nutzung von FIM für die Antragsübermittlung zu vereinfachen,
+ werden in Zusammenarbeit mit FIM neue technologische Ansätze und Verbesserung in der Schema Nutzung angestrebt.
### Entwicklerdokumentation- und tools
-- **Vollumfängliche Bereitstellung von SDKs**: In der zweiten Jahreshälfte werden SDKs in verschiedenen Programmiersprachen für alle zentralen FIT-Connect Anforderungen angeboten.
-- **FIM Entwicklungstools**: Um die Nutzung von FIM für Antragsschemata sollen diverse Entwicklungstools für die Generierung und Validierung von FIM/XFall Nachrichten angeboten werden.
+
+- **Vollumfängliche Bereitstellung von SDKs**: In der zweiten Jahreshälfte werden SDKs in verschiedenen
+ Programmiersprachen für alle zentralen FIT-Connect Anforderungen angeboten.
+- **FIM Entwicklungstools**: Um die Nutzung von FIM für Antragsschemata sollen diverse Entwicklungstools für die
+ Generierung und Validierung von FIM/XFall Nachrichten angeboten werden.
### Infrastruktur
-- **Validierungsumgebung:** Um gegenüber Auftraggebern oder anderen Stellen nachzuweisen, dass die eigene Software FIT-Connect nutzen kann, soll eine Validierungsumgebung geschaffen werden, die die API-Umsetzung gegenüber festgelegten Testfällen prüfen und hierfür einen signierten Nachweis an den Verfahrenbetreiber ausstellt.
+
+- **Validierungsumgebung:** Um gegenüber Auftraggebern oder anderen Stellen nachzuweisen, dass die eigene Software
+ FIT-Connect nutzen kann, soll eine Validierungsumgebung geschaffen werden, die die API-Umsetzung gegenüber
+ festgelegten Testfällen prüfen und hierfür einen signierten Nachweis an den Verfahrenbetreiber ausstellt.
## Erste Jahreshälfte 2022