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

út 16. 12. 2025 v 12:45 odesílatel Dr John O'Hare <w3c@xrsystems.uk> napsal:

> 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?
>

Git based is great. This is really interesting. I think on a longer time
line, keys will start to become exposed.


> 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.
>

I hadn't considered that. There are scenarios which need faster transition,
and those that need slower.


> 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.
>

Very good point. alsoKnownAs is something of a hack, that replaces sameAs /
seeAlso. The suggestion of using alsoKnownAs here is also a bit of a
kludge. Something to get the ball rolling until nostr has better solutions.


> 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.
>
>
Is this for HD wallets? That's a more complex case. Unsure anyone is using
HD Wallets with nostr yet.


> 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.
>
>
Delegation is definitely something that will be needed in future, we did it
with WebID and Solid and its needed. Henry Story had the concept of a
"secretary" as being an Agent that keeps your secrets.


> 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.
>

Definitely! I'll ask in the Nostr repo about NIP-41 or we can do a crawl, I
have about 250k profiles in my did:nostr store. If NIP-41 is not used, we
can perhaps make some proposals in the design space.


> 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
>
>
>