julian
355026dcf7
Neither UHPPOTE nor ZKTeco is used — the Dingtian relay controller was chosen and verified. Remove their code and re-scope the wiki. Code: - delete access-uhppote.ts, uhppoted.d.ts, access.ts (zkteco/esp32-relay stubs), and the three uhppote-*.mjs hardware test scripts. - remove the `uhppoted` npm dependency from @parking/devices and @parking/server. - unregister uhppote/zkteco/esp32-relay from the driver registry; drop their exports. Catalog access drivers = dingtian only. Build green (5/5). - refresh now-stale example comments (registry/interfaces/setup/api) to use current examples; keep the two "UHPPOTE blocker" references that explain why the precondition capability exists. Wiki (kept pages, re-scoped): - uhppote-controller, zkteco-controller -> rejected/historical with callouts; uhppote-vs-esp32 -> historical (detection-vs-prevention lens still useful). - re-point all "current device" framing (standing-decisions, bom, overview, open-questions, device-registry, device-discovery, index) to dingtian-relay. - transferable concepts (network-isolation, event-log-ingestion, barrier-not-a- door, threat-model) untouched. Raw source immutable. Links lint clean.
42 lines
2.6 KiB
Markdown
42 lines
2.6 KiB
Markdown
---
|
|
type: decision
|
|
tags: [parking, decisions, open]
|
|
sources: [parking-system-architecture]
|
|
updated: 2026-06-15
|
|
status: open
|
|
---
|
|
|
|
# Open Questions / Next Steps
|
|
|
|
**Not yet decided**, 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**.
|
|
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.
|