n_signer/plans/seed_phrase_uses.md

Seed Phrase Use Catalog for n_signer

This document catalogs potential uses of a single memorized BIP-39 seed phrase when mediated through n_signer role/purpose/curve controls.

It is intentionally expansive: some entries are immediate, others are future-facing.

1. Core idea

A single mnemonic can deterministically derive many key families. n_signer treats those as distinct role entries with explicit metadata:

• purpose
• curve
• derivation selector/path
• policy scope

This prevents "same seed means same trust domain" mistakes by separating identities at the policy layer.

2. Immediate and near-term domains

2.1 Nostr identities (purpose="nostr")

• Curve: secp256k1
• Typical shorthand: nostr_index -> m/44'/1237'/<index>'/0/0
• Uses:
  • main pub identity
  • throwaway anti-correlation identity
  • per-app/per-origin identities
  • delegated service identities for local systems

2.2 Bitcoin keys (purpose="bitcoin")

• Curve: secp256k1
• Typical path families (examples):
  • BIP44 legacy account trees
  • BIP49 wrapped-segwit
  • BIP84 native segwit
  • BIP86 taproot keypath flows
• Uses:
  • deterministic receive/change branches
  • per-context account segregation
  • deterministic recovery for wallet setups

2.3 Lightning-related identity material

• Curve: usually secp256k1
• Uses vary by node software and key hierarchy model.
• Practical use with n_signer should be constrained to explicit purpose-bound role entries, not shared with general signing identities.

2.4 Mesh/service identities (purpose="fips" and similar)

• Curve: primarily secp256k1 in current planning
• Uses:
  • deterministic node identity roots
  • stable key-derived addressing inputs
  • service bootstrapping in reproducible deployments

3. Additional potential domains

3.1 SSH identity material (purpose="ssh")

• Candidate curves: ed25519 (primary), potentially others
• Uses:
  • deterministic host/user key regeneration
  • environment-specific SSH key derivation without storing private keys on disk

3.2 age-style encryption identities (purpose="age")

• Candidate curves: x25519 / age-native identity mapping
• Uses:
  • deterministic file encryption identity recovery
  • reproducible offline decryption setups

3.3 WireGuard-like transport identities

• Candidate curves: curve25519 family
• Uses:
  • deterministic tunnel identity generation
  • ephemeral/per-peer derivation schemes (policy-gated)

3.4 PGP/OpenPGP-like profiles (future)

• Possible but operationally complex due to multipurpose key lifecycles and tooling expectations.
• Better treated as explicit, isolated purpose entries if ever added.

3.5 Deterministic password or secret derivation (future)

• Could derive app/site secrets from role-scoped KDF outputs.
• Must never blur boundaries with signing keys; separate purpose namespace and strict export policy required.

3.6 API/service auth tokens (future)

• Per-service deterministic auth keys (HMAC or asymmetric challenge keys depending on service model).
• Strongly policy-scoped to avoid accidental cross-service linkage.

4. Curve and derivation notes

n_signer currently models curve metadata from day one:

• secp256k1
• ed25519
• x25519

Not every purpose should be valid on every curve. Enforcement should be explicit in policy/runtime validation.

5. Operational caveats

1. One seed phrase is one root compromise domain

   • If the mnemonic is exposed, every derivable domain is exposed.

2. Purpose isolation is mandatory

   • Reusing one role across unrelated domains collapses privacy and security boundaries.

3. Pre-registration requirement matters

   • Arbitrary ad-hoc role_path requests are too permissive; only pre-registered paths should be derivable by clients.

4. Policy must constrain verbs + purposes + roles

   • A caller authorized for Nostr signing should not implicitly gain rights for Bitcoin or SSH derivations.

5. Auditability and naming discipline are crucial

   • Human-readable role names should clearly encode domain intent to avoid operator mistakes.

6. Practical guidance

Recommended baseline for early deployments:

• keep purpose="nostr" roles as primary production scope
• add non-Nostr purposes only when a concrete consumer exists
• require explicit approval to register new purpose+path combinations
• test recovery procedures per purpose before relying on them operationally

7. Relationship to main docs

• Product behavior contract: README.md
• Implementation sequencing: plans/nsigner.md
• Browser integration planning: plans/nsigner_browser_extension.md