“Vermittelte” v. “Direkte” Authentifizierung (5/8): Wie geht das mit Art. 15 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.

Wie bereits erwähnt, sind dezentrale Modelle (“direkte Authentifizierung”) auch unter dem BGEID möglich. Art. 1 Abs. 3 BGEID kann also eingehalten werden, auch wenn die Bestimmung ansonsten eher programmatischen Charakter hat und man sich fragen kann, ob es die Bestimmung wirklich braucht.

Was man aber diskutieren muss: Ob Art. 15 BGEID mit einem solchen dezentralen Modell umgesetzt werden kann. Art. 15 BGEID stellt einen Katalog von Pflichten auf, welche jeder IdP unter dem BGEID einhalten muss. In einem dezentralen Modell hat der IdP eher die Rolle eines Issuers, worauf bereits hingewiesen wurde. Wie auch immer man diese Entität bezeichnet: Der Issuer bzw. dezentrale IdP (“IdP D” oder “D-IDP”) kann grundsätzlich ohne Weiteres Adressat der Pflichten gemäss Art. 15 BGEID sein.

Dazu in aller Kürze Folgendes (wenn ich machbar für SSI schreibe, meine ich die Umsetzbarkeit in einem dezentralen Modell, am Beispiel einer SSI-Lösung):

lit. a.: Soweit der IdP ein System betreibt, muss er es sicher ausgestalten (machbar für SSI)
lit. b.: E-ID für alle (machbar für SSI).
lit. c.: Anforderung: “Er gestaltet das E-ID-System so aus, dass die Gültigkeit aller E-ID, die er ausstellt, mit einem gebräuchlichen Verfahren jederzeit zuverlässig und kostenlos überprüft werden kann”. Dies geht mit Revocation Registry (machbar für SSI)
lit. d.: Anforderung: “Er gestaltet das E-ID-System so aus, dass für Menschen mit Behinderung keine Benachteiligung bei der Beantragung einer E-ID entsteht”. Ich kann kein Problem erkennen, nehme aber gerne weitere Hinweise entgegen (machbar für SSI)
lit. e.: Einhalten Sicherheitsanforderungen nach Art. 13 Abs. 2 lit. d (machbar für SSI)
lit. f.: Aktualisierung Personenidentifizierungsdaten (machbar für SSI)
lit. g.: Melden von Fehlern (machbar für SSI)
lit. h.: Melden von Security Issues (machbar für SSI)
lit. i.: Einwilligung von der Nutzerin einholen vor Übermittlung der Personenidentifizierungsdaten (if any) (machbar für SSI)
lit. j.: Zugang zu Daten, die bei ihm entstehen (machbar für SSI: Nutzungsdaten entstehen nicht)
lit. k.: Vernichtung von Daten, die bei einer Anwendung der E-ID entstehen (machbar für SSI; es entstehen keine bei ihm)
lit. l.: Verträge mit Relying Party (machbar für SSI)
lit. m: Melden von Änderungen (machbar für SSI)

Im Resultat kann somit Art. 15 BGEID auch dann umgesetzt werden, wenn man eine dezentrale Lösung unter dem BGEID etabliert.