- 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.
Not yet decided, and they drive everything else — settle before procurement. (See
parking-system-architecture §10.)
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.)
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.
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).
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.
Durability / backup. Backup strategy for the sqlite database + recovery plan; "sync
later" currently leaves a disk failure as total revenue-history loss.
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.
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.
julian
7de5c74500