The monolithic open-questions.md (1310 lines, 47 OQs) was large enough to be unmanageable, with high size variance (OQ-42 at 220 lines next to OQ-06 at 8). Decomposed into one file per OQ under docs/architecture/questions/ (NNN-slug.md, mirroring the ADR convention), with open-questions.md retained as the index: theme-grouped tables plus a cross-theme Deferred/Blocked section that surfaces the 6 deferred OQs with their Blocked-on conditions inline (the safe-exit visibility surface). Per-OQ content moved verbatim; all 62 inbound links stay valid (none used anchors). README's curated OQ summary dropped (now redundant with the index tables). Also seeds tasks/architecture/ with this task plus two follow-ups found during the decompose: OQ-09/10 missing structured Blocked-on fields, and the tasks/architecture/ blocker-task half of the Safe Exit protocol being unenforced.
1.4 KiB
OQ-35: API Key Identity vs Peer Identity (Dissolved)
-
Origin: ADR-030 §"API keys" (the asymmetry between the two auth paths)
-
Status: dissolved (2026-06-27 — the framing was wrong)
-
Door type:
One-way -
Priority:
medium -
Resolution: Dissolved. The original framing ("the fingerprint path gets
PeerEntryid-decoupling, the API-key path doesn't — the asymmetry is deliberate") was based on a false distinction between "peer bearer" and "auth bearer" tokens. The correct framing is the three credential types (Ed25519, X.509, bearer token) and whether the token needs a stable logical id across rotation:PeerEntrysupports multiple credential paths:fingerprints: Vec<String>(Ed25519 and/or X.509) +auth_token_hash: Option<String>(bearer token). All resolve to the samepeer_id.ApiKeyEntryis for bearer tokens that ARE the identity (rotation = new identity, no stable logical id needed).
A bearer token that is one credential path among several for a stable peer goes in
PeerEntry.auth_token_hash. A bearer token that IS the identity stays inApiKeyEntry. The distinction is whether the token needs a stable logical id across rotation, not "peer bearer vs auth bearer." See ADR-030 §"Bearer tokens."