From e498d30450e481ef9f4865cf839eeffa7e9ec62d Mon Sep 17 00:00:00 2001
From: Marco Holz <marco.holz@fitko.de>
Date: Mon, 30 Aug 2021 08:44:59 +0200
Subject: [PATCH] Bezeichnung der API auf `FIT-Connect Submission API`
vereinheitlicht
---
docs/account.mdx | 2 +-
.../infrastructure-docs/scopes-internal.md | 2 +-
docs/details/infrastructure-docs/sender.md | 6 +--
.../details/infrastructure-docs/subscriber.md | 6 +--
docs/glossary.md | 6 +--
docs/intro.md | 43 ++++++++++---------
docs/roadmap.md | 10 ++---
docs/status-and-error-codes.md | 4 +-
8 files changed, 40 insertions(+), 39 deletions(-)
diff --git a/docs/account.mdx b/docs/account.mdx
index 0e657d5f9..e97853e89 100644
--- a/docs/account.mdx
+++ b/docs/account.mdx
@@ -27,7 +27,7 @@ Nach erfolgreicher Authentifizierung wird die Startseite des Self-Service-Portal
<img width="600" alt="Client-Verwaltung mit eingerichteten Clients" src={useBaseUrl('/images/ssp/6-Clientverwaltung.png')} />
Hierbei wird zwischen **Sendern** und **Subscribern** unterschieden.
-**Sender** repräsentieren dabei technische Systeme, die Einreichungen über die Submission-API des Zustelldiensts vornehmen.
+**Sender** repräsentieren dabei technische Systeme, die Einreichungen über die Submission API des Zustelldiensts vornehmen.
**Subscriber** stellen technische Systeme dar, die Einreichungen auf Verwaltungsseite entgegennehmen und bearbeiten.
### Sender hinzufügen
diff --git a/docs/details/infrastructure-docs/scopes-internal.md b/docs/details/infrastructure-docs/scopes-internal.md
index 6531cba29..877d28cd2 100644
--- a/docs/details/infrastructure-docs/scopes-internal.md
+++ b/docs/details/infrastructure-docs/scopes-internal.md
@@ -1,4 +1,4 @@
-# OAuth Berechtigungen für infrastrukturinterne API Aufrufe
+# OAuth Berechtigungen für infrastrukturinterne API-Aufrufe
## Scope für die Anlage neuer Destinations durch das Self-Service-Portal
diff --git a/docs/details/infrastructure-docs/sender.md b/docs/details/infrastructure-docs/sender.md
index 419847f6e..aff123687 100644
--- a/docs/details/infrastructure-docs/sender.md
+++ b/docs/details/infrastructure-docs/sender.md
@@ -2,12 +2,12 @@
**Achtung: Die folgende Dokumentation ist für Softwareentwickler:innen und Betreiber der zentralen Übertragungsinfrastruktur gedacht. Diese Unterlagen befinden sich in einer Überarbeitung und spiegeln nicht den aktuellen Stand wieder.**
-Die Authentifizierung von sendenden Systemen erfolgt bei FIT-Connect auf Basis von OAuth 2.0 Client Credentials gemäß [RFC 6749](https://tools.ietf.org/html/rfc6749) und Access Tokens auf Basis von JSON Web Tokens gemäß [RFC 7519](https://datatracker.ietf.org/doc/html/rfc7519). Im Folgenden sollen die nötigen Schritte zur Registrierung und zum Zugriff auf die Schnittstelle des FIT-Connect Zustelldienstes beschrieben werden. Dieses Dokument dokumentiert die implementierten Authentifizierungsmechanismen und macht Vorgaben zur Implementierung der Authentifizierung von sendenden Systemen. Bei der Umsetzung der Authentifizierung kann darüber hinaus auf das vom Projekt FIT-Connect bereitgestellte Software Development Kit (SDK) zurückgegriffen werden, dass die Vorgaben aus diesem Dokument umsetzt bzw. bei deren Umsetzung unterstützt.
+Die Authentifizierung von sendenden Systemen erfolgt bei FIT-Connect auf Basis von OAuth 2.0 Client Credentials gemäß [RFC 6749](https://tools.ietf.org/html/rfc6749) und Access Tokens auf Basis von JSON Web Tokens gemäß [RFC 7519](https://datatracker.ietf.org/doc/html/rfc7519). Im Folgenden sollen die nötigen Schritte zur Registrierung und zum Zugriff auf die Schnittstelle des FIT-Connect Zustelldienstes (Submission API) beschrieben werden. Dieses Dokument dokumentiert die implementierten Authentifizierungsmechanismen und macht Vorgaben zur Implementierung der Authentifizierung von sendenden Systemen. Bei der Umsetzung der Authentifizierung kann darüber hinaus auf das vom Projekt FIT-Connect bereitgestellte Software Development Kit (SDK) zurückgegriffen werden, dass die Vorgaben aus diesem Dokument umsetzt bzw. bei deren Umsetzung unterstützt.
## Zugriff auf die API mittels Access Token
-Wenn ein Online-Antragsservice einer Antragsteller:in ermöglichen möchte, eine Einreichung an die FIT-Connect API zu übermitteln, muss dieser zunächst mithilfe der OAuth Client-Credentials beim OAuth-Server einen Berechtigungstoken (im Folgenden "Access Token") nach dem Standard *JSON Web Token* gemäß [RFC 7519](https://tools.ietf.org/html/rfc7519)) abrufen. Dieser vom OAuth-Server signierte Access Token enthält den Public-Key des Online-Antragsdienstes, der bei der Registrierung im Self-Service-Portal festgelegt wurde. Aus Sicht von API-Clients sind die Inhalte des Tokens gemäß OAuth-Spezifikation als bedeutungslos anzusehen und SOLLTEN daher NICHT interpretiert werden. Eine Prüfung des Access Token auf Korrektheit und Gültigkeit erfolgt intern.
+Wenn ein Online-Antragsservice einer Antragsteller:in ermöglichen möchte, eine Einreichung an die FIT-Connect Submission API zu übermitteln, muss dieser zunächst mithilfe der OAuth Client-Credentials beim OAuth-Server einen Berechtigungstoken (im Folgenden "Access Token") nach dem Standard *JSON Web Token* gemäß [RFC 7519](https://tools.ietf.org/html/rfc7519)) abrufen. Dieser vom OAuth-Server signierte Access Token enthält den Public-Key des Online-Antragsdienstes, der bei der Registrierung im Self-Service-Portal festgelegt wurde. Aus Sicht von API-Clients sind die Inhalte des Tokens gemäß OAuth-Spezifikation als bedeutungslos anzusehen und SOLLTEN daher NICHT interpretiert werden. Eine Prüfung des Access Token auf Korrektheit und Gültigkeit erfolgt intern.
### Payload des Access Tokens
Der hier beschriebene Payload des Access Tokens dient lediglich der Dokumentation/Spezifikation. Im Payload des signierten Access Token werden vom Autorisierungsdienst die folgenden [standardisierten Felder](https://www.iana.org/assignments/jwt/jwt.xhtml) gesetzt:
@@ -15,7 +15,7 @@ Der hier beschriebene Payload des Access Tokens dient lediglich der Dokumentatio
| Feld | Inhalt | Erläuterung |
| ---------------- | ------------------------------------- | --------------- |
| `sub` (Subject) | Client ID des sendenden Systems | Beim gewählten Client Credential Flow wird hier die Client ID des System eingetragen.|
-| `aud` (Audience) | URL der 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). |
+| `aud` (Audience) | URL der Submission API | Die URL der API des Zustelldienstes, für den der Token ausgestellt wurde, gemäß [RFC 7519, Abschnitt 4.1.3](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3). |
| `scope` | Zustellberechtigungs-Scopes | Eine Liste der Zustellberechtigungs-Scopes, separiert mit Leerzeichen gemäß [RFC 6749, Abschnitt 3.3](https://datatracker.ietf.org/doc/html/rfc6749#section-3.3). Für sendende System sind [folgende Scopes](/details/authentication/scopes-sender.md) zu nutzen. |
| `iss` (Issuer) | URL des Autorisierungsservers | Die URL des Autorisierungsservers, der das Token ausgestellt hat. |
| `exp` | Unix Timestamp | Zeitpunkt, wann der Token abläuft, als Unix Timestamp (Token DARF max. 24 Stunden gültig sein; vgl. [BSI APP.3.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Kompendium_Einzel_PDFs/06_APP_Anwendungen/APP_3_1_Webanwendungen_Edition_2020.pdf?__blob=publicationFile&v=1)) |
diff --git a/docs/details/infrastructure-docs/subscriber.md b/docs/details/infrastructure-docs/subscriber.md
index 4a55aee19..a95ec2370 100644
--- a/docs/details/infrastructure-docs/subscriber.md
+++ b/docs/details/infrastructure-docs/subscriber.md
@@ -13,7 +13,7 @@ erhalten Behörden und andere Abrufberechtigte, nach einer Anmeldung im Self-Ser
Zum Abruf von Anträgen müssen sich empfangende Systeme zunächst mithilfe der OAuth Client-Credentials beim OAuth-Server
ein Berechtigungstoken (im Folgenden "Access Token") nach dem Standard JSON Web Token
gemäß [RFC 7519](https://tools.ietf.org/html/rfc7519) abrufen. Dieser vom OAuth-Server signierte Token kann anschließend
-genutzt werden, um sich gegenüber der Antrags-API eines Zustelldienstes zu authentifizieren.
+genutzt werden, um sich gegenüber der Submission API eines Zustelldienstes zu authentifizieren.
Bei erfolgreicher Registrierung erhält die für den Zustellpunkt verantwortliche Behörde OAuth2-Zugangsdaten für den
Authentifizierungstyp "Client-Credentials" (`client_id` und `client_secret`). Mit diesen kann sich das empfangende
@@ -24,7 +24,7 @@ diesem Access Token ist anschließend ein Abruf der im Zustelldienst hinterlegte
Das Access Token für empfangende Systeme wird vom Autorisierungsdienst erzeugt und DARF vom empfangenden System NIEMALS
an dritte Systeme (mit Außnahme des Zustelldienstes zum Zwecke der Authentifizierung) weitergegeben werden. Das Access
-Token für empfangende Systeme wird beim Zugriff auf die Antrags-API im `Authorization`-Header mit `Bearer`
+Token für empfangende Systeme wird beim Zugriff auf die Submission API im `Authorization`-Header mit `Bearer`
-Authentifizierungsschema gemäß [RFC 6750](https://datatracker.ietf.org/doc/html/rfc6750) an den Zustelldienst
übermittelt:
@@ -65,7 +65,7 @@ folgenden [standardisierten Felder](https://www.iana.org/assignments/jwt/jwt.xht
| Feld | Inhalt | Erläuterung |
| ---------------- | ----------------------------- | --------------- |
| `sub` (Subject) | ID des empfangenden Systems | Identifiziert ein empfangendes System. Festgelegt im Autorisierungsdienst. |
-| `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). |
+| `aud` (Audience) | URL der Submission API | Die URL der API des Zustelldienstes, für den der Token ausgestellt wurde, gemäß [RFC 7519, Abschnitt 4.1.3](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.3). |
| `scope` | Zustellberechtigungs-Scopes | Eine Liste der Zustellberechtigungs-Scopes, separiert mit Leerzeichen gemäß [RFC 6749, Abschnitt 3.3](https://datatracker.ietf.org/doc/html/rfc6749#section-3.3). Für sendende System sind [folgende Scopes](/details/authentication/scopes-subscriber.md) zu nutzen. |
| `iss` (Issuer) | URL des Autorisierungsservers | URL des Autorisierungsservers der das Access Token ausgestellt hat. |
| `exp` | Unix Timestamp | Ablaufzeitpunkt des Access Tokens (DARF max. 2 Stunden gültig sein; vgl. [BSI APP.3.1](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Kompendium_Einzel_PDFs/06_APP_Anwendungen/APP_3_1_Webanwendungen_Edition_2020.pdf?__blob=publicationFile&v=1)) |
diff --git a/docs/glossary.md b/docs/glossary.md
index 154f2aa04..d38896926 100644
--- a/docs/glossary.md
+++ b/docs/glossary.md
@@ -9,9 +9,9 @@ hide_table_of_contents: true
| Anlage (attachment) | Sind Anlagen zu einer Einreichung. Diese sind nicht zwingend maschinenlesbar oder an Standards geknüpft. |
| Antragsteller:in (applicant) | Bezeichnung der Person, die den Onlinedienst benutzt. Z.B. eine Verwaltungskund:in, die einen Einreichung absendet. |
| Antwort (reply) | Alle auf eine Einreichung (submission) folgende Übertragungen, egal in welche Richtung (sender → subscriber oder subscriber → sender) |
-| API-Client | Ein technisches System, dass auf die APIs (des Zustelldienstes) zugreift. Dieser Begriff kann verwendet werden, wenn eine Unterscheidung zwischen Fachverfahren, virtueller Poststelle, Onlineservice oder Endgerät der antragstellenden Person nicht nötig ist. |
+| API-Client | Ein technisches System, dass auf die FIT-Connect-Schnittstellen zugreift. Dieser Begriff kann verwendet werden, wenn eine Unterscheidung zwischen Fachverfahren, virtueller Poststelle, Onlineservice oder Endgerät der antragstellenden Person nicht nötig ist. |
| API-Gateway | Das API-Gateway ist eine technische Komponente, die die Prüfung von OAuth-Tokens prüft und nicht oder falsch authentifizierte Anfragen blockiert. Ein Zugriff auf die Schnittstellen des Zustelldienstes ist ausschließlich über das API-Gateway möglich. |
-| Autorisierungsdienst | Der Autorisierungsdienst / OAuth-Dienst stellt via Client-Credentials-Flow OAuth-Tokens an API-Clients aus, mit denen diese sich anschließend gegenüber den Zustelldienst APIs (d.h. gegenüber dem API-Gateway) authentifizieren können. |
+| Autorisierungsdienst | Der Autorisierungsdienst / OAuth-Dienst stellt via Client-Credentials-Flow OAuth-Tokens an API-Clients aus, mit denen diese sich anschließend gegenüber den FIT-Connect-Schnittstellen (d.h. gegenüber dem API-Gateway) authentifizieren können. |
| Einreichungsstatus (submission status) | Beschreibt den fachlichen Status einer Einreichung für das einreichende System. |
| Einreichung (submission) | Ist eine Einreichung bei einer zuständigen Stelle über die FIT-Connect Übermittlungsinfrastruktur. Eine solche Einreichung kann ein Antrag (bspw. ein Antrag nach dem Onlinezugangsgesetz), ein Bericht (bspw. Statistikmeldung eines Unternehmens) oder eine sonstige Einreichung für die Initiierung eines Bearbeitungsvorgangs in einem Verwaltungsverfahren sein. Eine Einreichung besteht aus mindestens aus einem Metadatensatz und einem Fachdatensatz und / oder einem oder mehreren Anlagen. Eine Einreichung besitzt immer eine systemübergreifend eindeutige ID (submissionId), um dauerhaft den Einreichungsvorgang zu referenzieren oder zu dokumentieren. Diese ID wird bei jedem Einreichungsvorgang durch ein sendendes System vergeben. |
| empfangendes System (subscriber) | Das technische System, das Einreichungen auf Verwaltungsseite entgegennimmt. (z.B. Fachanwendung / virtuelle Poststelle) |
@@ -26,7 +26,7 @@ hide_table_of_contents: true
| Metadatensatz (metadata) | Ein Metadatensatz beschreibt: <ul> <li>Fachunabhängige Metadaten der Einreichung: Authentifizierung des Autors einer Einreichung oder Berichts (bspw. über einen eID-Laufzettel, Identifikation Report, Informationen über Signaturnutzung einschließlich Angabe des Signaturformats und ggf. separater Signaturdateien.), Ergebnisse eines Bezahlvorgangs oder digitale Verbindungs- und Adressparameter für die Verfahrensinformationen (falls vom Verwaltungskund:in gewünscht).</li> <li>Strukturbeschreibung der Einreichung: Art der Leistung oder Einreichungsbestandteile.</li> </ul> |
| Onlineservice | Ein Onlineservice kann entweder von einer Behörde, einem Unternehmen oder einer zivilgesesellschaftlichen Organisation betrieben wird. Er interagiert in der Art mit FIT-Connect, dass er Anträge im Namen bzw. Auftrag eines Endnutzers verschlüsselt übermittelt. |
| Self-Service-Portal | Das Self-Service-Portal ist Teil des Autorisierungsdienst und ermöglicht es, Accounts/Berechtigungen für die Anbindung von Onlinediensten und Fachverfahren/virtuellen Poststellen anzulegen. |
-| sendendes System (sender) | Das technische System, das eine Einreichung über die Zustelldienst-API vornimmt. (z.B. Online-Antragsservice oder Unternehmenssystem). Dies ist in der Regel ein Online-Antragsservice (spezialisiertes Webportal für eine bestimmte Fachlichkeit), das Endgerät der Antragsteller:in oder auch ein Verwaltungsportal, das typischerweise mehrere Fachlichkeiten / Antragstypen unterstützt. Perspektivisch wären hier auch andere API-Clients denkbar, z.B. spezialisierte Anwendungen zur Antragseinreichung ohne Webinterface oder Fachverfahren der Verwaltung, über die beim Behördengang durch eine Sachbearbeiter:in stellvertretend für die Antragsteller:in ein Einreichung eingereicht wird. |
+| sendendes System (sender) | Das technische System, das eine Einreichung über die Submission API vornimmt. (z.B. Online-Antragsservice oder Unternehmenssystem). Dies ist in der Regel ein Online-Antragsservice (spezialisiertes Webportal für eine bestimmte Fachlichkeit), das Endgerät der Antragsteller:in oder auch ein Verwaltungsportal, das typischerweise mehrere Fachlichkeiten / Antragstypen unterstützt. Perspektivisch wären hier auch andere API-Clients denkbar, z.B. spezialisierte Anwendungen zur Antragseinreichung ohne Webinterface oder Fachverfahren der Verwaltung, über die beim Behördengang durch eine Sachbearbeiter:in stellvertretend für die Antragsteller:in ein Einreichung eingereicht wird. |
| Vorgangsreferenz (caseID) | Systemübergreifend eindeutige ID für einen langlaufenden Kommunikationsvorgang zwischen dem einreichenden System und der Empfangsseite, wenn über die FIT-Connect kommuniziert werden sollen. Innerhalb einem Kommunikationsvorgang können weitere Fachdatensätze und Anlagen zwischen beiden Parteien ausgetauscht werden. |
| Zustellberechtigungs-Scope | Beschreibt die Scopes aus den OAuth-Tokens (JWT), die im Zustelldienst dazu dienen, um zu überprüfen, ob ein Onlinedienst Einreichungen bei einer Destination vornehmen darf. |
| Zustellpunkt (Destination) | Technisch eindeutig adressierbarer Endpunkt zur digitalen Einreichung von Anträgen oder Berichten an die Verwaltung über die FIT-Connect Übermittlungsinfrastruktur. Ein Zustellpunkt repräsentiert typischerweise ein konkretes empfangendes System (Fachverfahren oder virtuelle Poststelle). Für ein empfangendes System können jedoch multiple Zustellpunkte angelegt werden. In der Konfiguration eines Zustellpunkts sind interne und öffentliche Teile hinterlegt. Interne Angaben sind solche, die zu Administrationszwecken dienen. Öffentliche Angaben legen z. B. fest, in welcher Form der Empfänger Einreichungen akzeptiert. Die öffentlichen Angaben sind: <ul> <li>Zulässige Schemata für einen Fachdatensatz (und die Pflicht, einen Fachdatensatz mit dem definierten Fachdatensatz in einer Einreichung zu nutzen)</li> <li>Öffentlicher Schlüssel zur Verschlüsselung von Fachdatensatz, Anlage und Metadatensatz</li> </ul> |
diff --git a/docs/intro.md b/docs/intro.md
index dc07719e2..b4c3a9592 100644
--- a/docs/intro.md
+++ b/docs/intro.md
@@ -27,9 +27,9 @@ Die FIT-Connect Submission API ist als ein universelles Eingangstor für digital
- Empfangende Systeme (bspw. Fachverfahren oder E-Akte Systeme) können einen digitalen Zugang (Zustellpunkt) eröffnen und hierüber beliebige Einreichungen (Anträge,
Berichtsmeldung, etc. ) erhalten. Was empfangen wird, kann über eindeutige Schema Referenzen auf Fachstandards festgelegt werden.
-- Sendende Systeme (bspw. Antragsdienste) können Einreichungen an alle existierenden Zustellpunkte senden. Um die richtigen Zustellpunkte für den jeweiligen Leistungskontext
-und die jeweilige Zuständigkeit zu finden, wird sendenden Systemen eine Routing API bereitgestellt. Mit der FIT-Connect API können sendende Systeme die auf Basis Leistungs- und Ortsbezug
-der Einreichung den richtigen Zustellpunkt ermitteln und alle technischen Verbindungsparameter ermitteln.
+- Sendende Systeme (bspw. Antragsdienste) können Einreichungen an alle existierenden Zustellpunkte senden.
+Um die richtigen Zustellpunkte für den jeweiligen Leistungskontext und die jeweilige Zuständigkeit zu finden, wird sendenden Systemen eine Routing API bereitgestellt.
+Mit der Routing API können sendende Systeme auf Basis des Leistungs- und Ortsbezugs der Einreichung den richtigen Zustellpunkt ermitteln und alle technischen Verbindungsparameter ermitteln.
Die Vertraulichkeit der Übermittlung ist jederzeit gewährt, da eine Ende-zu-Ende-Verschlüsselung standardmäßig für alle übermittelten Daten vorgesehen ist und bis in den Browser oder das Endgerät der Antrag- oder Berichtssteller:in möglich ist.
@@ -37,11 +37,11 @@ Die Vertraulichkeit der Übermittlung ist jederzeit gewährt, da eine Ende-zu-En
-Über die `Submission API` können die zuständigen Stellen für ihre Systeme einen Zustellpunkt eröffnen, der
+Über die Submission API können die zuständigen Stellen für ihre Systeme einen Zustellpunkt eröffnen, der
über eine `destination-Id` eindeutig adressierbar ist. Für diese Zustellpunkte legen die zuständigen Stellen alle
fachlichen Vorgaben (Zulässige Fachstandards, Verschlüsselung, Datenformate etc.) fest, damit eine medienbruchfreie
Weiterverarbeitung in ihren Systemen gewährleistet ist. Über die Angabe der `destination-Id` in
-der `Submission API` können sendende Systemen Einreichungen an die zuständige Stelle senden.
+der Submission API können sendende Systemen Einreichungen an die zuständige Stelle senden.
Dieser Zustellpunkt ist jedoch vorab für eine Verwaltungsleistung und den jeweiligen örtlichen Antragskontext (bspw. Ort
der Antragsstellung) korrekt zu ermitteln. Damit die Ermittlung des korrekten Zustellpunkts skalierbar für das ganze
@@ -51,10 +51,10 @@ IDs werden durch das Online-Gateway (<https://www.onlinezugangsgesetz.de/Webs/OZ
gebündelt. Fragt nun ein sendendes System über die Routing API an, ermittelt der FIT-Connect Routingdienst die korrekte `destination-Id` im Onlinegateway,
ruft auf Basis dieser ID die technischen Verbindungsparameter im DVDV ab und sendet diese Informationen an das sendende System zurück.
-## Für wen ist die FIT-Connect API gedacht und warum sollte ich sie nutzen?
+## Für wen ist die FIT-Connect Submission 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
+Die FIT-Connect Submission API ist für alle Hersteller, Entwickler und Verfahrensverantwortliche von sendenden und empfangenden
+Systemen gedacht. Insbesondere folgende Systeme mit bundesweiten Nutzungsszenarien sollen mit der FIT-Connect Submission API
unterstützt werden:
- **Einer für alle (EfA) Verfahren**: Länderübergreifend entwickelte Antragsverfahren für eine bestimmte
@@ -74,18 +74,18 @@ Antragsprozesse eine Reihe von Mehrwerten:
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
+- **Leichgewichtige APIs und Industriestandards**: Die FIT-Connect-Schnittstellen bauen auf leichgewichtigen RESTful API-Ansätzen
+ auf und nutzt verbreitete Industriestandards wie den OpenAPI-Spezifikationsstandard und das OAuth-2.0-Autorisierungsframework, sodass kein spezialisiertes
Know-How und spezifische Softwarekomponenten für die Anbindung erforderlich sind.
-- **Flexibilität in der Antragsübermittlung**: Die FIT-Connect API verbindet Flexibilität und Standardisierung. Während
- die FIT-Connect API eine einheitliche Metadatenstruktur festlegt, um Einreichungen strukturiert zu verarbeiten, können
- beliebige Fachstandards und Anhänge übertragen werden. Auch die Übertragung von Einreichungen im PDF Format ist möglich,
- solange für die Antragsdaten noch kein FIM Schema vorhanden ist.
+- **Flexibilität in der Antragsübermittlung**: Die FIT-Connect APIs verbinden Flexibilität und Standardisierung. Während
+ die FIT-Connect Submission API eine einheitliche Metadatenstruktur festlegt, um Einreichungen strukturiert zu verarbeiten, können
+ beliebige Fachstandards und Anhänge übertragen werden. Auch die Übertragung von Einreichungen im PDF-Format ist möglich,
+ solange für die Antragsdaten noch kein FIM-Schema vorhanden ist.
**Nutzung bestehender Prozesse und Strukturen für die Pflege von Adressierungsinformationen**: Langjährig erprobte
Prozesse und Strukturen zur Pflege der Zuständigkeitsinformationen, können in den zuständigen Stellen beibehalten
- werden. Technische Adressierungsparameter der FIT-Connect API werden über die gleichen Systeme und Prozesse gepflegt,
+ werden. Technische Adressierungsparameter werden über die gleichen Systeme und Prozesse gepflegt,
die schon heute bei Informationen zu Anschriften, Rufnummern, E-Mail-Adressen oder Ansprechpartnern genutzt werden.
-- **Machine2Machine Ready**: Die FIT-Connect API und die FIT-Connect Antragsübertragungsarchitektur sind von Grund auf
+- **Machine2Machine Ready**: Die FIT-Connect Submission API und die FIT-Connect Antragsübermittlungsarchitektur sind von Grund auf
als offene API-Plattform konzipiert. Dadurch können auch verwaltungsexterne Antrags- und Berichtssysteme wie
Drittsoftware oder Unternehmenssysteme direkt eingebunden werden, ohne das hierfür eine gesonderte Infrastruktur
notwendig ist.
@@ -98,12 +98,13 @@ diese Systeme standardisiert verbunden, ohne das die Behörde in Abhängigkeiten
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 diese nutzen?
+## In welchem Stand befindet sich FIT-Connect Submission API und wann kann man diese nutzen?
-Ein Zugang für interessierte Enwickler zur Test-API ist in Q3 2020 geplant. Um auf diese API zuzugreifen, müssen interessierte
-Entwickler ihre Anwendungen das Self-Service-Portal vorab registrieren. Projektpartner können die API und Infrastruktur
-für produktive Datenübermittlungen ab September 2020 nutzen. Detailerte Zeitpläne können der [Roadmap](https://docs.fitko.de/fit-connect/docs/roadmap)
-entnommen werden. Updates werden regelmäßig im Bereich [News](https://docs.fitko.de/fit-connect/news) mitgeteilt.
+Ein Zugang für interessierte Enwickler zur einer Testinfrastruktur ist seit August 2021 möglich.
+Um auf diese Testumgebung zuzugreifen, können interessierte Entwickler ihre Anwendungen das Self-Service-Portal vorab registrieren.
+Projektpartner können die API und Infrastruktur für produktive Datenübermittlungen ab September 2021 nutzen.
+Detailerte Zeitpläne können der [Roadmap](https://docs.fitko.de/fit-connect/docs/roadmap) entnommen werden.
+Updates werden regelmäßig im Bereich [News](https://docs.fitko.de/fit-connect/news) mitgeteilt.
## Ich habe einen Fehler in der Dokumentation oder in der API-Spezifikation gefunden. Wo kann ich diesen melden? {#found-bug}
diff --git a/docs/roadmap.md b/docs/roadmap.md
index ce25cd512..1c49a7380 100644
--- a/docs/roadmap.md
+++ b/docs/roadmap.md
@@ -9,7 +9,7 @@ Erprobung und Feedback zu ermöglichen.
Die Roadmap soll daher einen Überblick verschaffen, wann das FIT-Connect Team für die folgenden Projektliefergegenstände
neue Features anstrebt:
-- **API-Spezifikation:** In der OpenAPI geschriebene Spezifikation der FIT-Connect Einreichungs-API.
+- **API-Spezifikation:** In der OpenAPI geschriebene Spezifikation der FIT-Connect Submission API.
- **Entwicklerdokumentation- und tools:** Weiterführende Dokumentationsartikel zur technischen Anbindung an der API für
sendende und empfangende Systeme udn Bereitstellung von Tools für technische Querschnittsaufgaben wie Tokenhandling,
Signaturprüfung oder Verschlüsselung.
@@ -21,7 +21,7 @@ jedoch passen wir die Umsetzungen den aktuellen Bedarfen des Projekts an, wodurc
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
+Wir nehmen gerne neue Wünsche & Anregungen für die FIT-Connect APIs als Issue auf unserem
Projekt (https://git.fitko.de/fit-connect/api) entgegen und versuche diese Issues nach einer Umsetzungsprüfung in unsere
Roadmap aufzunehmen.
@@ -29,12 +29,12 @@ Roadmap aufzunehmen.
## Überblick über die Zeitplanung
-- **Seit 24.06.2021:** Preview der API-Spezifikation und der Entwicklerdokumentaion für die Version 1.0 der API ist
+- **Seit 24.06.2021:** Preview der API-Spezifikation und der Entwicklerdokumentaion für die Version 1.0 der Submission API ist
online und ist für alle interessierten Entwickler zugänglich.
-- **Anfang August 2021:** Bis zu diesem Zeitpunkt werden alle Kernfeatures API spezifiziert und als stabile API
+- **Anfang August 2021:** Bis zu diesem Zeitpunkt werden alle Kernfeatures der Submission API spezifiziert und als stabile API
Spezifikation veröffentlicht. Für die Evaluierung und Entwicklung durch interessierte Entwickler wird ein öffentlicher
Testserver bereitgestellt.
-- **Bis September 2021:** Die API wird als Produktivinfrastruktur für erste Pilotantragsverfahren und deren Systeme
+- **Bis September 2021:** Die Submission API wird als Produktivinfrastruktur für erste Pilotantragsverfahren und deren Systeme
bereitstellt. Zudem werden noch neue abwärtskompatible Features und zusätzliche Entwicklerangebote bereitgestellt.
- **Bis Q2 2022:** Alle Beschlüsse zur weiteren Pflege der API und dem Betrieb der Infrastruktur liegen vor.
diff --git a/docs/status-and-error-codes.md b/docs/status-and-error-codes.md
index f60f183a2..c993e2c5f 100644
--- a/docs/status-and-error-codes.md
+++ b/docs/status-and-error-codes.md
@@ -6,7 +6,7 @@ title: Fehlerverhalten und Statuscodes
> Wo 200 Licht ist, ist auch 403 Schatten. -Göthe
-Diese Seite gibt einen Überblick über Fehlerhandling in der FIT-Connect API (nachfolgend nur noch *API* genannt).
+Diese Seite gibt einen Überblick über Fehlerhandling in der FIT-Connect Submission API (nachfolgend nur noch *API* genannt).
## Features
@@ -68,7 +68,7 @@ abgebildet. Fachliche schon.
## Verhalten von API Clients
-API Clients sollten gemäß RFC 7231 so implementiert sein, dass auch unbekannte HTTP Statuscodes gemäß ihrer
+API-Clients sollten gemäß RFC 7231 so implementiert sein, dass auch unbekannte HTTP Statuscodes gemäß ihrer
Statusklasse (`Axx, A=[1,5]`) interpretiert werden können:
> "HTTP status codes are extensible. HTTP clients are not required to understand the meaning of
> all registered status codes, though such understanding is obviously desirable. However, a client
--
GitLab