“Vermittelte” v. “Direkte” Authentifizierung (4/8): Dezentrale Datenspeicherung ist möglich
Dieser Beitrag knüpft an eine Diskussion auf Twitter an:
- https://twitter.com/lauxandlaw/status/1367145656922603521
- https://twitter.com/lauxandlaw/status/1367176454715375618
Er ist zugleich ein Beitrag zur Diskussion mit Kaspar Etter auf diesem Blog, namentlich zu Punkt 3 und Punkt 4 in seinem Gastbeitrag “Fachliche Kritik am E-ID-Gesetz”. Und er ist zu lesen in Verbindung mit den anderen Beiträgen zum Thema “Vermittelte” v. “Direkte” Authentifizierung auf diesem Blog.
Auf Twitter wurde ich Folgendes gefragt:
Ist eine dezentrale Datenspeicherung auch unter dem BGEID möglich?
Die Frage kann in den umstrittenen Punkten mit JA beantwortet werden, wie das folgende Rollenschema zeigt. Namentlich muss der Ausstellungsprozess für eine E-ID betrachtet werden. Er zeigt, dass man auch in einer dezentralen Welt nicht um einen IdP bzw. einen Issuer herumkommen wird (die Bezeichnung “IdP” wurde gewählt, um die “dezentrale Welt” (sprich: “Direkte Authentifizierung”) auf das BGEID zu mappen. Eine in aller Kürze gezeichnete Skizze zum Ausstellungsprozess (mit einer SSI auf Basis eines Ledgers) sieht so aus:
Dass man den “IdP” gemäss vorstehender Skizze allenfalls auch nur als “Issuer” bezeichnen sollte, darauf wurde ich auf Twitter hingewiesen:
Mir ist das recht, dass man in der vorstehenden Zeichnung den Begriff “Issuer” verwendet. Warum ich dennoch den Begriff des IdP verwendet habe, habe ich oben bereits erläutert (Mapping auf das BGEID).
Nach alldem lautet die Antwort auf die im Titel genannte Frage also “im Prinzip JA”:
- Die Nutzerin hält die Attribute, welche sie gegenüber der Relying Party angibt (also: diesbezüglich gibt es dezentrale Datenhaltung). Diesbezüglich also: Antwort JA.
- Beim Issuer gibt es für eine bestimmte Zeit eine zentrale Datenhaltung. Diesbezüglich also: Antwort NEIN.
- Der Issuer wird aber nicht in Transaktionen eingebunden, in welchen die Nutzerin sich gegenüber Relying Parties authentifiziert. In Bezug auf Nutzungsdaten gibt es also kein zentrale Datenhaltung. Diesbezüglich also: Antwort JA.
Im Rahmen des besprochenen Modells ist eine datensparsame Umsetzung des E-ID-Ökosystems bereits mit dem BGEID möglich.
«Beim Issuer gibt es für eine bestimmte Zeit eine zentrale Datenhaltung. Diesbezüglich also: Antwort NEIN.»
Ich konnte die Kritik bezüglich Kopien der Personenidentifizierungsdaten bisher nicht nachvollziehen. Dass ein (Certificate) Issuer eine Kopie der Identifizierungsdaten behält (Nutzungsdaten erhält er ja keine), finde ich nicht problematisch. Es wäre ja auch die Aufgabe des Issuers, ein Zertifikat zu revozieren, bspw. bei Verlust der E-ID durch die Nutzerin. Um dies machen zu können, müsste die Inhaberin des Zertifikates vermutlich erneut identifiziert werden, wozu ein Vergleich mit den gespeicherten Identifizierungsdaten notwendig ist. Wenn man auf Certificate Revocation Lists verzichten möchte, müssten die Zertifikate (vollständig automatisiert) mit einer kurzen Gültigkeitsdauer ausgestellt werden. Auch in diesem Fall müsste der Issuer die Identifizierungsdaten behalten.