Ergänzung des Endpunkts `GET /destinations/{destinationId}` um eine Signatur der ausgegebenen Daten

Warum?

Der Routingdienst benötigt signierte Zustellpunkt-Informationen.

~"workflow::reevaluate" Alternative: Zustellpunkt-Informationen aus Routing API entfernen

Relevante Links und Bemerkungen

• siehe #146 (closed)

Akzeptanzkriterien

1. Die Submission API gibt bei der Ausgabe der öffentlichen Zustellpunkt-Informationen ("destination-public") im Endpunkt GET /destinations/{destinationId} eine detached JWS des HTTP-Body im HTTP-Header jws-signature aus. Dabei werden die Vorgaben zur Signaturanbringung beachtet:
   • Bei der Signatur handelt es sich um eine Detached JSON Web Signature in der Compact Serialization (siehe https://datatracker.ietf.org/doc/html/rfc7515#section-3.1 und https://datatracker.ietf.org/doc/html/rfc7515#appendix-F).
   • Der Zustelldienst nutzt für die Signatur einen gültigen Key aus dem bestehenden https://<URL der Submission-API>/.well-known/jwks.json Enpunkt, damit externe Systeme die Signatur der Zustellpunkt-Informationen prüfen können. Der genutzte Public Key aus dem Endpunkt wird anhand der Key-ID (kid) im Header der JSON Web Signature (JWS) angegeben.
   • Vor der Signaturanbringung/-prüfung müssen alle semantisch unbedeutenden nicht-druckbaren Zeichen (Leerzeichen, Tabs, Line Feed \n, Carriage Return \r) vor und nach den strukturierenden Zeichen ([, {, ], }, :, ,) aus dem JSON-Payload entfernt werden.
   • Vor der Signaturanbringung/-prüfung müssen die Attribute des JSON-Objekts in alphabetischer Reihenfolge sortiert werden.
2. Die Attribute des HTTP-Body im Endpunkt GET /destinations/{destinationId} werden in alphabetischer Reihenfolge ausgegeben.
3. null-Attribute im HTTP-Body des Endpunkt GET /destinations/{destinationId} werden nicht ausgegeben.
4. Der Abruf der öffentlichen Zustellpunkt-Informationen ("destination-public") im Endpunkt GET /destinations/{destinationId} ist ohne Authentifizierung möglich. Der Abruf der nicht-öffentlichen Zustellpunkt-Informationen ("destination-private" inkl. contactInformation und callback) ist weiterhin nur authentifiziert durch Subscriber möglich. Bei Abruf der nicht-öffentlichen Zustellpunkt-Informationen muss keine Signatur ausgegeben werden. Wenn ein Client mit einem Access Token mit einem send:region:DE<region-id> Scope eine GET Abfrage durchführt, muss er auch eine Antwort mit den signierten öffentlichen Zustellpunkt-Informationen wie bei einer Anfrage ohne Authentifizierung. -> verschoben nach #742 (closed)
5. Bei Abruf der nicht-öffentlichen Zustellpunkt-Informationen (destination-private) durch einen Subscriber muss keine Signatur ausgegeben werden.
6. Die im Endpunkt GET /destinations/{destinationId} via HTTP-Header ausgegebene Signatur wird nicht bei jedem GET-Request, sondern nur bei Veränderung des ausgegebenen Objekts aktualisiert (PUT/PATCH auf /destinations/{destinationId}, POST auf /destinations).
7. API-Spec Änderungen wurde im API-Spec MR für den Rückkanal ergänzt --> submission-api!132 (closed)
8. Abwärtskompatibilität zu früheren Versionen wurde geprüft.

Durchführungsplan

• Anpassung der API-Spezifikation der Submission API (Header-Parameter)
• Signautur im Endpunkt GET /destinations/{destinationId} ergänzen
• ...