“Vermittelte” v. “Direkte” Authentifizierung (6/8): Geht das auf mit Art. 18 Abs. 1 BGEID?
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.
Wenn man über Art. 18 Abs. 1 BGEID schreibt, ist der Gesetzeswortlaut in Erinnerung zu rufen:
IdP akzeptieren ihre E-ID-Systeme gegenseitig und stellen sicher, dass die E-ID-Systeme interoperabel sind.
Im Gegnerlager wird vorgebracht, Art. 18 Abs. 1 BGEID verbiete geradezu dezentrale Lösungen (Self Sovereign Identity, SSI).
Dass man zu zentralen Systemen Interoperabilität herstellen könne, sei aus Sicht einiger Gegner a priori nicht möglich. Hauptpunkt offenbar: Weil man gar noch nicht abschliessend definiert habe, was Interoperabilität heisse, könne man Interoperabilität auch nicht bestätigen. Entsprechend müsse dem BGEID Interoperabilität abgesprochen werden:
Zwar ist es richtig, dass diesbezüglich noch keine langstehend etablierten Standards vorliegen. Wohl deshalb betonen auch weitere Exponenten im Gegnerlager “fehlende Interoperabilität”:
Hier machen es sich die Gegner meines Erachtens zu einfach (dass “Interoperabilität ist noch nicht etabliert” dasselbe bedeutet wie “das BGEID verbietet SSI-Lösungen” ist jedenfalls nicht schlüssig). Wenn es so ist, dass heute noch nicht alle Fragen bezüglich den Standards der Interoperabilität bei SSI-Lösungen geklärt sind, bedeutet das natürlich keineswegs, dass das BGEID SSI-Lösungen verbietet. Allerhöchstens bedeutet dies, dass derzeit Interoperabilität noch nicht auf einen ready-made Standard aufsetzen kann und dass dies dazu führen könnte, dass SSI-Lösungen dann gegenüber anderen Modellen zu Beginn einen schwereren Stand haben könnten. Möglich ist, dass die derzeit mit Hochdruck vorangetriebenen Arbeiten betreffend Standardsetzung mit Abschluss der Arbeiten zur Verordnung zum BGEID so weit gediehen sind, dass die Welt dannzumal schon anders aussieht. Jedenfalls ist das apodiktische Njet (“geht nicht”) sicherlich wenig belastbar und vielleicht auch etwas, woran man bereits in kurzer Zeit gar nicht mehr gerne erinnert werden möchte.
Man müsste sich z.B. unterhalten dazu, was Aspekte von Interoperabilität sind. Und man muss sich dabei wohl auch auf Authorization Flows festlegen. Dass es der Ablauf sein muss, der vom Bundesamt für Justiz bis heute vorgesehen ist, ist in meinen Augen jedenfalls nicht zwingend.
Das BGEID sieht meines Erachtens inhärent vor, dass jede Relying Party eine Schnittstelle wie von Kaspar Etter gefordert einbauen sollte:
Wenn man sich auf das in Beitrag 2/8 (und von Kaspar Etter auch geforderte) Modell festlegt, wäre dies auch nach Meinung der Gegner des BGEID offenbar mehrheitsfähig, wie z.B. den folgenden Aussagen zu entnehmen ist:
Dass eine Relying Party über die von Kaspar Etter geforderte Schnittstelle faktisch das gesamte Verzeichnis der anerkannten IdP und der von ihnen zugelassenen E-IDs nicht nur erschliessen kann, sondern sogar muss (wenn der Bundesrat dies entsprechend festlegt, was er m.E. tun muss), ergibt sich m.E. aus der Argumentation in Beitrag 3/8. Damit fallen auch weitere Bedenken weg, die vom Gegnerlager normalerweise mit Hinweis auf die Interoperabilität abgetan werden.
Und wenn das Modell, wie in den Beiträgen 2/8 und 3/8 beschrieben zur Umsetzung gelangt, reduziert sich die Herausforderung, die Interoperabilität z.B. bis hin zu dezentralen Wallets im Einzelnen zu konzipieren:
Sodann kann man sich fragen, ob ein dezentraler IdP, der also in erster Linie nur als Issuer fungiert, allenfalls ganz generell von der Interoperabilität nach Art. 18 Abs 1 befreit sein sollte. Er ist anders als ein zentral agierender IdP ja nicht als “Authentisierungsgehilfe” tätig, weswegen sich eine solche Differenzierung rechtfertigt.
Soweit nach dem Gesagten in Bezug auf dezentrale Modelle das Problem der Interoperabiltät noch relevant sein sollte, wird man sich dem im Rahmen der technischen Detailspezifikation widmen müssen. Dabei darf man nicht unterschätzen, dass der Bundesrat im Rahmen der Verordnung und der weiteren technischen Erlasse unterer Stufe Vorgaben zur Standardisierung machen kann. Mit anderen Worten sehe ich nicht ganz ein, warum Art. 18 Abs. 1 BGEID ein Hinderungsgrund für dezentrale Lösungen unter dem BGEID sein soll.
«Dass man zu zentralen Systemen Interoperabilität herstellen könne, sei aus Sicht einiger Gegner a priori nicht möglich.»
Ich gehe davon aus, dass zumindest fachlich kompetente Gegner des BGEID mit “Interoperabilität ist nicht möglich” meinen, dass direkte Authentifizierung bei der im BGEID vorgesehen Interoperabilität zu einer vermittelten Authentifizierung verkommt, wodurch man nicht von direkter Authentifizierung sprechen kann (siehe meinen 4. Kritikpunkt unter https://e-idblog.ch/2021/02/26/fachliche-kritik-am-e-id-gesetz-gastbeitrag/). Wenn dem so ist, dann tragen nur die letzten zwei Abschnitte deines Artikels etwas zur Diskussion bei. Und soweit ich das beurteilen kann, sieht Artikel 18 keine Ausnahmen bezüglich Interoperabilität vor.
«Wenn es so ist, dass heute noch nicht alle Fragen bezüglich den Standards der Interoperabilität bei SSI-Lösungen geklärt sind, bedeutet das natürlich keineswegs, dass das BGEID SSI-Lösungen verbietet. Allerhöchstens bedeutet dies, dass derzeit Interoperabilität noch nicht auf einen ready-made Standard aufsetzen kann und dass dies dazu führen könnte, dass SSI-Lösungen dann gegenüber anderen Modellen zu Beginn einen schwereren Stand haben könnten.»
Du tust oft so, als ob direkte Authentifizierung weniger ausgereift sei als vermittelte Authentifizierung. Transport Layer Security (TLS) ist mit seiner Möglichkeit für Client-Authentication älter als die heutzutage üblichen Standards für vermittelte Authentifizierung wie SAML und OpenID Connect. Mit einiger Wahrscheinlichkeit wird die E-ID Schnittstelle aber ohnehin eine neues Konstrukt sein, wodurch Argumente wie “bereits etabliert” ins Leere schiessen.
Nein, dass direkte Authentifizierung weniger ausgereift sei, will ich nicht sagen. Bei dem von dir zitierten Abschnitt wurde das Wording beeinflusst davon, was ich aus dem Gegnerlager immer wieder gehört habe zum Thema Interoperabilität und SSI: “Interop mit SSI ist übrigens reine Spekulation.” Für mich war schon für die JA-Position des BGEID immer entscheidend, was du in deinem Kommentar auch schreibst: “Argumente wie “bereits etabliert” [schiessen] ins Leere”. Ich weiss nicht, warum die beiden von mir zitierten Tweets so vehement propagiert haben, dass Interoperabilität das Problem darstellen würden (das hat mich nie überzeugt). Demgegenüber überzeugt mich deine Position in deinem Kommentar: Die E-ID-Schnittstelle wäre ein neues Konstrukt.
Auch wenn die Abstimmung gelaufen ist noch ein Kommentar von mir dazu:
Wir können uns Systeme nicht einfach Interoperabel wünschen und dabei neue Protokolle definieren. Dies aus mehrerlei Hinsicht und insbesondere dem Thema Sicherheit falsch.
Die SSI Welt setzt andere Mechaniken ein als die Föderierte IDP Welt. Die Interoperabilität dieser Systeme ist heute definitiv noch nicht gegeben. Dazu kommt dass das Konzept “Fed-Hub” nicht ansatzweise Standardisiert ist und auf proprietäre Lösungen herausläuft, was weit entfernt ist von Self-Sovereign ist.
Vielen Dank für den Kommentar. Derzeit ist nichts standardisiert, das ist nach meinem Verständnis der Fall.
Was mich aber interessiert — und es wäre auf jeden Fall sinnvoll zu verstehen — welche Themen denn zu definieren wären, damit man Interoperabilität herstellen kann, ob das aus der Perspektive Schweiz (Ökosystem Schweiz) möglich / sinnvoll ist (wenn ja/nein; warum / warum nicht).
Es würde mich in diesem Zusammenhang auch interessieren, welche Themen man denn überhaupt zu definieren hätte. Man müsste doch in der Lage sein zu formulieren, was es überhaupt braucht. Können Sie dazu etwas sagen?
(i) Interaktionen zwischen vermittelten Verfahren und SSI-Verfahren (auf Ebene Protokoll, und wo sonst?)
(ii) Interaktion zwischen verschiedenen SSI-Verfahren (dito)
(iii) Credentials: Welche Inhalte sind überhaupt definiert?
(iv) Welche Angaben sind vorzuzeigen?
(v) Weitere