Add support for key rotation in DID Document

[sondreb]

I'm not sure if there is a NIP or kind for announcing a potential lost private key, but if there is one, we could easily implement key rotation for the Nostr DID Method. What it would do is find this event, then return the new pubkey as the DID Method and not the old one.

This means the DID Subject will not change, it will continue to work and resolve just fine, but with the new pubkey.

[melvincarvalho]

Thanks for raising this. Key rotation is an important topic for DID methods.

The Challenge

The did:nostr method has a fundamental constraint: the public key is the identifier (did:nostr:<pubkey>). True key rotation would change the DID itself, which breaks the core DID principle of persistent identifiers.

Nostr Protocol Status

NIP	Status	Description
NIP-41	Draft/Stalled	Key migration - new key, old key signs attestation
kind:1776	Proposed	Key rotation event

Neither is widely adopted yet.

Possible Approaches

1. Track NIP-41 migrations - Return new key in alsoKnownAs, old DID still resolves
2. Multiple verification methods - Include both old (revoked) and new keys in verificationMethod array
3. Deactivate old DID - Set didDocumentMetadata.deactivated: true when migration detected
4. Change DID structure - Use did:nostr:<stable-id> instead of pubkey (breaking change)

Current Spec Position

The DID Nostr spec currently states:

This DID Method does not support updating the DID Document.

Recommendation

This might be worth discussing at the spec level first. The resolver could implement whatever semantics the spec defines. Options 1-3 above could be implemented without breaking changes once there's clarity on the expected behavior.

Would it make sense to open an issue on nostrcg/did-nostr to discuss key rotation semantics for the spec?