Am 7. März 2021 wird über das BGEID, d.h. über das Bundesgesetz über Elektronische Identifizierungsdienste, abgestimmt. In diesem zweiteiligen Beitrag wird ein Überblick über den Umgang mit personenbezogenen Daten im E-ID Ökosystem gegeben. In Teil 1 wird aufgezeigt, welche Daten wo gehalten und wofür benutzt werden.

Daten im Informationssystem des FedPol

Der Vertrauensanker der E-ID ist die Datenbank mit Personendaten beim Bundesamt für Polizei (FedPol).. Diese wird mit Angaben aus fünf bestehenden Bundesregistern gespiesen (Art. 24 Abs. 3 BGEID). Diese fünf Register sind

• das bereits bestehende Ausweisregister des FedPol,
• das Personenstandsregister
• das Register für Schweizerinnen und Schweizer im Ausland (Ordipro)
• das Register für Ausländer und Ausländerinnen in der Schweiz (ZEMIS)
• das zentrale Versichertenregister der Zentralen Ausgleichsstelle für die AHV.

Datenprüfungsvorgänge bei Beantragung einer E-ID

Wer eine E-ID will beantragt diese bei einem Identitätsprovider (IdP). Dieser leitet die Anfrage ans Bundesamt für Polizei (FedPol) weiter. Dort wird plausibilisiert, ob die Anfrage mit der Datenlage in der Datenbank des FedPol übereinstimmt. Die zur Plausibilisierung eingereichten Daten sind z.B. Geburtsort, Mädchenname der Mutter, Heiratsdatum, etc. Der IdP ist in diesen Vorgang nicht involviert und erhält die von der Nutzerin im Rahmen der Plausibilisierung gegebenen Antworten nicht. Mit erfolgreicher Plausibilisierung wird eine E-ID-Nummer generiert. Die E-ID ist damit erstellt.

Datenprüfungsvorgänge bei der Verifikation

Dann geht es darum, die E-ID im Alltag als Login nutzbar zu machen. Die Nutzung im Alltag setzt zweierlei voraus. Einerseits muss die Nutzerin Legitimationsmittel in die Hand bekommen, damit sie den Loginvorgang unter Zuhilfenahme des IdP künftig erfolgreich absolvieren kann. Anderseits muss eine Verknüpfung der E-ID mit der Nutzerin hergestellt werden. Vereinfacht gesagt: Die Nutzerin muss sich einmal beim IdP «zeigen», damit sie sich künftig bei den Amtsstellen oder Online-Diensten, die auf die E-ID vertrauen (sog. Relying Parties), nicht mehr zeigen muss.

Die Verifikation wird von den IdP vorgenommen. Hier kommen nun erstmals die drei Stufen ins Spiel, die mit der E-ID zusammenhängen: niedrig, substanziell und hoch. Je nachdem, wie viel Vertrauen vermittelt werden, wird der Prüfvorgang aufwändiger oder weniger aufwändig ausgestaltet:

• Für das Sicherheitsniveau niedrig prüft der IdP mindestens offiziöse Dokumente (die NZZ hat in ihrer Ausgabe vom 13.02.2021 als Beispiele die Handyrechnung oder die Steuerrechnung angeführt).
• Für das Sicherheitsniveau substanziell und hoch können zusätzlich das Gesichtsbild zur Verifikation geprüft werden.

Dass die Verordnung weitere Vorgaben zu den Prüfschritten macht, ist anzunehmen. Letztlich geht es darum, dass die Prüfschritte genügend belastbar sind, um der E-ID das Vertrauen zu geben, das Relying Parties benötigen.

Datenhandling beim IDP

Der IdP erhält vom FedPol eine im Voraus bestimmte, im BGEID genau definierte Menge von Personendaten, und zwar geht es je nachdem, bis zu welchem Sicherheitsniveau die Nutzerin ihre E-ID einsetzen will, um Folgendes:

• Sicherheitsniveau niedrig: amtlicher Name mit Vorname(n) und Geburtsdatum
• Sicherheitsniveau substanziell: zusätzlich Geschlecht, Geburtsort und Staatsangehörigkeit
• Sicherheitsniveau hoch: zusätzlich das Gesichtsbild, wie es in der Datenbank des FedPol gespeichert ist

Zusätzlich erhält der IdP die E-ID-Registrierungsnummer, die er dazu verwendet, seine Datenbanken belastbar und für allfällige Überprüfungen nachvollziehbar zu organisieren. Das Gesichtsbild erhält der IdP zwar auch zur Verifikation der E-ID mit Sicherheitsniveau substanziell, darf es aber nicht gespeichert halten, wenn die Nutzerin die E-ID nicht auch für die den Zweck «hoch» einsetzen will.

Die in diesem Abschnitt genannten Daten bezeichnet man als Personenidentifizierungsdaten (Art. 5 BGEID).

Vorgänge beim Einsatz der E-ID

Wenn die Nutzerin sich bei einer Amtsstelle oder einem Online-Dienst (Relying Party, in der folgenden Tabelle als «RP» bezeichnet) mit der E-ID einloggen will, läuft Folgendes ab:

Dieser Ablauf funktioniert, solange der IdP der RP und der Nutzerin derselbe ist. Stimmen die IdPs nicht überein, so sind weitere Schritte zwischen den beteiligten IdPs nötig. Wie die Interoperabilität effektiv aussehen wird, hängt von der Umsetzung der Verordnung ab und ist noch nicht definitiv abbildbar.

*Anmerkung zu Schritt 7: Die Anfrage darf nicht weitergehen als zulässig. Was zulässig ist, bestimmt sich nach dem Datenschutzgesetz, der Verordnung zum BGEID (das derzeit noch in Ausarbeitung ist) und dem Anschlussvertrag zwischen IdP und Relying Party.

Maschinensicht auf die Datenhaltung

Im Rahmen der vorgängig beschriebenen Abläufe entstehen zusätzlich zu den bereits beschriebenen Personenidentifizierungsdaten weitere Daten. Es ist naheliegend, bei Beschreibung der Datenlage zu differenzieren nach Relying Party (im Beispiel: einem Handelsregisteramt) und IdP. Zunächst beschreiben wir die Ebene der Datenhaltung, d.h. die blosse Maschinensicht. Ob es auch Personen gibt, die zusätzlich zur Maschinensicht (Datenebene) noch weitere Erkenntnisse bekommen (Klartextsicht oder Personensicht), behandeln wir später.

Datenhaltung bei der Relying Party

• Nutzungsdaten: Auf den Systemen der Relying Party (dem Handelsregisteramt) entstehen Daten dazu, wer (die Nutzerin) wann und mit wem (mit dem Handelsregisteramt selber) interagiert.
• Inhaltsdaten: Als Inhaltsdaten bezeichnen wir jene Angaben, die beschreiben, was die Nutzerin dem Handelsregisteramt mitteilt. Das Handelsregisteramt hat natürlich eigene Daten (Maschinensicht) darüber, warum die Nutzerin mit ihm interagiert hat (z.B. Gründung einer GmbH).
• Nutzungsprofil: Wenn die Nutzerin mehr als einmal in wiedererkennbarer Weise beim Handelsregisteramt Meldungen macht, erhält das Handelsregisteramt natürlich so etwas wie eine Querschnittssicht auf die Aktivitäten der Nutzerin. Dass sie z.B. nicht nur Gesellschafterin der GmbH ist, sondern offenbar auch noch Verwaltungsrätin bei der X. AG, etc. Man kann diese Gesamtsicht bzw. Querschnittsbetrachtung als Nutzungsprofil bezeichnen. Das Handelsregister hat dazu eine Maschinensicht.

Datenhaltung beim IdP

• Nutzungsdaten: Auch der IdP hat auf seinen Systemen eigene Daten, die beschreiben, dass die Nutzerin zu einem bestimmten Zeitpunkt mit dem Handelsregisteramt interagiert hat.
• Inhaltsdaten: Anders als das Handelsregisteramt hat der IdP auf seinen Systemen keine eigenen Daten darüber, worüber die Nutzerin sich mit dem Handelsregister austauscht.
• Nutzungsprofil: Der IdP erhält bei mehrfachem Einsatz der E-ID durch die Nutzerin auch eine Datenreihe, die man als Nutzungsprofil bezeichnen kann. Einzelne Datenpunkte werden dabei allerdings nur für maximale 6 Monate (je nach Use Case für einen kürzeren Zeitraum) gespeichert. Wer die E-ID weniger oft als einmal halbjährlich einsetzt, der kann das Entstehen von Nutzungsprofilen beim IdP also verhindern. Die beim IdP anfallenden Datenpunkte sind inhaltlich enger als jene bei der Relying Party. Der IdP erhält nur Daten dazu, wer (die Nutzerin) wann mit wem (dem Handelsregisteramt) interagiert hat. Inhaltsdaten erhält der IdP wie erwähnt nicht und kann solche Angaben somit auch nicht in das Nutzungsprofil speichern.

Personensicht auf die Datenhaltung

Ob es über die Maschinensicht (Datenebene) hinaus noch eine Klartextsicht jener Personen gibt, welche die betreffenden IT-Systeme verwalten (d.h. Personal des Handelsregisteramts für dessen Systeme, einerseits, und Personal des IdP andererseits, für dessen Systeme), ist im Folgenden zu beschreiben, wiederum getrennt für die Relying Party und den IdP:

Klartextsicht:

• Bei der Relying Party: Eine solche Klartextsicht erfolgt nur dann, wenn die Relying Party keine Prozesse eingerichtet hat, um die Einsichtnahme durch Personen zu verhindern. Nach dem revDSG, das für die E-ID relevant werden wird, muss die Relying Party Vorgaben von Privacy by Design etc. einhalten und Klartextsichten nur jenen erlauben, die zur Erfüllung ihrer Arbeit darauf angewiesen sind (Need-to-Know-Grundsatz). Wenn die Relying Party eine Amtsstelle ist, braucht sie in der Regel eine gesetzliche Grundlage.
• Beim IdP: Auch der IdP untersteht dem revDSG. Auch der IdP muss somit Grundsätze von Privacy by Design einhalten (Art. 7 Abs. 1 revDSG). Was besonders ist: Der IdP darf keine Mutmassungen anstellen über die Interaktionen der Nutzerin bei der Relying Party. Das wäre eine Bearbeitung von Personenidentifizierungsdaten. Solche Beobachtungen oder Mutmassungen sind verboten (Art. 9 Abs. 1 BGEID). Ein IdP, der solche Beobachtungen anstellen würde, würde seine Zulassung verlieren.

In Teil 2 wird insbesondere darauf eingegangen, wie die personenbezogenen Daten EID-Ökosystem geschützt werden.