Zum Hauptinhalt springen

Rückkanalinformationen

Diese Sektion beschreibt das Feld replyChannel im Metadatenschema.

Wünscht ein Onlineservice eine bidirektionale Kommunikation mit dem Verwaltungssystem, so kann dies im Rückkanal angegeben werden. Alle für Antworten nötigen Verbindungs- und Adressparameter müssen vom Onlineservice im Metadatensatz (verschlüsselt) mitgeliefert werden. Das Verwaltungssystem nutzt diese dann für die Antwort.

Der gewählte Rückkanal des Onlineservices muss mit den angebotenen Rückkanaloptionen des Verwaltungssystems kompatibel sein. Ist dies nicht der Fall, so kann das Verwaltungssystem möglicherweise nicht antworten.

Im Folgenden beschreiben wir noch einige weniger intuitive Felder im Detail.

Angabe der Prozessstandards im Rückkanal FIT-Connect (fitConnect)​

Wird der Rückkanal fitConnect für eine Submission gewählt, so müssen im Feld processStandards kompatible Prozessstandards angegeben werden. Kompatible Prozessstandards eines Verwaltungssystems können an seiner Destination im Feld replyChannels gelesen werden. Nur so kann im Zusammenspiel von Onlineservice und Verwaltungssystem eine machinenlesbare Kommunikation erfolgen.

Beispiel für die Rückkanalauswahl eines Onlinedienstes​

{
  "$schema": "https://schema.fitko.de/fit-connect/metadata/1.2.0/metadata.schema.json",

  // ...

  "replyChannel": {
    "fitConnect": {
      "processStandards": [
        "urn:xoev-de:bmk:standard:xbau_2.4",
      ],
      "encryptionPublicKey": {
        // ...
      }
    }
  }
}

In Worten: Falls das Verwaltungssystem antworten möchte, kann es dies über den Rückkanal FIT-Connect tun. Als Onlineservice unterstützen wir den Prozessstandard XBau in Version 2.4. Die Antwort (Reply) soll vom Verwaltungssystem außerdem mit diesem Schlüssel (Feld: encryptionPublicKey) verschlüsselt werden.

Wichtig!

Der im Feld encryptionPublicKey angegebene Public Key dient der Verschlüsselung von Antworten (Replies) vom Verwaltungssystem an den Onlinedienst. Um die Kommunikationskanäle zwischen einem Verwaltungssystem und mehreren Antragstellenden kryptographisch zu trennen, MUSS im Onlinedienst für jede antragstellende Person ein neues Schlüsselpaar generiert werden. Idealerweise SOLLTE für jeden einzelnen Vorgang (Case) ein neues Schlüsselpaar generiert werden. Hersteller und Betreiber von Onlinediensten MÜSSEN geeignete Maßnahmen ergreifen, um kryptografische Schlüssel derart zu speichern bzw. aufzubewahren, sodass Unbefugte nicht darauf zugreifen können. Betreiber MÜSSEN in diesem Zusammenhang die Einhaltung der Vorgaben aus Grundschutz-Baustein CON.1 sicherstellen.

Verschlüsselung mit PGP für den Rückkanal E-Mail (eMail)​

Wird der Rückkanal eMail gewählt, so kann im Feld pgpPublicKey ein öffentlicher Schlüssel zur Verschlüsselung der Antwort angegeben werden. Dieser ist wie folgt zu befüllen:

Der Inhalt des Feldes ist ein durch gpg --export --armor "$KEY_ID" erzeugter ASCII-String in dem Zeilenumbrüche durch die Escape-Sequenz (\n) ersetzt wurden.

Die Kodierung erfolgt wie folgt:

$ KEY_ID='EEADEDE070FA9658F0BE084AC20D38DB3EA14B59'
$ gpg --export --armor "$KEY_ID" | python3 -c 'import sys; print(sys.stdin.read().replace("\n", "\\n"))'
-----BEGIN PGP PUBLIC KEY BLOCK-----\n\nmQINBEBEADSlS...9jlG\n-----END PGP PUBLIC KEY BLOCK-----\n

Die Dekodierung ist obiger Schritt in Gegenrichtung:

$ KEY_ASCII='-----BEGIN PGP PUBLIC KEY BLOCK-----\n\nmQINBEBEADSlS...9jlG\n-----END PGP PUBLIC KEY BLOCK-----\n'
$ echo "$KEY_ASCII" | python3 -c 'import sys; print(sys.stdin.read().replace("\\n", "\n"))'
-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBEBEADSlS...9jlG
-----END PGP PUBLIC KEY BLOCK-----

Der gewählte Rückkanal kann nun z.B. so angegeben werden:

{
  "$schema": "https://schema.fitko.de/fit-connect/metadata/1.2.0/metadata.schema.json",

  // ...

  "replyChannel": {
    "eMail": {
      "address": "onlineservice@example.org",
      "pgpPublicKey": "-----BEGIN PGP PUBLIC KEY BLOCK-----\n\n ..."
    }
  }