How to Secure User Keys
The first step is giving the user access to a cryptographic identity. Ideally this would be portable between different devices and applications, but also remains backed up and private.
1. Mnemonics
We use BIP-39 to produce 12 words, and the user is responsible for backing them up somewhere.
The mnemonic is converted to raw data (entropy) which is used to deterministically derive a key pair
2. WebCrypto IDB Non-Extractable
Browser is responsible for storage, key is not visible or usable to the user or any JS code running in the browser.
This is how web keys are currently saved. But it is problematic for long-term identities because the browser frequently wipes the data.
3. OS Keychain
We currently use this for storing keys in the desktop app.
Ideally the keychain will be backed up and synced to other devices by the operating system, but it is not currently doing that.
Note: We save mnemonics in the desktop app using a similar approach, but the keychain holds only the decryption key, and the encrypted mnemonics are saved to disk inside the app's data dir.
4. Zero-Knowledge Server Storage
Described in detail in Zero-Knowledge Multi-Device Identity System
The simple way to think about this: The server stores the encrypted key, and the user is required to remember a decryption passphrase.
How to Use and Link Keys
Now that the user has some form(s) of crypto keys that they can use to sign content, we need mechanisms to give those keys meaning.
1. Domain-Key Linking
A special API endpoint on a domain can specify what is the public key, and that public key can also sign something that says "my domain is X"
This is how Web Sites are currently associated with HM Accounts.
1A. Multi Domain Key
In theory, a domain could specify a list of keys that are allowed to represent it.
2. Agent Capabilities
One key gives another key full access to write on behalf of itself. This is dangerous but is how we accomplish device linking today.
3. Profile Redirects
One key will create a profile blob that redirects to another account ID.
4. Contacts
A generic ability for one key to sign information about another key. This information can include an edge name or other metadata, possibly specifying if this key is a device for the same user.
This mechanism can be used for a server to sign information about other keys that are used on that server. For example the gabo.es key can sign something saying that another key has authenticated as Gabo, and this may be interpreted by readers as coming from the same person.
Forming Permanent References
Right now when we want to refer to a person or an organization, the users will usually think in terms of domains. But we store the identities in the form of account IDs. This is a disconnect we should probably remedy.
Referencing Account IDs
Save the reference to the person/organization/site by using the account ID in URL format, such as hm://z1234...
Account ID references are good because they are trustless, they last forever, and they do not rely on external infrastructure.
Referencing Domains
Domains are easy for people to read and memorize.
When referencing with domains, the keys can be rotated or accounts can be recovered.
Hybrid References
Ideally, we will move to a form of reference which primarily uses account IDs but also saves the domains.
This allows us to reach the benefits of both reference types, but it requires additional UX to handle situations where the domain is unreachable or if the key has changed.