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.
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 is the dingtian-relay 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
355026dcf7