CHANGELOG.md

Changelog

Das Format dieser Datei basiert auf Keep a Changelog.

[Unveröffentlicht] - ????-??-??

Diese Version beinhaltet breaking changes

Allgemein

• Reduktion der Verarbeitung von personenbezogenen Daten
• Daten eines Antrags müssen nun Ende-zu-Ende verschlüsselt übertragen werden
• API-Endpunktstruktur hat sich verändert, um
  • die Pfade einfacher und kürzer zu gestalten
  • und nur Parameter zu erfassen, die auch benötigt werden
• Hinzugefügt: Endpunkt /status zur Prüfung ob der Zustelldienst verfügbar ist.

Destinations

Der Aufbau & Umfang von Destination-Objekten hat sich geändert:

• Das Attribut publicOrganization entfällt, weil
  • nur Kontaktinformationen für den Fall von technischen Problemen erfasst und hierbei so wenig Informationen wie möglich gespeichert werden sollen.
  • Der Name der Organisation ist als Attribut für eine bessere Zuordnung zu contactInformation unter legalName gewandert.
• Das Attribut technicalContact wird umbenannt zu contactInformation und inhaltlich wie im Beispiel unten geändert
• Die Attribute callback und callbackURI wurden zusammengeführt,
  • um die Struktur flacher zu gestalten,
  • und weil neben callbackURI keine anderen Attribute angeordnet sind.
• Im Attribut schemas entfällt das Attribut encoding,
  • da ab Version 1 jede Kommunikation Ende-zu-Ende verschlüsselt sein muss.
• Das Attribut publicKey wurde umbenannt zu encryptionKid. Weiterhin wurde ein Feld keys eingefügt.
  • encryptionKid: Die KeyId des Schlüssels der zur Verschlüsselung der an einen Zustellpunkt gesendeten Daten verwendet wird. Der Schlüssel ist abrufbar im Attribut keys.
  • keys: Hier befinden sich die öffentlichen Schlüssel des Zustellpunktes.
  • Der signingKid fehlt, da dieser an signierten Nachrichten mit angehängt wird und ebenso im Attribut keys auffindbar ist.
• Ein Schema besteht nun aus einer schemaURI und optional einem Feld mimeType.
  • Wurde im Zuge der Vereinfachung so umgesetzt. URLs und URNs können in das Feld schemaURI eingetragen werden.

{
  "contactInformation": {
    "legalName": "Max",
    "address": "Mustermann",
    "phone": "+49170123456789",
    "email": "max@mustermann.not",
    "unit": "Musterabteilung XYZ"
  },
  "schemas": [
    {
      "schemaURI": "urn:fitko:schema-x"
    }
  ],
  "callback": "http://127.0.0.1:4010/voluptas",
  "keys": {
    "my-key-id": {
      
    }
  },
  "encryptionKid": "my-key-id"
}

Get Destination

• destinationId
• schemas
• encryptionKid
• keys

Das Attribut contact (vormals technicalContact) wird nicht mehr zurückgegeben, da dies schützenswerte Informationen sind.

Update Destination

• Attribut destinationId ist nicht länger aktualisierbar, da die Id vom Service und nicht vom Nutzer der API verwaltet wird
• Liefert jetzt bei erfolgreicher Aktualisierung die öffentlichen Attribute des Zustellpunktes zurück, anstatt vorher nur { "result": "success" }.

Create Destination

Liefert jetzt bei erfolgreichem Erstellen die öffentlichen Attribute des Zustellpunktes zurück, anstatt vorher nur die destinationId.

Delete Destination

Eigentlich müsste dieser Endpunkt gar keinen Body mitliefern. Damit nicht-konforme Middleware den Request trotzdem sauber routen kann, liefert er jetzt {} anstatt { "result": "success" } zurück.

Application Transfer

• Die Grundstruktur eines Antrags wurde angepasst, da der Großteil der Informationen nun verschlüsselt übertragen wird.
• Einige Endpunkte und HTTP-Methoden wurden angepasst, um den Ablauf kürzer, einfacher, stabiler und sicherer zu gestalten.
• Metadaten eines Antrags: Alle Metadaten eines Antrags werden nun verschlüsselt im Attribut encryptedMetadata übertragen.

Create Application

• Beim Anlegen eines Antrags muss nun die Id der Destination (Zustellpunktes) mit angegeben werden, da sie nur bei der Anlage des Antrags notwendig ist und nicht bei den weiteren Aufrufen.
• Struktur um eine Application anzulegen ist nun nur noch { destinationId: …, announcedContentStructure: … }, da sich die Gesamtstruktur geändert hat. In announcedContentStructure wird angegeben ob Fachdaten für diesen Antrag hochgeladen werden als auch eine Liste an UUIDs die für diesen Antrag hochgeladen werden. Die Erstellung der UUIDs ist dem Client überlassen.

Add Document to Application

• Der Inhalt des Dokuments wird nun verschlüsselt, daher ist der Content-Type statt application/json nun application/jose
• Als Antwort müsste dieser Endpunkt gar keinen Body mitliefern. Damit nicht-konforme Middleware den Request trotzdem sauber routet: liefert er jetzt {} statt {"result": "success"}

Send Application

• Send Application und Application Data hinzuzufügen ist nun in einem Endpunkt kombiniert, da kein Antrag ohne Fachdaten übertragen werden können soll.
• Der Aufruf des Endpunktes und die Übertragung der verschlüsselten Fachdaten markiert den Antrag dann auch als "final" und löst die Übertragung an den Zustellpunkt aus.
• Die Fachdaten sind nun verschlüsselt, wodurch der Content-Type nicht mehr application/json sonder application/jose ist
• Der Response Status ist nicht mehr 200, sondern 202, da die Fachdaten akzeptiert wurden und der Antrag abgeschickt wird.

Status Endpunkte

• Der upload-status entfällt, da alle Informationen verschlüssselt sind und nun nicht bekannt ist, wie viele Dokumente eines Antrags bereits hochgeladen wurden.
• Die Informationen zum Status eines Antrags und dessen Historie sind nun direkt im Antrag hinterlegt und werden mit zur Verfügung gestellt, wodurch keine separaten Endpunkte mehr notwendig sind.

Application Retrieval