RTD: Signaturprüfung der Adressierungsinformationen anpassen
User Story
Als Nutzer des Routingdienstes möchte ich auch solche Zustellpunkte finden, deren DestinationSignature in Zukunft vom Zustelldienst generiert und signiert wird.
Die Prüfung der DestinationSignatures muss in Zukunft wie folgt ablaufen (vgl. #2379):
- Prüfe den Issuer, dass seine Domain mit
.fit-connect.fitko.net
endet (.fit-connect.fitko.dev
beim Testsystem) - Hole das JWKS vom Issuer (Issuer +
/.well-known/jwks.json
), z.B.https://test.fit-connect.fitko.dev/.well-known/jwks.json
- Prüfe den Schlüssel gegen das JWKS.
Für die Testumgebung muss ein neuer Issuer hinzugefügt werden: https://test.fit-connect.fitko.dev/.well-known/jwks.json bzw. https://test.fit-connect.fitko.dev/
Analog für die Produktivumgebung: https://prod.fit-connect.fitko.net/.well-known/jwks.json bzw. https://prod.fit-connect.fitko.net/
Warum
Anbindungsprojekte wollen die DestinationSignature per API beziehen, um sie automatisiert ins PVOG einpflegen zu können. Bisher genereriert das Self-Service-Portal die DestinationSignatures. Die Daten der Zustellpunkte werden im Zustelldienst gespeichert. Daher müsste in Zukunft der Zustelldienst die DestinationSignature generieren und signieren, um sie per API berreitstellen zu können.
Links, Hinweise, Bemerkungen
Akzeptanzkriterien
-
Die bisher vom SSP generierten und signierten DestinationSignatures werden in der Prüfung durch den RTD akzeptiert. -
Die in Zukunft vom ZSD generierten und signierten DestinationSignatures werden in der Prüfung durch den RTD akzeptiert. -
...
Mögliche Folgeaktivitäten (vom Entwickler zu ergänzen)
-
Test in der Testumgebung, sobald ZSD dort DestinationSignatures generieren kann -
... -
... -
Definition of Done was checked.