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 (16)
Expand all Hide whitespace changes
Inline Side-by-side
Showing
with 2261 additions and 85 deletions
docs/changelog.md
View file @ 1a2ff8c6
# Changelog
Das Format dieser Datei basiert auf [Keep a Changelog](https://keepachangelog.com/de).
## 2022-02-03
### Zustelldienst 1.2.0
- Story: Der Zustelldienst schreibt nun zusätzliche Infos in die Events `submit-submission` und `notify-submission`.
Die Events enthalten jetzt eine Referenz (`$schema`) auf das zugehörige Schema.
([Story](https://git.fitko.de/fit-connect/planning/-/issues/210))
### Dokumentation
- Die [Beschreibung des Ereignisprotokolls](getting-started/event-log/overview.mdx) wurde in mehrere Seiten aufgeteilt.
- Die [Liste der Ereignisse](getting-started/event-log/events.mdx) wurde um die Beschreibung der Payloads erweitert.
- Umgang mit [Empfangsbestätigung oder Zurückweisung](sending/accept-reject.mdx) ergänzt.
- [Einreichung überprüfen](receiving/verification.mdx) ergänzt.
## 2022-01-19
### Dokumenation
- [Aufbau der Zustellpunkt-Informationen](responsibilities/get-destination.mdx#destination-object) überarbeitet
## 2022-01-17
### Dokumentation
- [Kontaktmöglichkeiten](/contact) überarbeitet
## 2022-01-11
### Dokumentation
- [Abschnitt zur Pflege der FIT-Connect „destinationSignatur“ in FIM-Redaktionssytemen](responsibilities/routing.mdx) 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`)
......
docs/details/destination-management.mdx
View file @ 1a2ff8c6
......@@ -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.
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).
### Beispiele
......
docs/getting-started/account.mdx
View file @ 1a2ff8c6
......@@ -5,7 +5,7 @@ import useBaseUrl from '@docusaurus/useBaseUrl';
Das **Self-Service-Portal** von FIT-Connect erlaubt es Ländern, Kommunen oder interessierten IT-Dienstleistern über eine grafische Oberfläche mit wenigen Klicks OAuth-API-Clients anzulegen und Zustellpunkte, auch **Destinations** genannt, für ihre bereits bestehenden Fachverfahren und Verwaltungsleistungen zu registrieren.
OAuth-API-Clients müssen für jedes an FIT-Connect angebundene System registriert werden.
Das [Anlegen eines Zustellpunktes](../receiving/destination.mdx) ist dagegen nur für empfangende Systeme (Subscriber) notwendig.
Zustellpunkte können dann im Rahmen von FIT-Connect über den Antrags-Routingdienst gefunden werden.
Zustellpunkte können dann im Rahmen von FIT-Connect über den Routingdienst gefunden werden.
**Testumgebung**: Das [Self-Service-Portal der Testumgebung](https://portal.auth-testing.fit-connect.fitko.dev/) steht allen Interessierten zur Registrierung von API-Clients für die Testinstanz des FIT-Connect Zustelldienstes zur Verfügung.
......
docs/getting-started/event-log/events.mdx 0 → 100644
View file @ 1a2ff8c6
---
title: Ereignisse
---
import ApiLink from '@site/src/components/ApiLink'
Das folgende Statusdiagramm zeigt die Status und Ereignisse einer Einreichung. Die Status sind als orange Ovale dargestellt.
Rechtecke stehen für Ereignisse. Blau dargestellte Ereignisse werden vom Zustelldienst, grüne vom empfangenden System erstellt und signiert.
![Statusdiagramm](/images/status/status.svg)
Das Akzeptieren oder Zurückweisen von Einreichungen auf einer rein technischen Ebene und trifft keine Aussage über die fachliche Korrektheit der Einreichungen.
Gründe für technische Rückweisungen wären beispielsweise Probleme bei der Entschlüsselung oder Validierungsfehler der Datenstrukturen.
In der folgenden Tabelle sind die möglichen Ereignisse, ihre Beschreibungen und die Autoren aufgeführt und beschrieben.
| Event | Autor | Bedeutung |
|------------------------------------------------------------------------------------------|---------------------|-------------------------------|
| `https://schema.fitko.de/fit-connect/events/create-submission` [↓](#create-submission) | Zustelldienst | Die Einreichung wurde durch den Sender angelegt. |
| `https://schema.fitko.de/fit-connect/events/submit-submission` [↓](#submit-submission) | Zustelldienst | Die Einreichung wurde durch den Sender abgesendet. |
| `https://schema.fitko.de/fit-connect/events/notify-submission` [↓](#notify-submission) | Zustelldienst | Der Empfänger wurde per Webhook über die Einreichung informiert. |
| `https://schema.fitko.de/fit-connect/events/forward-submission` [↓](#forward-submission) | Empfangendes System | Ein nachgelagertes System hat die Einreichung zur Weiterleitung übernommen. |
| `https://schema.fitko.de/fit-connect/events/reject-submission` [↓](#reject-submission) | Empfangendes System | Die Einreichung wurde durch den Empfänger zurückgewiesen. |
| `https://schema.fitko.de/fit-connect/events/accept-submission` [↓](#accept-submission) | Empfangendes System | Die Einreichung wurde durch den Empfänger akzeptiert. |
| `https://schema.fitko.de/fit-connect/events/delete-submission` [↓](#delete-submission) | Zustelldienst | Die Einreichung wurde durch den Zustelldienst gelöscht. |
## create-submission {#create-submission}
Mit dem Event `https://schema.fitko.de/fit-connect/events/create-submission` dokumentiert der Zustelldienst,
dass eine Einreichung angelegt wurde.
```json
{
"$schema": "https://schema.fitko.de/fit-connect/set-payload/1.0.0/set-payload.schema.json",
"jti": "ada1b5b4-1bd2-4fab-b236-c30ef88e8c72",
"iss": "https://submission-api-dev.fit-connect.fitko.dev",
"iat": 1622796532,
"sub": "submission:02bf1d9f-282d-4abf-810a-c4104baf0afe",
"txn": "case:452b5ee6-35df-441a-bd39-6141723cf914",
"events": {
"https://schema.fitko.de/fit-connect/events/create-submission": {
}
}
}
```
## submit-submission {#submit-submission}
Mit dem Event `https://schema.fitko.de/fit-connect/events/submit-submission` dokumentiert der Zustelldienst,
dass die Einreichung abgesendet wurde.
Das Event enthält das Objekt `authenticationTags`, das die Authentication Tags der verschlüsselten Inhalte enthält.
- `metadata`: Authentication Tag des Metadatensatzes
- `data`: Authentication Tag des Fachdatensatzes
- `attachments`: Objekt mit den Authentication Tags der Anlagen mit ihren `attachmentId`s als Schlüssel
```json
{
"$schema": "https://schema.fitko.de/fit-connect/set-payload/1.0.0/set-payload.schema.json",
"jti": "25d2eb77-458d-4c9d-991c-6428c4651646",
"iss": "https://submission-api-dev.fit-connect.fitko.dev",
"iat": 1622796532,
"sub": "submission:02bf1d9f-282d-4abf-810a-c4104baf0afe",
"txn": "case:452b5ee6-35df-441a-bd39-6141723cf914",
"events": {
"https://schema.fitko.de/fit-connect/events/submit-submission": {
"authenticationTags": {
"metadata": "XFBoMYUZodetZdvTiFvSkQ",
"data": "UCGiqJxhBI3IFVdPalHHvA",
"attachments": {
"0b799252-deb9-42b0-98d3-c50d24bbafe0": "rT99rwrBTbTI7IJM8fU3El",
"25abf553-0e53-43b9-a14a-1581b32a9ee5": "i7226HEB7IchCxNuh7lCiu",
"046a9fa5-bed6-494b-aab6-d41056c6db79": "d48LxeolRdtFF4nzQibeYO"
}
}
}
}
}
```
## notify-submission {#notify-submission}
Mit dem Event `https://schema.fitko.de/fit-connect/events/notify-submission` dokumentiert der Zustelldienst,
dass das empfangende System Kenntnis von der Einreichung erlangt hat.
Wie dies erfolgt ist, wird mit dem Eintrag `notifyType` dokumentiert.
1. `"notifyType": "callback"` - Der Subscriber wurde per Callback informiert.
```json
{
"$schema": "https://schema.fitko.de/fit-connect/set-payload/1.0.0/set-payload.schema.json",
"jti": "116c3c03-5f31-4d4c-9e65-d36e1e3895f7",
"iss": "https://submission-api-dev.fit-connect.fitko.dev",
"iat": 1622796532,
"sub": "submission:02bf1d9f-282d-4abf-810a-c4104baf0afe",
"txn": "case:452b5ee6-35df-441a-bd39-6141723cf914",
"events": {
"https://schema.fitko.de/fit-connect/events/notify-submission": {
"notifyType": "callback"
}
}
}
```
2. `"notifyType": "polling"` - Der Subscriber hat die Liste der Submission über <ApiLink api="submission-api" to="/v1/submissions " withMethod="get"/> abgerufen.
```json
{
"$schema": "https://schema.fitko.de/fit-connect/set-payload/1.0.0/set-payload.schema.json",
"jti": "6127ff87-2786-4d0f-90fe-c531672f5de1",
"iss": "https://submission-api-dev.fit-connect.fitko.dev",
"iat": 1622796532,
"sub": "submission:02bf1d9f-282d-4abf-810a-c4104baf0afe",
"txn": "case:452b5ee6-35df-441a-bd39-6141723cf914",
"events": {
"https://schema.fitko.de/fit-connect/events/notify-submission": {
"notifyType": "polling"
}
}
}
```
## forward-submission {#forward-submission}
Mit dem Event `https://schema.fitko.de/fit-connect/events/forward-submission` dokumentiert ein nachgelagertes System,
dass es die Einreichung zur Weiterleitung übernommen hat.
```json
{
"$schema": "https://schema.fitko.de/fit-connect/set-payload/1.0.0/set-payload.schema.json",
"jti": "c0cda2aa-bf79-4427-86f3-9f973bad2ecd",
"iss": "40847c29-06aa-40e2-bf28-c29884c694c4",
"iat": 1622796532,
"sub": "submission:02bf1d9f-282d-4abf-810a-c4104baf0afe",
"txn": "case:452b5ee6-35df-441a-bd39-6141723cf914",
"events": {
"https://schema.fitko.de/fit-connect/events/forward-submission": {
}
}
}
```
## reject-submission {#reject-submission}
Mit dem Event `https://schema.fitko.de/fit-connect/events/reject-submission` dokumentiert das empfangende System,
dass die Einreichung zurückgewiesen wird.
Das Event enthält ein Array `problems`, dass die Fehler der Einreichung dokumentiert.
Der Aufbau ist an [RFC 7807](https://datatracker.ietf.org/doc/html/rfc7807) angelehnt,
lässt jedoch den Status aus, weil hier kein passender HTTP Status Code angegeben werden kann.
- `type`: Fehlercode in Form einer URI.
- `title`: Für Menschen verständliche Fehlermeldung
- `detail`: Details zum Fehler, z.B. eine technische Fehlermeldung (optional)
- `instance`: Betroffener Teil der Übertragung.
Mögliche Werte: `submission`, `metadata`, `data`, `attachment:` + UUID des Attachments oder `other`
```json
{
"$schema": "https://schema.fitko.de/fit-connect/set-payload/1.0.0/set-payload.schema.json",
"jti": "4ac47caa-bce1-435a-b04f-3322b224b32e",
"iss": "40847c29-06aa-40e2-bf28-c29884c694c4",
"iat": 1622796532,
"sub": "submission:02bf1d9f-282d-4abf-810a-c4104baf0afe",
"txn": "case:452b5ee6-35df-441a-bd39-6141723cf914",
"events": {
"https://schema.fitko.de/fit-connect/events/reject-submission": {
"problems": [
{
"type": "https://schema.fitko.de/fit-connect/events/problems/authentication-tag-incorrect",
"title": "Das Authentication Tag des Metadatensatzes ist ungültig",
"detail": "Das Authentication Tag des Metadatensatzes stimmt nicht mit dem im Submit-Submission-Event angegebenen Wert überein.",
"instance": "metadata"
}
]
}
}
}
```
## accept-submission {#accept-submission}
Mit dem Event `https://schema.fitko.de/fit-connect/events/accept-submission` dokumentiert das empfangende System,
dass die Einreichung akzeptiert wurde.
Das Event muss eine mit dem [`submit-submission`](#submit-submission) Event übereinstimmende Liste von Authentication Tags enthalten.
Das empfangende System dokumentiert damit, dass es die Authentication Tags überprüft hat.
```json
{
"$schema": "https://schema.fitko.de/fit-connect/set-payload/1.0.0/set-payload.schema.json",
"jti": "8538165b-9ce3-4097-871d-5b9581a3b4d9",
"iss": "40847c29-06aa-40e2-bf28-c29884c694c4",
"iat": 1622796532,
"sub": "submission:F65FEAB2-4883-4DFF-85FB-169448545D9F",
"txn": "case:F73D30C6-8894-4444-8687-00AE756FEA90",
"events": {
"https://schema.fitko.de/fit-connect/events/accept-submission": {
"authenticationTags": {
"metadata": "XFBoMYUZodetZdvTiFvSkQ",
"data": "UCGiqJxhBI3IFVdPalHHvA",
"attachments": {
"0b799252-deb9-42b0-98d3-c50d24bbafe0": "rT99rwrBTbTI7IJM8fU3El",
"25abf553-0e53-43b9-a14a-1581b32a9ee5": "i7226HEB7IchCxNuh7lCiu",
"046a9fa5-bed6-494b-aab6-d41056c6db79": "d48LxeolRdtFF4nzQibeYO"
}
}
}
}
}
```
Sofern Probleme in der Einreichung gefunden wurden,
die jedoch nicht zu einer Zurückweisung geführt haben,
werden diese analog zu der `problems` Liste in [`reject-submission`](#reject-submission) dokumentiert.
```json
{
"$schema": "https://schema.fitko.de/fit-connect/set-payload/1.0.0/set-payload.schema.json",
"jti": "6872b19f-5ee2-47d7-a0e9-ebfe87ab2563",
"iss": "40847c29-06aa-40e2-bf28-c29884c694c4",
"iat": 1622796532,
"sub": "submission:F65FEAB2-4883-4DFF-85FB-169448545D9F",
"txn": "case:F73D30C6-8894-4444-8687-00AE756FEA90",
"events": {
"https://schema.fitko.de/fit-connect/events/accept-submission": {
"problems": [
{
"type": "https://schema.fitko.de/fit-connect/events/problems/schema-missing",
"title": "Schemareferenz fehlt im Metadatensatz",
"detail": "Die Referenz auf das Metadatenschema ('$schema') fehlt im Metadatensatz.",
"instance": "metadata"
}
],
"authenticationTags": {
"metadata": "XFBoMYUZodetZdvTiFvSkQ",
"data": "UCGiqJxhBI3IFVdPalHHvA",
"attachments": {
"0b799252-deb9-42b0-98d3-c50d24bbafe0": "rT99rwrBTbTI7IJM8fU3El",
"25abf553-0e53-43b9-a14a-1581b32a9ee5": "i7226HEB7IchCxNuh7lCiu",
"046a9fa5-bed6-494b-aab6-d41056c6db79": "d48LxeolRdtFF4nzQibeYO"
}
}
}
}
}
```
## delete-submission {#delete-submission}
Mit dem Event `https://schema.fitko.de/fit-connect/events/delete-submission` dokumentiert der Zustelldienst,
dass die Einreichung gelöscht wurde.
```json
{
"$schema": "https://schema.fitko.de/fit-connect/set-payload/1.0.0/set-payload.schema.json",
"jti": "29d091aa-86ab-4806-beb5-fb462d18e2a1",
"iss": "https://submission-api-dev.fit-connect.fitko.dev",
"iat": 1622796532,
"sub": "submission:02bf1d9f-282d-4abf-810a-c4104baf0afe",
"txn": "case:452b5ee6-35df-441a-bd39-6141723cf914",
"events": {
"https://schema.fitko.de/fit-connect/events/delete-submission": {
}
}
}
```
docs/getting-started/event-log/overview.mdx 0 → 100644
View file @ 1a2ff8c6
---
title: Überblick
---
Im Ereignisprotokoll (Event Log) werden relevante Ereignisse (events) aufgezeichnet.
Beim Abruf des Ereignisprotokolls liefert die API ein Array von JSON Web Token (JWT) gemäß [RFC 7519](https://datatracker.ietf.org/doc/html/rfc7519).
Der JWT ist einen Security-Event-Token (SET) gemäß [RFC 8417](https://datatracker.ietf.org/doc/html/rfc8417).
Wie mit den Security-Event-Token (SET) umgegangen wird, wird in diesem Abschnitt beschrieben.
## Hintergrund
Für die Übermittlung von Einreichungen zwischen Sendern und Empfängern soll gewährleistet werden, dass alle Schritte nachweissicher dokumentiert werden, um im Streitfall den Ablauf eines erfolgten Übermittlungsvorgang zweifelsfrei zu dokumentieren.
Zudem sollen diese Nachweise außerhalb der Submission API und der damit verbundenen Systeme genutzt werden können, damit diese Dritten einfach zur Verfügung gestellt werden können.
SETs erfüllen diese Anforderungen durch folgende Merkmale:
- Für jedes SET wird ein eindeutiger Herausgeber definiert (`iss`)
- Jedes SET kann eindeutig einem konkreten fachlichen Kontext zugeordnet werden (`sub`)
- Mehrere SETs aus unterschiedliche fachlichen Kontexten können zu einem gemeinsamen Vorgang zusammengeführt werden (`txn`)
- SETs können für unterschiedliche Ereignisse ausgeprägt werden und innerhalb dieser Ereignisse können Detailinformationen ergänzt werden, die diese Ereignisse näher beschreiben
- Über ein Zeitstempel (`iat`) können diese Ereignisse zudem konkreten Zeitpunkt zugeordnet werden
- Durch eine Signatur im JWS Format wird sichergestellt, dass alle SETs ihre Integrität erhalten und eindeutig dem Schlüsselinhaber als Ersteller zugeordnet werden können.
Die Nutzung ist aber nicht auf die Klärung von Streitigkeiten zu technischen Übermittlungen beschränkt. SETs können aufgrund dieser Merkmale unter anderem auch für folgende Zwecke genutzt werden:
- Als Auditinstrument, dass bei Prüfungen oder Sicherheitsvorfällen durch Dritte (bspw. Datenschutz- oder Sicherheitsbeauftragte) genutzt wird,
- oder als Nachweis für den Start von Fristen in Verwaltungsverfahren, die in der Regel dann beginnen, wenn eine zuständige Stelle Kenntnis von einer Einreichung hat oder wenn diese Einreichung in den Hoheitsbereich der empfangenden Stelle gelangt.
In der Submission API werden SETs durch den Zustelldienst und das empfangende System erstellt.
Während die SETs des Zustelldienstes dazu dienen, die korrekte Übermittlung an den Zustelldienst und die Inkenntnissetzung von empfangende Systemen über neue Einreichungen dokumentieren, sollen SETs des empfangenden Systems die Bestätigung oder Ablehnung der technische Verarbeitbarkeit einer Einreichung nachweisen.
docs/getting-started/event-log/set-creation.mdx 0 → 100644
View file @ 1a2ff8c6
---
title: Erzeugen eines Security-Event-Token (SET)
---
import Tabs from '@theme/Tabs'
import TabItem from '@theme/TabItem'
# Event
Je nach Event ist ein Payload für das Event vorgesehen.
Auf der Seite [Ereignisse](./events.mdx) finden Sie eine Liste der Ereignisse und deren Struktur.
Derzeit ist es weiterhin möglich, Events ohne Payload zu senden.
In diesem Fall darf kein Schema (`$schema`) angegeben werden.
## Event Payload
### Authentication Tags
Die Struktur der "Authentication Tags" sieht wie folgt aus.
```json
{
"authenticationTags": {
"metadata": "XFBoMYUZodetZdvTiFvSkQ",
"data": "UCGiqJxhBI3IFVdPalHHvA",
"attachments": {
"0b799252-deb9-42b0-98d3-c50d24bbafe0": "rT99rwrBTbTI7IJM8fU3El",
"25abf553-0e53-43b9-a14a-1581b32a9ee5": "i7226HEB7IchCxNuh7lCiu",
"046a9fa5-bed6-494b-aab6-d41056c6db79": "d48LxeolRdtFF4nzQibeYO"
}
}
}
```
Diese können Sie zum Beispiel wie folgt aufbauen.
<Tabs
defaultValue="java"
values={[
{ label: 'Java', value: 'java', },
{ label: 'C#', value: 'csharp', },
{ label: 'JavaScript', value: 'js', },
]
}>
<TabItem value="java">
```java
public Map<String, Object> toEventPayloadMap() {
final HashMap<String, Object> authenticationTags = new HashMap<>(3);
authenticationTags.put("metadata", metadata);
if (data != null) {
authenticationTags.put("data", data);
}
if (!attachments.isEmpty()) {
authenticationTags.put("attachments", Collections.unmodifiableMap(attachments));
}
return Map.of(
"authenticationTags",
authenticationTags
);
}
```
</TabItem>
<TabItem value="csharp">
```csharp
// TBD
```
</TabItem>
<TabItem value="js">
```js
// TBD
```
</TabItem>
</Tabs>
### Problems
Die Struktur der "Problems" sieht wie folgt aus.
```json
{
"problems": [
{
"type": "https://schema.fitko.de/fit-connect/events/problems/authentication-tag-incorrect",
"title": "Das Authentication Tag des Metadatensatzes ist ungültig",
"detail": "Das Authentication Tag des Metadatensatzes stimmt nicht mit dem im Submit-Submission-Event angegebenen Wert überein.",
"instance": "metadata"
}
]
}
```
Diese können Sie zum Beispiel wie folgt aufbauen.
<Tabs
defaultValue="java"
values={[
{ label: 'Java', value: 'java', },
{ label: 'C#', value: 'csharp', },
{ label: 'JavaScript', value: 'js', },
]
}>
<TabItem value="java">
```java
public Map<String, Object> toEventPayloadMap() {
final ArrayList<Map<String, Object>> problemList = new ArrayList<>();
for (Problem problem : problems) {
final HashMap<String, Object> problemMap = new HashMap<>(problem.getParameters());
final URI type = problem.getType();
if (type != null) {
problemMap.put("type", type);
}
final String title = problem.getTitle();
if (title != null) {
problemMap.put("title", title);
}
final StatusType status = problem.getStatus();
if (status != null) {
problemMap.put("status", status);
}
final String detail = problem.getDetail();
if (detail != null) {
problemMap.put("detail", detail);
}
final URI instance = problem.getInstance();
if (instance != null) {
problemMap.put("instance", instance);
}
problemList.add(problemMap);
}
return Map.of("problems", problemList);
}
```
</TabItem>
<TabItem value="csharp">
```csharp
// TBD
```
</TabItem>
<TabItem value="js">
```js
// TBD
```
</TabItem>
</Tabs>
## SET Claims
Der SET Payload ist wie folgt aufgebaut.
Die Elemente der obersten Ebene sind bei allen SETs vorhanden.
Der Claim `events` enthält als Schlüssel das eigentliche Event, das ggf. einen Payload (hier: `authenticationTags`) enthält.
:::info
Derzeit ist die Version 0.1.0 des SET-Payload-Schemas aktuell.
Die in den Beispielen genannte Version 1.0.0 wird im Zuge des Rückkanals veröffentlicht.
:::
```json
{
"$schema": "https://schema.fitko.de/fit-connect/set-payload/1.0.0/set-payload.schema.json",
"jti": "8538165b-9ce3-4097-871d-5b9581a3b4d9",
"iss": "40847c29-06aa-40e2-bf28-c29884c694c4",
"iat": 1622796532,
"sub": "submission:F65FEAB2-4883-4DFF-85FB-169448545D9F",
"txn": "case:F73D30C6-8894-4444-8687-00AE756FEA90",
"events": {
"https://schema.fitko.de/fit-connect/events/accept-submission": {
"authenticationTags": {
"metadata": "XFBoMYUZodetZdvTiFvSkQ",
"data": "UCGiqJxhBI3IFVdPalHHvA",
"attachments": {
"0b799252-deb9-42b0-98d3-c50d24bbafe0": "rT99rwrBTbTI7IJM8fU3El",
"25abf553-0e53-43b9-a14a-1581b32a9ee5": "i7226HEB7IchCxNuh7lCiu",
"046a9fa5-bed6-494b-aab6-d41056c6db79": "d48LxeolRdtFF4nzQibeYO"
}
}
}
}
}
```
## SET Header
Der Header eines SET enthält immer die gleichen drei Angaben.
```json
{
"typ", "secevent+jwt",
"kid", "{keyId}",
"alg", "PS512"
}
```
## SET erzeugen und signieren
<Tabs
defaultValue="java"
values={[
{ label: 'Java', value: 'java', },
{ label: 'C#', value: 'csharp', },
{ label: 'JavaScript', value: 'js', },
]
}>
<TabItem value="java">
Das Erzeugen eines SET besteht aus drei Schritten.
```java
public static SignedJWT buildEvent(String issuer, UUID caseId, UUID submissionId, FitConnectEvent event, Map<String, Object> payload, JWK jwk) {
try {
final FitConnectSET set = new FitConnectSET("" + issuer, "submission:" + submissionId, "case:" + caseId);
set.addEvent(event, payload);
return set.sign(jwk);
} catch (ParseException | JOSEException ex) {
throw new FitConnectClientException(ex.getMessage(), ex);
}
}
```
### SET anlegen
Im Konstruktor der Klasse `FitConnectSET` wird das `JWTClaimsSet` erzeugt.
Als Claim `events` wird eine später zu befüllende `Map` eingesetzt.
```java
public FitConnectSET(String issuer, String subject, String transactionId) {
UUID jti = UUID.randomUUID();
this.events = new HashMap<>();
this.claimsSet = new JWTClaimsSet.Builder()
.claim(CLAIM_SCHEMA, FitConnect.SET_PAYLOAD_SCHEMA_TO_USE)
.issuer(issuer)
.issueTime(new Date())
.jwtID(jti.toString())
.subject(subject)
.claim("events", events)
.claim("txn", transactionId)
.build();
}
```
### Event Payload hinzufügen
Im zweiten Schritt wird das Event, ggf. mit Payload hinzugefügt.
```java
public void addEvent(FitConnectEvent event, Map<String, Object> payload) {
if (signedJWT != null || event == null) {
throw new UnsupportedOperationException("Im aktuellen Zustand kann kein Event hinzugefügt werden.");
}
events.put(event.getFullName(), payload == null ? Collections.emptyMap() : payload);
}
```
### SET erstellen & signieren
Im letzten Schritt wird das SET erstellt und signiert.
```java
public SignedJWT sign(JWK key) throws JOSEException, ParseException {
JWSSigner signer = new RSASSASigner(key.toRSAKey());
JWSHeader header = JWSHeader.parse(Map.of(
"typ", HEADER_TYPE,
"kid", key.getKeyID(),
"alg", "PS512"
));
this.signedJWT = new SignedJWT(header, claimsSet);
signedJWT.sign(signer);
return signedJWT;
}
```
</TabItem>
<TabItem value="csharp">
```csharp
// TBD
```
</TabItem>
<TabItem value="js">
```js
// TBD
```
</TabItem>
</Tabs>
docs/getting-started/first-steps.mdx
View file @ 1a2ff8c6
# Erste Schritte
Im folgenden "Getting Started"-Guide wird beschrieben, wie die ersten Interaktionen mit FIT-Connect ablaufen und FIT-Connect integriert werden kann.
In den nächsten Abschnitten wird beschrieben, wie man sich [gegenüber FIT-Connect authentifiziert](./authentication.mdx), Daten für die Übertragung [ver- und entschlüsselt](./encryption.mdx) werden, sowie welche Schritte für das [Einreichen](./sending/overview.mdx) bzw. [Empfangen](./receiving/overview.mdx) von Einreichungen notwendig sind.
Im folgenden "Getting Started"-Guide wird beschrieben, wie die ersten Interaktionen mit FIT-Connect ablaufen und FIT-Connect in IT-Systeme zum Versand und Empfang von Antragsdaten integriert werden kann.
In den nächsten Abschnitten wird beschrieben, wie man sich [gegenüber FIT-Connect authentifiziert](./authentication.mdx), Daten für die Übertragung [ver- und entschlüsselt](./encryption.mdx) werden, sowie welche Schritte für das [Einreichen](./sending/overview.mdx) bzw. [Empfangen](./receiving/overview.mdx) von Einreichungen (Anträge oder Berichte) notwendig sind.
:::note Zielgruppe
Die folgenden Seiten beinhalten technische Details zur Umsetzung einer Anbindung an die FIT-Connect-Schnittstellen.
Zielgruppe sind vorrangig Entwickler:innen.
:::
Kern von FIT-Connect ist der Zustelldienst, der sendende und empfangende Systeme einer Einreichung verbindet.
Kern von FIT-Connect ist der Zustelldienst, der sendende und empfangende Systeme einer Einreichung verbindet. Über das [Self-Service-Portal](./account.mdx) können Zugänge zur FIT-Connect-Infrastruktur registriert werden.
Jedes empfangende System (Fachverfahren / virtuelle Poststelle) verfügt über einen oder mehrere Zustellpunkte (Destinations), an die Einreichungen (Anträge oder Berichte) gesendet werden.
Zustellpunkte können von empfangenden Systemen [über das Self-Service-Portal](./account.mdx) konfiguriert und von sendenden Systemen adressiert werden.
......@@ -18,6 +18,10 @@ Zustellpunkte können von empfangenden Systemen [über das Self-Service-Portal](
Für Anbindungstests in der Testumgebung können Sie die folgenden Links & Infos verwenden:
- Self-Service-Portal der Testumgebung: siehe [Accountregistrierung und Client-Verwaltung](./account.mdx)
- OAuth Token URL: `https://auth-testing.fit-connect.fitko.dev/token`
- Submission API: `https://submission-api-testing.fit-connect.fitko.dev`
- Routing API: `https://routing-api-testing.fit-connect.fitko.dev`
- [OAuth Token URL](./authentication.mdx): `https://auth-testing.fit-connect.fitko.dev/token`
- [Submission API](../apis/submission-api.mdx): `https://submission-api-testing.fit-connect.fitko.dev`
- [Routing API](../apis/routing-api.mdx): `https://routing-api-testing.fit-connect.fitko.dev`
:::tip Hinweis
Auf den folgenden Seiten stellen wir Code-Beispiele für die Anbindung von IT-Systemen an FIT-Connect zur Verfügung. Die Code-Beispiele veranschaulichen und vereinfachen die konkrete Implementierung der Nutzung der Programmierschnittstellen (APIs) von FIT-Connect. Diese Schnittstellen basieren auf gängigen offenen Standards und ermöglichen auch über die bereitgestellten Code-Beispiel hinaus eine Anbindung an FIT-Connect mit allen gängigen Programmiersprachen.
:::
docs/getting-started/schema-validation.mdx
View file @ 1a2ff8c6
......@@ -26,13 +26,13 @@ Das Validierungsvorgehen wird im folgenden Anhand von Bespielen für FIM- und X
### Details zur Prüfung eines FIM-Fachdatensatzes (JSON Schema) {#fim-json}
:::caution
Das FITKO Schemarepository ist derzeit noch in Vorbereitung.
Das [FITKO-Schemarepository](https://schema.fitko.de/) ist derzeit noch in Vorbereitung.
Daher können die Fachschemata noch nicht wie beschrieben heruntergeladen werden.
Die JSON-Variante des FIM Fachdatensatzes befindet sich ebenfalls noch in der Konzeption und kann noch nicht genutzt werden.
:::
Die FIM-Fachschemata werden im FITKO Schemarepository (`https://schema.fitko.de/`) abgelegt.
Die FIM-Fachschemata werden im [FITKO-Schemarepository](https://schema.fitko.de/) abgelegt.
Die Fachschemareferenz gibt an, welches Schema zu beziehen ist.
```json
......@@ -46,7 +46,7 @@ Die Fachschemareferenz gibt an, welches Schema zu beziehen ist.
}
```
- Prüfen Sie, dass die `schemaUri` mit `https://schema.fitko.de/fim/` beginnt. Dies stellt sicher, dass das Fachschema aus dem FITKO Repository bezogen wird.
- Prüfen Sie, dass die `schemaUri` mit `https://schema.fitko.de/fim/` beginnt. Dies stellt sicher, dass das Fachschema aus dem FITKO-Schemarepository bezogen wird.
- Laden Sie das Fachschema herunter
```
......@@ -58,7 +58,7 @@ Die Fachschemareferenz gibt an, welches Schema zu beziehen ist.
### Details zur Prüfung eines FIM Fachdatensatzes (XML Schema) {#fim-xml}
Die Fachschemata im FIM XML Übertragungsformat (XFall) können über das FIM-Portal bezogen werden.
Zukünftig werden sie auch über das FITKO Schemarepository zur Verfügung stehen.
Zukünftig werden sie auch über das FITKO-Schemarepository zur Verfügung stehen.
```json
"contentStructure": {
......
docs/getting-started/submission/data.mdx
View file @ 1a2ff8c6
......@@ -4,3 +4,7 @@
Das Thema der Fachdaten hinsichtlich ihres Aufbaus und Verwendung wird hier in Zukunft beschrieben.
Daher ist der Artikel aktuell noch in Bearbeitung.
:::
Weitere Informationen zur Validierung eines Fachdatensatzes finden sich im Artikel [Schemavalidierung](../schema-validation.mdx).
Eine Erläuterung der Fachschemareferenzen für die gängigsten Fachstandards der Verwaltung findet sich im Artikel [Fachschemarefenzen auf Fachstandards und Rahmenwerke abbilden](/details/schema-reference.md).
docs/getting-started/submission/metadata.mdx
View file @ 1a2ff8c6
......@@ -2,17 +2,21 @@
title: Metadatensatz
---
Die Antragsmetadaten beschreiben die Struktur der Einreichung und dessen Inhalte, wie beispielsweise Anhänge oder die
Fachdaten. Zusätzlich können weitere Informationen über Verwaltungskund:innen hinterlegt werden. Eine genaue Definition
ist in der [Schema-Beschreibung](../../metadata/schema.mdx) zu finden. Im Folgenden wird nun beschrieben, wie für das
Versenden einer Einreichung das Schema aufgebaut und befüllt wird.
Die Antragsmetadaten beschreiben die Struktur der Einreichung und dessen Inhalte, wie beispielsweise Anhänge oder die Fachdaten.
Zusätzlich können weitere Informationen über Verwaltungskund:innen hinterlegt werden.
Eine genaue Definition ist in der [Schema-Beschreibung](../../metadata/schema.mdx) zu finden.
Im Folgenden wird nun beschrieben, wie für das Versenden einer Einreichung das Schema aufgebaut und befüllt wird.
Das Minimum, was an Information in den Metadaten vorhanden sein muss, sind die Felder `authenticationInformation` und `contentStructure`.
In der Beschreibung der Struktur (`contentStructure`) muss angegeben werden, ob und in welchem Format ein Fachdatensatz
mit versendet wird. Des Weiteren können Anhänge mit ihren Metainformationen beschrieben werden, die der Einreichung
beigefügt sind. Sollte ein Rückkanal gewünscht sein oder Bezahlinformationen notwendig sein, können die weiteren Felder,
die im Metadatenschema definiert sind, befüllt und mitversendet werden. Ob diese jedoch ausgewertet werden oder nicht
hängt u. a. von der vom Empfängers unterstützten Version des Metadatenschemas ab.
Das Minimum, was an Information in den Metadaten vorhanden sein muss, ist der Abbschnitt `contentStructure`.
In der Beschreibung der Struktur der Einreichung (`contentStructure`) muss angegeben werden, ob und in welchem Format ein Fachdatensatz mit versendet wird.
Des Weiteren können Anhänge mit ihren Metainformationen beschrieben werden, die der Einreichung
beigefügt sind.
Sollte ein Rückkanal gewünscht sein oder Bezahlinformationen notwendig sein, können die weiteren Felder, die im Metadatenschema definiert sind, befüllt und mitversendet werden.
Ob diese jedoch ausgewertet werden oder nicht hängt u. a. von der vom Empfängers unterstützten Version des Metadatenschemas ab.
:::tip Hinweis
Die einzelnen Abschnitte des Metadatensatzes werden im eigenständigen Abschnitt [Metadatensatz](../../metadata/overview.mdx) näher beschrieben.
:::
Ein Beispiel für das Metadatenschema eines Kindergeldantrags ist unten dargestellt:
......
docs/getting-started/submission/structure.mdx
View file @ 1a2ff8c6
......@@ -65,7 +65,7 @@ Die Fachschemareferenz ist im Zustellpunkt daher immer einer dazugehörigen Leis
```
Wenn ein sendendes System die Angaben eines Zustellpunkts ermittelt (bspw. über <ApiLink api="submission-api" to="/v1/destinations/{destinationId}" /> oder zukünftig die Routing API), 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](../../responsibilities/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?
......@@ -97,4 +97,4 @@ Es wird für sendende Systeme empfohlen, auf den Versand eigener proprietärer A
## Meine Software übermittelt oder empfängt nach Standard XYZ Fachdatensätze, wie kann ich das jeweils genutzte Fachschema korrekt referenzieren?
Eine Erläuterung der Fachschemareferenzen für die gängigsten Fachstandards der Verwaltung findet sich [hier](/details/schema-reference.md).
Eine Erläuterung der Fachschemareferenzen für die gängigsten Fachstandards der Verwaltung findet sich im Artikel [Fachschemarefenzen auf Fachstandards und Rahmenwerke abbilden](/details/schema-reference.md).
docs/glossary.md
View file @ 1a2ff8c6
......@@ -24,7 +24,7 @@ hide_table_of_contents: true
| FIM | Föderales Informationsmanagement, bestehend aus den Bausteinen *FIM Leistungen* (siehe *Leistungsschlüssel*), FIM Datenfelder (siehe *Fachschema*) und FIM Prozesse (Prozessabbildungen zu einer Leistungserbringung). Weiterführende Informationen finden sich im [FIM-Portal](https://fimportal.de/) |
| Gebiet (area) | Eine räumlich abgegrenzte Fläche, z.B. ein Postleitzahlenbereich, ein Naturschutzgebiet oder eine Region im Sinne des Amtlichen Regionalschlüssels (siehe *Region*). |
| Kommunikationskanal (communication channel) | Beschreibt einen Kommunikationskanal, um zwischen der zuständigen Fachbehörde und der Verwaltungskund:in zu digital zu kommunizieren. Kommunikationskanäle können sein: <ul> <li>E-Mail</li> <li>De-Mail</li> <li>FIT-Connect Rückkanal</li> <li>Interoperable Postfächer (FINK)</li> <li>Elster-Transfer des einheitlichen Unternehmenskontos</li> </ul>Eine zuständige Fachbehörde kommuniziert über den Zustellpunkt, welche Kommunikationskanäle unterstützt werden und die Verwaltungskund:in legt fest, welche Kommunikationskanäle genutzt werden sollen. Für die Adressierung der Verwaltungskund:in werden alle für den Kommunikationskanal notwendigen Verbindungs- und Adressierungsparameter (einschließlich ggf. notwendiger Schlüssel/Zertifikate) im Metadatensatz übertragen. |
| Leistungsschlüssel, ehemals *LeiKa-Schlüssel* | Eindeutige Kennung einer Verwaltungsleistung aus dem FIM-Baustein Leistungen (beginnt immer mit `99`). Der Leistungsschlüssel wird im Leistungskatalog der öffentlichen Verwaltung (LeiKa) definiert. Der *Leistungsschlüssel*/*LeiKa-Schlüssel* ist abzugrenzen von der LeiKa-intern verwendeten *LeiKa-ID*, die im Projekt FIT-Connect keine Anwendung findet. Siehe auch: *Leistungs-ID* |
| Leistungsschlüssel, ehemals *LeiKa-Schlüssel* | Eindeutige Kennung einer Verwaltungsleistung aus dem FIM-Baustein Leistungen (beginnt immer mit `99`). Der Leistungsschlüssel wird im Leistungskatalog der öffentlichen Verwaltung (LeiKa) definiert. Der *Leistungsschlüssel*/*LeiKa-Schlüssel* ist abzugrenzen von der LeiKa-intern verwendeten *LeiKa-ID*, die im Projekt FIT-Connect keine Anwendung findet. Weitere Informationen finden sich im [FIM-Portal](https://fimportal.de/). Siehe auch: *Leistungs-ID* |
| Leistungs-ID | Eindeutige Kennung einer Verwaltungsleistung. Eine Identifikation des Leistungen erfolgt über eine aus einem Leistungsschlüssel abgeleitete eindeutige URN (z.B. `urn:de:fim:leika:leistung:99010003001006`) |
| Metadatensatz (metadata) | Ein Metadatensatz beschreibt: <ul> <li>Fachunabhängige Metadaten der Einreichung: Authentifizierung des Autors einer Einreichung oder Berichts (bspw. über einen eID-Laufzettel, Identification 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 und Einreichungsbestandteile.</li> </ul> |
| Region (region) | Eine verwaltungspolitische Region (Gebietskörperschaften) im Sinne des Amtlichen Regionalschlüssels (ARS). Regionen werden in FIT-Connect durch Angabe eines ARS mit vorangestelltem Präfix `DE` identifiziert. Z.B. `DE081150045045`. Siehe auch: *Gebiet* |
......
docs/intro.mdx
View file @ 1a2ff8c6
......@@ -55,14 +55,14 @@ Fragt nun ein sendendes System über die Routing API an, ermittelt der FIT-Conne
### Anwendungsfall 3: Übermittlung von Einreichungen (Anträge oder Berichtsmeldungen)
Über den **FIT-Connect Zustelldienst** können sendende Systeme Einreichungen [an die zuvor ermittelte fachlich zuständige Behörde senden](./sending/overview.mdx).
Der Zustelldienst stellt hierfür die **Submission API** bereit. Sendende Systeme können sich über eine erfolgreiche Zustellung über ein [Ereignisprotokoll (Event Log)](./getting-started/event-log.mdx) informieren.
Der Zustelldienst stellt hierfür die **Submission API** bereit. Sendende Systeme können sich über eine erfolgreiche Zustellung über ein [Ereignisprotokoll (Event Log)](./getting-started/event-log/overview.mdx) informieren.
Die Vertraulichkeit der Übermittlung ist dank der [obligatorischen Ende-zu-Ende-Verschlüsselung](./getting-started/encryption.mdx) für alle übermittelten Daten jederzeit gewährleistet. Die eingesetzte Ende-zu-Ende-Verschlüsselung stellt sicher, dass auch die Betreiber der FIT-Connect-Infrastruktur zu keinem Zeitpunkt Zugriff auf die Inhalte der übermittelten Einreichungen erlangen können. Mit FIT-Connect ist eine Realisierung einer Ende-zu-Ende-Verschlüsselung bis in den Browser oder das Endgerät der Antrag- oder Berichtssteller:in möglich.
### Anwendungsfall 4: Abruf von Einreichungen (Anträge oder Berichtsmeldungen)
Empfangende Systeme werden durch den **FIT-Connect Zustelldienst** [über eingegangene Einreichungen informiert](./receiving/notification.mdx). Anschließend können empfangende Systeme diese Einreichungen über die **Submission API** [abrufen](./receiving/overview.mdx).
Nach dem Abruf ist der Versand einer Empfangsbestätigung über das [Ereignisprotokoll](./getting-started/event-log.mdx) möglich. So können empfangende Systeme den Eingang von Einreichungen nachweisbar bestätigen.
Nach dem Abruf ist der Versand einer Empfangsbestätigung über das [Ereignisprotokoll](./getting-started/event-log/events.mdx) möglich. So können empfangende Systeme den Eingang von Einreichungen nachweisbar bestätigen.
## Für wen ist die föderale Antragsdatenübermittlungsinfrastruktur FIT-Connect gedacht und warum sollte ich sie nutzen?
......
docs/metadata/overview.mdx
View file @ 1a2ff8c6
# Metadatensatz
Metadaten sind ein zentraler Bestandteil einer Einreichung. Sie beschreiben die Struktur der Einreichung und deren
Inhalte, wie beispielsweise Anlagen oder die Fachdaten. Zusätzlich können weitere Informationen über d:ie Verwaltungskund:in
hinterlegt werden. Eine genaue Definition ist in der [Schema-Definition](../metadata/schema.mdx)
zu finden. Im Folgenden werden nun die großen Bereiche, die im Metadatenschema aufgeführt werden, grob beschrieben.
Metadaten sind ein zentraler Bestandteil einer Einreichung.
Sie beschreiben die Struktur der Einreichung und deren Inhalte, wie beispielsweise Anlagen oder die Fachdaten.
Zusätzlich können weitere Informationen über d:ie Verwaltungskund:in hinterlegt werden.
Eine genaue Definition ist in der [Schema-Definition](../metadata/schema.mdx) zu finden.
Im Folgenden werden nun die großen Bereiche, die im Metadatenschema aufgeführt werden, grob beschrieben.
:::note Beispiele
Ein Beispiel für den Metadatensatz eines Kindergeldantrags findet sich in der [Dokumentation für sendende Systeme](../getting-started/submission/metadata.mdx)
:::tip Hinweis
Ein Beispiel für den Metadatensatz eines Kindergeldantrags findet sich in der [Dokumentation zum Aufbau einer Einreichung](../getting-started/submission/metadata.mdx)
:::
Das Metadaten-Schema validiert gegen und orientiert sich an der [JSON Schema Spezifikation 2020-12](https://json-schema.org/specification-links.html#2020-12)
in der Version von 2020. Es besteht primär aus den fünf Bereichen Authentifizierungsinformationen, Inhaltsstruktur,
Bezahlinformationen, Verwaltungsleistung und Rückkanal.
Das Metadaten-Schema validiert gegen und orientiert sich an der [JSON Schema Spezifikation 2020-12](https://json-schema.org/specification-links.html#2020-12) in der Version von 2020.
Es besteht primär aus den fünf Bereichen Authentifizierungsinformationen, Inhaltsstruktur, Bezahlinformationen, Verwaltungsleistung und Rückkanal.
```json
{
......
docs/receiving/process-and-acknowledge.mdx
View file @ 1a2ff8c6
......@@ -9,7 +9,7 @@ import TabItem from '@theme/TabItem'
Der letzte Schritt zum Empfang einer Einreichung ist die Bestätigung des Empfangs und damit auch der Gültigkeit der Einreichung.
Mit Gültigkeit ist hier gemeint, dass alle Informationen erfolgreich heruntergeladen, entschlüsselt und im Falle der Metadaten validiert werden konnten.
Wie auf der [Event Log Übersichtsseite](../getting-started/event-log.mdx#events) zu sehen, gibt es für ein empfangendes System ein festes Set an Events, die dem Zustelldienst gesendet werden können.
Wie auf der [Event Log Übersichtsseite](../getting-started/event-log/events.mdx) zu sehen, gibt es für ein empfangendes System ein festes Set an Events, die dem Zustelldienst gesendet werden können.
| Event | Autor | Bedeutung |
|-----------------------------------------------------------------|---------------------|-------------------------------|
......
docs/receiving/verification.mdx 0 → 100644
View file @ 1a2ff8c6
---
title: Einreichung überprüfen
---
import ApiLink from '@site/src/components/ApiLink'
import Tabs from '@theme/Tabs'
import TabItem from '@theme/TabItem'
Nachdem das empfangende System eine Einreichung empfangen hat, muss es diese überprüfen.
Nach der Überprüfung muss entweder ein Empfangsbestätigung ("accept submission") oder Zurückweisung ("reject submission")
gesendet werden.
Eine Rückweisung könnte wie folgt aussehen.
```json
{
"$schema": "https://schema.fitko.de/fit-connect/set-payload/1.0.0/set-payload.schema.json",
"jti": "4ac47caa-bce1-435a-b04f-3322b224b32e",
"iss": "40847c29-06aa-40e2-bf28-c29884c694c4",
"iat": 1622796532,
"sub": "submission:02bf1d9f-282d-4abf-810a-c4104baf0afe",
"txn": "case:452b5ee6-35df-441a-bd39-6141723cf914",
"events": {
"https://schema.fitko.de/fit-connect/events/reject-submission": {
"problems": [
{
"type": "https://schema.fitko.de/fit-connect/events/problems/an-example",
"title": "Nur ein Beispiel",
"detail": "Es darf kein Beispiel verwendet werden.",
"instance": "metadata"
}
]
}
}
}
```
Die grundsätzliche Struktur der Events ist auf der Seite [Ereignisse](../getting-started/event-log/events.mdx) beschreiben.
Das `reject-submission`-Event enthält eine Liste von Problemen.
Diese enthält im obigen Beispiel ein Beispiel-Problem.
```json
{
"type": "https://schema.fitko.de/fit-connect/events/problems/an-example",
"title": "Nur ein Beispiel",
"detail": "Es darf kein Beispiel verwendet werden.",
"instance": "metadata"
}
```
In der folgenden Liste der durchzuführenden Validierungen sind die zu verwendenden Werte für `type`, `title`, `detail`
und `instance` angegeben.
Die Angaben `type` und `instance` MÜSSEN exakt übernommen werden.
Die Angabe unter `title` SOLLTE wie dokumentiert übernommen werden.
Die Angabe `detail` KANN ergänzt oder ersetzt werden, sofern zur Fehlerbehebung hilfreiche Informationen zur Verfügung
stehen.
:::caution Hinweis
Alle Informationen im Problem-Datensatz werden an das sendende System gesendet, das sie zur Fehlerbehebung speichert.
Die Fehlermeldungen dürfen den Nutzern des Systems (z.B. Bürgern, die einen Online-Antrag nutzen) nicht angezeigt werden!
:::
## Überprüfung der Einreichung
### Überprüfung des Event-Logs
Rufen Sie das Event-Log unter <ApiLink api="submission-api" withMethod="get" to="/v1/cases/{caseId}/events" /> ab.
Prüfen Sie die Events gemäß der Seite [Prüfung eines Security-Event-Token (SET)](../getting-started/event-log/set-validation.mdx).
```json
{
"type": "https://schema.fitko.de/fit-connect/events/problems/invalid-event-log",
"title": "Inkonsistentes Event-Log",
"detail": "Das Event-Log ist inkonsistent.",
"instance": "submission"
}
```
### Genau ein Submit-Event
Das Event-Log muss genau ein Event `submit-submission` für die betreffende Einreichung enthalten.
```json
{
"type": "https://schema.fitko.de/fit-connect/events/problems/invalid-event-log",
"title": "Inkonsistentes Event-Log",
"detail": "Das Event-Log ist inkonsistent, da es nicht genau ein Event 'submit-submission' enthält.",
"instance": "submission"
}
```
### Authentication-Tags im Submit-Event
Das Submit-Submission-Event muss einen Payload `authenticationTags` enthalten.
```json
{
"type": "https://schema.fitko.de/fit-connect/events/problems/missing-authentication-tags",
"title": "Fehlende Authentication-Tags",
"detail": "Das Event 'submit-submission' enthält keine Authentication-Tags.",
"instance": "submission"
}
```
### Liste der Anlagen abgleichen
Die UUIDs der Anlagen in der Submission müssen den Schlüsseln der Anlagen in den Authentication-Tags entsprechen.
```json
{
"type": "https://schema.fitko.de/fit-connect/events/problems/attachments-mismatch",
"title": "Fehlerhafte Anlagen-Liste",
"detail": "Die Liste der Anlagen in Submission und Event-Log stimmt nicht überein.",
"instance": "submission"
}
```
## Überprüfung des Metadatensatzes
### Authentication-Tag prüfen
Stimmt der Authentication-Tag des Metadatensatzes (submission/encryptedMetadata) mit dem im Submit-Submission-Event (authenticationTags/metadata) überein?
```json
{
"type": "https://schema.fitko.de/fit-connect/events/problems/incorrect-authentication-tag",
"title": "Authentication-Tag ungültig",
"detail": "Das Authentication-Tag des Metadatensatzes ist ungültig.",
"instance": "metadata"
}
```
### Entschlüsselung
Kann der Metadatensatz (submission/encryptedMetadata) entschlüsselt werden?
```json
{
"type": "https://schema.fitko.de/fit-connect/events/problems/encryption-issue",
"title": "Entschlüsselungs-Fehler",
"detail": "Die Entschlüsselung des Metadatensatzes ist fehlgeschlagen.",
"instance": "metadata"
}
```
Sofern ein falscher oder veralteter Schlüssel verwendet wurde,
der Metadatensatz aber dennoch entschlüsselt werden konnte,
sollte Verarbeitung fortgesetzt werden, aber eine entsprechende Meldung erfolgen.
```json
{
"type": "https://schema.fitko.de/fit-connect/events/problems/encryption-issue",
"title": "Entschlüsselungs-Fehler",
"detail": "Der Schlüssel {kid} ist nicht der zu diesem Zweck vorgesehene Schlüssel.",
"instance": "metadata"
}
```
### Syntax-Validierung
Ist der Metadatensatz valides JSON?
```json
{
"type": "https://schema.fitko.de/fit-connect/events/problems/syntax-violation",
"title": "Syntax-Fehler",
"detail": "Der Metadatensatz ist kein valides JSON.",
"instance": "metadata"
}
```
### Schema-Referenz
Enthält der Metadatensatz einen Eintrag `$schema`?
```json
{
"type": "https://schema.fitko.de/fit-connect/events/problems/missing-schema",
"title": "Schema-Referenz fehlt",
"detail": "Die Schema-Referenz fehlt im Metadatensatz.",
"instance": "metadata"
}
```
### Metadatenschema
Entspricht die angegebene URI einem gültigen Metadatenschema?
Wird die verwendete Version des Metadatenschemas unterstützt?
```json
{
"type": "https://schema.fitko.de/fit-connect/events/problems/unsupported-schema",
"title": "Metadatenschema nicht unterstützt",
"detail": "Die angegebene Metadatenschema-URI ('$schema') ist keines der unterstützten Metadatenschemas.",
"instance": "metadata"
}
```
### Schema-Prüfung
Ist der Metadatensatz valide bezüglich des verwendeten Metadatenschemas?
```json
{
"type": "https://schema.fitko.de/fit-connect/events/problems/schema-violation",
"title": "Schema-Fehler",
"detail": "Der Metadatensatz ist nicht schema-valide.",
"instance": "metadata"
}
```
### Verwaltungsleistung abgleichen (I)
Stimmt der Identifier des Metadatensatzes `publicServiceType/identifier`
mit dem der Submission `serviceType/identifier` überein?
Die Verwarbeitung sollte mit dem `identifier` aus dem Metadatensatz fortgesetzt werden.
```json
{
"type": "https://schema.fitko.de/fit-connect/events/problems/service-mismatch",
"title": "Verwaltungsleistung stimmt nicht überein",
"detail": "Die Verwaltungsleistung in Submission und Metadatensatz stimmen nicht überein.",
"instance": "metadata"
}
```
### Verwaltungsleistung abgleichen (II)
Stimmt der Identifier unter `publicServiceType/identifier` mit einem der
Identifier der Destination unter `services[]/identifier` überein?
```json
{
"type": "https://schema.fitko.de/fit-connect/events/problems/unsupported-service",
"title": "Verwaltungsleistung nicht unterstützt",
"detail": "Die angegebene Verwaltungsleistung wird nicht unterstützt.",
"instance": "metadata"
}
```
### Fachdatensatz
Enthält die Einreichung einen Fachdatensatz?
```json
{
"type": "https://schema.fitko.de/fit-connect/events/problems/missing-data",
"title": "Fachdatensatz fehlt",
"detail": "Der Fachdatensatz fehlt.",
"instance": "metadata"
}
```
### Fachdatenschema
Stimmt das ausgewählte Fachdatenschema mit einem der angebotenen überein?
Die Angabe `contentStructure/data/schema` muss mit einem Eintrag unter `submissionSchemas[]`
des ausgewählten Services (siehe oben) übereinstimmen.
Die Verarbeitung sollte ohne Prüfung des Fachdatenschemas fortgeführt werden.
```json
{
"type": "https://schema.fitko.de/fit-connect/events/problems/unsupported-schema",
"title": "Fachdatenschema nicht unterstützt",
"detail": "Das angegebene Fachdatenschema wird nicht unterstützt.",
"instance": "metadata"
}
```
### Liste der Anlagen abgleichen
Stimmt die Liste der Anlagen in der Submission mit den Anlagen im Metadatensatz überein?
```json
{
"type": "https://schema.fitko.de/fit-connect/events/problems/attachments-mismatch",
"title": "Fehlerhafte Anlagen-Liste",
"detail": "Die Liste der Anlagen in Submission und Metadatensatz stimmt nicht überein.",
"instance": "metadata"
}
```
### Rückkanal
Entspricht der gewählte Rückkanal einem der angebotenen Kanäle?
Die Angabe keines Rückkanals ist immer gültig, auch wenn Rückkanäle angeboten werden.
Die Angabe des falschen Rückkanals sollte ignoriert und die Verarbeitung ohne Rückkanal fortgesetzt werden.
Es wird daher der postalische Weg als Fallback genutzt.
```json
{
"type": "https://schema.fitko.de/fit-connect/events/problems/unsupported-reply-channel",
"title": "Rückkanal nicht unterstützt",
"detail": "Der gewählte Rückkanal wird nicht unterstützt.",
"instance": "metadata"
}
```
## Überprüfung des Fachdatensatzes
### Authentication-Tag prüfen
Stimmt das Authentication-Tag mit dem im Submit-Submission-Event überein?
```json
{
"type": "https://schema.fitko.de/fit-connect/events/problems/incorrect-authentication-tag",
"title": "Authentication-Tag ungültig",
"detail": "Das Authentication-Tag des Fachdatensatzes ist ungültig.",
"instance": "data"
}
```
### Entschlüsselung
Kann der Fachdatensatz entschlüsselt werden?
```json
{
"type": "https://schema.fitko.de/fit-connect/events/problems/encryption-issue",
"title": "Entschlüsselungs-Fehler",
"detail": "Der Fachdatensatz konnte nicht entschlüsselt werden.",
"instance": "data"
}
```
Sofern ein falscher oder veralteter Schlüssel verwendet wurde,
der Fachdatensatz aber dennoch entschlüsselt werden konnte,
sollte Verarbeitung fortgesetzt werden, aber eine entsprechende Meldung erfolgen.
```json
{
"type": "https://schema.fitko.de/fit-connect/events/problems/encryption-issue",
"title": "Entschlüsselungs-Fehler",
"detail": "Der Schlüssel {kid} ist nicht der zu diesem Zweck vorgesehene Schlüssel.",
"instance": "data"
}
```
### Hash-Prüfung
Passt der Hash im Metadatensatz zu den entschlüsselten Daten?
```json
{
"type": "https://schema.fitko.de/fit-connect/events/problems/hash-mismatch",
"title": "Prüfsumme stimmt nicht",
"detail": "Die Prüfsumme des Fachdatensatzes stimmt nicht.",
"instance": "data"
}
```
### Syntax-Validierung
Handelt es sich beim Fachdatensatz um valides JSON bzw. XML gemäß dem MIME-Type im Schema?
```json
{
"type": "https://schema.fitko.de/fit-connect/events/problems/syntax-violation",
"title": "Syntax-Fehler",
"detail": "Der Fachdatensatz ist kein valides JSON.",
"instance": "data"
}
```
```json
{
"type": "https://schema.fitko.de/fit-connect/events/problems/syntax-violation",
"title": "Syntax-Fehler",
"detail": "Der Fachdatensatz ist kein valides XML.",
"instance": "data"
}
```
### Schema-Prüfung
Ist der Fachdatensatz valide bezüglich des verwendeten Fachdatenschemas?
Falls die Abweichung nicht zu groß ist, sollte die Verarbeitung fortgesetzt werden.
```json
{
"type": "https://schema.fitko.de/fit-connect/events/problems/schema-violation",
"title": "Schema-Fehler",
"detail": "Der Fachdatensatz ist nicht schema-valide.",
"instance": "data"
}
```
## Überprüfung der Anlagen
### Anlage laden
Kann das im Metadatensatz genannte Attachment geladen werden?
```json
{
"type": "https://schema.fitko.de/fit-connect/events/problems/missing-attachment",
"title": "Anlage fehlt",
"detail": "Die Anlage {attachmentId} konnte nicht geladen werden.",
"instance": "attachment:{attachmentId}"
}
```
### Authentication-Tag prüfen
Stimmt das Authentication-Tag mit dem im Submit-Submission-Event überein?
```json
{
"type": "https://schema.fitko.de/fit-connect/events/problems/incorrect-authentication-tag",
"title": "Authentication-Tag ungültig",
"detail": "Das Authentication-Tag der Anlage {attachmentId} ist ungültig.",
"instance": "attachment:{attachmentId}"
}
```
### Entschlüsselung
Kann die Anlage entschlüsselt werden?
```json
{
"type": "https://schema.fitko.de/fit-connect/events/problems/encryption-issue",
"title": "Entschlüsselungs-Fehler",
"detail": "Die Anlage {attachmentId} konnte nicht entschlüsselt werden.",
"instance": "attachment:{attachmentId}"
}
```
Sofern ein falscher oder veralteter Schlüssel verwendet wurde,
die Anlage aber dennoch entschlüsselt werden konnte,
sollte Verarbeitung fortgesetzt werden, aber eine entsprechende Meldung erfolgen.
```json
{
"type": "https://schema.fitko.de/fit-connect/events/problems/encryption-issue",
"title": "Entschlüsselungs-Fehler",
"detail": "Der Schlüssel {kid} ist nicht der zu diesem Zweck vorgesehene Schlüssel.",
"instance": "attachment:{attachmentId}"
}
```
### Hash-Prüfung
Passt der Hash im Metadatensatz zu den entschlüsselten Daten?
```json
{
"type": "https://schema.fitko.de/fit-connect/events/problems/hash-mismatch",
"title": "Prüfsumme stimmt nicht",
"detail": "Der Hash der Anlage {attachmentId} stimmt nicht.",
"instance": "attachment:{attachmentId}"
}
```
### Inhaltliche Prüfung
Inhaltliche Prüfung, z.B. auf Viren oder Prüfung des Dateiformats: Wenn z.B. ein Word-Datei geschickt wurde, obwohl als Art „PDF“ angegeben wurde.
```json
{
"type": "https://schema.fitko.de/fit-connect/events/problems/invalid-content",
"title": "Unzulässiger Inhalt",
"detail": "Der Inhalt der Anlage {attachmentId} ist nicht zulässig.",
"instance": "attachment:{attachmentId}"
}
```
## Weitere Fehler
### Technischer Fehler
Fehler bei der technischen Verarbeitung im empfangenden System
```json
{
"type": "https://schema.fitko.de/fit-connect/events/problems/technical-error",
"title": "Technischer Fehler",
"detail": "Bei der Verarbeitung im empfangenden System trat ein technischer Fehler auf.",
"instance": "other"
}
```
docs/responsibilities/get-destination.mdx
View file @ 1a2ff8c6
......@@ -8,10 +8,6 @@ import TabItem from '@theme/TabItem'
## Zustellpunkt und `destinationId` über die Routing API ermitteln
:::caution Hinweis
Bis zur Bereitstellung des Routingdienstes können [Zustellpunkt-Informationen über die Submission API abgerufen werden (siehe unten)](#submissionapi).
:::
Um eine Einreichung an die fachlich korrekte Stelle sicherzustellen und die technischen Parameter des richtigen Zustellpunkts zu ermitteln, muss die `destinationId` der zuständigen Stelle und die Adresse des zuständigen Zustelldienstes ermittelt werden.
Die Ermittlung der `destinationId` und die Ermittlung der technischen Parameter erfolgt über einen GET Request auf den Endpunkt <ApiLink api="routing-api" to="/routes" /> des FIT-Connect Routingdienstes.
......@@ -40,21 +36,21 @@ Beispiele für das Ermitteln der benötigten Daten:
$ export ROUTING_API=https://routing-api-testing.fit-connect.fitko.dev
$ curl \
-H "Content-Type: application/json" \
-X GET "$ROUTING_API/v1/routes?leikaKey=99010003001006&ags=15085055"
-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=99010003001006&ars=150850055055"
-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=99010003001006&areaId=15529"
-X GET "$ROUTING_API/v1/routes?leikaKey=99108012005000&areaId=15529"
```
</TabItem>
......@@ -64,9 +60,9 @@ Beispiel für die Response:
```json
{
"count": 500,
"count": 1,
"offset": 0,
"totalCount": 0,
"totalCount": 1,
"routes": [
{
"destinationId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
......@@ -124,13 +120,24 @@ Beispiel für die Response:
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).
:::
Diese Informationen sind:
- Der Status (`status`) gibt an, ob der Zustellpunkt aktiv ist. Nur im Status `active` können neue Einreichungen versendet werden.
- Die Verwaltungsleistungen (`services`), die über diesen Zustellpunkt abgebildet werden, bestehend aus:
- einem Identifikator der Verwaltungsleitung (`identifier`): Typischerweise entspricht dieser einem Leistungsschlüssel aus dem FIM-Baustein Leistungen (ehemals *LeiKa-Schlüssel*, siehe [Leistungskatalog im FIM-Portal](https://fimportal.de/kataloge#download-leistungen)).
- einer Liste an zulässigen Fachdatenschemata (`submissionSchemas`): Hiermit legt das empfangende System fest, welchem Schema die übergebenen Fachdatensätze entsprechen müssen. Welches der angegebenen Schemata verwendet werden muss, bestimmt das sendende System aus dem eigenen fachlichen Kontext heraus. Wenn bspw. ein Antrag für einen Schwerbehindertenausweis gestellt wird, muss der Fachdatensatz aus den dort hinterlegten Schemata gemäß dem dortigen Schema für den Schwerbehindertenausweis (bspw. ein FIM/XFall Schema) entsprechen.
- einer Liste an Regionen (`regions`), für die die Verwaltungsleistung angeboten wird.
- Schlüssel-ID (Key-ID, `kid`) des öffentlichen Verschlüsselungsschlüssels (`encryptionKid`): Empfangende Systeme veröffentlichen die Schlüssel-ID ihres Verschlüsselungsschlüssels für die Verschlüsselung von Einreichungen. Der dazugehörige JSON Web Key (JWK) ist in einer Antwort des Routingdienstes im Attribut `publicKeys` enthalten und kann auch über den Endpunkt <ApiLink api="submission-api" to="/v1/destinations/{destinationId}/keys/{keyId}" /> abgefragt werden.
### Aufbau der Zustellpunkt-Informationen {#destination-object}
Die Zustellpunkt-Informationen bestehen aus:
- Die Destiantion-ID (`destinationId`) des Zustellpunktes.
- Die signierten Adressierungsinformationen (`destinationSignature`).
- Das Zustellpunkt-Objekt (`destinationParameters`) mit folgenden Inhalten:
- Die Adresse des zuständigen Zustelldienstes (`submissionUrl`).
- Der Status (`status`) gibt an, ob der Zustellpunkt aktiv ist. Nur im Status `active` können neue Einreichungen versendet werden.
- Die Verwaltungsleistungen (`services`), die über diesen Zustellpunkt abgebildet werden, bestehend aus:
- einem Identifikator der Verwaltungsleitung (`identifier`): Typischerweise entspricht dieser einem Leistungsschlüssel aus dem FIM-Baustein Leistungen (siehe [Glossar](../glossary.md)).
- einer Liste an zulässigen Fachdatenschemata (`submissionSchemas`): Hiermit legt das empfangende System fest, welchem Schema die übergebenen Fachdatensätze entsprechen müssen. Welches der angegebenen Schemata verwendet werden muss, bestimmt das sendende System aus dem eigenen fachlichen Kontext heraus. Wenn bspw. ein Antrag für einen Schwerbehindertenausweis gestellt wird, muss der Fachdatensatz aus den dort hinterlegten Schemata gemäß dem dortigen Schema für den Schwerbehindertenausweis (bspw. ein FIM/XFall Schema) entsprechen.
- einer Liste an Regionen (`regions`), für die die Verwaltungsleistung angeboten wird.
- Schlüssel-ID (Key-ID, `kid`) des öffentlichen Verschlüsselungsschlüssels (`encryptionKid`): Empfangende Systeme veröffentlichen die Schlüssel-ID ihres Verschlüsselungsschlüssels für die Verschlüsselung von Einreichungen. Der dazugehörige JSON Web Key (JWK) ist in einer Antwort des Routingdienstes im Attribut `publicKeys` enthalten und kann auch über den Endpunkt <ApiLink api="submission-api" to="/v1/destinations/{destinationId}/keys/{keyId}" /> abgefragt werden.
- Die Liste der öffentlichen Schlüssel des Zustellpunktes (`publicKeys`) als JSON Web Key Set (JWKS). Siehe Artikel [Verschlüsseln](../sending/encrypt.mdx).
- Die Liste der unterstüzten Metadaten-Schema (`metadataVersions`). Siehe Artikel zum [Metadatensatz](../metadata/overview.mdx).
- Die Liste der unterstüzten Rückkanäle (`replyChannels`).
- Die Signatur des Zustellpunkt-Objekts (`destinationParametersSignature`).
- Der Name der zuständigen Fachbehörde (`destinationName`).
- Die URL des Logos der zuständigen Fachbehörde (`destinationLogo`).
### Inhalt der Adressierungsinformationen (Parameter `destinationSignature`)
Der dekodierte Inhalt (Payload) der Adressierungsinformationen sieht beispielhaft wie folgt aus (Leerzeichen und Zeilenumbrüche dienen ausschließlich der besseren Lesbarkeit):
......@@ -141,16 +148,16 @@ Der dekodierte Inhalt (Payload) der Adressierungsinformationen sieht beispielhaf
"services": [
{
"gebietIDs": [
"urn:de:bund:destatis:bevoelkerungsstatistik:schluessel:rs:12345"
"urn:de:bund:destatis:bevoelkerungsstatistik:schluessel:rs:150850055055"
],
"leistungIDs": [
"urn:de:fim:leika:leistung:100"
"urn:de:fim:leika:leistung:99108012005000"
]
}
],
"destinationId": "0c438057-ec3e-4ce0-b154-1683b5d3c2e8",
"iat": 1637685592,
"jti": "ae37e58b-e280-4706-b99e-738f24c8d98f"
"destinationId": "9162e3c9-5364-489a-9e99-aeb24eacc85c",
"iat": 1639572681,
"jti": "5b47d038-6e4d-4060-9da3-6720689287a1"
}
```
......@@ -170,19 +177,9 @@ Ein Beispiel für ein JWKS ist in folgendem Ausschnitt dargestellt:
"key_ops": [
"verify"
],
"kid": "6508dbcd-ab3b-4edb-a42b-37bc69f38fed",
"kty": "RSA",
"n": "65rmDz943SDKYWt8KhmaU…ga16_y9bAdoQJZRpcRr3_v9Q"
},
{
"alg": "PS512",
"e": "AQAB",
"key_ops": [
"verify"
],
"kid": "14a70431-01e6-4d67-867d-d678a3686f4b",
"kid": "aeBUhQS8uaJvtzMcTyiEAN3KW4m65uDmL0X1AAIqdCE",
"kty": "RSA",
"n": "wnqKgmQHSqJhvCfdUWWyi8q…yVv3TrQVvGtsjrJVjvJR-s_D7rWoBcJVM"
"n": "4Y0sJhadfrQnNZXeS7Pqh73FvtFPXLvLw11h7OiZM0DlqvRNgoYHO5k-kxJKOVCaFek0LjKM1_VQxMVpdChCkHeapdTg60oQTQZj3pG0boR3LStbqN3hNEx_JZC4aHH16kau0vqBBPiOOoq-ExUz-hXz_GMLsp9QVqIkw9okO_tzNPjQOo--GM8r4eSsKzgSHZzmepc9Gfk16eraGicBevlkclk32TmWIE_ErD31dtVbBlK-7GG2NUe-o_5rkiCJ2EwKRHZlLkBYJkkj_IjeUdKc4dawXoE8L83DSBPyapX47_L1VHTnT0hJdOVe6WHtvzzpusZ0Au-YDhp6LSwXnU9d0-VzBJmQvtrep1FM0d9aQrz0e0lVf8wCn13VdKO_FBZw9D7i0XRhF8JqQRblqhcCY7UGshbTTM8HORMFONHFmSQm10qfV29PLmztOhIuubMyYe1DPnlfRkpn5jnt8IPoopl6MliDKSc3m4dgG23KylBpTLr3U-XGQrTlerjrYh4t1LXiJ-jQhLefkak_WnExZJSXv601BgmbGj3GdIhS6lxdMX62cOuwKLVISOmHHxvimpQwhtYwiFR9OmGoKVgtCQ5eMKLwGWVwXSvUJ5YXH-yUyNW1_vOrt0DAtYmXwS_Ij0bMg9WoXKJ-5NtQpnnIzw1lr5bW5fNn2TgWpHk"
}
]
}
......@@ -377,34 +374,38 @@ Die URL der Submission API findet sich im Artikel [Erste Schritte](../getting-st
```bash
$ export SUBMISSION_API=https://submission-api-testing.fit-connect.fitko.dev
$ export JWT_TOKEN=eyJhbGciOiJIUzI1NiJ9.eyJJc3N1Z...NL-MKFrDGvn9TvkA
$ export DESTINATION_ID=13ad2349-975c-4167-bcd8-da606b4e1d84
$ export DESTINATION_ID=9162e3c9-5364-489a-9e99-aeb24eacc85c
$ curl \
-H "Authorization: Bearer $JWT_TOKEN" \
-H "Content-Type: application/json" \
-X GET "$SUBMISSION_API/v1/destinations/$DESTINATION_ID"
{
"destinationId": "13ad2349-975c-4167-bcd8-da606b4e1d84",
"status": "active",
"destinationId": "9162e3c9-5364-489a-9e99-aeb24eacc85c",
"status": "created",
"services": [
{
"identifier": "urn:de:fim:leika:leistung:99107004018000",
"identifier": "urn:de:fim:leika:leistung:99108012005000",
"submissionSchemas": [
{
"schemaUri": "https://schema.fitko.de/fim/s00000122_1.0.0.schema.json",
"schemaUri": "https://schema.fitko.de/fim/s17000098_1.0.schema.json",
"mimeType": "application/json"
}
],
"regions": [
"DE09415061516",
"DE09420411"
"DE150850055055"
]
}
],
"encryptionKid": "e4142167-7f03-4d4f-a8c9-c7ecc78f55f8",
"encryptionKid": "rZ2DkPobwJRGSIC23MZtrWdlqbkzWovmvhPHNOwqxMA",
"metadataVersions": [
"1.0.0"
]
],
"replyChannels": {
"eMail": {
"usePgp": true
}
}
}
```
</TabItem>
......
docs/sending/accept-reject.mdx 0 → 100644
View file @ 1a2ff8c6
This diff is collapsed.
docs/sending/overview.mdx
View file @ 1a2ff8c6
......@@ -6,13 +6,9 @@ import Tabs from '@theme/Tabs'
import TabItem from '@theme/TabItem'
import Mermaid from '@site/src/components/Mermaid'
Bei einer Einreichung z. B. eines Antrags reicht ein Onlineservice im Namen und Auftrag eines Endnutzers Fachdaten und/oder Anlagen bei einem Zustellpunkt ein.
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 man an diese Informationen gelangt ist unter [Zustellpunkt ermitteln](../responsibilities/get-destination.mdx) genauer beschrieben.
:::caution
Wie der Zustellpunkt der zuständigen empfangenden Stelle technisch ermittelt wird, wird aktuell noch nicht beschrieben. Die Ermittelung wird zukünftig über die Routing API ermöglicht, die sich aktuell noch in der Umsetzung (voraussicht bis Ende Q3 2021) befindet. Sobald Routing API spezifiziert ist und technisch bereitsteht, wird die Ermittlung des korrekten Zustellpunkt über die Routing API hier beschrieben. Bis dahin wird davon ausgegangen, dass der Zustellpunkt bzw. deren `destinationId` über einem bilateralen Mechanismus in Erfahrung gebracht wird.
:::
Wie der Zustellpunkt der zuständigen empfangenden Stelle technisch ermittelt wird ist unter [Zustellpunkt ermitteln](../responsibilities/get-destination.mdx) genauer beschrieben.
FIT-Connect möchte einen sehr sicheren Übermittlungsweg bereitstellen, weswegen alle Daten immer vom Browser des Users bis in die Behörde Ende-zu-Ende-Verschlüsselt übertragen werden müssen.
Das dafür benötigte Schlüsselmaterial wird auch über die Submission API und Routing API bereitgestellt und der Umgang damit im Weiteren erklärt.
......