# 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.