diff --git a/docs/triangle_slider_nostr_keycloak.html b/docs/triangle_slider_nostr_keycloak.html new file mode 100644 index 000000000..103a0448a --- /dev/null +++ b/docs/triangle_slider_nostr_keycloak.html @@ -0,0 +1,795 @@ + + + + + 3-Achsen-Dreiecks-Slider – Nostr & Keycloak + + + + +

Balance: Nutzerfreundlichkeit – Sicherheit – Datensouveränität
+ (Onboarding zu Nostr über Keycloak) +

+ +
+ + + + + + + + + + + + + + + + + + + Nutzerfreundlichkeit + + + Sicherheit + + + Datensouveränität + + + +
+
+ + +
+
+
Nutzerfreundlichkeit
+
33%
+
+
+
+
+
+
Sicherheit
+
33%
+
+
+
+
+
+
Datensouveränität
+
33%
+
+
+
+
+
+ + +
+ + + + + +
+ + +
+ + +
+ + +
+

📖 Was bedeutet die Position im Dreieck?

+
+
Nutzerfreundlichkeit (oben)
+
+ Hoher Wert: Onboarding „ein Klick", kaum Schlüsselbegriffe, wenig Reibung. + Niedriger Wert: mehr Erklärungen, Bestätigungen, zusätzliche Schritte (z.B. Seed-Backup, Passphrasen). +
+ +
Sicherheit (links unten)
+
+ Hoher Wert: starke Trennung von Systemen, minimale Angriffsfläche, Härtung von Diensten, wenig Vollzugriffe. + Niedriger Wert: mehr Komfort, aber größere Folgen bei Kompromittierung einzelner Komponenten. +
+ +
Datensouveränität (rechts unten)
+
+ Hoher Wert: Nutzende behalten Kontrolle über ihre Nostr-Schlüssel und Relays, Transparenz, Export/Exit möglich. + Niedriger Wert: mehr Bequemlichkeit, aber stärkere Bindung an zentrale Infrastruktur. +
+
+ +

📚 Beispiele: Nostr-Onboarding über Keycloak

+
+
UX first (nsec in Keycloak)
+
+ Architektur: NSEC wird einmalig erzeugt und als verschlüsseltes Attribut in Keycloak gespeichert. + Web-App holt den Schlüssel via Token und signiert Events server- oder clientseitig automatisch.
+ Effekt im Dreieck: Sehr hohe Nutzerfreundlichkeit („Einloggen & fertig"), + aber starke Abhängigkeit von Keycloak als „single point of failure" und zentrale Stelle für Schlüsselkompromittierung. + Datensouveränität ist begrenzt, Export/Relay-Wechsel eher ein Power-User-Feature. +
+ +
Security first (Key beim User)
+
+ Architektur: NSEC liegt ausschließlich beim Nutzenden (z.B. Nostr-Signer-App, Browser-Extension). + Keycloak macht nur OIDC-Login, Nostr erfolgt über NIP-46/Delegation oder lokale Signatur. + Server sieht den NSEC nie.
+ Effekt im Dreieck: Sehr hohe Sicherheit und hohe Datensouveränität, weil der Schlüssel + nicht in deiner Infrastruktur liegt. UX leidet: zusätzliche App/Extension, mehr Erklärungsbedarf, + Onboarding-Schritte für „Signer verbinden". +
+ +
Data first (Bunker + Schlüsselverschlüsselung)
+
+ Architektur: NSEC wird verschlüsselt (z.B. mit Nutzer-Passphrase oder Key aus Keycloak-Token) + in einem dedizierten Bunker/Key-Service gespeichert. Signaturen laufen über den Bunker, der nur „entschlüsseln & signieren" kann, + ohne den Klartext-Schlüssel breit verfügbar zu machen.
+ Effekt im Dreieck: Hohe Datensouveränität (klar definierter Schlüsselort, theoretisch portierbar), + hohe Sicherheit (Schlüssel nur entschlüsselt im Bunker-Kontext), + UX mittel: etwas mehr Erklärung („Was ist Bunker?"), aber ins UI gut integrierbar. +
+ +
Compliance-Modus (Org-Bunker mit Policies)
+
+ Architektur: Bunker/Key-Service wird von der Organisation betrieben, + mit Logging, Rollen, evtl. HSM/Hardware-Backends. Keycloak-Login erteilt nur zeitlich begrenzte + Delegationen/Session-Keys für den Bunker. Richtlinien definieren, wer wann signieren darf (z.B. nur Dienstaccounts, + nur bestimmte Kinds, nur bestimmte Relays).
+ Effekt im Dreieck: Sicherheit und Compliance sehr hoch, + Datensouveränität eher organisationsbezogen als individuell. + UX je nach UI: für Redakteur:innen kann es noch recht smooth sein, aber spontane Privatnutzung ist eingeschränkt. +
+ +
Ausgewogen (Balanced)
+
+ Architektur: Kombination, z.B.: + Keycloak für komfortablen Login, NSEC im Bunker mit guter UI, + einfache Ex-/Import-Funktionen für Schlüssel, klare Info-Texte („Wo liegt mein Schlüssel?").
+ Effekt im Dreieck: Kein Extrem: genug Komfort für Alltag, + genug Sicherheit/Datensouveränität für Bildungs-Infrastruktur, + ohne Nutzer:innen mit Kryptodetails zu erschlagen. +
+
+
+ +
+ + + +