Description
One of the core concepts of Atomic Data is that users sign their changes using their identity. This allows for fully traceable, verifiable information, which is one of the core features of atomic data. However, this also poses a challenge: how do you manage the private key? How do you deal with users forgetting their key, how do you make sure that the key is stored safely in apps? In this issue, we'll discuss various topics related to key management of Agents.
Storing the key safely in client apps
Client apps need the key to sign Commits. We don't want to bother users by entering their key on every single commit, but we do want to protect them.
In the current implementation of atomic-data-browser, the private key is simply stored in the front-end app, which is not great for security (see issue).
Forgetting a secret
If you don't know your secret (containing the private key), you can't log in anywhere or sign anything. Since an Agent is stored on some Server, the server's admin can always change the Agent's public key. This process should be facilitated through software, maybe even through a standardized endpoint. It might be a good idea to, as a backup, add your e-mail to your agent.
Easy-to-remember secret
At this point in time, secrets are very long strings that are practically impossible to remember. This means users have to use some form of key-manager (e.g. bitwarden / lastpass / browser password store), which is a bit inaccessible for some. We could use some form of seed that is easier to remember, but this still needs a nice bit of randomness / entropy.
The BIP39 spec uses an set of words such as welcome bar control expand desk wonder naive stove sight human furnace arrow ill exclude govern.
Session scoped keys
If a user enters their secret and the app needs to store that secret to sign items, we will always have a risk of leaking that secret somewhere. If we scope keys to sessions, we can reduce this risk. We could let users enter their secret to prove their identity to the server, and sign some nonce from the server. This signed nonce could be used as the seed for a new session scoped private key, which signs the actual commits. In theory, Commits signed by these derived keys would still be traceable to the Agent.