“Vermittelte” v. “Direkte” Authentifizierung (2/8): Relying Parties in die Pflicht nehmen
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.
In Beitrag 1/8 habe ich den Vorschlag von Kaspar Etter positiv erwähnt. Er regt an, die Relying Parties sollten verpflichtet sein, eine Schnittstelle für die direkte Authentifizierung in ihren Anmeldeprozess aufzunehmen. Diese würde sicherstellen, dass jeder und jede, die sich mit einer direkten Authentifizierungslösung (z.B. einer Self Sovereign Identity oder SSI-Lösung) bei der Relying Party anmelde, von dieser auch “gelesen” werden könne. Zudem müsste die Nutzerin auch direkt bei der Relying Party auswählen können, welche Lösung sie im Einsatz hat.
Ich bin einverstanden. Es braucht so etwas, wenn man das BGEID dann umsetzen sollte. Dies ist nötig, damit Lösungen mit Direkter Authentifizierung faktisch möglich sind. Ich habe zwar noch eine alternative Lösung vorgeschlagen (Lösung mit redundant aufgestellten Gateways: hier und hier), sehe aber — auch nach vertiefender Diskussion ausserhalb dieses Blogs — dass diese Lösung wohl nicht mehrheitsfähig wäre, wenn man auf die Diskussion der vergangenen Wochen zurückblickt.
Warum ist das Postulat von Kaspar Etter sinnvoll? Die Begründung ist relativ offensichtlich:
- Nutzen: Wenn die Relying Party den erforderlichen Code einbindet, ist nicht nur die zur Hauptsache diskutierte zentrale Lösung (“Vermittelte Authentifizierung”) möglich, sondern es können auch beliebig viele dezentrale Lösungen (“Direkte Authentifizierung”) umgesetzt werden.
- Machbarkeit: Das Einbinden einer Schnittstellenfunktionalität (wie von Kaspar Etter gefordert) direkt bei der Relying Party dürfte keine grosse Sache sein für eine Relying Party, die ohnehin eine Authentisierungs-Schnittstelle in ihr Web-Angebot einbinden muss (Stichwort Verhältnismässigkeit).
- Datenschutzaspekte: Solche Schnittstellenfunktionalität würde man als Open Source Software verfügbar machen (idealerweise:) müssen (sofern nicht bereits geschehen). Zudem wäre diese Massnahme eine sehr wirksame Sache, um dem Grundsatz der Datensparsamkeit zum Durchbruch zu verhelfen.
Die Abläufe auf Basis einer solchen Ergänzung des Web-Auftritts der Relying Party sähen dann wie folgt aus (sehr vereinfachte Handskizze):
Dass _das BGEID_ derzeit keine Pflicht zu Lasten der Relying Party vorsieht, eine solche Schnittstellenfunktionalität einzubinden, darüber besteht zwischen Kaspar Etter und mir Einigkeit:
Ich sehe die Bedenken also. Aber ich halte sie nicht für entscheidend. Ich gehe später, d.h. in nochmals einem separaten Beitrag genauer darauf ein. Hier in Kürze vorab die Begründung, warum man mit dem BGEID das Postulat von Kaspar Etter dennoch umsetzen kann: Man darf nicht nur auf das BGEID schauen, sondern muss den Gesamtkontext der Gesetzeslage ansehen. Namentlich das DSG gibt die Antwort, und zwar wie es in Verbindung mit dem BGEID wirken wird. Der Beitrag hier führt dazu Weiteres aus.