Zum Hauptinhalt springen
Version: FIT-Connect_v1

Changelog

Das Format dieser Datei basiert auf Keep a Changelog.

2021-11-29#

Self Service Portal 1.1.0 / 1.1.1#

  • Story: Export von Zustellpunkt Adressierungsinformationen als JWS (Story)

2021-11-23#

Zustelldienst 1.0.3#

  • Bugfix: Nicht-erfolgreiche Callback-Aufrufe d├╝rfen nicht zu einem Fehler f├╝hren. (Bug)
  • API-Version in 1.0.3 ge├Ąndert.

2021-11-18#

Self Service Portal 1.0.2#

  • Bugfix: Alle Links zur Dokumentations auf der Zustellpunkt Erstell und Bearbeiten Seite von der Version ┬┤next┬┤ zu ┬┤v1┬┤ ge├Ąndert.
  • Bugfix: Der Link zur Urn Verwaltungsleistung Suche auf der Zustellpunkt Erstell und Bearbeiten Seite wurde korrigiert

2021-11-17#

Zustelldienst 1.0.2#

  • Bugfix: Es wurde der Inhalt des type Felds gefixt, der bei der Callback-├ťbermittelung an einen Zustellpunkt verwendet wird. (Story)
  • Bugfix: Der Endpunkt POST /v1/submissions/{submissionId} wurde gem├Ą├č der aktuellen API-Spezifikation nach POST /v1/cases/{caseId} verlegt. (Story)

2021-11-15#

API Spezifikation 1.0.3#

  • Der Wert created f├╝r den Status wurde aus dem PATCH-Endpunkt entfernt. (Bug)

Die Version 1.0.2 wurde zur├╝ckgezogen und durch 1.0.3 ersetzt. Version 1.0.3 ist gleichwertig zu 1.0.1

2021-11-11#

API Spezifikation 1.0.1#

  • Die Callback URIs wurden korrigiert, so dass sie jetzt die submission-api enthalten.

2021-11-10#

Metadata Schema 1.0.0#

Self Service Portal 1.0.1#

  • Die ausw├Ąhlbare unterst├╝tze Metadaten Version 0.9.6 bei Zustellpunkten wurde deprecated und entfernt. Sie wird durch die neu releaste Version 1.0.0 ersetzt. (Story)

Zustelldienst 1.0.1#

  • Die ausw├Ąhlbare unterst├╝tze Metadaten Version 0.9.6 bei Zustellpunkten wurde deprecated und entfernt. Sie wird durch die neu releaste Version 1.0.0 ersetzt. Alle bestenden Zustellpunkte werden automatisch von Version 0.9.6 auf 1.0.0 migriert. (Story)
  • Bugfix: Es wurde gefixt, dass bei einer erfolgreichen Einreichung nicht mehr der Sender, sondern der Empf├Ąnger ├╝ber den Callback benachrichtig wird. (Story)

[1.0.0] - 2021-11-05#

caution

Diese Version beinhaltet breaking changes

Allgemein#

  • Reduktion der Verarbeitung von personenbezogenen Daten
  • Daten einer Einreichung 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

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 submissionSchemas 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 einem 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"  },  "submissionSchemas": [    {      "schemaUri": "urn:xoev-de:xfall:standard:fim-s00000000009_1.0.0",      "mimeType": "application/xml"    }  ],  "callback": "http://127.0.0.1:4010/voluptas",  "keys": {    "my-key-id": {    }  },  "encryptionKid": "my-key-id"}
Get Destination#
  • destinationId
  • submissionSchemas
  • 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 einer Einreichung 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 einer Einreichung: Alle Metadaten einer Einreichung werden nun verschl├╝sselt im Attribut encryptedMetadata ├╝bertragen.

Create Application#

  • Beim Anlegen einer Einreichung muss nun die Id der Destination (Zustellpunktes) mit angegeben werden, da sie nur bei der Anlage der Einreichung 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 Einreichung hochgeladen werden als auch eine Liste an UUIDs die f├╝r diesen Einreichung 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 Einreichung ohne Fachdaten ├╝bertragen werden k├Ânnen soll.
  • Der Aufruf des Endpunktes und die ├ťbertragung der verschl├╝sselten Fachdaten markiert den Einreichung 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 Einreichung abgeschickt wird.

Status Endpunkte#

  • Der upload-status entf├Ąllt, da alle Informationen verschl├╝sselt sind und nun nicht bekannt ist, wie viele Dokumente einer Einreichung bereits hochgeladen wurden.
  • Die Informationen zum Status einer Einreichung und dessen Historie sind nun direkt im Einreichung hinterlegt und werden mit zur Verf├╝gung gestellt, wodurch keine separaten Endpunkte mehr notwendig sind.

Application Retrieval#

Wie oben schon angesprochen hat sich die Struktur einer Einreichung ver├Ąndert, sodass ein Einreichung bei der Abholung wie folgt beispielhaft aufgebaut ist:

{  "destinationId": "879ee109-a690-4db8-ab32-424284184d7d",  "submissionId": "ce75a6b8-d72f-4b94-b09e-af6be35bc2ae",  "attachments": [    "879ee109-a690-4db8-ab32-424284184d7d",    "2046f9f1-dc89-4440-9c24-c76a8f40d668"  ],  "encryptedMetadata": "eyJlbmMiOiJBMjU2R0NNIiwiYWxnIjoiUlNBLU9BRVAtMjU2In0.nlXGAufYH36IABDy0En0LXEhGfC20IZSSchs27ADalHpRoTZKfXhc7hcMk8Y9V8yTP0jYbmrq6NtEg-QS2O5TQFD9Hluhpb631PBgKjPXHYX1Y6iUcR1sXxSUPjePi8F8PcZUZuUJLnhz6myyc9scdAq9BXG2cDJVgkfLI8eZdrqnrY24Hh32_7d5OKLFSpSDrBlqfyQuY8Wbs2h8Wy4Z4hwT1aWDO7b-SqJA181hUbNcF_rR4Mze3Fdtu-3uOIQYgLBBRmN1ZHDLk0EKNCI4B8MyDKLGPoM0ZomV5lVwVWjAMRI4CgQkIQ9rnm-Adof-GbegQL3yJSoNIWRWgzCnZBYZ638QgPllCMVW3WvEVvsgj0Hj16PbofqXTQ5S73LINfP6FZawfC0yMrYjSV_N2L0Lkp2KI3BkJcy-PcFhBnhwu2IsJGAlyDRCnXdVqig8m5yLHuSMQTpLW69LzPEskfsjhnNDR-CEBZpicjMfc-4CL6U7E7YoGc_99DzE5U5._JfqyKH23GiKsnDW.ZtMMjZ3GgcgHss8qbFRhrjl4L0kAfbco-oXICkk.VBHJ00FyDTYjOA_OYfiz5g",  "encryptedData": "eyJlbmMiOiJBMjU2R0NNIiwiYWxnIjoiUlNBLU9BRVAtMjU2In0.nlXGAufYH36IABDy0En0LXEhGfC20IZSSchs27ADalHpRoTZKfXhc7hcMk8Y9V8yTP0jYbmrq6NtEg-QS2O5TQFD9Hluhpb631PBgKjPXHYX1Y6iUcR1sXxSUPjePi8F8PcZUZuUJLnhz6myyc9scdAq9BXG2cDJVgkfLI8eZdrqnrY24Hh32_7d5OKLFSpSDrBlqfyQuY8Wbs2h8Wy4Z4hwT1aWDO7b-SqJA181hUbNcF_rR4Mze3Fdtu-3uOIQYgLBBRmN1ZHDLk0EKNCI4B8MyDKLGPoM0ZomV5lVwVWjAMRI4CgQkIQ9rnm-Adof-GbegQL3yJSoNIWRWgzCnZBYZ638QgPllCMVW3WvEVvsgj0Hj16PbofqXTQ5S73LINfP6FZawfC0yMrYjSV_N2L0Lkp2KI3BkJcy-PcFhBnhwu2IsJGAlyDRCnXdVqig8m5yLHuSMQTpLW69LzPEskfsjhnNDR-CEBZpicjMfc-4CL6U7E7YoGc_99DzE5U5._JfqyKH23GiKsnDW.ZtMMjZ3GgcgHss8qbFRhrjl4L0kAfbco-oXICkk.VBHJ00FyDTYjOA_OYfiz5g",  "currentStatus": "queued",  "statusHistory": [    {      "sourceState": "incomplete",      "targetState": "queued",      "timestamp": "2021-01-30T08:30:00Z"    }  ]}

Die Fachdaten und Metadaten sind verschl├╝sselt, die Struktur ver├Ąndert und daher hat sich auch bei der Abholung einer Einreichung der Prozess ver├Ąndert bzw. reduziert, indem die Endpunkte f├╝r die Abholung der Fachdaten und Metadaten nun kombiniert sind.

Dokument abholen#

Bei der Abholung werden nun als Antwort keine Bin├Ąrdaten mehr zur Verf├╝gung gestellt, sondern die verschl├╝sselten Inhalte.

Best├Ątigung der Abholung#

  • Als Antwort m├╝sste dieser Endpunkt gar keinen Body mitliefern. Damit nicht-konforme Middleware den Request trotzdem sauber routet liefert er jetzt {} (statt vorher {"result": "success"}).

[0.7.0]#

Umgesetzte Change Requests#

#13 API Specification: Method of Acknowledge Application endpoint of Subscriber API should be PUT instead of POST#

Die Operationen "Send Application" und "Acknowledge Application" wurden auf PUT umgestellt.

Bitte beachten Sie, dass die PUT-Operationen jetzt auf die Status-Resource wirken.

#19 contentStructure.data.size entfernen#

Aufgrund verschiedener Codierungen kann die Gr├Â├če der Fachdaten (JSON oder XML) in Bytes nicht einfach und verl├Ąsslich vorhergesagt werden. Daher wurde die Angabe der Gr├Â├če der Fachdaten aus den Metadaten entfernt.

#23 Pattern nicht referenzieren#

Im Dokument (document.json) wurde bei der Property signature als Pattern eine Referenz auf base64url.json gesetzt:

    "signature": {"pattern": {"$ref": "../common/base64url.json#/pattern"},"type": "string","description": "Sofern der Antragstellers dieses Dokument signiert hat, wird die Signatur hier base64url-encoded eingebettet"}

Dies f├╝hrt beim Swagger-Codegen und dem OpenAPI-Generator zu Fehlern. Um die Codegenerierung zu erleichtern wurde das Pattern dorthin kopiert.

    "signature": {"type": "string","description": "Sofern der Antragstellers dieses Dokument signiert hat, wird die Signatur hier base64url-encoded eingebettet","pattern": "^[a-zA-Z0-9-_=]+$"}

#24 Keine mehrfachen Typen#

Im Modell address-national.json wurde f├╝r die Hausnummer (houseNumber) die Typen integer und string definiert. Die Hausnummer sollte eigentlich vom Typ integer sein und Zus├Ątze in den Hausnummerzusatz (houseNumberSuffix) kommen. Um etwas flexibler zu sein, wurde aber alternativ auch ein string f├╝r die Hausnummer zugelassen. In FIM wurde die Hausnummer auch als Text-Feld definiert (F00000016).

    "houseNumber": {"type": ["string","integer"],"description": "Hausnummer","maxLength": 9,"pattern": "^[1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?$","minimum": 1}

Die Verwendung von mehr als einem Typen f├╝hrt bei Codegeneratoren zu Problemen. Daher wird nur noch der Typ string verwendet.

    "houseNumber": {"type": "string","description": "Hausnummer","maxLength": 9,"pattern": "^[1-9][0-9]{0,3}(-[1-9][0-9]{0,3})?$"}

#25 Rechtsgrundlage der Verwaltungsleistung#

Das Modell "Public Service Type" (public-service-type.json) wurde in "Verwaltungsleistung" umbenannt und hat ein zus├Ątzliches Feld "Rechtsgrundlage" (legalBasis) erhalten.

#33 Antragsdatum#

Unter additionalReferenceInfo wurde eine optionale Property applicationDate (Antragsdatum) hinzugef├╝gt.

#34 Status History und aktuellen Status verschieben#

Die Pfade f├╝r den aktuellen Status und die Statushistorie sind jetzt:

  • /destinations/{destinationId}/applications/{applicationId}/status - aktueller Status
  • /destinations/{destinationId}/applications/{applicationId}/status/history - Statushistorie

#35 Info/Test Resource hinzuf├╝gen#

Es wurde in beiden APIs eine Resource /info hinzugef├╝gt, die aktuell die API-Version ausgibt. Dies kann genutzt werden, um die Grunds├Ątzliche Erreichbarkeit der API zu testen und um sicherzustellen, dass eine kompatible Version der API verwendet wird.

#43 AuthentificationInfo um Liste von verifizierten Feldern erg├Ąnzen#

Die authentificationInfo wurde um ein Array authenticatedFields erg├Ąnzt, das die Felder aus der identityInfo auflistet, f├╝r die die Authentifkation gilt. Zus├Ątzlich wurde authentificationMethod zu einem Enum umgewandelt.

#45 Mime-Types#

Die Mime-Types in Application Schema wurden gem├Ą├č RFC abgebildet werden:

  • application/json statt json
  • application/xml statt xml

#49 JSON Web Key Set durch JSON Web Key ersetzt#

Die Destination enth├Ąlt nun einen JWK statt einem JWK Set.

[0.6.0]#

Dokumentation#

Umgesetzte Change Requests#

#3 Sematic error of the OAS in editor.swagger.io#

Das Security Schema darf keine Leerzeichen enthalten und wurde deswegen von "OAuth 2.0" in "OAuth20" umbenannt.

#4 academicTitle -> doctoralDegrees#

Alle Vorkommen von academicTitle wurden durch doctoralDegrees ersetzt.

#5 telephone -> telephones#

Da Arrays mit einem Plural bezeichnet werden sollen wurde telephone durch telephones ersetzt.

#7 Regex f├╝r Hausnummernzusatz ist falsch#

Das Pattern f├╝r den Hasnummernzusatz ^[\\p{L}0-9. ]*$ war inkorrekt da die Zeichenklassen \p{L} nicht zul├Ąssig ist. Es wurde daher zu ^[A-Za-z0-9. ]*$ korrigiert.

#10 API Specification: senderId and subscriberId in URIs#

Die Sender- und Subscriber-ID muss nicht mehr ├╝ber den Pfad mitgegeben werden sondern wird automatisch ├╝ber das Token ermittelt. Damit entfallen die IDs als Pfadangabe.

#11 API Specification: Missing nouns in Sender API URIs endpoints#

Die Pfade auf in der Sender API enthielten vor den IDs kein beschreibendes Nomen. Dies wurde korrigiert. Zum Beispiel:

  • vorher: /{destinationId}/{applicationId}/data
  • nachher: /destinations/{destinationId}/applications/{applicationId}/data

#12 API Specification: Missing destinationId in Get Status endpoint of Sender#

Die Operation "Get Status" wies im Gegensatz zu den anderen Operationen keine vorangestellte Destination-ID auf.

  • vorher: /{applicationId}/status
  • nachher: /destinations/{destinationId}/applications/{applicationId}/status

#16 Fachdaten optional#

Das Element data in der contentStructure war verpflichtend. Damit mussten Fachdaten ├╝bertragen werden. Das Element ist jetzt optional.

[0.5.0]#

├ťbergreifende ├änderungen#

Basis-URLs#

Die Basis-URLs werden ab sofort mit jeder neuen Version ge├Ąndert, damit ein paralleler Betrieb mehrerer API-Versionen m├Âglich ist. Die Basis-URLs f├╝r diese Version sind:

CR-1: Diversen Modellen wurde der Discriminator type hinzugef├╝gt#

  • models/application/applicant-contact-info.json
  • models/application/applicant-contact-info.json
  • models/application/applicant-person.json
  • models/application/applicant.json
  • models/common/address-international.json
  • models/common/address-national.json
  • models/common/address-postbox.json
  • models/common/individual.json
  • models/destination-no-id.json

CR-3: Source in Sender ├Ąndern#

In der Dokumentation werden die Begriffe "Source" und "Sender" synonym verwendet. Um die Dokumentation klarer zu machen, wurden alle Vorkommen von "Source" in "Sender" ge├Ąndert.

Hinweis: Dies wirkt sich auch auf die OAuth-Scopes aus. Der Scope {senderId}:source:manage wurde in {senderId}:sender:manage ge├Ąndert.

CR-5: Zus├Ątzliche Properties verbieten#

  • Wo m├Âglich wurde "additionalProperties": false gesetzt um weitere Properties zu verbieten.
  • Bei den Metadaten und der Destination ohne ID musste "additionalProperties": false wieder entfernt werden da sonst keine Ableitung mit allOf m├Âglich ist.

Dokumentation#

  • Release Notes mit aufgenommen
  • Dokumentation zu OAuth integriert
  • Token-URL eingetragen
  • Postman Collection & Environment integriert

Modelle#

Destination#

models/destination-no-id.json

eID#

  • eID-org-acting-person.json aufgel├Âst und in eID-natural-person.json integriert.

Postfachadresse#

models/common/address-national.json models/common/address-postbox.json

  • Um ein doppeltes oneOf zu vermeiden wurde die Postfach Adresse aus der nationalen Adresse herausgel├Âst.

Application Document#

models/application/document.json

  • Regex Pattern f├╝r SHA-256/512 Hash pr├Ązisiert: "[0-9A-F]{64,128}" -> "^[A-Fa-f0-9]{64}([A-Fa-f0-9]{64})?$"

Application Sender API#

Add Application Data#

  • Im Erfolgsfall enth├Ąlt der Body {"result":"success"}

Add Application Document#

  • Im Erfolgsfall enth├Ąlt der Body {"result":"success"}

Application Subscriber API#

Update Destination#

  • Im Erfolgsfall enth├Ąlt der Body {"result":"success"}

Delete Destination#

  • Im Erfolgsfall enth├Ąlt der Body {"result":"success"}

Acknowledge Application#

  • Bugfix: Property final-delivery auf Camelcase umgestellt.
  • Bugfix: Angaben von finalDelivery in Acknowledge Application ist verpflichtend.

[0.4.0]#

Modelle#

  • Alle Bezeichner auf CamelCase umgestellt.
  • Beispiele angepasst.

Application Metadata#

models/application/metadata-no-id.json

  • data/mimeType entfernt, da redundant zu data/schema/mimeType

Application Sender API#

  • Alle Bezeichner auf CamelCase umgestellt.
  • Beispiele angepasst.

Application Subscriber API#

  • Alle Bezeichner auf CamelCase umgestellt.
  • Beispiele angepasst.

[0.3.0]#

Modelle#

Application Metadata#

models/application/metadata-no-id.json

  • Property data/size erg├Ąnzt

eID#

models/common/eID-org-acting-person.json

  • Property artictic-name in artistic-name umbenannt

Internationale Adresse#

models/common/address-international.json

  • Property lines:
    • Es m├╝ssen mindestens zwei Zeilen angegeben werden
    • Maximall├Ąnge 35 Zeichen

Nationale Adresse#

models/common/address-national.json

  • Alle Eigenschaften mit weiteren Einschr├Ąnkungen mit Maximall├Ąnge oder Pattern versehen

eID#

models/common/eID-org-acting-person.json

  • Property academic-title in doctoral-degrees umbenannt

Phone#

models/common/phone.json

  • Property number: Formatbeschr├Ąnkung gelockert
  • Property type entfernt
  • Property description hinzugef├╝gt

Phone Number#

models/common/phonenr.json

  • Unbenutztes Modell gel├Âscht

[0.2.0] - 2020-03-31#

Modelle#

Antragsteller - Organisation#

models/application/applicant-organization.json

  • Property role entfernt
  • Property org-validation/validated entfernt
  • Property legal-representatives ist jetzt eine $ref auf models/common/individual.json

Antragsteller - Nat├╝rliche Person#

models/application/applicant-person.json

  • Property role entfernt

Application Schema#

Das Schema wurde umgebaut und enth├Ąlt jetzt drei Angaben:

  • mime-type: ist entweder json oder xml
  • schema-source: Quelle f├╝r das Schema. Kann fim oder none sein. Bei none d├╝rfen beliebige Datenstrukturen ├╝bertragen werden.
  • schema-id: ID des Schemas, ist von der Schemaquelle (schema-source) abh├Ąngig.

Person#

Die Person (Verzeichnis models/person/) wurde weitestgehend entfernt. Es gibt nur noch das Modell models/common/individual.json f├╝r eine nat├╝rliche Person.

Phone#

models/common/phone.json

  • Properties number und type sind jetzt verpflichtend

Destination#

Die Destination wurde in mehrere Modelle zerlegt, um dem Sender einen anderen Umfang zu zeigen als dem Subscriber.

Status├╝bersicht#

models/status-overview.json

  • Umbenannt: models/status.json Ôćĺ models/status-overview.json
  • Enum Wert sending entfernt
  • Property since in timestamp umbenannt
  • Property number erg├Ąnzt

Error Body#

models/error-body.json

  • Umbenannt: models/error.json Ôćĺ models/error-body.json
  • Enth├Ąlt jetzt ein Array von Fehlern, statt nur einem.

Neue Modelle#

  • base64: models/common/base64.json
  • JSON Web Encryption (JWE): models/common/jwe.json
  • JSON Web Key (JWK): models/common/jwk.json

Application Sender API#

reference/sender.json

  • Vorkommen von "Transfer" in "Application" umbenannt
    • Dadurch sind auch Operation-IDs ge├Ąndert worden (siehe unten)
  • OAuth2 Scopes erg├Ąnzt
  • Operation "Get Status Entry" (get-application-status-entry) entfernt
  • Operation "Get Application Upload Status"
    • Property docs/doc-id erg├Ąnzt
  • Operation "Create Application": ID in create-application ge├Ąndert
  • Operation "Send Application" (fr├╝her "Commit Application"): ID in commit-application ge├Ąndert

Application Subscriber API#

  • OAuth2 Scopes erg├Ąnzt
  • Operation "Acknowledge Application" (fr├╝her "Commit Application"): ID in ack-application ge├Ąndert

Dokumentation#

Die Dokumentation im Verzeichnis docs wurde erstellt.