“Vermittelte” v. “Direkte” Authentifizierung (3/8): Das BGEID ermöglicht Dezentrale Lösungen (Art. 1 Abs. 3 BGEID)

Dieser Beitrag knüpft an eine Diskussion auf Twitter an:

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.

(1) Verpflichtung der RPs auf eine Schnittstelle

In Beitrag 1/x habe ich den Vorschlag von Kaspar Etter positiv erwähnt. Er regt an, die Relying Parties (RP) 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. Dies sähe stark vereinfacht so aus:

Die Kernfunktion der besagten Schnittstelle bei der Relying Party besteht darin, dass die Relying Party mit ihrer Web-Lösung jeweils in Echtzeit bei Anfrage einer Nutzerin auf das Verzeichnis bei der EIDCOM zugreifen kann, das Auskunft gibt darüber, wen die EIDCOM als IdP akkreditiert hat. Bei Besuch einer Nutzerin “am Webshop” der Relying Party bzw. am “Bürgerinnenportal” der Amtsstelle, würde der Nutzerin eine Auswahl aller IdPs gezeigt, die von der EIDCOM akkreditiert sind. Es ist somit die Nutzerin, welche das Routing-Problem löst und so verhindert, dass andere davon erfahren, dass sie den Server bei der Relying Party besuchen will.

An dieser Stelle würde Kaspar Etter auf seine Kritik in Punkt 4 verweisen (keine Pflicht der Relying Party im BGEID, eine solche Lösung zu implementieren). Ich sehe jedoch einen Weg, die Relying Party über den Anschlussvertrag zwischen IdP und Relying Party zu verpflichten.

In diesem Beitrag möchte ich darlegen, warum der Bundesrat bereits auf das Datenschutzgesetz verweisen könnte und sollte, um das Einbinden einer solchen Implementierung durch die Relying Parties anzuordnen. Und zwar möchte ich aus datenschutzrechtlicher Sicht betrachten, wie die EIDCOM während des Ausstellungsprozesses durchaus dafür sorgen kann, dass jede Relying Party eine Schnittstelle installieren muss, wie Kaspar Etter sie fordert.

Ich möchte mit anderen Worten präzisierend anknüpfen an den folgenden Austausch zwischen Kaspar Etter und mir, in dem wir zum Schluss kommen, dass _das BGEID_ derzeit keine Pflicht zu Lasten der Relying Party vorsieht, eine solche Schnittstelle einzubinden:

Das Folgende zeigt, dass es aber sehr wohl doch eine Handhabe gibt, die Relying Parties zur Integration einer solchen Schnittstellenfunktionalität in ihre Authentisierungsschnittstelle zu bewegen.

(2) Wie hängt dies mit dem Ausstellungsprozess zusammen?

Kaspar Etter beklagt das Fehlen von Regeln, welche die Relying Parties verpflichten. Und solche Bestimmungen können auch nur noch nachträglich, mittels Gesetzesänderung eingeführt werden.

Aber an dieser Stelle lohnt sich ein Blick auf das Ausstellungsverfahren und wie es zusammenhängt mit den folgenden wesentlichen Bestimmungen im BGEID:

Art. 20 Vereinbarung mit einem IdP
Wer einen E-ID-verwendenden Dienst betreiben will, braucht eine Vereinbarung mit einem IdP. Die Vereinbarung regelt insbesondere:
a. welche Sicherheitsniveaus zur Anwendung kommen;
b. welche technischen und organisatorischen Prozesse einzuhalten sind.

Die Regelung zeigt, dass die IdP die Bannerträger sind für das Gesamtsystem, das dem Gesetzgeber vor Augen schwebte. Das BGEID kann wie folgt charakterisiert werden: Es reguliert bei den Relying Parties sehr wenig und überlässt dies dem Datenschutzgesetz. Anstatt dessen sieht es vor, dass der IdP die Nutzungsbeziehung mit der Relying Party gestaltet. Diese Regelung zeichnet sich durch Flexibilität aus. Und: Die EIDCOM kann im Rahmen ihrer Aufsicht Massnahmen treffen, um den Einsatz von Bestimmungen zu verhindern, welche konzeptwidrig wären. Der EDÖB seinerseits verhindert, dass die Verträge der IdP mit den Relying Parties gegen das Datenschutzgesetz (revDSG) verstösst. Massgeblich ist die folgende Bestimmung im BGEID:

Art. 15 Abs. 1 BGEID
1 Der IdP hat folgende Pflichten:
a. …
b. – k. …
l. Er erarbeitet Muster für die Vereinbarungen mit Betreiberinnen von E-ID-verwendenden Diensten und legt sie dem EDÖB vor.

Wenn der EDÖB erkennt, dass die vom IdP eingeführte Form zur Eruierung der massgeblichen, im Ablauf einer Authentisierung involvierten Parteien gegen das Datenschutzrecht verstossen würde, wird der EDÖB dies somit in den Musterverträgen erkennen. Der EDÖB muss sich dabei an die Grundsätze der Verhältnismässigkeit halten. Anderes wäre ein unzulässiger Eingriff in die Wirtschaftsfreiheit.

Verhältnismässigkeit ist ohnehin ein Kernprinzip des Datenschutzrechts. Das DSG verfolgt den Schutz von Personendaten, wobei ein Ausgleich zu treffen ist: Und zwar geht es einerseits um die auf dem Spiel stehenden Interessen (Vertraulichkeit, kein Profiling, Art der betroffenen Personendaten und Gefahren für die Freiheit der Nutzerin) und andererseits um die rechtmässigen Alternativen, welche eine verantwortliche Stelle (hier: der IdP und die Relying Party) haben, um den Grundsätzen von Privacy by Design und Datensparsamkeit (wie z.B. Art. 7 revDSG) zum Durchbruch zu verhelfen. Wenn die beiden folgenden Aussagen zutreffen, wird der EDÖB im Rahmen der Prüfung der Musterverträge darauf drängen müssen, dass der IdP “seine” Relying Parties verpflichtet, Schnittstellen wie von Kaspar Etter gefordert in ihre Authentisierungsschnittstelle einzubauen. Vorausgesetzt ist dafür:

  • dass es erstens wirklich um eine so dramatische Gefährdung des Datenschutzes und der Freiheiten des Einzelnen geht, wie die Gegner es behaupten (wie man bei Lektüre dieses Blogs unter https://e-idblog.ch unschwer erkennen kann, teile ich diese Sicht nicht uneingeschränkt)
  • dass es zweitens wirklich einfach und ohne grösseren finanziellen und zeitlichen Aufwand möglich ist, eine solche Schnittstelle in die Authentisierungsschnittstelle bei der Relying Party einzubauen (wovon ich ausgehe, siehe oben, was aber noch zu beweisen ist)

Nachdem dies dargestellt worden ist, kann man erkennen, dass der Bundesrat einerseits (Verordnungskompetenz) sowie die EIDCOM andererseits für diese Diskussion eine Schlüsselposition einnehmen werden, wenn es um die technische Umsetzung des BGEID gehen wird (dazu sogleich: Die EIDCOM ist der Joker).

(3) Die EIDCOM ist der Joker

Was ist im Rahmen der Verordnungsgebung einerseits (vom Bundesrat) und im Rahmen der Anerkennung (von Seiten der EIDCOM) vorzukehren? Dazu Folgendes:

(a) Verordnung

In der Verordnung sollte klargestellt werden, dass die EIDCOM im Rahmen des Anerkennungsverfahrens dafür sorgen soll, den IdP Vorgaben zu machen in Bezug auf den Datenschutz. Konkret: Wenn ein IdP (bei im Prinzip vergleichbarem Aufwand) die Wahl hat, seine Relying Parties auf eine dem Datenschutz weniger gut oder besser genügende Art und Weise an seine Systeme anzubinden, dann soll er den schonenderen Weg wählen.

Der Bundesrat sollte der EIDCOM oder einer anderen Stelle sodann den Auftrag geben, die technischen Voraussetzungen für die notwendigen Schnittstelle einerseits und API’s zur Abfrage der gelisteten IdPs geben. Selbstverständlich muss es möglich sein, hierfür Open Source Software-Komponenten zu definieren und zu beschreiben.

Der Bundesrat sollte die EIDCOM ausdrücklich ermächtigen, initiale Entwicklungen selbständig finanzieren zu können, damit solche Software nicht nur spezifiziert, sondern z.B. von der EIDCOM oder einem Bundesamt (oder einer anderen Stelle) auch gleich bereitgestellt werden kann. Es werden in solchen Kontexten noch Themen der gesetzlichen Grundlage und des Beschaffungsrechts zu adressieren sein, worauf ich an dieser Stelle aber nicht eingehen will.

Diese Ausführungen dienen insgesamt der Interessenabwägung, die der EDÖB dannzumal vorzunehmen hat: Wenn es sehr einfach und ohne grösseren Kostenaufwand möglich ist, Relying Parties mit einer solchen Schnittstelle auszustatten, wird der EDÖB eher darauf drängen, dass solche Schnittstellen tatsächlich zum Einsatz kommen. Wenn solche Lösungen aber nicht vorliegen, wäre dies geradezu widersinnig. Dies führt jedoch zu einer positiveren Gesamtwertung während der Übergangszeit: Das Ökosystem mit E-ID könnte bereits in einem frühen Zeitpunkt implementiert werden. Man müsste nicht warten, bis alle Akteure bereit sind, das Routing direkt an der Authentisierungsschnittstelle der Relying Party abzubilden.

(b) Anerkennungsverfahren vor der EIDCOM

Auf dieser Basis wird es der EIDCOM dann möglich sein, zu beurteilen, ob die Zeit bereits reif ist, den Einbau von den betreffenden standardisierten Schnittstellen verbindlich als Anerkennungsvoraussetzung zu fordern. Die EIDCOM ist sodann jene Stelle, die überwacht, wie sich solche Massnahmen auf das gesamte Ökosystem auswirken werden.

(c) Fazit

Auch im vorliegenden Kontext wird somit ersichtlich, dass die EIDCOM eine sehr zentrale Rolle spielen kann, wenn es darum geht, massgebliche Weichen im Ökosystem zu stellen. Anzunehmen ist, dass man über solche Herangehensweisen nach der Abstimmung wird sprechen wollen.

Ich weiss, dass Viele jetzt sagen würden: “Und warum steht das nicht bereits im BGEID?”. Ich kann diese Frage nicht beantworten. Jedenfalls könnte man sagen: Wahrscheinlich, weil sie niemand (auch nicht die Gegner) in das parlamentarische Verfahren eingebracht haben. Fingerpointing ist aber einfach nicht relevant an dieser Stelle. Entscheidend ist, dass der Bundesrat nicht nur eine gesetzliche Grundlage hat, entsprechende Vorkehrungen zu veranlassen, sondern dass es darüber hinaus auch eine sehr gute Idee wäre und mit Blick auf den Abstimmungskampf politisch wohl nicht machbar wäre, eine solche berechtigte Forderung zu ignorieren. Denn: Dass direkte Authentifizierungen möglich sein sollen, dies hat das Parlament mit Art. 1 Abs. 3 BGEID klar gefordert.

Ich sehe also die Möglichkeit, der Gesamtaufgabenstellung in einer guten Form zu begegnen. Dies führt im Resultat dazu, dass ich das BGEID nicht ablehnen möchte. Es gibt mit dem BGEID Lösungen, welche Daten schützen und schonend mit Nutzerprofilen umgehen.

Das könnte Dich auch interessieren...

1 Antwort

  1. Kaspar Etter sagt:

    «Die Kernfunktion der besagten Schnittstelle bei der Relying Party besteht darin, dass die Relying Party mit ihrer Web-Lösung jeweils in Echtzeit bei Anfrage einer Nutzerin auf das Verzeichnis bei der EIDCOM zugreifen kann, das Auskunft gibt darüber, wen die EIDCOM als IdP akkreditiert hat. Bei Besuch einer Nutzerin “am Webshop” der Relying Party bzw. am “Bürgerinnenportal” der Amtsstelle, würde der Nutzerin eine Auswahl aller IdPs gezeigt, die von der EIDCOM akkreditiert sind. Es ist somit die Nutzerin, welche das Routing-Problem löst und so verhindert, dass andere davon erfahren, dass sie den Server bei der Relying Party besuchen will.»

    Das kann man so lösen, doch würde es wohl kein Informatiker so lösen. Das “Routing-Problem” existiert nur, wenn man meint, dass sich die Relying Party beim richtigen Identity Provider oder beim SSI Wallet zu melden hat. Es gibt keinen Grund, weshalb sich das SSI Wallet nicht bei der Relying Party melden kann (so wie es der Browser der Nutzerin davor auch schon getan hat). Die Relying Party könnte einen QR Code anzeigen und die Nutzerin scannt diesen mit ihrer SSI Wallet, welche nach Bestätigung der Nutzerin die angefragten Attribute mitsamt Bestätigung/Zertifikat an die im QR Code angegebene URL schickt. Auf dem Smartphone würde man das mit “Mobile Deep Linking” statt mit QR Code umsetzen. Die EIDCOM könnte einfach als Trust Anchor/Root Certificate Authority auftreten (und möglicherweise eine Certificate Revocation List herausgeben). Eine Abfrage in Echtzeit ist nicht nötig.

    Ich stimme dir zu, dass mit dem aktuellen BGEID die involvierten Instanzen der Exekutive über die Identity Provider die Relying Parties zur Unterstützung einer direkten Authentifizierung verpflichten könnten. Dass es dazu kommen muss/wird, ist aber reine Spekulation. Bei Annahme des BGEID werden die Schnittstellen und Anforderungen von jenen Leuten festgelegt, die diesen Gesetzesentwurf ausgearbeitet und befürwortet haben. Ohne dem BGEID könnte ich als Betroffener gemäss deiner Argumentation vielleicht mein “Recht” auf eine direkte Authentifizierung dank dem Datenschutzgesetz einklagen (insbesondere bei Authentifizierungen gegenüber Behörden). Mit dem BGEID wäre das wohl nicht mehr möglich, denn ein Gericht müsste zum Schluss kommen, dass der Gesetzgeber eine vermittelte Authentifizierung für zumutbar befunden hat. Ohne eine Volksinitiative starten zu müssen, ist die Ablehnung des BGEID meine letzte Möglichkeit, zu verhindern, dass es überhaupt soweit kommt. Grundsatzentscheide von diesem Ausmass sollten von der Legislative (und per Referendum/Initiative vom Stimmvolk) und nicht von der Exekutive gefällt werden.

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert