I wish Nostr used DIDs, specifically a new DID spec that functions something like this:
Each DID document includes:
- A version number, which the owner increments each time a new version of the DID document is created.
- A master key, where the pubkey acts as the identity. The master private key is intended to live in cold storage, think of it as an "in emergency break glass" key.
- One or more update key(s), that can be rotated by creating a new DID document and signing it with the master key. Update keys have authority to sign new versions of the DID document, changing the list of update keys or verification keys + permission strings. Update private keys are intended to live in an identity wallet on a users device.
- One or more verification key(s), with a string of permissions granted to the key(s). These are intended to be used to grant permissions to applications.
- A version history that lists revoked update keys and verification keys.
- A list of relays the DID document owner uses.
This would grant a bunch of nice properties, such as:
- Ability to revoke update and verification keys in case of compromises.
- Key rotation would not lead to your pubkey/identity changing, which would break eg. mentions in Nostr.
- No need for complex key share handling where you must dispose of shares when rotating keys, and having to have multiple devices on at all times to be able to use Nostr, like would be the case with Frostr which uses a threshold based signature scheme.
- No longer needing to use remote signers as a best practice in all cases, if a verification key is compromised it is a limited amount of damage it can do since permissions are limited to only what you want to give the application ability to do.
- Because the DID documents have to be signed either with a master key or an update key, they can't be changed without invalidating the signature, which makes it easily cryptographically verifiable that a DID document has in fact been signed by the owner.
(Not an exhaustive list, just some highlights).
DID documents would be distributed to DID Directory Relays. The relays would not have any authority over the documents, just like in Nostr today, if a relay blocks you, users can simply find your DID document on a different relay. The DID document can also be sent directly to a user or service without going through a relay. This is fundamentally different than eg. AT Protocol that relies on the centralized PLC Directory for distribution of DID documents.
Each DID document includes:
- A version number, which the owner increments each time a new version of the DID document is created.
- A master key, where the pubkey acts as the identity. The master private key is intended to live in cold storage, think of it as an "in emergency break glass" key.
- One or more update key(s), that can be rotated by creating a new DID document and signing it with the master key. Update keys have authority to sign new versions of the DID document, changing the list of update keys or verification keys + permission strings. Update private keys are intended to live in an identity wallet on a users device.
- One or more verification key(s), with a string of permissions granted to the key(s). These are intended to be used to grant permissions to applications.
- A version history that lists revoked update keys and verification keys.
- A list of relays the DID document owner uses.
This would grant a bunch of nice properties, such as:
- Ability to revoke update and verification keys in case of compromises.
- Key rotation would not lead to your pubkey/identity changing, which would break eg. mentions in Nostr.
- No need for complex key share handling where you must dispose of shares when rotating keys, and having to have multiple devices on at all times to be able to use Nostr, like would be the case with Frostr which uses a threshold based signature scheme.
- No longer needing to use remote signers as a best practice in all cases, if a verification key is compromised it is a limited amount of damage it can do since permissions are limited to only what you want to give the application ability to do.
- Because the DID documents have to be signed either with a master key or an update key, they can't be changed without invalidating the signature, which makes it easily cryptographically verifiable that a DID document has in fact been signed by the owner.
(Not an exhaustive list, just some highlights).
DID documents would be distributed to DID Directory Relays. The relays would not have any authority over the documents, just like in Nostr today, if a relay blocks you, users can simply find your DID document on a different relay. The DID document can also be sent directly to a user or service without going through a relay. This is fundamentally different than eg. AT Protocol that relies on the centralized PLC Directory for distribution of DID documents.
4
