[DRAFT RFC] Browser-based auth & one-command client provisioning

[saadqbal]

Summary

Design epic (DRAFT) for replacing the "create a client in the web UI, copy Client ID + password, paste into installer" onboarding with: sign in (browser device flow) → name + confirm location → done.

Draft RFC lives at docs/rfcs/0001-cli-auth-and-client-provisioning.md (currently uncommitted on develop — to be opened as a PR for review once it firms up).

Key findings that shaped it

• Client = EdgeDevice (Django User subclass). Human-readable name (first_name) and structured location (location → Electricity Maps ZONE_CHOICES) already exist and feed a working carbon pipeline. No new model fields needed.
• Provisioning API already exists: POST /edge-device/ (writable: first_name, account, location, password).
• Auth today = DRF token + Google/GitHub web OAuth. No RFC 8628 device flow, no PAT — the only net-new backend surface.
• A maintained Go CLI (tracebloc/cli, v0.2.0) already exists and is installed by the client installer — the right home for login + client create.

Status

DRAFT — open for enhancement. Not approved.

Next steps (not started)

• Resolve open questions (esp. air-gapped segment, namespace derivation, location-change semantics) — see RFC §11
• Open the RFC as a PR for team review
• Split into sub-tickets across backend (device endpoints), cli (commands), client (installer reorder) — RFC §12

Constraints carried in

• Credentials entered by the user interactively / browser — never through tooling.
• Dual-mode: existing Client ID + password installs must keep working.

[LukasWodka]

Retiring this RFC tracking issue as superseded by backend#830 — the RFC-0001 epic now lives there (North Stars; cross-repo plan + the flow-family trackers #877–880), and the RFC document is PR #55. Consolidating to two non-redundant artifacts: #830 (tracker) + #55 (doc). Per @LukasWodka — @saadqbal, reopen if you'd rather keep this as the cli-side index.