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
Currently, we store private keys inside XDI graphs. They are persisted in the graph store. We need some abstraction layer here that allows private keys to be handled more securely. Similar considerations apply to the handling of secret tokens.
There is a certain abstraction mechanism for some crypto operations already in place. For example, in order to validate signatures on an incoming XDI message, the corresponding public key could be obtained using XDI discovery, it could be hardcoded in a configuration file, or it could come from other sources. This abstraction is a good start, but needs to be improved.
Currently, we store private keys inside XDI graphs. They are persisted in the graph store. We need some abstraction layer here that allows private keys to be handled more securely. Similar considerations apply to the handling of secret tokens.
There is a certain abstraction mechanism for some crypto operations already in place. For example, in order to validate signatures on an incoming XDI message, the corresponding public key could be obtained using XDI discovery, it could be hardcoded in a configuration file, or it could come from other sources. This abstraction is a good start, but needs to be improved.
See also:
https://github.com/projectdanube/xdi2/wiki/AuthenticationSignatureInterceptor
https://github.com/projectdanube/xdi2/wiki/AuthenticationSecretTokenInterceptor
The text was updated successfully, but these errors were encountered: