--- title: "Preparing a web application for the Swiss e-ID" summary: "The e-ID is late. What a web application will receive from a wallet, what to change in your account model now, and what the sandbox offers today." author: "Samuel Krauss" author_title: "Founder" publisher: "Elchi Studios" published: 2026-10-03 updated: 2026-10-03 url: https://elchi.dev/en/journal/preparing-for-the-swiss-e-id language: en tags: ["e-id","swiyu","identity","switzerland","eauth"] words: 985 --- # Preparing a web application for the Swiss e-ID *By Samuel Krauss, Founder. Published 3 October 2026.* > The e-ID is late. What a web application will receive from a wallet, what to change in your account model now, and what the sandbox offers today. Switzerland voted for a state electronic identity, and the Confederation is building it. On 30 June 2026 the Federal Office of Justice postponed the launch, which had been planned for the second half of this year, without a new date: the date will be announced once further security work, against deepfakes and malware among other things, is largely done. The trust infrastructure under it, called swiyu, is on its own schedule and expected to operate in the first half of 2027. If your application serves Swiss customers, the question "can we log in with the e-ID" arrives before the e-ID does. This is what the answer involves, and what can be done before either date. ## What a wallet hands you The e-ID is not a login provider. Nobody redirects to a government page and comes back with a token. It is a credential in a wallet app on the phone, and the flow is a presentation: your application asks for specific attributes, the wallet shows the person what is being asked, the person agrees, and the wallet sends a signed presentation. Your side checks three things: the issuer's signature on the credential, the proof that this wallet holds it, and that it has not been revoked. The formats are public and not exotic. Credentials are SD-JWT VCs: a JSON Web Token in which each attribute that can be disclosed on its own is replaced by a digest, so the wallet can reveal the family name without the date of birth. Issuers and verifiers are identified by DIDs of the `did:webvh` kind, published on a base registry the Confederation runs. Verification runs over OpenID4VP 1.0, a request and a response, with a query language, DCQL, that names the attributes you want. Revocation is a token status list, signed by the issuer and hosted on the same registry. Anybody who has implemented OpenID Connect will find the shapes familiar and the details new. ## What you receive, and what you do not You receive the attributes you asked for and the person agreed to: a family name, given names, a date of birth, or, where the credential carries it, only whether the person is over 18. You do not receive an email address, because the e-ID has none. You do not receive a password, a session or a user record; those are yours to make. That single fact shapes the data model. An application that identifies people by email address has to learn that a person may arrive with a verified name and no address at all, and that two people may share a name and a birthday. Which attribute recognises the same person next time is a decision the protocol leaves to you, and it deserves care. If the credential offers a personal number, an identifier that follows the person into every other system is more than a login needs; check what the law allows before you store one. ## What to have ready - **A place for an external identifier beside the address.** An account can have zero or more linked identities; the e-ID would be one of them, next to a passkey and next to "signed in with Google". If your users table has one `email` column and a password hash, this is the change. - **A distinction between what the person typed and what was verified.** A verified family name is worth more than a typed one, and you will want to know which is which later, for a signature, a contract or an age check. - **A step-up rule.** Most of an application does not need a verified identity; a payment, a signature or a change of bank account might. Decide which actions will require the e-ID and which accept a password before the e-ID arrives, so the decision is a rule and not an argument per feature. - **A way to link an existing account.** Your customers already have accounts. The first e-ID sign-in must offer "this is me, link it" rather than create a duplicate. - **A second way for everybody else.** The e-ID is optional, a complement to the identity card. Every action that asks for it needs another path for people who do not have it. None of this requires the e-ID to exist. All of it is easier before the first customer asks. ## What can be tried today The Confederation runs a sandbox, a test environment of the trust infrastructure, with no limit on participants. It publishes reference software: a generic verifier and a generic issuer, ready to run, and a DID toolbox for the keys. The swiyu Sandbox Wallet app holds test identities, among them a Beta-ID, which has the technical characteristics of the future e-ID and no legal validity. A working verification takes four steps of setup: install the sandbox wallet, register your organisation on the swiyu portal, generate keys and a DID with the toolbox, and run the generic verifier. Then you create a verification through its management API with a DCQL query, turn the deep link it returns into a QR code, scan it with the wallet, and ask the verifier for the result until it has one. The Confederation's cookbook walks through each step. What comes back is exactly what your account model will have to take, which makes it a cheap design review. ## Where EAuth stands EAuth does not support the e-ID today, and I will not give a date for something whose own date is not set. What exists is preparation: a written design and the reading behind this post. The intention, not a commitment, is that an application on EAuth receives the e-ID through the OpenID Connect sign-in it already uses, without running a verifier of its own. When there is something you can try, the documentation and this journal will say so. Until then, the work in the sections above is the same whoever verifies the presentation in the end, and none of it waits for Bern. ## Sources 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, read 2026-10-03 2. [Sandbox](https://www.eid.admin.ch/en/sandbox-e), Swiss Confederation, read 2026-10-03 3. [Technology Stack, swiyu technical documentation](https://swiyu-admin-ch.github.io/technology-stack/), Swiss Confederation, read 2026-10-03 4. [How to integrate the swiyu Generic Verifier](https://swiyu-admin-ch.github.io/cookbooks/onboarding-generic-verifier/), Swiss Confederation, read 2026-10-03 5. [OpenID for Verifiable Presentations 1.0](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html), OpenID Foundation, read 2026-10-03 6. [RFC 9901: Selective Disclosure for JSON Web Tokens](https://www.rfc-editor.org/rfc/rfc9901.html), IETF, read 2026-10-03