Skip to content
Snippets Groups Projects

Compare revisions

Changes are shown as if the source revision was being merged into the target revision. Learn more about comparing revisions.

Source

Select target project
No results found

Target

Select target project
  • fit-connect/docs
1 result
Show changes
Commits on Source (24)
Showing
with 184 additions and 143 deletions
......@@ -13,7 +13,6 @@ include:
stages:
- build
- upload
- validate
build:
stage: build
......@@ -68,20 +67,6 @@ upload:production:
- ssh -o CheckHostIP=no fitko@dorado.uberspace.de mkdir -p docs.fitko.de/fit-connect
- rsync -rLvz --delete --checksum -e "ssh -o CheckHostIP=no" --ipv4 --progress ./build/. fitko@dorado.uberspace.de:docs.fitko.de/fit-connect
link-check:
stage: validate
rules:
- if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH
variables:
CRAWLER_URL: https://preview.docs.fitko.dev/fit-connect/$CI_COMMIT_REF_SLUG/docs
CRAWLER_DOMAIN: preview.docs.fitko.dev/fit-connect/$CI_COMMIT_REF_SLUG/docs
needs:
- upload:preview
trigger:
strategy: depend
project: fit-connect/schema-link-checker
branch: main
stop:preview:
stage: .post
image: alpine:latest
......
......@@ -4,6 +4,7 @@ Das Format dieser Datei basiert auf [Keep a Changelog](https://keepachangelog.co
Das hier veröffentlichte Changelog bezieht sich auf die [Testinstanz von FIT-Connect](https://docs.fitko.de/fit-connect/docs/getting-started/get-started#testing).
## 2022-08-22
### Dokumentation
......@@ -14,11 +15,13 @@ Das hier veröffentlichte Changelog bezieht sich auf die [Testinstanz von FIT-Co
## 2022-08-18
### Dokumentation
- Der Menüpunkt "Grundlagen" wurde umbenannt in "Infos für Entwickler:innen".
- Die Menüpunkte "Versand von Einreichung" und "Abruf von Einreichungen" befinden sich jetzt unterhalb des Menüpunkts "Grundlagen für Entwickler:innen".
## 2022-07-26
### Zustelldienst 1.8.1
......@@ -229,7 +232,7 @@ Das hier veröffentlichte Changelog bezieht sich auf die [Testinstanz von FIT-Co
## 2022-02-07
### Dokumentation
- Hinweise zur [Signaturprüfung der vom DVDV gelieferten Zustellpunkt-Parameter](./responsibilities/get-destination.mdx#checkDestinationParametersSignature) ergänzt
- Hinweise zur [Signaturprüfung der vom DVDV gelieferten Zustellpunkt-Parameter](./sending/get-destination.mdx#checkDestinationParametersSignature) ergänzt
## 2022-02-03
### Zustelldienst 1.2.0
......@@ -245,7 +248,7 @@ Das hier veröffentlichte Changelog bezieht sich auf die [Testinstanz von FIT-Co
## 2022-01-19
### Dokumenation
- [Aufbau der Zustellpunkt-Informationen](responsibilities/get-destination.mdx#destination-object) überarbeitet
- [Aufbau der Zustellpunkt-Informationen](./sending/get-destination.mdx#destination-object) überarbeitet
## 2022-01-17
### Dokumentation
......@@ -253,7 +256,7 @@ Das hier veröffentlichte Changelog bezieht sich auf die [Testinstanz von FIT-Co
## 2022-01-11
### Dokumentation
- [Abschnitt zur Pflege der FIT-Connect „destinationSignatur“ in FIM-Redaktionssytemen](responsibilities/routing.mdx) ergänzt
- [Abschnitt zur Pflege der FIT-Connect „destinationSignatur“ in FIM-Redaktionssytemen](./organisation-tasks/publish_destination#signierte-adressierungsinformationen) ergänzt
### Self Service Portal 1.3.1
- Fix: Anpassung des Address Export und Zustelldienst Signature Typs um dem JWT Standard besser gerecht zu werden (`JWT` statt `jwt`)
......
......@@ -20,7 +20,7 @@ Für die Aktualisierung der Schlüssel des Zustellpunktes gibt es folgenden Endp
* <ApiLink api="submission-api" to="/v1/destinations/{destinationId}/keys" withMethod="post"/>
Die Details sind der API-Spec zu entnehmen. Eine Beschreibung der Parameter des Zustellpunkt-Objektes findet sich im Artikel [Aufbau der Zustellpunkt-Informationen](../responsibilities/get-destination.mdx#destination-object).
Die Details sind der API-Spec zu entnehmen. Eine Beschreibung der Parameter des Zustellpunkt-Objektes findet sich im Artikel [Aufbau der Zustellpunkt-Informationen](../sending/get-destination.mdx#destination-object).
### Beispiele
......
......@@ -90,30 +90,71 @@ values={[
<TabItem value="java">
Im folgenden Beispiel kann die allgemeine Struktur eines SET über folgenden Code validiert werden.
Die Prüfungen bauen auf der Methode `assertTrue` auf.
Im folgenden Beispiel kann die allgemeine Struktur eines SET über folgenden Code validiert werden.
Außerdem wird der Schlüssel verifiziert.
Die Prüfungen bauen auf der Methode `validateTrueOrElseThrow` auf. Die Methode prüft, ob ein Ausdruck der Wahrheit entspricht.
Diese kann im Fehlerfall die Fehler sammeln oder direkt eine Exception werfen.
```java
public void validate(SignedJWT signedJWT, UUID caseId, FitConnectKeyLookup keyLookup) {
try {
final JWSHeader header = signedJWT.getHeader();
validateHeader(header);
//
final JWTClaimsSet payload = signedJWT.getJWTClaimsSet();
validatePayload(payload);
validateSubject(payload);
//
validateTxnClaim(signedJWT.getJWTClaimsSet(), caseId);
//
validateSignature(signedJWT, keyLookup);
} catch (Exception e) {
fail(e.getMessage());
}
validateHeader(signedJWT.getHeader());
validatePayload(signedJWT.getJWTClaimsSet());
String subject = payload.getStringClaim("sub");
String tokenSubmissionId = subject.substring(subject.indexOf(':') + 1);
validateTrueOrElseThrow(tokenSubmissionId.equalsIgnoreCase(submissionId), "The provided subject does not match with the submission.");
String txn = payload.getStringClaim("txn");
String transactionId = txn.substring(txn.indexOf(':') + 1);
validateTrueOrElseThrow(transactionId.equalsIgnoreCase(caseId), "The provided txn does not match with the case.");
UUID jti = UUID.fromString(payload.getStringClaim("jti"));
try {
// Validate public Key
RSAKey parsedPublicKey = RSAKey.parse(publicKey);
validateRSAKey(parsedPublicKey, false);
JWSVerifier jwsVerifier = new RSASSAVerifier(parsedPublicKey);
validateTrueOrElseThrow(signedJWT.verify(jwsVerifier), "The signature of the token could not be verified with the specified key.");
} catch (ParseException | JOSEException e) {
throw new RuntimeException("The SET could not get parsed properly.");
}
} catch (AssertionError e) {
throw new RuntimeException(e.getMessage());
}
}
public static void validateRSAKey(RSAKey RSAKey, boolean isPrivate){
validateTrueOrElseThrow(RSAKey.getModulus().decodeToBigInteger().bitLength() >= 4096, "JWK has wrong key length.");
validateTrueOrElseThrow(RSAKey.getAlgorithm().equals(JWSAlgorithm.PS512), "The specified public key does not use PS512 as algorithm.");
if(isPrivate){
validateTrueOrElseThrow(RSAKey.getKeyOperations().size() == 1 &&
RSAKey.getKeyOperations().contains(KeyOperation.SIGN),
"The specified private key is not intended for 'sign' as specified through key operation.")
}
else{
validateTrueOrElseThrow(RSAKey.getKeyOperations().size() == 1 &&
RSAKey.getKeyOperations().contains(KeyOperation.VERIFY),
"The specified public key is not intended for 'verify' as specified through key operation.")
};
validateTrueOrElseThrow(RSAKey.getPublicExponent().toString().equals("AQAB"), "The specified key does not match the public exponent 'AQAB'.");
}
private static void validateTrueOrElseThrow(boolean expression, String msg) {
if (!expression) {
throw new RuntimeException(msg);
}
}
```
Der Header wird auf die drei verpflichtenden Angaben geprüft.
Der folgende Quellcode prüft, ob der Header Pflichtangaben enthält:
```java
private void validateHeader(JWSHeader header) {
......
......@@ -65,7 +65,7 @@ Die Fachschemareferenz ist im Zustellpunkt daher immer einer dazugehörigen Leis
```
Wenn ein sendendes System die Angaben eines Zustellpunkts ermittelt (über den Endpunkt <ApiLink api="submission-api" to="/v1/destinations/{destinationId}" /> der Submission API oder [über die Routing API](../../responsibilities/get-destination.mdx)), so muss der Fachdatensatz diesem Schema entsprechen.
Wenn ein sendendes System die Angaben eines Zustellpunkts ermittelt (über den Endpunkt <ApiLink api="submission-api" to="/v1/destinations/{destinationId}" /> der Submission API oder [über die Routing API](../../sending/get-destination.mdx)), so muss der Fachdatensatz diesem Schema entsprechen.
Wenn mehrere Schemata (bspw. innerhalb des `submissionSchemas` Array) im Zustellpunkt referenziert werden, so muss der Fachdatensatz einem dieser referenzierten Schemata entsprechen.
## Warum muss das sendende System über den Metadatensatz eine Fachschemareferenz mitliefern?
......
......@@ -5,7 +5,7 @@ hide_table_of_contents: true
| Begriff | Beschreibung |
|---------|--------------|
| FIT-Connect Adressierungsinformationen | Für die Zuständigkeitsfindung im Portalverbund ist eine Hinterlegung von signierten Adressierungsinformationen in einem Landes-Redaktionssystem notwendig (siehe Artikel [Konfiguration des Antragsroutings](responsibilities/routing.mdx)). Die FIT-Connect-Adressierungsinformationen werden im Format XZuFi von den Landes-Redaktionssystemen an das Onlinegateway des Portalverbundes (PVOG) übermittelt und vom FIT-Connect Routingdienst in Kombination mit den im Deutschen Verwaltungsdiensteverzeichnis (DVDV) zur Zuständigkeitsfindung / technischen Adressierung von *Zustellpunkten* genutzt. |
| FIT-Connect Adressierungsinformationen | Für die Zuständigkeitsfindung im Portalverbund ist eine Hinterlegung von signierten Adressierungsinformationen in einem Landes-Redaktionssystem notwendig (siehe Artikel [Konfiguration des Antragsroutings](organisation-tasks/publish_destination#signierte-adressierungsinformationen)). Die FIT-Connect-Adressierungsinformationen werden im Format XZuFi von den Landes-Redaktionssystemen an das Onlinegateway des Portalverbundes (PVOG) übermittelt und vom FIT-Connect Routingdienst in Kombination mit den im Deutschen Verwaltungsdiensteverzeichnis (DVDV) zur Zuständigkeitsfindung / technischen Adressierung von *Zustellpunkten* genutzt. |
| Amtlicher Gemeindeschlüssel (AGS) | Schlüssel zur Identifizierung von verwaltungspolitischen Gebieten. Siehe [AGS](./details/ags.mdx) |
| Amtlicher Regionalschlüssel (ARS) | Schlüssel zur Identifizierung von verwaltungspolitischen Gebieten. Nachfolger des AGS. Siehe [ARS](./details/ars.mdx) |
| Angekündige Anlage | Angabe gegenüber dem Zustelldienst, welche Anlagen übermittelt werden. Teilmenge der Angaben in der `contentStructure` im verschlüsselten Metadatensatz. |
......@@ -16,7 +16,7 @@ hide_table_of_contents: true
| API-Gateway | Das API-Gateway ist eine technische Komponente, die OAuth-Tokens prüft und nicht oder falsch authentifizierte Anfragen ablehnt. Ein Zugriff auf die Schnittstelle des Zustelldienstes erfolgt immer über das API-Gateway. |
| 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. |
| Destination | siehe *Zustellpunkt (Destination)* |
| Destination-ID (`destinationId`) | Die Destination-ID ist eine vom *Zustelldienst* vergeben ID für einen *Zustellpunkt*. Sie wird von Betreiber:innen empfangender Systeme im Self-Service-Portal angelegt und dienst der eindeutigen Adressierung des empfangenden Systems der zuständigen Fachbehörde im jeweiligen Antragskontext auf Basis eines *Leistungsschlüssels* und eines geographischen Merkmals (z.B. ARS oder PLZ). Sendende Systeme (z.B. Online-Antragsdienste) können die Destination-ID über die Routing API oder über bilaterale Absprachen mit den Betreiber:innen empfangender Systeme ermitteln (siehe Artikel [Zustellpunkt ermitteln](responsibilities/get-destination.mdx)). |
| Destination-ID (`destinationId`) | Die Destination-ID ist eine vom *Zustelldienst* vergeben ID für einen *Zustellpunkt*. Sie wird von Betreiber:innen empfangender Systeme im Self-Service-Portal angelegt und dient der eindeutigen Adressierung des empfangenden Systems der zuständigen Fachbehörde im jeweiligen Antragskontext auf Basis eines *Leistungsschlüssels* und eines geographischen Merkmals (z.B. ARS oder PLZ). Sendende Systeme (z.B. Online-Antragsdienste) können die Destination-ID über die Routing API oder über bilaterale Absprachen mit den Betreiber:innen empfangender Systeme ermitteln (siehe Artikel [Zustellpunkt ermitteln](sending/get-destination.mdx)). |
| Einreichung (submission) | Eine Einreichung bei einer zuständigen Stelle 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 mindestens aus einem Metadatensatz und optional einem Fachdatensatz und / oder einem oder mehreren Anlagen. Eine Einreichung besitzt immer eine systemübergreifend eindeutige ID (`submissionId`). Diese ID wird für jeden Einreichungsvorgang durch den Zustelldienst vergeben. |
| Einreichungsvorgang (case) | Bei Erstellung einer neuen Einreichung wird durch den Zustelldienst automatisch ein neuer Einreichungsvorgang angelegt. Der Einreichungsvorgang kann neben der initialen Einreichungen auch mehrere Antworten (replies) umfassen. Innerhalb eines Einreichungsvorgangs können weitere Fachdatensätze und Anlagen zwischen beiden Parteien in Form von Antworten (replies) ausgetauscht werden. Der Einreichungsvorgang wird über eine eindeutige *Vorgangsreferenz* identifiziert. |
| Empfangendes System (subscriber) | Das technische System, das Einreichungen auf Verwaltungsseite entgegennimmt. (z.B. Fachanwendung / virtuelle Poststelle) |
......@@ -42,5 +42,5 @@ hide_table_of_contents: true
| Zuständige Fachbehörde | Die für die Bearbeitung der Einreichung zuständige Stelle. Die zuständige Fachbehörde betreibt zum Empfang von Einreichungen ein empfangendes System. |
| 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. |
| Zustelldienst | Zentrale Komponente der FIT-Connect-Infrastruktur. Der Zustelldienst implementiert die Submission API und ermöglicht die Übermittlung und den Abruf von Einreichungen von sendenden Systemen an empfangende Systeme. |
| Zustellpunkt (Destination) | Technisch eindeutig adressierbarer Endpunkt zur Einreichung von Anträgen oder Berichten an die für die Verwaltungsleistung zuständige Fachbehörde über die FIT-Connect Übermittlungsinfrastruktur. Ein Zustellpunkt beschreibt die Konfiguration eines konkreten empfangenden Systems (Fachverfahren oder virtuelle Poststelle). Für ein empfangendes System können (z.B. für unterschiedliche Fachlichkeiten) 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. Zustellpunkte werden über die sogenannte Destination-ID eindeutig identifiziert. Weitere Informationen finden sich in den Artikeln [Zustellpunkt anlegen](receiving/destination.mdx) und [Zustellpunkt ermitteln](responsibilities/get-destination.mdx). |
| Zustellpunkt (Destination) | Technisch eindeutig adressierbarer Endpunkt zur Einreichung von Anträgen oder Berichten an die für die Verwaltungsleistung zuständige Fachbehörde über die FIT-Connect Übermittlungsinfrastruktur. Ein Zustellpunkt beschreibt die Konfiguration eines konkreten empfangenden Systems (Fachverfahren oder virtuelle Poststelle). Für ein empfangendes System können (z.B. für unterschiedliche Fachlichkeiten) 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. Zustellpunkte werden über die sogenannte Destination-ID eindeutig identifiziert. Weitere Informationen finden sich in den Artikeln [Zustellpunkt anlegen](receiving/destination.mdx) und [Zustellpunkt ermitteln](sending/get-destination.mdx). |
| Zuständigkeitsverzeichnis | Dienst, der eine Abfrage der *Adressierungsinformationen* anhand eines Leistungsschlüssels und eines geographischen Merkmals (z.B. ARS oder PLZ) ermöglicht; z.B. Portalverbund Online-Gateway oder Behördenfinder Deutschland |
......@@ -9,8 +9,8 @@ import TabItem from '@theme/TabItem'
### Zertifikate der Verwaltungs-PKI beantragen
Verantwortliche für Fachverfahren benötigen für das Produktivsystem von FIT-Connect Zertifikate der Verwaltungs-PKI. <br/>
Die Zertifikate enthalten öffentliche und private Schlüssel für Verschlüsselung und Signierung. Sie dienen zur Sicherung der Anträge und Berichte, die Antragsplattformen oder Softwareprogramme an Fachverfahren senden.
Verantwortliche für Fachverfahren benötigen für das Produktivsystem von FIT-Connect Zertifikate der Verwaltungs-PKI. <br/>
Die Zertifikate enthalten öffentliche und private Schlüssel für Verschlüsselung und Signatur. Öffentliche Schlüssel werden bei Zustellpunkten hinterlegt und ermöglichen es den sendenden Systemen in FIT-Connect, Anträge oder Berichte Ende-zu-Ende verschlüsselt an den Zustellpunkt zu übersenden bzw. signierte Empfangsbestätigungen und Empfangsablehnungen seitens des Empfängers zu überprüfen. Private Schlüssel dienen der Entschlüsselung und Signatur auf Seiten der Empfänger und dürfen niemals veröffentlicht bzw. an unberechtigte Dritte weitergegeben werden.
#### Überblick
Das Beantragen von Zertifikaten ist eine Aufgabe, die Verantwortliche für Fachverfahren beachten müssen, um Fachverfahren an FIT-Connect anzubinden.
......
---
title: Fachverfahren anbinden
title: Fachverfahren anmelden
---
import useBaseUrl from '@docusaurus/useBaseUrl';
import Tabs from '@theme/Tabs'
......@@ -16,7 +16,7 @@ Vor der Anbindung an das Produktivsystem von FIT-Connect ist es erforderlich, Ih
#### Konzeptionelle Vorüberlegungen
Verantwortliche für ein Fachverfahren sollten zunächst die folgenden Fragen klären:
- Welche Leistungen sollen Bürger:innen online beantragen können? <br/>
Wie lauten die Leika-Schlüssel dieser Leistungen? <br/>
Wie lauten die Leistungsschlüssel (ehemals: _Leika-Schlüssel_) dieser Leistungen? <br/>
- Wie antwortet Ihr Fachverfahren auf Anträge? <br/>
Werden Sie Bescheide über FIT-Connect, Elster, FINK, als E-Mail, De-Mail oder als Brief zustellen?
- Welches Schema (FIM- oder XÖV-Schema) für Fachdaten will Ihr Fachverfahren nutzen?
......
......@@ -15,7 +15,7 @@ Die Zertifikate und die damit verbundenen JWKs haben eine begrenzte Gültigkeit
### Zertifikate der Verwaltungs-PKI
Sie benötigen Zertifikate der Verwaltungs-PKI, um ein Fachverfahren an das Produktivsystem von FIT-Connect anzubinden.
Wie Sie Zertifikate der Verwaltungs-PKI beantragen, das ist [hier](../getting-started/account#anmeldung-am-self-service-portal) beschrieben.
Wie Sie Zertifikate der Verwaltungs-PKI beantragen, das ist [hier](../organisation-tasks/apply-for-certificates) beschrieben.
:::note Hinweis
Für die Testumgebung von FIT-Connect sind keine Zertifikate der Verwaltungs-PKI erforderlich. Hier können selbst signierte Zertifikate genutzt werden. Das Vorgehen ist im Artikel [Erstellen von JSON Web Keys für Testzwecke](../details/jwk-creation.md) beschrieben.
......
......@@ -98,7 +98,7 @@ Anschließend kann der Zustellpunkt entweder über das Self-Service-Portal oder
:::
:::caution Hinweis
Um eine [Auffindbarkeit des Zustellpunktes über die Routing API](../responsibilities/get-destination.mdx) zu ermöglichen, müssen die konfigurierten Zuständigkeitsinformationen zunächst in einem an den Portalverbund angeschlossenen Landes-Redaktionssystem des FIM-Bausteins Leistungen hinterlegt werden. Weitere Informationen hierzu finden sich im Artikel [Konfiguration des Antragsroutings](../responsibilities/routing.mdx).
Um eine [Auffindbarkeit des Zustellpunktes über die Routing API](../sending/get-destination.mdx) zu ermöglichen, müssen die konfigurierten Zuständigkeitsinformationen zunächst in einem an den Portalverbund angeschlossenen Landes-Redaktionssystem des FIM-Bausteins Leistungen hinterlegt werden. Weitere Informationen hierzu finden sich im Artikel [Konfiguration des Antragsroutings](../organisation-tasks/publish_destination#signierte-adressierungsinformationen).
:::
## Zugriff auf Zustellpunkte einrichten
......
---
title: Konfiguration des Antragsroutings
---
import useBaseUrl from '@docusaurus/useBaseUrl';
import Tabs from '@theme/Tabs'
import TabItem from '@theme/TabItem'
Um die [Auffindbarkeit eines Zustellpunktes über die Routing API](./get-destination.mdx) zu ermöglichen, müssen die [im Self-Service-Portal konfigurierten Zuständigkeitsinformationen](../receiving/destination.mdx) zunächst in einem an den Portalverbund angeschlossenen Landes- oder Bundes-Redaktionssystem des FIM-Bausteins Leistungen hinterlegt werden.
## Schritt 1: Abruf der signierten Adressierungsinformationen im Self-Service-Portal
Die zu einem Zustellpunkt gehörigen signierten Zuständigkeits-/Adressierungsinformationen (`destinationSignature`) können im Self-Service-Portal über einen Button in der Zustellpunkt-Übersichtsliste in die Zwischenablage kopiert werden.
Von der Zwischenablage können diese Informationen dann in das zuständige Redaktionssystem kopiert/import werden.
<div class="center">
<img width="800" alt="Button in der Zustellpunkt-Übersichtsliste"
src={useBaseUrl('/images/ssp/destination-overview-export-address-information.png')}/>
</div>
## Schritt 2: Pflege der signierten Adressierungsinformationen im FIM-Redaktionssystem
Die notwendige Pflege der FIT-Connect Adressierungsinformationen (`destinationSignature`) in einem Landes- oder Bundes-Redaktionssystem des FIM Baustein Leistungen und die Zuständigkeitsermittlung im Portalverbund ist in folgendem Schaubild dargestellt:
<div class="center">
<img width="550" alt="FIT-Connect Routing-Architektur"
src={useBaseUrl('/images/routing/routing-architecture-overview.png')}/>
</div>
Nach der Übernahme der Adressierungsinformationen in das Redaktionssystem werden diese im Format XZuFi an das [Onlinegateway des Portalverbund (PVOG)](https://servicesuche.bund.de/) übermittelt und sind anschließend [über die Routing API abrufbar](./get-destination.mdx).
Der Prozess der Pflege der in Schritt 1 abgerufenen signierten Adressierungsinformationen ist abhängig von dem im jeweiligen Bundesland verwendeten Redaktionssytem.
### Infodienste (Systeme) der Linie6Plus (BB, HE, MV, NI, RP, SH, SL, ST, TH)
#### Einleitung/Allgemeines
Zur Steuerung von Antragsinformationen der Plattform FIT-Connect bzw. um die signierten Adressierungsinformationen eines Zustellpunktes (Destination) auszugegeben, muss die in Schritt 1 abgerufene „destinationSignatur“ (im Folgenden „FIT-Connect destinationSignatur“ genannt) verwendet werden.
Dafür wird die teilweise eingeführte Destination-ID entfallen, da die FIT-Connect destinationSignatur bereits die Destination-ID enthält.
Diese lässt sich in den Infodiensten pflegen; Voraussetzung und Ablauf sind im folgenden Abschnitt beschrieben.
#### Anlage eines Zustellkanals für die FIT-Connect destinationSignatur
Für die Pflege der FIT-Connect destinationSignatur in den Infodiensten wird ein neuer Zustellkanal benötigt.
Dieser kann nach Beauftragung durch die jeweiligen Länder der Linie6Plus durch den Support (support@teleport.de) zentral in den Infodiensten für die benötigte Datenpflege implementiert werden.
Da die FIT-Connect destinationSignatur einen eindeutigen Zustellpunkt definiert, muss sie an der Organisationseinheit als zuständige Stelle für definierte Verwaltungsleistungen verortet sein.
In dem Modul `Organisationseinheit` -> `Einstellung Kontakt/Verkehr`, kann die FIT-Connect destinationSignatur als neues Kontaktsystem für die Organisationseinheit angegeben werden.
Dementsprechend darf in den Infodiensten nicht nur der Wert Destination-ID hinterlegt werden, sondern dort müssen ebenfalls die signierten Adressierungsinformationen aus Schritt 1 hinterlegt werden können.
Dies ist durch das Anlegen der FIT-Connect destinationSignatur möglich, da diese den Wert ebenfalls enthält.
Konkret wird das (neue) Kontaktsystem wie folgt benannt: „FIT-Connect (destinationSignatur)“ mit der Kurzbezeichnung "FITCONNECTDESTSIGNATURE".
#### Pflege der FIT-Connect destinationSignatur in den Infodiensten
Die Redakteure der Kommunen und der zentralen Landesredaktion pflegen die FIT-Connect destinationSignatur an der Organisationseinheit dezentral.
In dem Modul `Organisationseinheit` -> `Einstellung Kontakt/Verkehr` kann der Redakteur ein Kontaktsystem hinzufügen.
Hierbei steht ihm als Option das Kontaktsystem „FIT-Connect (destinationSignatur)“ als Auswahloption zur Verfügung.
Im Feld `Kennung` hinterlegt der Redakteur die FIT-Connect destinationSignatur der Organisationseinheit.
Für bestimmte Anwendungsfälle besteht aber auch die Möglichkeit die FIT-Connect destinationSignatur mehrfach zu hinterlegen.
### Weitere Redaktionssysteme
Wir streben an, für alle in Deutschland gängigen Systeme ein entsprechendes Pflegekonzept bereitzustellen.
Hierzu freuen wir uns über Bedarfsmeldungen, um besser abschätzen zu können, für welche Systeme ein Pflegekonzept prioritär benötigt wird.
Teilen Sie uns auch gerne mit, wenn Ihnen ein hier noch nicht aufgeführtes Pflegekonzept bekannt ist.
......@@ -16,7 +16,7 @@ Eine Übertragung über FIT-Connect besteht aus
Alle drei Datensatzarten müssen mit [JSON Web Encryption (JWE)](https://tools.ietf.org/html/rfc7516) verschlüsselt und mit [JWE-Compact Serialisierung](https://tools.ietf.org/html/rfc7516#section-7.1) serialisiert werden.
Dokumente müssen als Binärdateien und nicht als Zeichenketten kodiert verschlüsselt werden.
Der [vorher abgerufene Zustellpunkt](../responsibilities/get-destination.mdx#informationen-des-zustellpunktes-erhalten) beinhaltet die Schlüssel-ID des öffentlichen Verschlüsselungsschlüssels unter dem Feld `encryptionKid`.
Der [vorher abgerufene Zustellpunkt](../sending/get-destination.mdx#informationen-des-zustellpunktes-erhalten) beinhaltet die Schlüssel-ID des öffentlichen Verschlüsselungsschlüssels unter dem Feld `encryptionKid`.
Damit können wir den öffentlichen Schlüssel des Zustellpunktes im JSON Web Key (JWK)-Format abrufen um Daten zu verschlüsseln.
```shell title="Beispiel: Abruf des JWK eines Zustellpunktes"
......
......@@ -17,16 +17,16 @@ Für eine Auffindbarkeit der Zustellpunkte über die Routing-API ist in der Test
Sofern eine Destination-ID bereits bekannt ist, können die in einem Zustellpunkt hinterlegten technischen Parameter alternativ auch über den Endpunkt <ApiLink api="submission-api" to="/v1/destinations/{destinationId}" /> der Submission API des zuständigen Zustelldienstes [abgerufen werden (siehe unten)](#submissionapi).
Die Konfiguration des Antragsroutings in der produktiven Umgebung ist bereits jetzt möglich. Die [in den Landesredaktionen konfigurierten Zustellpunkte](routing.mdx) sind in der Produktivumgebung über Routing API abrufbar.
Die Konfiguration des Antragsroutings in der produktiven Umgebung ist bereits jetzt möglich. Die [in den Landesredaktionen konfigurierten Zustellpunkte](../organisation-tasks/publish_destination.mdx) sind in der Produktivumgebung über Routing API abrufbar.
:::
Die Ermittlung der `destinationId` und die Ermittlung der technischen Parameter über die Routing-API erfolgt über einen GET-Request auf den Endpunkt <ApiLink api="routing-api" to="/routes" /> des FIT-Connect Routingdienstes.
Der Endpunkt erwartet genau zwei Parameter:
- Einen Identifikator einer Verwaltungsleistung. Als Identifikator der Verwaltungsleistung muss ein Leistungsschlüssel aus dem FIM-Baustein Leistungen (ehemals *LeiKa-Schlüssel*, siehe [Leistungskatalog im FIM-Portal](https://fimportal.de/kataloge#download-leistungen)) verwendet werden.
- Einen Identifikator eines verwaltungspolitischen Gebietes. Für den Identifikator des verwaltungspolitischen Gebietes kann entweder der [amtliche Gemeindeschlüssel (AGS)](../details/ags.mdx), der [amtliche Regionalschlüssel (ARS)](../details/ars.mdx) oder die [Id eines Gebietes](#verwaltungspolitische-gebiete-ermitteln) aus der Suche über den Endpunkt <ApiLink api="routing-api" to="/areas" /> verwendet werden.
- Einen Identifikator eines verwaltungspolitischen Gebietes. Für den Identifikator des verwaltungspolitischen Gebietes kann entweder der [amtliche Gemeindeschlüssel (AGS)](https://www.destatis.de/DE/Themen/Laender-Regionen/Regionales/Gemeindeverzeichnis/Glossar/amtlicher-gemeindeschluessel.html), der [amtliche Regionalschlüssel (ARS)](https://www.destatis.de/DE/Themen/Laender-Regionen/Regionales/_FAQ/regionalschluessel.html) oder die [Id eines Gebietes](#verwaltungspolitische-gebiete-ermitteln) aus der Suche über den Endpunkt <ApiLink api="routing-api" to="/areas" /> verwendet werden.
Der Endpunkt <ApiLink api="routing-api" to="/routes" /> implementiert eine Pagination.
Der Endpunkt <ApiLink api="routing-api" to="/routes" /> implementiert Pagination.
Das Ergebnis der Anfrage enthält daher neben der eigentlichen (Teil-)Ergebnismenge der Routing-Informationen (`routes`) auch Informationen wie Anzahl (`count`), Gesamtanzahl (`totalCount`) und Startpunkt der Ergebnismenge (`offset`).
Die zurückgegebene Teilergebnismenge ist standardmäßig auf 100 Einträge limitiert und kann über den GET-Parameter `limit` auf maximal 500 Einträge erweitert werden.
Über den GET-Paramter `offset` können weitere Teilmengen der Ergebnismenge ermittelt werden.
......@@ -36,48 +36,96 @@ Der Endpunkt <ApiLink api="routing-api" to="/routes" /> ist auf die Anzahl von A
Beispiele für das Ermitteln der benötigten Daten:
<Tabs
defaultValue="url"
defaultValue="curl"
values={[
{ label: 'Direkt via URL', value: 'url', },
{ label: 'curl', value: 'curl', },
]}>
<TabItem value="url">
Die Routing-API kann direkt manuell über den Aufruf der folgenden Links ausprobiert werden:
- via ARS: https://routing-api-testing.fit-connect.fitko.dev/v1/routes?ars=064350014014&leikaKey=99123456760610
- via AGS: https://routing-api-testing.fit-connect.fitko.dev/v1/routes?ags=06435014&leikaKey=99123456760610
- via Area-ID (siehe Abschnitt [Verwaltungspolitische Gebiete ermitteln](#verwaltungspolitische-gebiete-ermitteln)): https://routing-api-testing.fit-connect.fitko.dev/v1/routes?areaId=931&leikaKey=99123456760610
</TabItem>
]
}>
<TabItem value="curl">
```bash
$ export ROUTING_API=https://routing-api-testing.fit-connect.fitko.dev
$ curl \
-H "Content-Type: application/json" \
-X GET "$ROUTING_API/v1/routes?leikaKey=99123456760610&ars=064350014014"
-X GET "$ROUTING_API/v1/routes?leikaKey=99108012005000&ags=15085055"
```
```bash
$ export ROUTING_API=https://routing-api-testing.fit-connect.fitko.dev
$ curl \
-H "Content-Type: application/json" \
-X GET "$ROUTING_API/v1/routes?leikaKey=99123456760610&ags=06435014"
-X GET "$ROUTING_API/v1/routes?leikaKey=99108012005000&ars=150850055055"
```
```bash
$ export ROUTING_API=https://routing-api-testing.fit-connect.fitko.dev
$ curl \
-H "Content-Type: application/json" \
-X GET "$ROUTING_API/v1/routes?leikaKey=99123456760610&areaId=931"
-X GET "$ROUTING_API/v1/routes?leikaKey=99108012005000&areaId=15529"
```
</TabItem>
</Tabs>
Alternativ können Aufrufe auch über das "Try"-Feature in der API-Dokumentation des Endpunktes <ApiLink api="routing-api" to="/routes" /> durchgeführt werden.
Beispiel für die Response:
Ein Beispiel für eine Antwort des Routingdienstes findet sich in der in der API-Dokumentation der Routing-API im Endpunkt <ApiLink api="routing-api" to="/routes" />.
```json
{
"count": 1,
"offset": 0,
"totalCount": 1,
"routes": [
{
"destinationId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
"destinationSignature": "eyJraWQiOiJmT0hzdExPNGJlQnEwcHgtMDFwTEoyUnhQbUJEakNtbEtIQk84ZzVXLVNBIiwidHlwIjoiand0IiwiYWxnIjoiUFM1MTIifQ.eyJzdWJtaXNzaW9uSG9zdCI6InN1Ym1pc3Npb24tYXBpLWRldi5maXQtY29ubmVjdC5maXRrby5kZXYiLCJpc3MiOiJodHRwczpcL1wvcG9ydGFsLmF1dGgtZGV2LmZpdC1jb25uZWN0LmZpdGtvLmRldiIsInNlcnZpY2VzIjpbeyJnZWJpZXRJRHMiOlsidXJuOmRlOmJ1bmQ6ZGVzdGF0aXM6YmV2b2Vsa2VydW5nc3N0YXRpc3RpazpzY2hsdWVzc2VsOnJzOjEyMDY0NTQxMCJdLCJsZWlzdHVuZ0lEcyI6WyJ1cm46ZGU6ZmltOmxlaWthOmxlaXN0dW5nOjk5MTM0MDA1MDE3MDAwIl19XSwiZGVzdGluYXRpb25JZCI6ImFjNzE1ZjM0LTMzM2UtNDFmNC05YmI1LTE4NmIzMDllYTIzMyIsImlhdCI6MTYzNzg2MzQ4MSwianRpIjoiMmQxNDI2ZjItZDY3My00NmRlLTg2OGUtZDk2ODQ0ZDI0ZmUxIn0.gSfjbRck_BmhkVx-P-E9UexlQudEZV8auYTHXrCSM4ja3gDg2VGlpCjH3-WBvgdLp7zv0J0z9en6PecF73QV4ltik0c7j4tbpAPz9tmTu0pedjVrbkbWj4b4H-EyYt1IJeDyrZJglZ1EB4b_4mk5HNZHgZnbMx0QLhRci8-wJf76hJgoWHkebpXNjdHHqndFbpGa7HCiul1XeJVv8Ny6Fgb7Nu-c5-YmVl5kZSCmxURAZlZubk3jBaIfMOEXIth3B4FtOvEiEXkWTtH0r99eZkYdK-ykLuefenS_Ib56ZpZ67Sw3T-LuV5pIzhq--REL6PaCOvRkU88SS1iW8LmiwEIxCIwFNEpnohNYjy4ZG8CnCfD4SztRA9nQYohdh2Cc_3MafUX7wjz1vqlonmZ7m4QYfZCqtl3IkcJLeayBU5OHTlcvHAQRIfgvP9SJApJr_Y2p3p4fHePOVStxLMlCOCYcmf0EBibvUsuwbEbmeppP72OFOkCwA9I82Z0SnxLdaHLXup2f_z0OnJtxrJAZnhREyYSvL2HOJusNKfpNy360C7Kf2g-BzAEvD4K5LzqWhKrWgztn4SDmgWL_Z3Ez1e2ZqTzfmJXxE_WGit2Lr0rBd9vTPGYKidBLZ8B-2JJZCPbrqlTxPdWImPrgcZP0qpNsJdls4OJo7xz5ozwrR4Y",
"destinationParameters": {
"submissionUrl": "https://submission-api.fit-connect.example.org/v1",
"status": "active",
"submissionSchemas": [
{
"schemaUri": "urn:xoev-de:bmk:standard:xbau_2.2#baugenehmigung.antrag.0200",
"mimeType": "application/xml"
}
],
"encryptionKid": "NFNb7k84r61G9ayAAJItJCNGl7wKWif9HyBAgicJq_8",
"publicKeys": {
"keys": [
{
"kty": "RSA",
"key_ops": [
"wrapKey"
],
"alg": "RSA-OAEP-256",
"x5c": [
"...(base64 encoded cert)...",
"...(base64 encoded intermediate cert)...",
"...(base64 encoded root cert)..."
],
"kid": "NFNb7k84r61G9ayAAJItJCNGl7wKWif9HyBAgicJq_8",
"n": "1f1070XZ4NpHN2WqdH5c8dBUBPH99TJEvVXSP_jjZdOEzRJztUwSpIabtAvgDnNGmPTLs-jLlVR3NQCyKwOwpHVi3FmudKmIPplBFpsEpZ9JYBGpg8_ZbDN9fwJhob0KjAlsSY9mBOTfqLCqqVIJrk4fxBjwNaroCLkSbS2RrfMtUEW5T5Vo1uw2lnYTKq1uyhr1PG02mvDCBb0LMAqcMXRR6bdme8GN55S3UNWhsaonpq04aa8_baVdjoJYTk03VLORMojnnrJjxyPPiHRs2Re9JQoaVPy6TUrbFV63zvt30XM8ZJnla09yhMmuBJXpdtyWXKnKyqj8m9D5Vg68xksQVeJozpCAoBlsJeAheE31XPQwCBvamy46K669ZCkfkdhQgoIJMt1AVSef0qcLDg__nQ-rfIuYxHrtn7jgI0NeCGFbscxmzl08_LSj3nlj2-ag2uVq4bbdH3tziNxy_rr84N-6AA5iQe5v1L_zYXYWxGzaAOUWzJt0QRiEC9pF6Zqfrn4mPHn5lm2jtdM9AlmgkZtmK92rByfcMzo5-yEK37K96NtqpDCsoABUkvC1TLiqaCkGkQd1DmGnfNyGJV_eNMwmZyotom8WLS-icbQD913F9YlSTRsQYhFzw78pDJHHo4AtldMiQcpUY4qoVVpfpPZlMWTq7idnq6iO4MM",
"e": "AQAB"
}
]
},
"metadataVersions": [
"string"
],
"replyChannels": {
"eMail": {
"usePgp": true
},
"deMail": {},
"fink": {},
"elster": {}
}
},
"destinationParametersSignature": "eyJ0eXAiOiJKT1NFIiwiYWxnIjoiUFM1MTIiLCJraWQiOiJlOWJjMDk3YS1jZTUxLTQwMzYtOTU2Mi1kMmFkZTg4MmRiMGQiLCJjdHkiOiJhcHBsaWNhdGlvbi9qb3NlIn0..g9xgjWf-_3JjMAFwPgBB4iXFrkrsRS-Ois3pxWWcFzdZuu_I8jH9Bd4FAQpf6nJwPtytJgoWYkm7gTCMwKiQH7JknXXrdYcnHRrlU2aT9thjaK5uYKYvuDfvklvQvKTYtfqowkMtk3pl91TfB1Pyxbprx6u5qut_pI-z2E7SC8gJ6V8u1rT1wDHOp-xrvMHUQiH7Ugmyb7Tg_Dc55AL0FrZ2wmurdPK46iAZBfIpzNJgUbqrlKvKQkwbs11Bc2qRzrFIG8yMyuN-qhGxibokMoq1U3FjlxtNgwWQJJOYlMiCbMibkINsmZ5mGZDS_Dra89TVMz0_rZagj-mxJ5-DlIE7E1LsvUKXYBHhPFoCJTGH1Lla7AEWtZ59HNSalMjvgcGWTgp-xTbqo8Ej6PwUM9j7_lNH1kT0iSvuCTYktVJEmovmpT0gB9c0AaGbQfiZFk8UUiBSAVFoD2B-0EP8CkEDAxsL0xlDdSAeK4Zrvg2nnck8NjdDQa68KfW4Fp32cfdkWYhGJ13xNG889P0aofCv7Joj4zxVEsPGfvqe6b78i8oZOe_Tn2lIVBwxZ6phtvEmZ8w_aS4zGSuYXoXx1DOjwatvCuH3rKicbQpJwEX3Bbcmv-NSgVZDae4dntgc89zbPbAg1zsqZDyHublVSK8m7i5CVLKiDvXdoWidNbY",
"destinationName": "Einwohnermeldeamt",
"destinationLogo": "https://einwohnermeldeamt.beispielstadt.example.org/logo.png"
}
]
}
```
:::tip Hinweis
Sofern eine Destination-ID und die Adresse des zuständigen Zustelldienstes bereits bekannt sind, können die in einem Zustellpunkt hinterlegten technischen Parameter auch über den Endpunkt <ApiLink api="submission-api" to="/v1/destinations/{destinationId}" /> der Submission API des zuständigen Zustelldienstes [abgerufen werden (siehe unten)](#submissionapi).
......@@ -242,8 +290,6 @@ Die vom DVDV gelieferten Daten enthalten den Zustellpunkt sowie dessen Signatur
Die `destinationParametersSignature` wird in der Routing API im gleichnamigen Feld und in der API des DVDV über den HTTP-Header `jws-signature` zurückgegeben.
Bei der Signatur handelt es sich um eine JSON Web Signature (JWS) in der Compact Serialization gemäß [RFC 7515, Abschnitt 3.1](https://datatracker.ietf.org/doc/html/rfc7515#section-3.1).
Die Signatur liegt als Detached Signature gemäß [RFC 7515, Anlage F](https://datatracker.ietf.org/doc/html/rfc7515#appendix-F) vor.
Bei einer Detached Signature sind die eigentlichen Inhaltsdaten (Payload) nicht Teil der übertragenen Signatur, sondern werden separat übermittelt.
Für eine Signaturprüfung müssen die separat übermittelten Inhaltsdaten (Payload) daher zunächst wieder zur Signatur hinzugefügt werden (siehe unten).
Beispiel eines Zustellpunktes (`destinationParameters`):
```json
......@@ -288,6 +334,9 @@ Beispiel eines Zustellpunktes (`destinationParameters`):
}
```
Bei einer Detached Signature sind die eigentlichen Inhaltsdaten (Payload) nicht Teil der übertragenen Signatur, sondern werden separat übermittelt.
Für eine Signaturprüfung müssen die separat übermittelten Inhaltsdaten (Payload) daher zunächst wieder zur Signatur hinzugefügt werden (siehe unten).
Beispiel einer Detached JWS (`destinationParametersSignature`):
```
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IjNTNjd6UVE3QWFMdHFuSkthV2Y3N0FjM1d3WTItTEtXVVZTM1dJRUsyY2sifQ..At8ecdCMaUHQIo-22FKHBIocZ7hFxIHQxo0u_61tMKvDUy_BStKt46Aqh7lt41OLfIwEu6b4ZjLmWTeMi5SV-KMEAdRnYp5_WAmVhJttDkpf3d32uBcql0xJChAd93mr4qUnMvo-p3ltYgiKkG6_IHt8lUPt6BaH_BqWvidmtM5_Hd1SyW92OkEm1d50eMIJMxwY2e7_4qGKWqnMTel-dmY4HXlfqwfkkwkfvzVxQgOLtw0pzPKx3qODxuiOx6CVzr_QTrs12ugt7YkVkXSuVT40vekPw006O6aDOyETITK6OmDGnAB3iRqEX_qcOco2GWT0o66J2IARbtd12Hd0OpI0seqLONmSGNxcIxMcQwp5SAQa92xKkGFHgW86zAi6DQGggAh-Pb7MMN-i20jv1iC5hEpcd_eSKFDAGp_paEJkjOy-WPyhsksssdpival9OkXCQmHQnGzqu-RS4CS5l3gkAL-q5HoZHGD-YbXaYXRac4nyCrvmYg5yDBFSOvi4v07bokXiIp52tVAhuagmishsIDPI52ke4hkhHP68mUIQaA8UBhekNxPoEpXWfNwBmJpMc4Aa17Ko5WGYPG01_w11EXZ2q80-T4eINWdfAZAhrrmJwSmPQwnsrnuwTTOpl89vSeXi17KM-VxAf9kGrvE5scAtwGEjTlr56LEUieI
......@@ -566,4 +615,4 @@ $ curl \
}
```
</TabItem>
</Tabs>
</Tabs>
\ No newline at end of file
......@@ -8,10 +8,10 @@ import Mermaid from '@site/src/components/Mermaid'
Bei einer Einreichung z.B. eines Antrags reicht ein Onlinedienst im Namen und Auftrag eines Endnutzers Fachdaten und/oder Anlagen bei einem Zustellpunkt ein.
Hierfür benötigt der Onlinedienst die öffentlich verfügbaren Informationen eines Zustellpunktes, wie beispielsweise die Zustellpunkt-Id (`destinationId`) oder den JWK des Zustellpunktes.
Wie der Zustellpunkt der zuständigen empfangenden Stelle technisch ermittelt wird ist unter [Zustellpunkt ermitteln](../responsibilities/get-destination.mdx) genauer beschrieben.
Wie der Zustellpunkt der zuständigen empfangenden Stelle technisch ermittelt wird ist unter [Zustellpunkt ermitteln](../sending/get-destination.mdx) genauer beschrieben.
FIT-Connect möchte einen sehr sicheren Übermittlungsweg bereitstellen, weswegen alle Daten immer Ende-zu-Ende-Verschlüsselt gemäß dem in [Verschlüsselte Übertragung von Antragsdaten](../getting-started/encryption.mdx) beschriebenen Vorgehen übertragen werden müssen.
Das dafür benötigte Schlüsselmaterial wird als Teil der technischen Informationen eines Zustellpunkts über die Submission API und Routing API bereitgestellt und unter [Zustellpunkt ermitteln](../responsibilities/get-destination.mdx) als Teil der Zustellpunktermittlung näher beschrieben.
Das dafür benötigte Schlüsselmaterial wird als Teil der technischen Informationen eines Zustellpunkts über die Submission API und Routing API bereitgestellt und unter [Zustellpunkt ermitteln](../sending/get-destination.mdx) als Teil der Zustellpunktermittlung näher beschrieben.
Während der Einreichung erhält man von der API eine `caseId`, mithilfe welcher man nach der Abgabe den Event Log der Einreichung abrufen kann.
Dieser Event Log enthält eine Liste von Ereignissen, ähnlich wie im Interface einer Paketverfolgung, mit denen der aktuelle Zustellungsstatus der Einreichung sowie aller zukünftig zu diesem Case hinzugehörigen Einreichungen transparent wird.
......
......@@ -19,7 +19,7 @@ Die UUIDs der Anlagen müssen eindeutig sein und werden vom sendenden System fes
Der Endpunkt erwartet folgende Parameter:
- Eine Destination-ID. Dies ist die eindeutige UUID des Zustellpunktes, an den die Einreichung vermittelt werden soll (`destinationId`). Im Artikel [Zustellpunkt Ermitteln](../responsibilities/get-destination.mdx) wird beschrieben wie diese ermittelt werden kann.
- Eine Destination-ID. Dies ist die eindeutige UUID des Zustellpunktes, an den die Einreichung vermittelt werden soll (`destinationId`). Im Artikel [Zustellpunkt Ermitteln](../sending/get-destination.mdx) wird beschrieben wie diese ermittelt werden kann.
- Die Liste der angekündigten Anlagen (`announcedAttachments`). Dies ist eine Liste der Attachment-IDs aller Anlagen, die mit der Einreichung hochgeladen werden sollen. Die Liste enthält [eine UUIDv4](https://de.wikipedia.org/wiki/Universally_Unique_Identifier#(Pseudo)zuf%C3%A4llig_generierte_UUIDs_(Version_4)) für jedes Attachment. Die UUIDs müssen vom sendenden System selbst generiert werden. Für alle `announcedAttachments` muss anschließend das jeweilige Attachment hochgeladen werden (siehe [Anlagen hochladen](./attachments.mdx), bevor sich die Einreichung im Schritt [Einreichung versenden](submit.mdx) abschließen lässt.
- Der Typ der Verwaltungsleistung (`serviceType`). Dies ist eine Beschreibung der Art der Verwaltungsleistung. Die angegebene Verwaltungsleistung muss der Verwaltungsleistung der Einreichung und einem der angebotenen Verwaltungsleistung des Zustellpunkts entsprechen. Für die jeweilige Verwaltungsleistung muss immer sowohl ein Name (`name`), als auch ein eindeutiger Identifier (`identifier`) angegeben werden. Der Identifier besteht aus einem einem Leistungsschlüssel und dem Präfix `urn:de:fim:leika:leistung:`. Ist für die gegebene Verwaltungsleistung kein Leistungsschlüssel vorhanden, kann die Verwaltungsleistung übergangsweise über die Angabe einer anderen eindeutigen Schema-URN beschrieben werden. Bestehende Leistungssschlüssel können [über das FIM-Portal](https://fimportal.de/) oder [über die LeiKa-Suche (inoffiziell)](https://opengovtech.de/leika/) ermittelt werden.
- Optional kann hier auch ein Callback hinterlegt werden, um Benachrichtigungen über neue Events der Einreichung zu erfahren. Näheres dazu wird im Artikel [Verwendung von Callbacks](../details/callbacks.mdx) beschrieben.
......
......@@ -13,10 +13,18 @@ module.exports = {
{
type: 'category',
label: 'Infos für Verantwortliche',
collapsed: true,
items: [
'organisation-tasks/publish_destination',
'organisation-tasks/register_onlineservice',
'organisation-tasks/apply-for-certificates',
{
type: 'category',
label: 'Fachverfahren anbinden',
collapsed: true,
items: [
'organisation-tasks/publish_destination',
'organisation-tasks/apply-for-certificates',
],
},
'organisation-tasks/register_onlineservice',
],
},
'changelog',
......@@ -45,9 +53,10 @@ module.exports = {
items: [
'sending/overview',
'sending/start-submission',
'sending/get-destination',
'sending/metadata',
'sending/encrypt',
'sending/attachments',
'sending/attachments',
'sending/submit',
'sending/query-status',
'sending/accept-reject',
......@@ -83,14 +92,6 @@ module.exports = {
'getting-started/rate-limiting',
],
},
{
type: 'category',
label: 'Zuständigkeitsermittlung',
items: [
'responsibilities/routing',
'responsibilities/get-destination'
]
},
{
type: 'category',
label: 'Weiterführende Informationen',
......
import React from 'react';
import {Redirect} from '@docusaurus/router';
export default function publish_destination() {
return (
<p>
<Redirect to="../../../docs/sending/get-destination" />
</p>
);
}
\ No newline at end of file
import React from 'react';
import {Redirect} from '@docusaurus/router';
export default function routing() {
return (
<p>
<Redirect to="../../../docs/organisation-tasks/publish_destination#signierte-adressierungsinformationen" />
</p>
);
}
\ No newline at end of file