SLIM identity: move beyond shared-secret PSK to JWT/JWKS/SPIRE (prereq for hosted/multi-user)

[juliarvalenti]

Move SLIM identity beyond the shared-secret PSK (JWT / JWKS / SPIRE)

Type: enhancement / hardening — hard prerequisite before anything hosted or multi-user.

Current state

SLIM app identity today is a deterministic shared-secret PSK: a per-channel secret is HMAC-SHA256(master_secret, "workspace/room"), derived independently by every host so no key-exchange round-trip is needed. Passed to the fabric via service.create_app_with_secret(name, secret).

• Master secret: MYCELIUM_SLIM_MASTER_SECRET, else a public dev literal committed in-repo (mycelium-dev-shared-secret-v1-do-not-use-in-prod) — anyone with the repo can derive it, so it authenticates nothing on its own.
• MYCELIUM_SLIM_REQUIRE_SECRET=1 fails closed on a host that forgot to set a real secret.
• Source: fastapi-backend/app/services/slim_client.py (~L61-75, mint_shared_secret/resolve_master_secret) and the CLI mirror mycelium-cli/src/mycelium/slim/naming.py.
• CLAUDE.md already flags this: "real identity (JWT/SPIRE) is a hard prerequisite before anything hosted / multi-user."

Gaps this creates

• No per-agent identity. The secret is scoped to workspace/room — the agent segment is ignored — so every member of a room is cryptographically indistinguishable.
• No revocation. Removing an agent's access means rotating the room/master secret for everyone.
• Shared-secret parity trap across hosts (documented in docs/cross-machine.md): every host must set the same private master secret out of band.

What the fabric already supports (from the audit)

slim-bindings exposes a full identity stack we don't touch — verified in the upstream examples (_slim-research/slim-bindings/python/examples/common.py):

• JWT + JWKS — IdentityProviderConfig.JWT / IdentityVerifierConfig.JWT, ClientJwtAuth, JwtKeyConfig (JwtAlgorithm.RS256, JwtKeyFormat.PEM|JWKS, JwtKeyData), audience/issuer/subject/duration. Identity = the sub claim; per-agent identity falls out naturally.
• SPIRE / SPIFFE — IdentityProviderConfig.SPIRE / .SPIRE verifier, SpireConfig(socket_path, target_spiffe_id, jwt_audiences, trust_domains). Consumes JWT-SVIDs from the SPIRE Workload API: zero-secret bootstrapping, automatic rotation, workload attestation. Upstream's recommended production setup.
• App creation switches from create_app_with_secret(...) to service.create_app(name, provider_config, verifier_config).
• Transport is a separate axis: node TLS/mTLS today is insecure: true (see the inline node config in docker/compose.yml); SPIRE can also source mTLS certs (tls.source.type: spire).

Suggested direction

• Add a JWT/JWKS identity path behind a config seam, keeping shared-secret as the local-dev default.
• Evaluate SPIRE for the hosted/multi-user target (recommended upstream); scope what a SPIRE agent + trust domain looks like in our deploy.
• Turn on node TLS for any non-localhost topology (pairs with mycelium hub host / mycelium connect).
• Define per-agent identity + revocation semantics on top of real identity tokens.

Notes

This supersedes the inline "debt D1" comment shorthand scattered in slim_client.py/naming.py (that label should get scrubbed in the audit-comments pass, #455). Reference checkout: ../_slim-research/slim-bindings/python/examples/common.py shows all three auth modes end to end.

[juliarvalenti]

Re-scope: identity is for the trust domain, not public multi-tenant

The "prereq for hosted/multi-user" framing is superseded. We've drawn the deployment boundary: Mycelium is a trust-scoped self-hosted appliance — one instance per trust domain (GitLab-self-managed style), not a public multi-tenant SaaS. The architecture (hub-moderator reads plaintext, LLM interprets agent text as good-faith, Pi executes on behalf of agents) only makes sense inside a trust boundary, so "sign up and share a hub with strangers" is explicitly out of scope.

That doesn't kill this work — it re-aims it. JWT/JWKS/SPIRE is still worth doing, but for three in-boundary reasons:

1. Per-agent identity + revocation within a trust domain — so humans and agents on one hub are distinguishable and individually revocable, replacing the single shared PSK.
2. API authentication — the HTTP API is currently completely unauthenticated (real problem even single-tenant; today we firewall to compensate). A JWT doubles as the bearer token on the CLI/browser → backend path.
3. The thin-spoke hub-and-spoke story — a machine or browser joining a remote hub as an authenticated client (the mycelium join <hub> flow), which is how multi-machine works without every spoke running its own moderator.

Suggested retitle: drop "prereq for hosted/multi-user" → "Per-agent identity + API auth within a trust domain (shared-PSK → JWT/JWKS/SPIRE)."

[juliarvalenti]

Concrete gap this must close: agent impersonation + false attribution

Surfaced while building the self-asserted principal layer (#495). The principal work adds owner/team on agents, a global user store, and inline owner attribution in the chat (CLI + UI). But at the self-asserted tier, ownership is a label, not a lock — which this repro makes concrete.

Setup: handshake-bot is a registered claude_code agent with owner: julia.

Repro (as an unrelated caller "joe"):

mycelium room send --room handshake --handle handshake-bot "joe here, speaking as julia's agent."

Result — it posts, and renders as:

handshake-bot owned by @julia [broadcast]: joe here, speaking as julia's agent.

The attribution isn't just unverified, it's actively wrong: joe's words are stamped onto julia's agent.

Three holes, one root (no verified identity)

1. No caller identity. Nothing establishes that the caller is joe (or anyone). --handle handshake-bot is taken at face value.
2. No owner check. The manifest says owner: julia, but the post path only checks the handle is a real, non-engine principal — never "are you julia / are you handshake-bot?"
3. The owner field is writable. mycelium agent create handshake-bot --owner joe upserts the manifest and takes it outright. It's a string in a markdown file.

What already landed vs. what #476 must add

• Landed (First-class principal: agent owner/team + user store + attribution #495, role-based, self-asserted): engines are non-impersonable and phantom handles can't post (app/services/principals.py:post_rejection_reason + guards in routes/participate.py and routes/messages.py). This enforces role, not identity — deliberately, since there's no identity to check yet.
• SLIM identity: move beyond shared-secret PSK to JWT/JWKS/SPIRE (prereq for hosted/multi-user) #476 must make owner + caller into signed claims (JWT/JWKS/SPIRE, per-member SLIM binding instead of the shared PSK) so the post-path guard can finally reject "you're not julia and you're not handshake-bot." Only then does inline attribution (owned by @julia) become trustworthy rather than merely consistent.

Docs already frame the current tier honestly as "consistent, not cryptographic" (docs/principals.md); this is the specific thing that flips it to cryptographic.

[juliarvalenti]

Client↔identity binding: what the self-asserted tier does vs. what verified auth must add

Follow-on from the impersonation note above, surfaced while building the in-app identity editor (#496). This is about the bind step — connecting a machine's client to an identity — and why the current version is a convenience, not auth.

What ships now (self-asserted, #496)

• The app's acting-as picker lets you create/edit a user (name, teams, notify) and, after selecting, flashes a copyable one-liner: mycelium iam julia --name "Julia Valenti" --team core.
• mycelium iam <handle> sets local identity.name and upserts the local users/<handle> record. Writes are content-idempotent, so re-running converges.

The catch (why this isn't auth yet)

• iam is client-local. It never contacts the server. It writes the local .mycelium store + local config. There's no fetch of a server-side record and no verification.
• So the "bind your machine to this identity" framing is really "self-assert this identity on this machine." The reason the copyable command carries the full fields (--name/--team/...) is precisely because the client can't pull them from the server — it has to reproduce the record locally.
• There are effectively two disconnected "who am I" stores: the browser's acting-as (localStorage) and the CLI's config.identity.name. Neither is anchored to a server-verified identity; both are consistent-not-cryptographic.

What #476 (verified tier) must add

• Server-anchored identity. The machine's client should authenticate to the backend and fetch its principal (JWT/JWKS/SPIRE), rather than self-asserting a local handle. iam (or its successor) becomes "log in / bind to this verified identity," not "write a local file."
• Signed owner/actor claims so "acting as julia" and "this agent belongs to julia" are verifiable — closing the impersonation gap in the note above (joe posting as julia's handshake-bot).
• One identity per machine, reconciled with the server, instead of the browser-local + CLI-config split we have now.

Net: #496 makes the shape right (there's a user, an owner, a bind action, an idempotent record) so #476 can swap the self-asserted local write for a verified server bind without reworking the model or the UX.