Slack thread
Currently, if a PRIVATE_KEY is not provided to backend, the backend will generate a new key to be used for its own Open Payments client requests. In general, this is fine, but it becomes a problem when we want to replicate the services.
It's possible that if we put several backend's (Open Payments resource services) behind a load balancer, an external service that is verifying the signature originating from one of these backends will have issue verifying the correct key was used to sign the request. For example, if we have 3 backends behind a load balancer (A, B, C), and A makes a signed request, the external service may end up reaching service B (with a different key from A), which ends up resulting the service failing to validate the signature.
Slack thread
Currently, if a PRIVATE_KEY is not provided to
backend, the backend will generate a new key to be used for its own Open Payments client requests. In general, this is fine, but it becomes a problem when we want to replicate the services.It's possible that if we put several backend's (Open Payments resource services) behind a load balancer, an external service that is verifying the signature originating from one of these backends will have issue verifying the correct key was used to sign the request. For example, if we have 3 backends behind a load balancer (A, B, C), and A makes a signed request, the external service may end up reaching service B (with a different key from A), which ends up resulting the service failing to validate the signature.