Accettare una presentazione dell'EUDI Wallet è una decisione di fiducia, e il codice di integrazione è il punto in cui tale decisione viene presa. Questo articolo è rivolto alle relying party: i comuni e i fornitori di servizi che accetteranno presentazioni dal wallet, non i team che sviluppano i wallet. Elenca le domande a cui vorremmo avere risposta prima di attivare il wallet per utenti reali, come checklist di revisione e non come progetto definitivo.
Sapere a quale specifica ci si sta riferendo
Il fondamento tecnico è l'Architecture and Reference Framework (ARF). È pubblicato in un repository GitHub pubblico e sviluppato nell'ambito del Common Union Toolbox. Il repository indica che la versione autorevole più recente è l'ultima release con tag. Un branch o la sintesi di un blog non hanno valore di riferimento.
La base giuridica è il Regolamento (UE) n. 910/2014 come modificato dal Regolamento (UE) 2024/1183, insieme ai relativi regolamenti di esecuzione della Commissione. L'ARF rimanda all'elenco aggiornato di tali atti nelle sezioni Introduction e References.
Le prime domande sono dunque di natura amministrativa, ma contano:
- Su quale release dell'ARF si è basato il vostro fornitore o integratore?
- Chi, da parte Vostra, monitora le nuove release con tag e i regolamenti di esecuzione, e come arrivano le modifiche al Vostro backlog?
- Il contratto con il fornitore di identità indica una versione precisa, oppure soltanto «conforme a eIDAS 2.0»?
Domande sull'asserzione
Il wallet consegna al Vostro servizio una presentazione. Prima che possa diventare una sessione, occorre sapere che cosa è stato effettivamente verificato.
- Chi l'ha emessa? Il Vostro servizio dovrebbe accettare presentazioni solo da emittenti che avete deciso di considerare affidabili, per i tipi di attributo che avete deciso di accettare. «Qualsiasi firma valida» non è una policy. Mettete per iscritto l'elenco di accettazione, indicate un responsabile e definite come si aggiungono e si rimuovono le voci.
- È legata a questa transazione? Una presentazione che può essere riproposta (replay) contro il Vostro endpoint di login è una credenziale rubata in attesa di essere usata. Verificate con il fornitore come una presentazione viene associata alla Vostra sessione e testate che una presentazione vecchia venga rifiutata.
- Che cosa accade quando la verifica fallisce o non è disponibile? Decidete se il sistema debba adottare un comportamento fail closed. Controllate che la gestione degli errori e le condizioni di carico non indirizzino gli utenti verso un percorso di fallback più debole.
- Che cosa registrate nei log? Servono dati sufficienti per indagare su un incidente, senza conservare i dati personali che il wallet è stato progettato per ridurre al minimo.
Una precisazione sul primo punto: la policy di accettazione di emittenti e attributi è il controllo che raccomandiamo. Non è un requisito citato dall'ARF.
Domande sugli attributi
La Commissione descrive il wallet come uno strumento che consente agli utenti di divulgare solo i dettagli necessari, come l'età o la nazionalità, trattenendo gli altri dati personali. Questo definisce l'aspettativa che la Vostra integrazione, in quanto relying party, deve soddisfare.
Se il Vostro servizio deve sapere che una persona ha superato una certa età, chiedete questo e non la data di nascita. Se serve un residente nel Vostro comune, chiedete l'attributo che lo dimostra, non l'indirizzo completo. Ogni attributo aggiuntivo richiesto aumenta i dati che dovete proteggere e giustificare nella Vostra valutazione d'impatto sulla privacy.
Chiedetevi poi che cosa l'attributo dimostri realmente. Un attributo emesso da un ente pubblico e uno emesso da un soggetto privato possono convivere nello stesso wallet e apparire identici nel Vostro codice. Associate ciascuno alla decisione che supporta. Il numero di una tessera di biblioteca non dovrebbe consentire l'accesso alla dichiarazione dei redditi.
Una singola riga della policy di accettazione potrebbe avere questo aspetto. I valori illustrano il formato e non costituiscono una raccomandazione:
| Emittente | Attributo | Decisione della relying party | Responsabile | Intervallo di revisione |
|---|---|---|---|---|
| Emittente di ID nazionale (esempio) | Età superiore a 18 anni | Consentire l'accesso al servizio con restrizioni di età; non conservare la data di nascita | Responsabile del servizio | Ogni sei mesi |
Se non riuscite a compilare tutte e cinque le colonne per una voce, quella voce non è pronta per entrare nell'elenco.
Per l'uso in ambito organizzativo, i progetti pilota stanno sperimentando le identità digitali organizzative come caso d'uso: dimostrare che una persona è un rappresentante legittimo di un'organizzazione. Se servite imprese, decidete fin d'ora come tratterete una persona che agisce per conto di una società e come verrete a sapere quando i suoi poteri di rappresentanza cessano.
Domande sui flussi di firma
La firma dei contratti è uno degli scenari dei progetti pilota, quindi va trattata come un caso di assurance distinto dal login.
- Da quali servizi dipende il Vostro flusso di firma o di sigillo, e chi li gestisce?
- Che cosa conservate come evidenza di una firma, e per quanto tempo?
- Se una firma venisse contestata tra due anni, sareste in grado di dimostrare che cosa è stato presentato e verificato in quel momento?
Non date per scontato che un login riuscito implichi una catena di firma valida. Sono controlli separati, con modalità di errore separate. I Vostri team legale e sicurezza dovrebbero concordare che cosa costituisce un'evidenza accettabile prima che venga firmato il primo contratto.
Testare l'integrazione, e poi testarla di nuovo
Il wallet prototipo della Commissione include librerie di codice e un'applicazione di esempio, e l'implementazione di riferimento è open source. Il repository dell'ARF rimanda a un sito di conformità. Usate questi strumenti per i test, non come dipendenza di produzione che non avete mai sottoposto a revisione.
I progetti pilota su larga scala coinvolgono oltre 350 soggetti di 26 Stati membri, Norvegia, Islanda e Ucraina, e coprono ambiti come i servizi pubblici, il settore bancario e i pagamenti. I Vostri endpoint, i percorsi di fallback e la gestione delle sessioni richiedono comunque test propri.
Trattate l'integrazione come nuovo codice di autenticazione. Ciò significa un threat model, test di abuse case contro replay, presentazioni malformate ed emittenti inattesi, e un penetration test del flusso completo prima del go-live. Qualunque test abbia svolto il fornitore del wallet, il Vostro servizio di relying party richiede una revisione indipendente.
Da dove iniziare
- Fissate il Vostro riferimento: registrate la release dell'ARF e i regolamenti di esecuzione su cui si basa l'integrazione, e incaricate qualcuno di monitorarne le modifiche.
- Scrivete una policy di accettazione: elencate gli emittenti e i tipi di attributo di cui Vi fiderete, la decisione supportata da ciascuno, il responsabile e l'intervallo di revisione.
- Riducete le richieste di attributi al minimo necessario per ciascun servizio e documentate il risultato nella Vostra valutazione d'impatto sulla privacy.
- Costruite un piano di test sull'implementazione di riferimento e sulle risorse di conformità, includendo casi di replay, emittente errato, modalità di errore e percorsi di fallback.
- Separate login e firma: decidete quali evidenze conservare per ciascuno e chi le approva.
- Fate eseguire una revisione indipendente prima del go-live. Se desiderate un supporto per definirne il perimetro, contatti il nostro team di consulenza.
