This is why I proposed a “burn notice” event to @nostr.build. Anyone with the private key for an npub should be able to issue a “burn notice” event that includes a reason, say “key_compromise” or “migration”. If nostr / npub+nsec will be used for authentication, then key revocations must be made possible. In bring-your-own identity models, the user is the credential issuer (not a centralized identity provider) so the user (or private key holders) should be able to notify the nostr network (via the nostr signed event) that the key should not be used or treated with extra care. Nostr clients could warn appropriately for interactions with burnt nbups and websites using auth like described above could also handle appropriately.

With proper client handling decisions around burn notices, it could be made only attractive to the real user to issue a burn notice, and disadvantageous for an attacker with the private key to burn it intentionally.

For example, the burn notice event should include a hint to the new npub but clients should be careful about allowing interaction with new npub. NIP-05 verification could enable smooth transition to the new npub since control of the dns domain is demonstrated in addition to having the private key. Attackers would also need to gain control of the nip05 domain to abuse burn notices in their favor.

Also, npub / nostr authentication to websites should add TOTP codes (not passwords!) on top for mfa