Research how to generate signatures on the backend

Is your feature request related to a problem? Please describe.
Currently, the PASS document signing process goes through these steps:

1. The PASS client requests the private key stored in the User_Credentials container of the user's Pod server
2. The pod returns the private key to the PASS client
3. The PASS client uses the private key to generate a signature
4. The PASS client sends the signature document to the pod server

This flow is less than ideal from a security perspective. Private keys are supposed to be kept top secret. Constantly transferring them between client and server like this makes it easier to steal the private key and impersonate the user. There is also no way for the server to guarantee that the PASS client has cleared the private key from the client's own storage

Describe the solution you'd like
A better approach would be if the PASS client could send the Pod server the document it wants signed, then the pod server could access the user's private key itself, and return a signature. Then the server wouldn't have to transfer the key back and forth.

Describe alternatives you've considered
Another possibility would be for PASS to store the keys for its users itself, in its own database outside the users' pods. This would mean PASS could enforce its own security requirements, without having to rely on the user's pod. However, this requires setting up a centralized user database. That would transform PASS into a full-stack application instead of a client-only application. This would also break the user control of data that is the foundation of Solid.

There may also be a way to generate one-time use signing keys. This would make the loss of such a key less damaging, as it could only be used the one time.

No files or tests are named. Start by tracing the existing PASS client signing flow, including the User_Credentials container and Pod server interaction. Done should be a documented, agreed approach for backend signature generation that addresses private-key handling and the stated alternatives.