Bug: Inkorrekte Schreibweise des `eMail`-Attributs (replyChannels) in der API des DVDV-Microservice

Zusammenfassung

Die Routing API und der DVDV verhalten sich unterschiedlich beim Erstellen des JSON für die ReplyChannels. Beim DVDV wird email vom Server zurückgegeben. Bei der Routing API eMail.

Das führt zu Problemen bei der Signaturprüfung, wenn die JSON Payloads clientseitig berechnet werden müssen. Zumindest in C#, da dort die Properties nur sortiert werden können, wenn die JSON-Daten zuerst in eine bekannte Klasse umgewandelt werden müssen. Anonyme Klassen können nicht sortiert werden.

DVDV:

"replyChannels": {
  "email": {
    "usePgp": true
  }
}

Routing API:

"replyChannels": {
  "eMail": {
    "usePgp": true
  }
}

Grund dafür ist, dass der Zustelldienst (konform zur API-Spezifikation der DVDV-API) Signaturen auf Grundlage der Schreibweise email (statt eMail) erzeugt.

Schritte zum Reproduzieren

• Destination vom DVDV
• Routing API
• Prüfen der Signature mittels retrieveDestination.py: https://git.fitko.de/fit-connect/fitconnect-dvdv-api-tests#check-destination-signature

Übersicht über die Schreibweise

• Submission API: eMail (im Feld contactInformation wird abweichend email genutzt -> unschön, aber unkritisch)
• Routing API: eMail
• Metadatenschema: eMail
• DVDV-Microservice-API: email

Wie verhält sich der aktuelle Fehler?

Die Signatur kann nur als valid geprüft werden, wenn email in den replyChannels angegeben wird.

TODO: Fehler besser beschreiben.

Was ist das erwartete richtige Verhalten?

Der DVDV-Microservice "FIT-Connect" sollte in den replyChannels auch die Schreibweise eMail nutzen, um dem Schema der Routing API und der Submission API zu entsprechen.

Der Zustelldienst sollte Signaturen auf Basis der Schreibweise eMail erzeugen.

Zu klären

• Erstellt der Zustelldienst die destinationSignature mit email oder eMail? -> email (siehe Kommentar unten)
  • Warum? In src/main/java/de/fiep/zustelldienst/dvdv/model/DvdvDestinationReplyChannels.java heißt es private DvdvEMailReplyChannel eMail;...

Alternativen

• Bug nicht beheben zugunsten von #516

Akzeptanzkriterien

a) Korrektur der Signaturen

1. Der Zustelldienst erstellt nun korrekte Signaturen (Schreibweise eMail).
2. Die Signaturen werden zu jedem Zeitpunkt vom Routingdienst als gültig angesehen. (Hierzu muss der Routingdienst ggf. vor Umstellung der Signatur-Erzeugung im Zustelldienst angepasst werden.)
3. Die Signaturen werden zu jedem Zeitpunkt vom Java-SDK als gültig angesehen. (Hierzu muss das SDK ggf. vor Umstellung der Signatur-Erzeugung im Zustelldienst angepasst werden.)
4. Die Signaturen werden zu jedem Zeitpunkt vom .NET-SDK als gültig angesehen. (Hierzu muss das SDK ggf. vor Umstellung der Signatur-Erzeugung im Zustelldienst angepasst werden.)

b) Korrektur der API des DVDV-Microservice

1. In der API-Spezifikation des DVDV-Microservice wird die Schreibweise von email auf eMail korrigiert.
2. Falls nötig, wurde die Implementierung des DVDV-Microservice entsprechend angepasst.
3. Der Zustelldienst exportiert Daten an die API des DVDV-Microservice mit der korrekten Schreibweise eMail.
4. Der Routingdienst empfängt die Daten jederzeit korrekt. (Hierzu muss der Routingdienst in der Lage sein, das E-Mail-Feld sowohl in der Schreibweise email, als auch in der Schreibweise eMail zu empfangen).
5. Die Ausgabe der Routing API verändert sich zu keinem Zeitpunkt.