HMS MediaEngine Agent
c4574927fd
- hms_cluster: ClusterMessage (§6.5: Pflichtfelder, Sequenzen, Revisionen, execute_at, Trace-ID), CommandTracker (idempotent, vorwärts-only: accepted->armed->executed/failed) - NodeRegistry: online/degraded/stale/offline über Schwellen, UI-Kategorien discovered/paired/unknown/incompatible/offline, Doppel-Node-ID blockiert, IP-Wechsel erhaelt node_id (§6.3, §6.5) - Pairing: PIN (TTL 120s, Versuchslimit), Fingerprint (SHA-256 gruppiert), Token nur als Hash, Scopes read/control/content_sync/admin, Ablauf + sofortiger Widerruf (§6.3, §27.1, ADR-0010) - Discovery-Modell: _hmsmedia._tcp.local. TXT ohne Secrets, Capability- Digest, persistente manuelle Fallback-Liste (ADR-0009) - ADR-0009 (mDNS + Fallback) und ADR-0010 (Paarung) dokumentiert - 25 Unit-Tests; Gesamtsuite 183 Tests gruen, Ruff gruen
46 lines
1.6 KiB
Markdown
46 lines
1.6 KiB
Markdown
# ADR-0010: Node-Paarung – PIN/Fingerprint, Token-Scopes, Widerruf
|
||
|
||
- **Status:** Angenommen
|
||
- **Datum:** 2026-09-11
|
||
- **Phase:** 1
|
||
- **Bauplan:** §6.3, §27.1, §32 (ADR-Pflicht: Node-Paarung, TLS, Berechtigungsscopes)
|
||
|
||
## Entscheidung
|
||
|
||
1. Paarung: kurzlebige PIN + sichtbarer Identitäts-Fingerprint. Ein Node wird
|
||
erst nach erfolgreicher PIN-Prüfung steuerbar (§6.3).
|
||
2. Nach Paarung erhält der Partner ein wiederrufbares Token mit getrennten
|
||
Scopes: `read`, `control`, `content_sync`, `admin` (§27.1).
|
||
3. Tokens werden als Hash gespeichert, nie im Klartext; Widerruf = Deletion,
|
||
sofort wirksam.
|
||
4. Ungepaarte Nodes geben ausschließlich minimale Discovery-/Pairing-
|
||
Informationen heraus (§27.1).
|
||
|
||
## Umsetzung Phase 1
|
||
|
||
- `hms_cluster.pairing`: PIN-Erzeugung (6-stellig, kryptographisch),
|
||
Fingerprint (SHA-256 über Identitäts-Public-Daten, hex-gruppiert sichtbar),
|
||
Paarungs-State, Token-Hash mit Scopes + Ablauf, Versuchslimit.
|
||
- TLS-Transport und Zertifikatsaustausch folgen mit dem Cluster-WebSocket
|
||
(Phase 2); dieses ADR legt die Datenmodell-Basis.
|
||
|
||
## Alternativen
|
||
|
||
- Nur Zertifikate ohne PIN: anfällig für falsche Geräte in Setup-Situationen;
|
||
sichtbare PIN ist bewusst einfach (§6.3).
|
||
- Statische API-Keys: keine Scopes, kein gezielter Widerruf.
|
||
|
||
## Folgen
|
||
|
||
- Gate-1-Test „sicher gepaart“: PIN-Prüfung + Token-Ausstellung + Widerruf
|
||
getestet; TLS-Handshake folgt in Phase 2 und bleibt in STATUS.md offen.
|
||
|
||
## Messwerte / Nachweise
|
||
|
||
- Unit-Tests: PIN-Format/-TTL, Fingerprint-Stabilität, Scope-Zuordnung,
|
||
Ablauf, Widerruf, Hash-only-Speicherung, Versuchslimit.
|
||
|
||
## Freigabe
|
||
|
||
- Standardumsetzung gemäß §6.3/§27.1.
|