Re: Key Rotation & DID Nostr - Where do we stand?

Hi all,

Good timing on this thread - I'm currently writing up a funding proposal to expand a DID/Nostr-based human/agent collaboration layer within a multi-user visual ontology system I'm building. The key migration question is directly relevant, but from an angle that might usefully stress-test the current thinking. My system is git-based, and agents are prone to doxing themselves in commits. Private keys end up in version history. The question then becomes: what does key migration look like when you need to revoke authority from a potentially branching tree of autonomously-derived agent keys, not just a single identity?

For my use case, the critical metric is time-to-kill - how quickly can I propagate revocation across the network and ensure that a compromised key can no longer sign actions that will be accepted? Given that agents can potentially performa economic, data governance, workflow orchestration, the revocation window is the attack surface.

Recovery speed - how quickly delegated authority reconstitutes under a new key is secondary. I can tolerate slow rebuilding; I can't tolerate a zombie agent signing things for hours after I know it's compromised.

This makes me wonder whether the `alsoKnownAs` migration pattern, which is fundamentally about identity continuity, is the right primitive for revocation semantics. They're related but not identical concerns. Where this gets properly messy: if a mid-level agent key is compromised - say, one that has itself derived a subtree of sub-agents via deterministic derivation the `alsoKnownAs` pattern assumes 1:1 migration. It seems like compromise of a parent key arguably poisons the entire derivation branch, since an attacker with the parent key can derive all children.

The current spec doesn't address:

1.  Cascading revocation signalling - how do you atomically indicate that an entire derivation subtree is invalid?
2.  Propagation timing guarantees - Nostr's eventual consistency model means revocation events race against attacker actions, with no bounded propagation time
3.  Structure preservation - if `parent_key_A` derives `{child_A1, A2, A3...}`, then `parent_key_B` will derive entirely different children. Obvs we cannot re-root a subtree under a new parent. The new key could explore the same derivation paths, so in practice, migrating a compromised hierarchical agent structure means O(n) independent migrations, each agent publishing its own `alsoKnownAs` chain, with no guarantee the structure itself survives intact.

curious if others have views:

1.  Explicit delegation over deterministic derivation - agents hold independent keys with authority granted via signed delegation credentials from parents. Compromise then requires revoking the parent and re-issuing delegation creds to existing children, but children's identities survive. The `controller` property in DID docs could potentially support this. This feels like a big change?
2.  Dedicated revocation event kind - rather than inferring deactivation from `alsoKnownAs` presence or `kind:0` conventions, a specific Nostr event kind for revocation with clear semantics. Could include subtree scope indicators. Less disruptive?
3.  Short-lived authority tokens - agents operate with time-bounded credentials requiring periodic renewal, bounding the damage window from any single key exposure. MUCH less distruptive, and an actionable design choice for my system. Ephemeral agents with time to live and an action passing framework makes sense to me and I will likely do that first.

On NIP-41 specifically - I'd also be interested to know its status. The draft I've seen focuses on single-identity migration, but the hierarchical agent case might warrant consideration if there's active work happening.

Does this framing resonate with anyone else working on agentic systems? Happy to share more detail on the specific architecture if useful.

John


On Tuesday, 16 December 2025 at 05:14, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

> Hi all,
> 

> As we continue developing the **DID Nostr specification**, the topic of key rotation has naturally come up. Since `did:nostr` embeds the public key directly in the identifier (e.g., `did:nostr:<pubkey>`), a true key rotation would, by definition, require changing the DID itself.
> 

> However, we can potentially support **key migration** using existing DID Core properties like `alsoKnownAs`. This method allows an old DID document to point to the new one, signaling the migration:
> 

> {
> "id": "did:nostr:oldpubkey...",
> "alsoKnownAs": ["did:nostr:newpubkey..."]
> }
> 

> This approach raises several technical questions we need to address in the specification:
> 

> ## Key Migration Questions
> 

> 1. **NIP-41 Status:** There was a proposal (NIP-41) for key migration within Nostr. Does anyone know the current status of this NIP? Is there active work being done, or has it stalled?
> 2. **Deactivation Signaling:** What is the best and most reliable way to signal that an old key/DID is deactivated or has been migrated? We have a few options:
> * A dedicated **Nostr event kind**.
> * A defined convention within the `kind:0` profile metadata.
> * Relying on **Resolver inference** based solely on the presence of `alsoKnownAs`.
> 

> Would love to hear thoughts on key rotation implementation experience, or on NIP41.
> 

> Related discussion on GitHub: https://github.com/nostrcg/did-nostr/issues/73
> 

> 

> Thanks,
> Melvin