---
title: "Eine Webanwendung auf die Schweizer E-ID vorbereiten"
summary: "Die E-ID verspätet sich. Was eine Webanwendung von einer Wallet bekommt, was Sie jetzt am Kontomodell ändern sollten und was die Sandbox heute bietet."
author: "Samuel Krauss"
author_title: "Founder"
publisher: "Elchi Studios"
published: 2026-10-03
updated: 2026-10-09
url: https://elchi.dev/de/journal/webanwendung-fuer-die-schweizer-e-id-vorbereiten
language: de
translation_of: https://elchi.dev/en/journal/preparing-for-the-swiss-e-id
tags: ["e-id","swiyu","identity","switzerland","eauth"]
words: 918
---

# Eine Webanwendung auf die Schweizer E-ID vorbereiten

*Von Samuel Krauss, Founder. Veröffentlicht am 3. Oktober 2026.*

> Die E-ID verspätet sich. Was eine Webanwendung von einer Wallet bekommt, was Sie jetzt am Kontomodell ändern sollten und was die Sandbox heute bietet.

Die Schweiz hat Ja gesagt zu einer staatlichen elektronischen Identität, und der Bund baut sie. Am 30. Juni 2026 hat das Bundesamt für Justiz den Start, der für die zweite Hälfte dieses Jahres geplant war, ohne neues Datum verschoben: Das Datum wird bekannt gegeben, sobald weitere Sicherheitsarbeiten, unter anderem gegen Deepfakes und Malware, weitgehend abgeschlossen sind. Die Vertrauensinfrastruktur darunter, swiyu genannt, hat einen eigenen Zeitplan und soll im ersten Halbjahr 2027 in Betrieb gehen. Bedient Ihre Anwendung Kundschaft in der Schweiz, kommt die Frage „Können wir uns mit der E-ID anmelden?“ vor der E-ID selbst. Hier steht, was zur Antwort gehört und was sich vor beiden Daten schon tun lässt.

## Was eine Wallet Ihnen übergibt

Die E-ID ist kein Login-Provider. Niemand wird auf eine Seite des Bundes weitergeleitet und kommt mit einem Token zurück. Sie ist ein Credential in einer Wallet-App auf dem Telefon, und der Ablauf ist eine Präsentation: Ihre Anwendung fragt nach bestimmten Attributen, die Wallet zeigt der Person, wonach gefragt wird, die Person stimmt zu, und die Wallet schickt eine signierte Präsentation. Ihre Seite prüft drei Dinge: die Signatur des Ausstellers auf dem Credential, den Nachweis, dass diese Wallet es hält, und dass es nicht widerrufen wurde.

Die Formate sind öffentlich und nicht exotisch. Credentials sind SD-JWT VCs: ein JSON Web Token, in dem jedes Attribut, das sich einzeln offenlegen lässt, durch einen Digest ersetzt ist, sodass die Wallet den Nachnamen zeigen kann, ohne das Geburtsdatum preiszugeben. Aussteller und Verifizierer werden durch DIDs vom Typ `did:webvh` identifiziert, veröffentlicht in einem Basisregister, das der Bund betreibt. Die Verifikation läuft über OpenID4VP 1.0, eine Anfrage und eine Antwort, mit einer Abfragesprache, DCQL, die die gewünschten Attribute benennt. Widerruf läuft über eine Token Status List, signiert vom Aussteller und im selben Register gehostet. Wer schon OpenID Connect implementiert hat, wird die Formen vertraut finden und die Details neu.

## Was Sie bekommen und was nicht

Sie bekommen die Attribute, nach denen Sie gefragt und denen die Person zugestimmt hat: einen Nachnamen, Vornamen, ein Geburtsdatum oder, wo das Credential es enthält, nur die Angabe, ob die Person über 18 ist. Eine E-Mail-Adresse bekommen Sie nicht, denn die E-ID hat keine. Sie bekommen kein Passwort, keine Session und keinen Benutzerdatensatz; die müssen Sie selbst anlegen.

Diese eine Tatsache prägt das Datenmodell. Eine Anwendung, die Leute an ihrer E-Mail-Adresse erkennt, muss lernen, dass eine Person mit verifiziertem Namen und ganz ohne Adresse ankommen kann und dass zwei Personen Namen und Geburtstag teilen können. Welches Attribut dieselbe Person beim nächsten Mal wiedererkennt, überlässt das Protokoll Ihnen, und diese Entscheidung verdient Sorgfalt. Bietet das Credential eine Personennummer an: Ein Identifikator, der die Person in jedes andere System begleitet, ist mehr, als ein Login braucht. Prüfen Sie, was das Gesetz erlaubt, bevor Sie einen speichern.

## Was Sie bereit haben sollten

- **Einen Platz für einen externen Identifikator neben der Adresse.** Ein Konto kann null oder mehr verknüpfte Identitäten haben; die E-ID wäre eine davon, neben einem Passkey und neben „mit Google angemeldet“. Hat Ihre Benutzertabelle eine einzige Spalte `email` und einen Passwort-Hash, ist das die Änderung.
- **Eine Unterscheidung zwischen dem, was die Person eingetippt hat, und dem, was verifiziert wurde.** Ein verifizierter Nachname ist mehr wert als ein eingetippter, und Sie werden später wissen wollen, welcher welcher ist, für eine Signatur, einen Vertrag oder eine Altersprüfung.
- **Eine Step-up-Regel.** Der grösste Teil einer Anwendung braucht keine verifizierte Identität; eine Zahlung, eine Signatur oder die Änderung eines Bankkontos vielleicht schon. Legen Sie fest, welche Aktionen die E-ID verlangen und welche ein Passwort akzeptieren, bevor die E-ID kommt. Dann ist die Entscheidung eine Regel und keine Diskussion pro Feature.
- **Einen Weg, ein bestehendes Konto zu verknüpfen.** Ihre Kundinnen und Kunden haben schon Konten. Das erste Login mit der E-ID muss „Das bin ich, verknüpfen“ anbieten, statt ein Duplikat anzulegen.
- **Einen zweiten Weg für alle anderen.** Die E-ID ist freiwillig, eine Ergänzung zur Identitätskarte. Jede Aktion, die nach ihr fragt, braucht einen anderen Weg für Leute, die keine haben.

Nichts davon setzt voraus, dass es die E-ID schon gibt. Alles davon ist einfacher, bevor die erste Kundin fragt.

## Was sich heute ausprobieren lässt

Der Bund betreibt eine Sandbox, eine Testumgebung der Vertrauensinfrastruktur, ohne Beschränkung der Teilnehmenden. Er veröffentlicht Referenzsoftware: einen generischen Verifier und einen generischen Issuer, sofort lauffähig, und eine DID-Toolbox für die Schlüssel. Die App swiyu Sandbox Wallet hält Testidentitäten, darunter eine Beta-ID, die die technischen Eigenschaften der künftigen E-ID hat und keine rechtliche Gültigkeit.

Eine funktionierende Verifikation braucht vier Schritte Einrichtung: die Sandbox-Wallet installieren, Ihre Organisation im swiyu-Portal registrieren, mit der Toolbox Schlüssel und eine DID erzeugen und den generischen Verifier starten. Danach legen Sie über dessen Management-API mit einer DCQL-Abfrage eine Verifikation an, machen aus dem zurückgegebenen Deep Link einen QR-Code, scannen ihn mit der Wallet und fragen den Verifier so lange nach dem Ergebnis, bis er eines hat. Das Cookbook des Bundes geht jeden Schritt durch. Was zurückkommt, ist genau das, was Ihr Kontomodell aufnehmen muss, und damit ein billiges Design-Review.

## Wo EAuth steht

EAuth unterstützt die E-ID heute nicht, und ich nenne kein Datum für etwas, dessen eigenes Datum nicht feststeht. Was es gibt, ist Vorbereitung: ein schriftliches Design und die Lektüre hinter diesem Beitrag. Die Absicht, keine Zusage, ist, dass eine Anwendung auf EAuth die E-ID über das OpenID-Connect-Login bekommt, das sie schon nutzt, ohne einen eigenen Verifier zu betreiben. Sobald es etwas zum Ausprobieren gibt, sagen es die Dokumentation und dieses Journal.

Bis dahin ist die Arbeit aus den Abschnitten oben dieselbe, egal wer die Präsentation am Ende prüft, und nichts davon wartet auf Bern.

## Quellen

1. [Neuer Zeitplan für die Einführung der E-ID und der Vertrauensinfrastruktur](https://www.bj.admin.ch/de/newnsb/4ZNYpSk3J1-U), Federal Office of Justice, gelesen am 2026-10-03
2. [Sandbox](https://www.eid.admin.ch/en/sandbox-e), Swiss Confederation, gelesen am 2026-10-03
3. [Technology Stack, swiyu technical documentation](https://swiyu-admin-ch.github.io/technology-stack/), Swiss Confederation, gelesen am 2026-10-03
4. [How to integrate the swiyu Generic Verifier](https://swiyu-admin-ch.github.io/cookbooks/onboarding-generic-verifier/), Swiss Confederation, gelesen am 2026-10-03
5. [OpenID for Verifiable Presentations 1.0](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html), OpenID Foundation, gelesen am 2026-10-03
6. [RFC 9901: Selective Disclosure for JSON Web Tokens](https://www.rfc-editor.org/rfc/rfc9901.html), IETF, gelesen am 2026-10-03