Key Migration & Revocation Patterns with alsoKnownAs

Hi all,


We're working on the DID Nostr specification and have been discussing key
migration/rotation. Since did:nostr embeds the public key directly in the
identifier, true rotation requires a new DID, so we're exploring
alsoKnownAs as a migration signal:


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




This has surfaced some questions we suspect the CCG has encountered before:

1. Migration vs Revocation: alsoKnownAs seems designed for identity
continuity, but revocation has different requirements (especially
time-sensitive "kill" semantics). Has the CCG explored separating these

concerns?
2. Hierarchical Keys: For agentic systems with delegated/derived keys,
compromising a parent key may poison an entire subtree. Are there
established patterns for cascading revocation signaling?
3. Propagation Timing: In eventually-consistent networks, revocation events
race against attacker actions. Any guidance on bounding this window?

Would appreciate any pointers to prior art, specs, or lessons learned.
Happy to share more context on the Nostr-specific constraints if helpful.


Thanks,


Melvin