---
title: "Preparare un'applicazione web per l'e-ID svizzera"
summary: "L'e-ID è in ritardo. Cosa riceverà un'applicazione web da un wallet, cosa cambiare ora nel Suo modello degli account e cosa offre oggi la sandbox."
author: "Samuel Krauss"
author_title: "Founder"
publisher: "Elchi Studios"
published: 2026-10-03
updated: 2026-10-09
url: https://elchi.dev/it/journal/preparare-un-applicazione-web-per-l-e-id-svizzera
language: it
translation_of: https://elchi.dev/en/journal/preparing-for-the-swiss-e-id
tags: ["e-id","swiyu","identity","switzerland","eauth"]
words: 980
---

# Preparare un'applicazione web per l'e-ID svizzera

*Di Samuel Krauss, Founder. Pubblicato il 3 ottobre 2026.*

> L'e-ID è in ritardo. Cosa riceverà un'applicazione web da un wallet, cosa cambiare ora nel Suo modello degli account e cosa offre oggi la sandbox.

La Svizzera ha votato a favore di un'identità elettronica statale, e la Confederazione la sta costruendo. Il 30 giugno 2026 l'Ufficio federale di giustizia ha rinviato il lancio, previsto per la seconda metà di quest'anno, senza indicare una nuova data: la data sarà comunicata quando saranno in gran parte conclusi ulteriori lavori di sicurezza, tra l'altro contro deepfake e malware. L'infrastruttura di fiducia che sta sotto, chiamata swiyu, ha un calendario proprio e dovrebbe entrare in funzione nella prima metà del 2027. Se la Sua applicazione serve clienti svizzeri, la domanda «possiamo accedere con l'e-ID?» arriverà prima dell'e-ID. Ecco cosa comporta la risposta, e cosa si può fare prima dell'una e dell'altra data.

## Cosa Le consegna un wallet

L'e-ID non è un provider di login. Nessuno viene reindirizzato a una pagina della Confederazione per tornare con un token. È una credenziale in un'app wallet sul telefono, e il flusso è una presentazione: la Sua applicazione chiede attributi specifici, il wallet mostra alla persona cosa viene chiesto, la persona acconsente e il wallet invia una presentazione firmata. Dalla Sua parte si verificano tre cose: la firma dell'emittente sulla credenziale, la prova che questo wallet la detiene e il fatto che non sia stata revocata.

I formati sono pubblici e per nulla esotici. Le credenziali sono SD-JWT VC: un JSON Web Token in cui ogni attributo che può essere rivelato singolarmente è sostituito da un digest, così il wallet può rivelare il cognome senza la data di nascita. Emittenti e verificatori sono identificati da DID del tipo `did:webvh`, pubblicati su un registro di base gestito dalla Confederazione. La verifica passa per OpenID4VP 1.0, una richiesta e una risposta, con un linguaggio di interrogazione, DCQL, che nomina gli attributi richiesti. La revoca è una token status list, firmata dall'emittente e ospitata sullo stesso registro. Chi ha implementato OpenID Connect troverà familiari le forme e nuovi i dettagli.

## Cosa riceve, e cosa no

Riceve gli attributi che ha chiesto e che la persona ha accettato di dare: un cognome, i nomi, una data di nascita oppure, dove la credenziale lo prevede, solo l'informazione se la persona ha più di 18 anni. Non riceve un indirizzo e-mail, perché l'e-ID non ne ha. Non riceve una password, una sessione o un record utente; quelli deve crearli Lei.

Questo solo fatto dà forma al modello dei dati. Un'applicazione che identifica le persone tramite l'indirizzo e-mail deve imparare che una persona può arrivare con un nome verificato e nessun indirizzo, e che due persone possono avere lo stesso nome e lo stesso compleanno. Quale attributo riconosca la stessa persona la volta successiva è una decisione che il protocollo lascia a Lei, e merita attenzione. Se la credenziale offre un numero personale, un identificativo che segue la persona in ogni altro sistema è più di quanto serva a un login; verifichi cosa consente la legge prima di salvarne uno.

## Cosa preparare

- **Un posto per un identificativo esterno accanto all'indirizzo.** Un account può avere zero o più identità collegate; l'e-ID sarebbe una di queste, accanto a una passkey e accanto ad «accedi con Google». Se la Sua tabella degli utenti ha una sola colonna `email` e un hash della password, il cambiamento da fare è questo.
- **Una distinzione tra ciò che la persona ha digitato e ciò che è stato verificato.** Un cognome verificato vale più di uno digitato, e più avanti vorrà sapere quale è quale, per una firma, un contratto o una verifica dell'età.
- **Una regola di step-up.** Gran parte di un'applicazione non ha bisogno di un'identità verificata; un pagamento, una firma o il cambio di un conto bancario potrebbero averne. Decida quali azioni richiederanno l'e-ID e quali accettano una password prima che l'e-ID arrivi, così la decisione è una regola e non una discussione per ogni funzione.
- **Un modo per collegare un account esistente.** I Suoi clienti hanno già un account. Il primo accesso con l'e-ID deve offrire «sono io, collegalo» invece di creare un doppione.
- **Una seconda strada per tutti gli altri.** L'e-ID è facoltativa, un complemento alla carta d'identità. Ogni azione che la chiede ha bisogno di un'altra strada per chi non ce l'ha.

Nulla di tutto questo richiede che l'e-ID esista. Tutto è più facile prima che lo chieda il primo cliente.

## Cosa si può provare oggi

La Confederazione gestisce una sandbox, un ambiente di test dell'infrastruttura di fiducia, senza limiti di partecipanti. Pubblica software di riferimento: un verificatore generico e un emittente generico, pronti all'uso, e un DID toolbox per le chiavi. L'app swiyu Sandbox Wallet contiene identità di test, tra cui una Beta-ID, che ha le caratteristiche tecniche della futura e-ID e nessuna validità giuridica.

Una verifica funzionante richiede quattro passi di configurazione: installare il wallet della sandbox, registrare la propria organizzazione sul portale swiyu, generare chiavi e un DID con il toolbox e avviare il verificatore generico. Poi si crea una verifica tramite la sua API di gestione con una query DCQL, si trasforma il deep link restituito in un codice QR, lo si scansiona con il wallet e si chiede il risultato al verificatore finché non ne ha uno. Il cookbook della Confederazione accompagna ogni passo. Ciò che torna indietro è esattamente ciò che il Suo modello degli account dovrà accogliere, e questo ne fa una revisione del design a basso costo.

## A che punto è EAuth

Oggi EAuth non supporta l'e-ID, e non darò una data per qualcosa la cui data stessa non è fissata. Ciò che esiste è preparazione: un design scritto e le letture dietro questo articolo. L'intenzione, non un impegno, è che un'applicazione su EAuth riceva l'e-ID attraverso l'accesso OpenID Connect che usa già, senza dover gestire un verificatore proprio. Quando ci sarà qualcosa da provare, lo diranno la documentazione e questo diario.

Fino ad allora, il lavoro descritto nelle sezioni sopra è lo stesso chiunque verifichi la presentazione alla fine, e nulla di esso aspetta Berna.

## Fonti

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, consultato il 2026-10-03
2. [Sandbox](https://www.eid.admin.ch/en/sandbox-e), Swiss Confederation, consultato il 2026-10-03
3. [Technology Stack, swiyu technical documentation](https://swiyu-admin-ch.github.io/technology-stack/), Swiss Confederation, consultato il 2026-10-03
4. [How to integrate the swiyu Generic Verifier](https://swiyu-admin-ch.github.io/cookbooks/onboarding-generic-verifier/), Swiss Confederation, consultato il 2026-10-03
5. [OpenID for Verifiable Presentations 1.0](https://openid.net/specs/openid-4-verifiable-presentations-1_0.html), OpenID Foundation, consultato il 2026-10-03
6. [RFC 9901: Selective Disclosure for JSON Web Tokens](https://www.rfc-editor.org/rfc/rfc9901.html), IETF, consultato il 2026-10-03