parking_solution/wiki/decisions/open-questions.md

type, tags, sources, updated, status

type	tags	sources	updated	status
decision	parking decisions open	parking-system-architecture	2026-06-21	open

Open Questions / Next Steps

Not yet decided (or decided-but-not-yet-built), and they drive everything else — settle before procurement. (See parking-system-architecture §10.)

1. Lane topology. One host per lane, or one central host driving networked devices in each lane? Decides how many controllers, printers, UPSs, and sqlite instances exist, and the failure blast radius. (A single central host is a single point of failure for all lanes.)
2. Failure modes. Define per direction what happens to barriers on host/power/network loss — particularly fail-open on exit for egress safety. Currently unaddressed. See fail-state-safety.
3. Payment subsystem. Manned booth (P2PE terminal + cash drawer) vs unmanned pay station; confirm PCI scope is kept out of the application via a standalone certified terminal (see bom).
4. Reconciliation channel. Even if "offline," establish some periodic path (USB, hotspot, manager visit) to reconcile the signed log against an external authority — the real anti-fraud 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. (Confirmed in-scope to design, 2026-06-15.) Because the DB is the signed append-only-event-chain, a backup must preserve the chain intact (a restored copy must still verifyChain); options include SQLite WAL/online-backup snapshots to a second disk/USB + the periodic external export that doubles as the reconciliation channel (#4). Encryption at rest already applies (disk-os-hardening). Design TBD.
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 is the dingtian-relay 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.
8. Exchange-rate (FX) system. (Raised by the tariff design, 2026-06-15.) Currency is selectable per tariff version and the money model is FX-ready (payment stores currency + a reserved fxRate), but no conversion is built. If multi-currency pricing/charging is ever needed, it requires an offline rate source (rates can't depend on the network — offline-first), a base currency, and a rounding policy. Deferred; nothing blocks adding it later without migrating stored amounts.
9. Pay-station money corners — receipts & refunds/change. (Raised by the scope sweep, 2026-06-15; deferred until pay-station hardware is chosen.) Not yet designed: receipts / VAT invoices (fiscal receipt with tax number + sequential numbering may be legally required — could change what the payment event must store) and refunds / overpayment / change (cash change, "exact change only", a refund as a signed reversal event). Both depend on the unmanned-vs-manned payment subsystem (#3) and the note/coin/card acceptor hardware. Revisit at procurement.
10. Snapshot retention. (Raised by the entry-exit-points camera-snapshot build, 2026-06-16.) Entry/exit snapshots are stored as BLOBs in the sqlite snapshots table. This grows the single DB file fast (~100–300 KB per image × every entry and exit), and SQLite doesn't reclaim deleted-blob pages without VACUUM. Undecided: pruning policy (age-based vs. total-size cap), VACUUM cadence, and how this interacts with the #5 backup strategy (blobs bloat every backup). Until decided, snapshots accumulate unbounded. See entry-exit-points.
11. Appliance OS image → WebKitGTK version (Tauri dependency). (Raised by desktop-shell-tauri, 2026-06-21; narrowed same day.) The chosen desktop-shell-tauri renders through the host's WebKitGTK, not a bundled browser. The risk reduces to which OS the appliance runs:
    • Best case — Ubuntu 26.04 LTS desktop (intended): ships a current, distro-maintained WebKitGTK → this question is effectively resolved; just confirm the built SPA renders on the actual image and pin it.
    • Worst case — Windows 11 + WSL + Docker: this conflicts with the standing platform decision (Linux appliance, not Windows/WSL — see standing-decisions, disk-os-hardening) and a GUI shell doesn't live inside headless WSL/Docker. Fallback is no native shell — a kiosk browser at the local fastify-served SPA (Electron only if a standalone Windows installer is mandated). See desktop-shell-tauri for the decision table. Close this once the appliance OS image is fixed and the SPA is verified against its WebView. (Ties to #1 lane topology / image standardization.)
12. TPM 2.0 hardening — implementation (to build). (Recorded 2026-06-21; analysis in tpm.) On the Ubuntu 26.04 LTS appliance, harden using the host TPM: (a) sealed-LUKS auto-unlock (systemd-cryptenroll --tpm2-device) so the encrypted disk auto-unlocks only on an untampered boot → unattended reboot after power loss; (b) optionally hold the non-extractable host event-signing key in the TPM (a new Signer impl — no EventLog change; mirrors the atecc608 swap), defeating the offline pull-the-disk-and-re-sign attack. Must include: require TPM 2.0 (reject 1.2), prefer fTPM + a per-op PIN/auth policy (not PCR-only — bus-sniff), a LUKS recovery passphrase, and a re-seal-on-update runbook (kernel/GRUB/BIOS updates change the PCRs and lock the disk). TPM complements, never replaces, reconciliation; it does nothing against a rooted live host or the operator. Moot in the Windows + WSL fallback. See tpm, disk-os-hardening; relates to #6 (host secure-element by platform) and #13.
13. Startup chain-integrity self-check (to build). (Raised by the pull-the-disk trace, 2026-06-21.) verifyChain() exists and pinpoints any tamper, but nothing invokes it on boot — a tampered DB loads and serves normally (detectable but undetected). Wire a startup self-check that runs verifyChain() and, on a break, flags degraded state / writes a signed anomaly + alarms (surfaced to the booth footer / next reconciliation). Open: refuse-to-serve vs. serve-degraded — lean serve-degraded + loud alarm (fail-open on exit still governs; refusing to boot could strand a lane). Software-only, independent of the TPM/atecc608 hardware. See append-only-event-chain.
14. Printer USB transport — confirm the on-site printer + bake the provisioning. (Recorded 2026-06-24; the transport code is built — see printer-usb-transport.) The ESC/POS drivers now drive TCP (port 9100) OR local USB (/dev/usb/lp0) behind one render layer, selectable per device. Open: is the actual booth printer USB or network? (The site's verified units are networked — Cashino 10.0.10.9, Rongta 10.0.10.10 — so USB may be unused here; the original BOM listed "Epson TM / Citizen (USB or network)", so a future site may need it.) If USB is used, the appliance image must (a) load/keep the usblp kernel module bound to the printer (CUPS can claim the interface first), and (b) ship a udev rule giving the non-root server process write access to /dev/usb/lp*. Both are appliance-provisioning steps, not app code, and are unverified on hardware. Close this once the printer transport per site is fixed and (if USB) the udev/usblp rule is in the image and a real USB print is verified. Relates to #1 (lane topology / image standardization). See printer-usb-transport, rongta-printer.