@@ -6,0 +4,4 @@
+
+Bei Veranstaltungen kommt es oft vor, dass Clients (Browser auf Endgeräten) zeitweilig für Zugriffe freigegeben werden müssen. Dabei ist es oft nicht möglich auf den Clients alle Sicherheitsaspekte zu beachten (meist sind es private Endgeräte). Gerade Vereine sind auf die Bereitstellung privater Möglichkeiten angewiesen. Auch ist es nicht garantiert, dass der Nutzer diese Rechte jedes Mal identisch braucht.
+
+Das aktuelle Vorgehen wäre es, dem Nutzer einen Account zu geben. Dabei hat man aber nur eine geringe Kontrolle des Passwortes und wie oben gesagt der Clients-Sicherheit. Je mehr Rechte der User bekommt, umso anfälliger wird der Server für absichtliches wie unabsichtliches Fehlverhalten. Ausserdem entstehen so eine Unmenge an Accounts, die nicht mehr ordentlich gewartet werden können. Das verschärft die Sicherheitsprobleme witer.

@@ -6,0 +46,4 @@
+* Name des Clients
+* Rolle bzw Rollen des Clients
+* Benutzername des Veranstaltung-Administrators
+* gültiges OTP

@@ -6,0 +52,4 @@
+
+### Phase III
+
+Der Nutzer des Clients möchte eine Web-API-Aktivität ausführen über die Weboberfläche ausführen. Dazu sendet die Weboberfläche per JavaScript eine Anfrage an die Web-API, bei der der *JSON-Web-Token* mitgesendet wird.