wiki: record JWT key open question; defer ESP32 controller

- open-questions #7: symmetric vs. asymmetric JWT signing key (from the
  commit security review). Prefer RS256/EdDSA so verifying hosts hold only a
  public key — mirrors the ATECC608 / challenge-response "public key only"
  property. Decide before multi-host/multi-lane deployment.
- Mark esp32-custom-controller status: deferred per decision not to build
  device-level auth now; access control stays on UHPPOTE + network isolation
  (noted in open-questions #6).
- local-jwt-auth: document hardened secret handling + 8h expiry and the
  asymmetric-key pointer.
- Update index.md and append a log.md entry.

wiki/decisions/open-questions.md

@@ -2,7 +2,7 @@
 type: decision
 tags: [parking, decisions, open]
 sources: [parking-system-architecture]
-updated: 2026-06-14
+updated: 2026-06-15
 status: open
 ---
 
@@ -25,6 +25,17 @@ status: open
    control. See [[reconciliation]].
 5. **Durability / backup.** Backup strategy for the [[sqlite]] database + recovery plan; "sync
    later" currently leaves a disk failure as **total revenue-history loss**.
-6. **Secure-element integration.** Confirm [[atecc608]] wiring/usage on both the host (event
-   signing) and, if pursued, the custom controller (command authentication — see
-   [[esp32-custom-controller]]).
+6. **Secure-element integration.** Confirm [[atecc608]] wiring/usage on the host (event
+   signing). The [[esp32-custom-controller]] command-authentication use is **deferred — not
+   being implemented for now** (access control stays on the [[uhppote-controller]] behind
+   [[network-isolation]]); revisit only if prevention-grade device auth becomes a requirement.
+7. **JWT signing: symmetric vs. asymmetric key.** _(Raised by the commit security review, not the
+   source doc.)_ Auth currently uses a symmetric HMAC secret (`@fastify/jwt`, see
+   [[local-jwt-auth]]) — the same secret signs *and* verifies, so it must live on every host that
+   validates tokens. Consider rotating to an **asymmetric key (RS256 / EdDSA)** so the server
+   holds only the **public key** to verify; the private signing key can then live in the
+   [[atecc608]] or a key-management step. This mirrors the "store only the public key" property
+   already used for [[atecc608]] event signing and the [[challenge-response-auth]] scheme —
+   compromising a verifying host yields nothing that can forge a token. Decide before
+   multi-host / multi-lane deployment (see #1 lane topology), since that's when shared-secret
+   distribution becomes the liability.