Lo scenario operativo per l’attuazione del nuovo Regolamento eIDAS, mentre il percorso legislativo prosegue nelle sedi istituzionali comunitarie, dispone anche di un fondamentale tassello operativo con la pubblicazione del documento comunemente referenziato come Architecture and Reference Framework (ARF).
Il documento che commentiamo in questa sede è ufficialmente intitolato
“The Common Union Toolbox for a Coordinated Approach Towards a European Digital Identity Framework” (sottotitolato “The European Digital Identity Wallet Architecture and Reference Framework”) e rappresenta la base di riferimento per la costruzione funzionale del EDIW, il portafoglio europeo di identità digitale.
L’elaborazione di questo documento è stata complessa e ha coinvolto attori istituzionali e di mercato a partire da circa due anni fa. La pubblicazione avvenuta il 10 febbraio 2023 segna l’avvio ufficiale dello sviluppo per il EDIW (nel seguito wallet).
Il documento completo è disponibile al collegamento seguente:
Iniziamo a commentare questo documento concentrandoci sugli elementi più significativi.
Lo scopo del documento ARF è quello di fornire tutte le specifiche necessarie per sviluppare una soluzione di wallet interoperabile basata su standard e pratiche comuni.
Il documento presenta uno stato di avanzamento dei lavori in corso del gruppo di esperti eIDAS (rappresentato con un rigoroso numero di versione a tre cifre) e non implica alcun accordo formale in merito al suo contenuto o alla proposta legislativa.
Questo documento è integrato e aggiornato nel tempo attraverso il processo di definizione del toolbox, come descritto nel capitolo 8 di questo documento.
Una volta disponibile lo scenario, anche legislativo, consolidato, il documento descriverà la completa architettura e un quadro di riferimento che copre tutte le specifiche necessarie per implementare una soluzione europea di wallet.
La base funzionale del wallet deve essere sviluppata e fornita alle parti che vi fanno affidamento (relying parties) in modalità a codice aperto (open source). In tal senso la Commissione europea ha cofinanziato una serie di consorzi che hanno lo scopo di sviluppare la parte principale e le parti accessorie, tutte coordinate nella parte di sviluppo e di test funzionale con il comune cruciale obiettivo di mantenere il massimo controllo sui temi della sicurezza cibernetica e dell’interoperabilità.
L’ecosistema generale del wallet è rappresentato nella figura seguente tratta dal documento in esame.
Figura 1: Panoramica dei ruoli nel EDIW
1. Utenti finali del EDIW
2. Prestatori del EDIW
3. Prestatori di Dati Identificativi della Persona (PID)
4. Prestatori di elenchi pubblici di fiducia
5. Prestatori di attestazioni elettroniche di attributi qualificate (QEEA)
6. Prestatori di attestazioni elettroniche di attributi non qualificate (EEA)
7. Prestatori di certificati qualificati e non qualificati per le firme e i sigilli elettronici
8. Fonti autentiche
9. Parti facenti affidamento
10. Organismi per la valutazione della conformità (CAB)
11. Organismi di vigilanza
12.Fabbricanti di dispositivi e fornitori dei sottosistemi relativi
13. Prestatori degli schemi (Q)EAA
14. Organismi nazionali di accreditamento
Il wallet, per raggiungere i suoi obiettivi, deve interagire con le istituzioni che forniscono le identità digitali e gli attestati elettronici degli attributi così come stabilito nella bozza di “Proposta di Regolamento che modifica il Regolamento (UE) No 910/2014 per quanto riguarda l’istituzione di un quadro per un’Identità Digitale Europea” nel seguito eIDAS II.
Per comprendere la figura è indispensabile conoscere il significato degli acronimi.
Per non appesantire la lettura, per l’elenco completo si rinvia alla tabella del glossario a partire dalla pagina 7 del documento ARF.
In fase operativa l’utente interagisce, tramite il wallet, con chi emette i PID (Person Identification Data) o gli EAA (Electronic Attestation of Attributes) che sono qualificati (QEAA) secondo le regole stabilite dai soggetti di Governance (in rosa nella figura).
Le figure previste sono già funzionalmente note per la loro presenza nelle attività di qualifica dei prestatori di servizi fiduciari (Trust Service Provider) stabilite nel vigente Regolamento 910/2014.
Per agire nel modo più pratico possibile il gruppo di esperti eIDAS, preposto alla redazione del documento in esame, ha individuato alcuni casi d’uso che fanno parte della sperimentazione in corso nell’ambito dei cosiddetti Large Scale Pilots (LSP).
Come è prassi comunitaria per questo tipo di progetti, da essi ci si attende un ritorno operativo sui meccanismi di interazione tra i nuovi sviluppi e le interazioni con i servizi delle parti facenti affidamento al wallet, i prestatori di attestazioni elettroniche degli attributi qualificati e non qualificati (Q)EAA, i prestatori dei dati identificativi della persona (PID) e naturalmente degli utenti che utilizzando transazioni significative nell’ambito dei casi d’uso previsti nell’ARF.
I consorzi cofinanziati dalla Commissione si stanno focalizzando sulla struttura di base del wallet, l’identificazione sicura e affidabile per accedere ai servizi online, mobilità e patente digitale, dati e pratiche sanitarie, titoli di studio e qualifiche sanitarie, finanza digitale e credenziali di viaggio digitali. Il documento ARF non esclude ulteriori scenari per la sperimentazione essendo esso stesso un documento naturalmente dinamico.
Il documento descrive poi, con un paragrafo dedicato a ciascun ruolo, tutti quelli che hanno occupato i box mostrata in figura 1.
I meccanismi macroscopici di ingaggio e gestione delle varie fasi del ciclo di vita del wallet sono analoghi a quelli dei servizi qualificati del vigente Regolamento 910/2014. Naturalmente un ruolo importante lo hanno anche gli attestati elettronici degli attributi che si adeguano a quanto già noto per i servizi fiduciari qualificati e non qualificati. Stesso discorso per l’elenco pubblico di fiducia (TSL) che deve comunque ampliare il suo raggio di azione e prevede (con qualche indicazione generica) un elenco dei vari prestatori di servizio che possono operare nel contesto eIDAS II.
Ritroviamo anche i CAB (Conformity Assessment Bodies), gli organismi di vigilanza e quelli nazionali di accreditamento ai sensi del Regolamento europeo No 765/2008.
Le Fonti Autentiche (Authentic Sources) sono una novità. Queste sono definite nel glossario come: “Un archivio o sistema, tenuto sotto la responsabilità di un ente pubblico o di un ente privato, che contiene attributi relativi a una persona fisica o giuridica ed è considerato la fonte primaria di tali informazioni o riconosciuto come autentico dalla legislazione nazionale”. La definizione deriva dalla Proposta di modifica del Regolamento eIDAS. Quest’ultimo Regolamento dedica al tema l’Allegato VI.
L’ARF conclude la descrizione dei ruoli in gioco con il wallet trattando dei produttori di dispositivi e di entità correlate.
In questo paragrafo si tratta delle possibili interfacce con l’esterno del wallet, importanti oltre che per le funzionalità richieste, anche per le esigenze di sicurezza del wallet che deve memorizzare e gestire informazioni crittografiche e di sicurezza con il massimo livello di garanzia in base ai requisiti della Proposta di modifica eIDAS.
L’ARF passa poi a descrivere il ciclo di vita del wallet iniziando a concretizzare l’alto livello di astrazione del testo di legge. Si descrive quindi un modello a oggetti del wallet e i cicli di vita delle varie componenti partendo dal PID e dai (Q)EAA.
La realizzazione del wallet ha anche un suo ciclo di vita indipendente che porta all’inizio ad un soluzione “candidata” ad essere wallet. Dopo i passaggi di certificazione con il CAB, uno Stato Membro decide la messa in opera portando la soluzione allo stato “valido”.
Fatto il contenitore si devono attivare i contenuti. Quindi il documento ARF passa a descrivere il ciclo di vita dell’istanza di wallet che viene inizializzato dopo l’accettazione e verifica di un prestatore di PID che attiva un set di PID valido.
La validità dei PID è indispensabile per un wallet attivo con componenti attive valide come certificati di firma qualificata o (Q)EAA.
Il documento entra sempre in maggiore dettaglio sulle azioni operative e quindi vengo descritti i Requisiti per l’emissione di PID e (Q)EAA. Nei dettagli si indicano gli insiemi di dati (dataset) da utilizzare.
L’architettura di riferimento e i flussi operativi rappresentano un insieme di scelte effettuate durante il processo di progettazione dell’architettura delle soluzioni di wallet.
Si tiene conto delle necessità dell’utente che può operare in vari scenari e quindi le opzioni sono flessibili per evitare rigidità nel processo di sviluppo e messa in opera degli elementi.
Abbiamo poi considerazioni sul design e sulle componenti dell’architettura, come ad esempio l’archivio delle chiavi crittografiche o i formati del PID e degli (Q)EAA.
L’architettura logica del wallet è descritta diffusamente tanto da impegnare il paragrafo più lungo del documento ARF.
L’ultimo paragrafo operativo del documento ARF tratta della configurazione del wallet partendo dal razionale dell’oggetto fino a sviluppare la configurazione iniziale e i requisiti di configurazione del wallet.
I requisiti di tipo 1 sono obbligatori (MUST) quelli di tipo 2 sono opzionali (SHOULD o MAY) secondo il linguaggio tipico degli standard (RFC 2119).
I riferimenti operativi sono derivati da standard come ISO/IEC 18013-5: 2021 o il W3C per i web services. I riferimenti a OpenID4VCI per la verifica delle credenziali è un altro riferimento agli standard. Tutti i riferimenti documentali agli standard e alle specifiche tecniche sono raccolti nel capitolo finale che il numero 9.
Prima di questo abbiamo il capitolo 7 dedicato al processo di certificazione del wallet. Quest’ultimo è basato su regole consolidate per la certificazione con il coinvolgimento dei CAB che opereranno sulla base di regole che saranno anche coordinate con le norme comunitarie sulla sicurezza cibernetica e sugli schemi di certificazione stabilite in quella sede.
Il capitolo 8 è descrittivo dell’architettura e del modello di riferimento per il processo di sviluppo del wallet che viene pubblicato al collegamento dove sarà possibile seguirne il ciclo di vita in linea con gli scenari e le regole di GitHub.
Si può consultare il collegamento seguente:
Importante elemento di scenario è la gestione del numero di versione dell’ARF che è a tre cifre.
La prima (MAJOR) è il numero di versione, la seconda (MINOR) tiene conto di nuove informazioni aggiunte o rimosse dal documento, la terza (PATCH) viene incrementata in seguito a piccoli cambiamenti come la correzione di refusi.
Per concludere qualche breve considerazione sul documento ARF versione 1.0.0.
La qualità del documento è certamente elevata e il fatto che si proceda con i progetti pilota prima che sia definitivo il testo della Proposta di modifica del Regolamento è un segno di una forte volontà comunitaria di accelerare i tempi.
Ciò nonostante la complessità del wallet, soprattutto nell’interazione con tantissimi mondi esterni e eterogenei porta a qualche dubbio sui tempi al momento indicati nella bozza di Regolamento eIDAS.
Gli scenari stabiliti per i progetti pilota sono interessanti e ragionevoli ma gli Stati Membri sono tanti e di dimensioni estremamente diversa con sviluppi interni disomogenei sui temi del digitale. Qualcosa di funzionante nascerà e sarà certificato con qualche sforzo per i dispositivi di firma. Nuove tecnologie saranno disponibili per l’uso quotidiano, ma l’utente non deve essere lasciato indietro anche perché l’adozione del wallet non è obbligatoria e quindi i servizi devono essere utilizzabili anche con altri strumenti.
L’elemento cruciale sta nel fatto che l’attuale scenario funzionante e obbligatorio (vedi lo SPID) deve convergere “dolcemente” verso il wallet e questo deve essere il tema centrale per il supporto politico sulla materia. La sicurezza non è semplice da gestire e l’utente medio tende a ignorare le regole di sicurezza. Lo sappiamo perché oggi è così e la parte formativa deve essere curata anche con il mezzo radio televisivo.
Il progresso non si ferma ma bisogna gestire il rischio ed evitarlo, che la trasformazione digitale si trasformi in schiavitù digitale, seppur con tutta la buona fede del caso. Questo creerebbe rigetto e non supporto da parte dell’utente medio che solo parzialmente è un nativo digitale.