Zieldatum Dezember 2026: Erstmals wird die breite Öffentlichkeit die E-ID produktiv beziehen können. Die Erwartungen am digitalen Identitätsnachweis sind hoch. Mit der E-ID und der Vertrauensinfrastruktur sollen Prozesse vereinfacht, und ein Ökosystem aus Issuer und Verifier aufgebaut werden. Der Weg dorthin ist jedoch kein „Selbstläufer“. Anhand ausgewählter Use‑Case‑Szenarien werden einige zentrale Hürden sichtbar.
Damit die E-ID bezogen und genutzt werden kann, stellt der Bund die dafür notwendige technische Infrastruktur bereit. Diese sog. Vertrauensinfrastruktur ist offen konzipiert. Sie ermöglicht nicht nur die Nutzung der E‑ID, sondern auch das Ausstellen, Speichern und Prüfen weiterer digitaler Nachweise in Form von Verifiable Credentials (VCs).
Wie funktioniert die Vertrauensarchitektur? Rollen im Überblick
Holder und Wallets
Im Zentrum steht der Holder mit seiner Wallet. Initial ist ausschliesslich die SWIYU‑App zugelassen, wobei weitere Wallets später zugelassen werden sollen.
Issuer
Issuer stellen signierte VCs aus und definieren deren Inhalte (Claims). Die Credentials werden in der SWIYU-Wallet des Holders gespeichert und von diesem vorgewiesen.
Verifier
Verifier prüfen die kryptografische Gültigkeit der VCs. Dies wird u.a. durch die Kontrolle der Signatur des Issuers erreicht.
Register
Öffentliche Register schaffen dabei Vertrauen und Transparenz:
- Das Basisregister ist die Grundlage für die Teilnahme am Ökosystem. Organisationen werden dort über einen Decentralized Identifier (DID) referenziert, der auf ein DID‑Dokument mit Schlüsseln und technischen Endpunkten verweist.
- Im Vertrauensregister deklarieren Verifier, welche Daten sie zu welchem Zweck abfragen. Die SWIYU-Wallet wird Holder warnen, wenn Abfragen davon abweichen. Für besonders schützenswerte Daten wie die AHV‑Nummer wird bei der Registrierung geprüft, ob eine gesetzliche Grundlage besteht. Nicht deklarierte Abfragen solcher Daten werden automatisch von der SWIYU-App abgelehnt.
Use Cases und Hürden
Trotz der klaren Architektur ergeben sich in der Praxis konkrete Hürden.
Hürde 1: Unverknüpfbarkeit der E‑ID
Die E‑ID ist bewusst unverknüpfbar. Durch sogenannte Batch Issuance werden viele kryptografische Schlüssel erzeugt, die jeweils nur einmal verwendet werden. Das verhindert Profiling, erschwert jedoch bestimmte Use Cases.
Eines der relevantesten Beispiele aus der Finanzbranche mit erhofften Kosteneinsparungen und Prozessverbesserungen, ist der Use Case der Online‑Registrierung vom E‑Banking Login. Dieser heute aufwändige Prozess beinhaltet oft die postalische Zustellung eines neuen Sicherheitselementes (manchmal per Einschreiben) und kommt häufig vor, weil ca. einen Drittel des Bankkundenstamms in einem Jahr das mobile Gerät wechselt.
Da weder die AHV‑Nummer (Nutzung benötigt eine Gesetzesgrundlage) noch ein konstanter Identifikator genutzt werden können, bleibt oft nur ein Personendatenabgleich als Option, um die Identität des Users bei der Wiederherstellung vom Banking Login zu kontrollieren. Edge Cases wie Namensänderungen erhöhen die Komplexität. Aus Sicht vom Use Case wäre eine konstante, von der AHV entkoppelte Kennung komfortabler. Aktuell wurde jedoch dieser Trade‑off politisch zugunsten des Datenschutzes entschieden.
Hinzu kommt der gekoppelte Lifecycle. Sowohl E‑ID als auch der zweite Faktor eines Banking‑Authenticators sind an das Gerät gekoppelt. Bei Geräteverlust oder ‑Wechsel müssten User zuerst die E‑ID neu einrichten, bevor sie wieder auf das E‑Banking zugreifen können. Das erschwert die Benutzerführung und dürfte zusätzliche Support‑Anfragen auslösen.
Hürde 2: Fehlender Backup‑Service des Bundes
Beim Inkrafttreten des E‑ID‑Gesetzes steht kein Backup‑Service zur Verfügung. Wird ein Gerät gewechselt, müssen sämtliche gespeicherten VCs durch die jeweiligen Issuer neu ausgestellt werden. Mit einer wachsenden Anzahl Credentials, wird dies zu einem zentralen Bruch in der User Journey mit hohem Frustrationspotential.
Hürde 3: Fehlende Governance bei Definition von gemeinsamen VC‑Schemas
Die Effizienz des Ökosystems hängt stark von interoperablen VC‑Schemas ab. Ohne koordinierte Governance drohen parallele, inkompatible Lösungen. Ein Beispiel ist die Ausstellung des digitalen Maturitätszeugnisses (zuletzt hat der Kanton Neuenburg diesen implementiert): Der Inhalt dieser Zeugnisse wird heute kantonal geregelt. Langfristig wäre ein einheitliches Schema über alle Kantone hinweg erforderlich, um Skaleneffekte zu realisieren und den Integrationsaufwand und automatisierte Verarbeitung bei Verifiern (z.B. Hochschulen) zu reduzieren.
Der Koordinationsaufwand, um einen Konsens für einen einheitlichen Standard zu erreichen kann signifikant werden. Vor allem bei Anwendungen, wo es gleichzeitig viele Issuer und Verifier gibt („n-zu-n“-Beziehung), kann dies eine grosse Hürde darstellen.
Typischerweise ist dies bei industrie- bzw. branchenspezifische VCs zu erwarten. Einige Beispiele sind: der Vermögensausweis, der Vollmachtausweis, der Lohnausweise, der Bauchungs-/Transaktionsnachweis, der Steuerausweis, das E-Rezept, der Boarding Pass, der „Aircraft Operator Security Programs“-Approval und der „Supplementary Station Procedures“-Aproval.
Fazit
Die technische Basis der E‑ID ist solide und datenschutzorientiert. Ob sie ihr volles Potenzial entfalten kann, entscheidet sich jedoch nicht nur an der Technik, sondern auch an der Governance, User Experience und Skalierbarkeit der Use Cases die im Ökosystem aufgebaut werden.
Quellen und weiterführende Links zum Thema
- e-ID und Vertrauensinfrastruktur: Stand der Arbeiten und Ausblick – eGovernment Forum, 10.03.2025
- Swiyu Github – Introduction
- Swiyu Github – swiyu Trust Infrastructure: Interoperability profile
- Schweizerische Eidgenossenschaft – Elektronische Identität und Vertrauensinfrastruktur – Technologie
- Medienmitteilung Bundesrat vom 25.02.2026 – Akzeptanz der E-ID mit zusätzlichen Massnahmen stärken
- Aufnahme Youtube – Partizipations-Meeting / Réunion de participation | 27 02 2026
Dieser Blogbeitrag wurde mit Unterstützung von Künstlicher Intelligenz erstellt.
