You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
We are already working with a token. However, this has currently several shortcomings:
It is sent in clear text towards the backend for verification.
It cannot be reset.
There is no public key to verify it.
It is stored within the backend, so not really private.
Describe the solution you'd like
We should update the token to be a private key that is only known to the user and never sent to the backend. This could be done through a nicer cryptographic approach. Current idea:
create the token visible for the user.
store the associated public key with the appropiate storage_provider
use the private key to sign a simple message that shows that the token is valid, basically a very simple challenge.
most likely this requires a new version for the API, but we will see.
Describe alternatives you've considered
We could also have tried to store a private key on the backend. However, this would not be private in any way and should be avoided.
Additional context
This is all part of an effort to establish cryptographic ownership of jobs as described here and enabling ideas like this on payment.
The text was updated successfully, but these errors were encountered:
The approach with a private key is good for signing. However, it does not allow you easily to authentificate the user. Therefore, we might have further looks into this. For the moment it might be best to keep the API key for authentification very much like IBM is doing it as described here. Then we have a header which contains Authorization: Bearer YOUR_API_TOKEN_HERE. The full code example is:
Is your feature request related to a problem? Please describe.
We are already working with a token. However, this has currently several shortcomings:
Describe the solution you'd like
We should update the token to be a private key that is only known to the user and never sent to the backend. This could be done through a nicer cryptographic approach. Current idea:
Describe alternatives you've considered
We could also have tried to store a private key on the backend. However, this would not be private in any way and should be avoided.
Additional context
This is all part of an effort to establish cryptographic ownership of jobs as described here and enabling ideas like this on payment.
The text was updated successfully, but these errors were encountered: