10.5. Ciclo di Vita degli Attestati Elettronici

Questo capitolo specifica il ciclo di vita, la revoca e il controllo di stato di una Credenziale. La revoca di un'Istanza del Wallet è specificata in Revoca dell'Istanza del Wallet. La revoca dei certificati e dei Trust Artifact è specificata in Revocation Mechanisms.

Il Fornitore di Attestati Elettronici è responsabile della creazione e del rilascio degli Attestati Elettronici, nonché della gestione del loro ciclo di vita e dello stato di validità.

La Fonte Autentica è l'entità responsabile della gestione e della fornitura degli Attributi dell'Utente ai Fornitori di Attestati Elettronici. Esiste una relazione tra il ciclo di vita degli attributi gestiti dalla Fonte Autentica e il ciclo di vita degli Attestati Elettronici gestito dal Fornitore di Attestati Elettronici. Infatti, uno dei motivi per la revoca o la sospensione degli Attestati Elettronici è l'aggiornamento/revoca o sospensione degli attributi contenuti nell'Attestato Elettronico. In IT Wallet, la fornitura degli Attributi dell'Utente e la notifica di aggiornamenti o modifiche dei relativi stati vengono gestiti utilizzando l'infrastruttura PDND (vedere le relative sezioni per maggiori dettagli).

La Fig. 10.1 mostra gli stati e le transizioni relativi agli Attestati Elettronici. Include quattro stati distinti: Issued, Valid, Expired e Revoked. Mentre, nel caso degli Attestati Elettronici di Attributi (Q)EAA, c'è uno stato aggiuntivo: Suspended. Indipendentemente dallo stato, un Attestato Elettronico può essere eliminato (PID/(Q)EAA DEL) e questo termina il suo ciclo di vita.

Fig. 10.1 Transazioni di Stato degli Attestati Elettronici.

Nota

Gli Utenti POSSONO presentare un Attestato Elettronico in qualsiasi stato, spetta alla policy della Relying Party accettare un Attestato Elettronico non Valido. Un esempio di questo scenario è quando una Relying Party deve verificare che l'Utente non sia minorenne. In questo caso, anche se l'Utente presenta un Attestato Elettronico Issued/Expired/Revoked o Suspended, l'attributo relativo all'età è ancora affidabile.

Nota

Mentre Issued, Valid, Expired, Revoked sono esplicitamente menzionati nell'ARF (vedi Figura 5 di ARF v1.4), Suspended è implicitamente presente in EIDAS-ARF. Questa specifica lo considera esplicitamente.

10.5.1. Transizioni degli Attestati Elettronici

10.5.1.1. Transizione dell'Attestato Elettronico a Issued

Affinché la macchina a stati possa avviarsi, l'Istanza del Wallet DEVE essere nello stato Operational o Valid, consentendo il rilascio di Attestati Elettronici. La macchina a stati inizia con lo stato Issued, quando viene attivato un processo di emissione e, di conseguenza, un Attestato Elettronico viene rilasciato all' Istanza del Wallet (PID/(Q)EAA ISS). Si prega di fare riferimento a Emissione di Attestati Elettronici.

10.5.1.2. Transizione dell'Attestato Elettronico a Valid

Un Attestato Elettronico passa allo stato Valid quando:

• raggiunge la sua data di inizio validità.

• viene attivato un processo di riattivazione se l'Attestato Elettronico di Attributi (Q)EAA è stato sospeso.

10.5.1.3. Transizione dell'Attestato Elettronico a Expired

Un Attestato Elettronico passa naturalmente allo stato Expired quando scade automaticamente al raggiungimento della sua data di fine validità (PID/(Q)EAA EXP).

Se un Attestato Elettronico è Expired, l'Istanza del Wallet DOVREBBE notificare all'Utente che l'Attestato Elettronico è scaduto. L'Utente PUÒ eliminare l'Attestato Elettronico (PID/(Q)EAA DEL). Questo termina il suo ciclo di vita.

10.5.1.4. Transizione dell'Attestato Elettronico a Revoked

Un Attestato Elettronico passa dagli stati Issued, Valid o Suspended allo stato Revoked quando viene attivamente revocato dal Fornitore di Attestati Elettronici tramite un processo di revoca (PID/(Q)EAA REV). Le Relying Party NON DOVREBBERO più considerare utilizzabile un particolare Attestato Elettronico quando è Revoked, anche se è ancora temporalmente valido e contiene una firma valida del Fornitore di Attestati Elettronici. La revoca può avvenire nei seguenti casi:

• per motivi tecnici di sicurezza relativi alla compromissione del materiale crittografico.

• in caso di richieste esplicite dell'Utente.

• in caso di revoca degli attributi contenuti nell'Attestato Elettronico notificata dalla Fonte Autentica.

• morte dell'Utente.

• revoca dell'Istanza del Wallet a cui è stato rilasciato l'Attestato Elettronico.

• attività illegali dell'Utente segnalate da Organi Giudiziari o di Vigilanza.

Nel caso del solo PID e IT-Wallet ID, i seguenti casi si aggiungono a quelli sopra elencati.

• rilevamento di una violazione dell'identità digitale rilasciata da un Gestore di Identità Digitale e utilizzata per autenticare l'Utente durante il rilascio del PID/IT-Wallet ID.

• come risultato dell'ottenimento di un nuovo PID/IT-Wallet ID su una nuova Istanza del Wallet dallo stesso Fornitore di Wallet che ha fornito l'Istanza del Wallet contenente un PID/IT-Wallet ID precedentemente rilasciato.

Nota

Un Fornitore di Attestati Elettronici di Attributi (Q)EAA PUÒ revocare un Attestato Elettronico di Attributi (Q)EAA in caso di revoca del PID/IT-Wallet ID.

Quando un Attestato Elettronico è Revoked, l'Attestato Elettronico non può tornare allo stato Valid. L'Istanza del Wallet DOVREBBE notificare all'Utente che l'Attestato Elettronico è stato revocato. L'Utente PUÒ eliminare l'Attestato Elettronico (PID/(Q)EAA DEL). Questo termina il suo ciclo di vita.

10.5.1.5. Transizione dell'Attestato Elettronico a Suspended

Un Attestato Elettronico di Attributi (Q)EAA passa dagli stati Issued o Valid allo stato Suspended quando viene sospeso dal Fornitore di Attestati Elettronici ((Q)EAA SUSP). L'Attestato Elettronico di Attributi (Q)EAA rimane Suspended fino a quando non viene ripristinato allo stato Issued o Valid ((Q)EAA UNSUSP) a seconda dello stato precedente, cioè le condizioni che hanno portato alla sua sospensione vengono risolte, o passa a Revoked, Expired o viene eliminato. La sospensione di un Attestato Elettronico di Attributi (Q)EAA PUÒ essere:

• Guidata dal caso d'uso, basata sullo stato di validità degli attributi contenuti nell'Attestato Elettronico di Attributi (Q)EAA. In questo caso, una Fonte Autentica aderente a PDND DEVONO notificare al Fornitore di Attestati Elettronici qualsiasi cambiamento nello stato degli attributi attestati dall'Attestato Elettronico di Attributi (Q)EAA.

• Esplicitamente richiesta dall'Utente.

10.5.2. Ciclo di vita degli Attestati Elettronici ottenuti in batch

Ciascuna degli Attestati Elettronici emessi in batch, entra immediatamente nel proprio stato relativo al ciclo di vita. Tutte le transizioni di stato (Emessa → Valida → Scaduta/Sospesa/Revocata) avvengono a livello di singolo Attestato Elettronico, utilizzando i parametri individuali dell'Attestato Elettronico (ad esempio, date di validità, Status List).

10.5.3. Gestione del Ciclo di Vita degli Attestati Elettronici

Mentre la Fig. 10.1 mostra i diversi stati che un Attestato Elettronico può acquisire durante il suo ciclo di vita, la Fig. 10.2 mostra il punto di vista delle Istanze del Wallet e dei Fornitori di Attestati Elettronici nella gestione del ciclo di vita degli Attestati Elettronici e l'effetto sul loro storage locale.

Fig. 10.2 Gestione del Ciclo di Vita degli Attestati Elettronici.

Un Utente, attraverso l'Istanza del Wallet, è in grado di acquisire un nuovo Attestato Elettronico (Credential Acquisition) eseguendo il processo PID/(Q)EAA ISS. Questo DEVE risultare nella memorizzazione di un Attestato Elettronico nello stato Issued/Valid, ed sua eliminazione quando non è più necessario o è Expired/Revoked (Credential Deletion). Fino alla Credential Deletion, un Attestato Elettronico può essere presentato alle Relying Party, questa operazione non influenzerà il suo ciclo di vita.

Un Fornitore di Attestati Elettronici invece è responsabile per:

• Generazione dell'Attestato Elettronico: l'Attestato Elettronico viene generato come conseguenza di una richiesta di emissione e DEVE essere aggiunto allo storage locale del Fornitore di Attestati Elettronici dopo l'emissione riuscita.

• Revoca/Sospensione/Riattivazione dell'Attestato Elettronico (PID/(Q)EAA REV e (Q)EAA SUSP/UNSUSP): per motivi di sicurezza tecnici o richiesti da entità esterne (ad esempio, Utenti e Fonti Autentiche) lo stato dell'Attestato Elettronico DEVE essere aggiornato localmente.

• Eliminazione dei Dati: dopo aver raggiunto lo stato Expired, e in base alle politiche di conservazione del Fornitore di Attestati Elettronici, gli Attestati Elettronici DEVONO essere rimossi dallo storage locale del Fornitore di Attestati Elettronici.

10.5.3.1. Revoca e Sospensione degli Attestati Elettronici

Questa sezione descrive i flussi per richiedere un aggiornamento dello stato di un Attestato Elettronico (cioè revoca o sospensione), le entità coinvolte e i meccanismi di validazione per gli Attestati Elettronici nel sistema IT-Wallet.

Come evidenziato nella Sezione Ciclo di Vita degli Attestati Elettronici, il ciclo di vita di un Attestato Elettronico è influenzato da:

• Il ciclo di vita della sua Istanza del Wallet

• La validità degli Attributi gestiti dalle Fonti Autentiche

• Solo per i PID, lo stato dell'Identità Digitale utilizzata per l'autenticazione dell'Utente

Fattori esterni relativi all'utente possono anche influenzare il ciclo di vita di un Attestato Elettronico, come:

• Richiesta esplicita dal titolare dell'Attestato Elettronico

• Morte dell'Utente

• Attività illegali

10.5.3.2. Entità Coinvolte

Il Fornitore di Attestati Elettronici DEVE gestire direttamente lo stato di validità degli Attestati Elettronici che ha emesso. Altri attori POSSONO attivare il processo di revoca/sospensione dell'Attestato Elettronico.

• Gli Utenti, attraverso la loro Istanza del Wallet.

• Gli Utenti, attraverso il servizio web fornito dal Fornitore di Attestati Elettronici.

• La Fonte Autentica, quando gli attributi dell'Attestato Elettronico vengono aggiornati o cambiano stato di validità.

• Il Fornitore di Wallet, quando revoca un'Istanza del Wallet.

• Il Gestore di Identità Digitale, se l'Identità Digitale utilizzata per il rilascio del PID/IT-Wallet ID è stata rubata o compromessa.

• Le autorità legali o l'Organo di Vigilanza, in caso di attività illegali comprovate.

La seguente figura mostra un diagramma delle relazioni tra entità relative al flusso di aggiornamento dello stato.

Fig. 10.3 Entità coinvolte nel Flusso di Revoca degli Attestati Elettronici.

10.5.3.3. Flussi di Aggiornamento dello Stato

Questa sezione descrive i principali flussi per la gestione degli Aggiornamenti di Stato degli Attestati Elettronici da parte del Fornitore di Attestati Elettronici, in particolare l'Aggiornamento di Stato:

• relativo all'Utente.

• attivato da un'Istanza del Wallet.

• attivato da un Fornitore di Wallet.

• attivato da una Fonte Autentica.

Nota

I Flussi dettagliati di Aggiornamento dello Stato per i Gestori di Identità Digitale, le autorità legali e l'Organo di Vigilanza saranno trattati nelle versioni future della specifica tecnica.

10.5.3.3.1. Aggiornamento dello Stato relativo all'Utente

Gli Utenti POSSONO modificare lo stato di validità del loro Attestato Elettronico:

1. Eliminando l'Attestato Elettronico dalla propria Istanza del Wallet: l'Istanza del Wallet DOVREBBE proporre all'Utente un prompt per notificare opzionalmente al Fornitore di Attestati Elettronici il desiderio da parte dell'Utente di richiedere la revoca della Credenziale. Quando l'Utente utilizza questa funzionalità, la notifica da inviare al Fornitore di Attestati Elettronici DEVE utilizzare il Notification Endpoint messo a disposizione dal Fornitore di Attestati Elettronici, come descritto nella Sezione Aggiornamento dello Stato da parte dell'Istanza del Wallet.

2. Utilizzando il portale web del Fornitore di Attestati Elettronici:

1. Gli Utenti POSSONO accedere ad un'area sicura con almeno lo stesso Livello di Garanzia utilizzato durante la fase di emissione.

2. Il Fornitore di Attestati Elettronici DEVE consentire agli Utenti di:

• Visualizzare tutti i loro Attestati Elettronici contenuti nel database del Fornitore di Attestati Elettronici.

• Verificare l'autenticità dei dati.

• Visualizzare e aggiornare lo stato di validità (revocare i loro Attestati Elettronici e, se supportato dal Fornitore di Attestati Elettronici, sospenderle).

Inoltre, quando gli Utenti rilevano dati non corretti in un Attestato Elettronico rilasciato, l'Istanza del Wallet DOVREBBE avviare una richiesta di correzione dati tramite il Notification Endpoint come specificato in Correzione dati usando credential_failure. A seguito della conferma della discrepanza, il Fornitore di Attestati Elettronici DOVREBBE seguire il Re-issuance Flow.

Nota

Se l'Utente attiva un'altra Istanza del Wallet dello stesso Fornitore di Wallet e utilizzando la stessa Soluzione di Wallet e ottiene un nuovo PID/IT-Wallet ID, il precedente PID/IT-Wallet ID DEVE essere revocato. In caso di revoca del PID la precedente Istanza del Wallet DEVE passare allo stato operativo.

In caso di morte dell'Utente, i Fornitori di Attestati Elettronici DEVONO garantire che gli Attestati Elettronici e le Istanze del Wallet di proprietà dell'Utente siano revocati. La morte dell'Utente comporta una modifica dello stato di validità degli attributi identificativi dell'Utente contenuti nel registro pubblico (ANPR). La morte dell'Utente DEVE produrre la revoca del PID/IT-Wallet ID. Pertanto, la Fonte Autentica del PID/IT-Wallet ID (ANPR) DEVE notificare al PID/EAA Provider che gli attributi dell'Utente non sono più validi a causa della morte dell'Utente. La Fonte Autentica e il PID/EAA Provider DEVONO utilizzare i meccanismi previsti nella Sezione Aggiornamento dello Stato da parte delle Fonti Autentiche.

Nota

Le versioni future della presente specifica tecnica definiranno come le informazioni verso i Fornitori di (Q)EAA vengono propagate, in accordo alla normativa nazionale. Inoltre, saranno definite procedure automatizzate per la revoca degli Attestati dovuta ad attività illecite.

10.5.3.3.2. Aggiornamento dello Stato da parte dell'Istanza del Wallet

Quando l'Utente elimina un Attestato Elettronico dall'Istanza del Wallet, per impostazione predefinita l'Istanza del Wallet NON DEVE notificare questo evento al Fornitore di Attestati Elettronici. L'eliminazione dall'Istanza del Wallet rimuove solo la copia locale e non modifica lo stato di validità presso il Fornitore di Attestati Elettronici.

L'Istanza del Wallet PUÒ informare l'Utente, prima dell'eliminazione, che l'eliminazione è un'azione locale e non implica la revoca presso il Fornitore di Attestati Elettronici,. L'Istanza del Wallet PUÒ implementare, con il consenso esplicito dell’Utente al momento dell’eliminazione, una funzionalità di notifica per informare il Fornitore di Attestati Elettronici dell’intenzione dell’Utente di revocare l’Attestato Elettronico.

Se l'Utente desidera che il Fornitore di Attestati Elettronici revochi un Attestato Elettronico, l'Utente DOVREBBE confermare esplicitamente tale intenzione tramite il prompt di eliminazione dell’Istanza del Wallet (quando disponibile). L'Istanza del Wallet DEVE notificare il Fornitore di Attestati Elettronici. In alternativa, l'Utente PUÒ utilizzare il portale web del Fornitore di Attestati Elettronici o altri canali messi a disposizione.

Quando l'Attestato Elettronico revocato è il PID/IT-Wallet ID, il Fornitore di Attestati Elettronici DEVE inviare una notifica di questo evento all'Utente entro 24 ore. Per qualsiasi altro Attestato Elettronico diverso dal PID/IT-Wallet ID, il Fornitore di Attestati Elettronici DOVREBBE inviare una notifica di questo evento all'Utente. La notifica all'Utente PUÒ essere implementata in diversi modi, ad esempio utilizzando l'indirizzo email dell'Utente, il numero di telefono o qualsiasi altro canale di comunicazione verificato e sicuro. La notifica all'Utente DEVE includere anche tutte le informazioni sullo stato di revoca dell'Attestato Elettronico. Il metodo utilizzato per la notifica all'Utente è fuori dallo scopo del presente profilo tecnico di implementazione. Quando la revoca avviene, il Fornitore di Attestati Elettronici DEVE aggiornare di conseguenza lo stato dell'Attestato Elettronico. Quando la Notification Response inviata dal Fornitore di Attestati Elettronici viene ricevuta con successo dall'Istanza del Wallet, l'Istanza del Wallet DEVE eliminare l'Attestato Elettronico.

10.5.3.3.3. Aggiornamento dello Stato da parte dei Fornitori di Wallet

La revoca di un'Istanza del Wallet, inclusa la status list della Wallet Instance Attestation e della Key Attestation, è specificata in Revoca dell'Istanza del Wallet. Il controllo del Credential Issuer durante il periodo di validità, e la revoca delle Credenziali che dipendono da tale Istanza del Wallet, sono specificati in Meccanismi di Verifica della Revoca.

10.5.3.3.4. Aggiornamento dello Stato da parte delle Fonti Autentiche

Le Fonti Autentiche gestiscono gli attributi separatamente dagli Attestati Elettronici, i quali verificano l’autenticità in modo analogo ai documenti fisici. La perdita di un documento fisico non implica la perdita dei diritti che rappresenta. Significa solo che l’Utente non può dimostrarli. Tuttavia, se un Utente perde determinati diritti a causa di una grave infrazione, la Fonte Autentica revocherà gli attributi correlati. In tali casi, quando gli attributi di un Utente vengono aggiornati, le Fonti Autentiche DEVONO notificare ai Fornitori di Attestati Elettronici di aggiornare lo stato di validità di qualsiasi Attestato Elettronico che contenga tali attributi.

Le Fonti Autentiche che utilizzano PDND DEVONO usare Signal Hub come unico meccanismo di notifica degli aggiornamenti. In questo caso, le Fonti Autentiche DEVONO depositare un Signal tramite il e-Service di Raccolta Segnali nei seguenti casi:

• Il valore di uno o più Attributi contenuti nel database della Fonte Autentica è cambiato.

• Lo stato di validità degli Attributi è aggiornato (revoca o sospensione).

In entrambi i casi, il Signal DEVE avere signalType impostato a UPDATE.

I Fornitori di Attestati Elettronici DEVONO controllare periodicamente il PDND Signal Hub e-Service di Distribuzione Segnali per nuovi Signal. Per il flusso di processamento dei Signal, fare riferimento alla Sezione Elaborazione dei Segnali. Il Fornitore di Attestati Elettronici è in grado di identificare la natura del UPDATE Signal interrogando la API get attribute della Fonte Autentica e ispezionando il payload della risposta, come descritto nella Sezione Get Attribute Claims.

La seguente figura illustra ad alto livello il processo di aggiornamento dello stato da parte delle Fonti Autentiche.

Fig. 10.4 Processo di aggiornamento dello stato delle Fonti Autentiche

Il processo inizia con modifiche ai dati o alla validità dei dati che avvengono presso la Fonte Autentica. Le modifiche possono anche essere avviate da entità terze diverse dalla Fonte Autentica, ad esempio quando le autorità giudiziarie segnalano attività illecite.

Una volta che i dati cambiano, la Fonte Autentica notifica i Fornitori di Attestati Elettronici che hanno ricevuto i dati originali utilizzando il Signal Hub. La Fonte Autentica deposita un Signal nel Signal Collection e-Service. e-Service di Raccolta Segnali.

Il Fornitore di Attestati Elettronici interroga periodicamente il Signal Hub e-Service di Distribuzione Segnali per nuovi Signal. Quando viene trovato un nuovo Signal, il Fornitore di Attestati Elettronici lo recupera e lo processa come descritto in Elaborazione dei Segnali. Quindi, il Fornitore di Attestati Elettronici aggiorna lo Stato dell’Attestato secondo la modalità definita dal meccanismo di validità. Il Fornitore di Attestati Elettronici PUÒ notificare l’Utente tramite un canale di comunicazione registrato e out-of-band.

L’Istanza del Wallet, a seguito di controlli periodici dello stato di validità degli Attestati Elettronici memorizzati, riceve lo stato aggiornato. Quando lo Stato dell’Attestato viene modificato in INVALID, il Fornitore di Attestati Elettronici DEVE informare l’Utente di tale cambiamento. Nel caso in cui lo stato dell’Attestato venga modificato in UPDATE (risp. 0x03) o ATTRIBUTE_UPDATE (risp. 0x0F), l’Istanza del Wallet DOVREBBE procedere alla riemissione dell’Attestato Elettronico, come descritto in Re-issuance Flow.

10.5.3.4. Gestione del ciclo di vita delle Credenziali in batch

Quando più Attestati Elettronici vengono emessi insieme in un singolo batch, il loro ciclo di vita rimane completamente granulare:

• Trigger raggruppati, aggiornamenti indipendenti: indipendentemente dall'attore che ha innescato la variazione di stato del batch (ad esempio, la Wallet Instance tramite il Notification Endpoint con event=credential_deleted, un Wallet Provider tramite l'aggiornamento della Status List della Wallet Instance e Key Attestations) l'aggiornamento viene gestito come una o più modifiche di stato separate. Il Fornitore di Attestati Elettronici aggiorna lo stato di ciascun Attestato Elettronico singolarmente (ad esempio, impostando il bit della status-list su INVALID o SUSPENDED). Un'Istanza del Wallet NON DEVE attivare aggiornamenti di stato del batch quando l'Utente elimina Attestati Elettronici localmente. In fase di eliminazione, l’Istanza del Wallet PUÒ, con il consenso esplicito dell’Utente, notificare al Fornitore di Attestati Elettronici l’intenzione dell’Utente di revocare gli Attestati Elettronici interessati.

Nota

Poiché l'interfaccia utente del Wallet in genere visualizza un batch come un singolo Attestato Elettronico (ad esempio, con 3 utilizzi rimanenti), un'eliminazione da parte dell'utente rimuove l'intero batch localmente. Per impostazione predefinita non richiede la revoca presso il Fornitore di Attestati Elettronici. L’Istanza del Wallet PUÒ offrire all’Utente un prompt opzionale per richiedere la revoca presso il Fornitore di Attestati Elettronici nell’ambito del flusso di eliminazione.

10.5.4. Meccanismi di Verifica della Validità

Per la verifica dello stato di validità di un Attestato Elettronico a lunga durata, Token Status List (TOKEN-STATUS-LIST) DEVE essere supportato sia per lo scenario remoto che per quello di prossimità. La seguente tabella riassume i meccanismi di revoca richiesti per verificare lo stato degli Attestati Elettronici a lunga durata.

Flusso	Meccanismo di Revoca	Riferimento
Remoto	[OBBLIGATORIO] Token Status List.	TOKEN-STATUS-LIST.
Prossimità	[OBBLIGATORIO] Token Status List.	TOKEN-STATUS-LIST.

10.5.4.1. Token Status List (Profilo degli Attestati Elettronici)

Questa sezione profila il meccanismo Token Status List (TSL) di TOKEN-STATUS-LIST per gli Attestati Elettronici. Una TSL convoglia lo stato corrente di molti Attestati Elettronici in un Status List Token (SLT) compatto e firmato.

Lo SLT Provider DEVE essere il Fornitore di Attestati Elettronici.

10.5.4.1.1. Status List

Una Status List contiene un array di byte compresso le cui entry rappresentano gli stati di molti Attestati Elettronici. Il Fornitore di Attestati Elettronici DEVE assegnare a ciascun Attestato Elettronico emesso un valore idx distinto e non negativo e includerlo, insieme all'uri della SLT, nel riferimento alla status list dell'Attestato Elettronico. Per un Attestato Elettronico SD-JWT, il riferimento è in status.status_list, idx è un intero JSON e uri è una stringa JSON. Per un MSO mdoc, il riferimento è in issuerAuth.status_list, idx è un intero non firmato CBOR e uri è una text string CBOR. In entrambi i casi, uri DEVE essere un URI conforme a RFC 3986.

Secondo questa specifica, un Attestato Elettronico può avere uno dei seguenti stati:

• VALID. L'Attestato Elettronico è valido. Questo stato è rappresentato da 0x00 nella SLT.

• INVALID. L'Attestato Elettronico è revocato. Questo stato è rappresentato da 0x01 nella SLT.

• SUSPENDED. L'Attestato Elettronico è temporaneamente non valido e può essere ripristinato a VALID. Questo stato è rappresentato da 0x02 nella SLT.

• UPDATE. I parametri dei metadata dell'Attestato Elettronico sono cambiati. Questo stato è rappresentato da 0x03 nella SLT.

• ATTRIBUTE_UPDATE. Gli attributi dell'Attestato Elettronico sono cambiati. Questo stato è rappresentato da 0x0F nella SLT.

Di conseguenza, il Fornitore di Attestati Elettronici DEVE impostare il parametro bits nell'oggetto status_list della SLT a 4.

Il Fornitore di Attestati Elettronici PUÒ definire stati aggiuntivi specifici dell'applicazione nell'intervallo supportato da bits. DOVREBBE considerare con attenzione le informazioni divulgate alle Relying Party quando definisce stati aggiuntivi per il ciclo di vita dell'Attestato Elettronico.

Il Fornitore di Attestati Elettronici DEVE impacchettare le entry a partire dal bit meno significativo di ciascun byte. Il Fornitore di Attestati Elettronici DEVE comprimere l'array di byte con DEFLATE nel formato dati ZLIB. Il Fornitore di Attestati Elettronici DEVE pubblicare la Status List risultante nella SLT.

10.5.4.1.2. Status List Token

Il Fornitore di Attestati Elettronici DEVE agire sia come Status Issuer sia come Status Provider. DEVE rendere disponibile ciascuna SLT tramite HTTP GET all'URI specificato dal riferimento alla status list dell'Attestato Elettronico, usando application/statuslist+jwt per una SLT JWT oppure application/statuslist+cwt per una SLT CWT.

Il formato della SLT PUÒ essere JWT oppure CWT. Il formato della SLT DEVE essere protetto da una firma crittografica. Indipendentemente dal formato scelto, la SLT DEVE essere conforme alla Sezione 5.1 per i JWT oppure alla Sezione 5.2 per i CWT di TOKEN-STATUS-LIST.

Indipendentemente dal formato, il Fornitore di Attestati Elettronici DEVE firmare la SLT in uno dei modi seguenti.

• Un certificato X.509 valido la cui catena di fiducia termina al Trust Anchor pubblicato nella LoTE del Fornitore di Attestati Elettronici, quando il Fornitore di Attestati Elettronici è registrato nel Trust Framework EUDIW.

• Una chiave valida attestata dalla Entity Configuration del Fornitore di Attestati Elettronici, quando il Fornitore di Attestati Elettronici è registrato nel Trust Framework Nazionale.

10.5.4.1.3. Considerazioni sulla privacy

I Fornitori di Attestati Elettronici DEVONO integrare le informazioni di stato di molti Attestati Elettronici nella stessa lista. I Fornitori di Attestati Elettronici DEVONO pubblicare la SLT allo stesso uri per tutti quegli Attestati Elettronici. Lo scopo è impedire ai Fornitori di Attestati Elettronici di tracciare o profilare gli Utenti in base all'uso degli Attestati Elettronici. I Fornitori di Attestati Elettronici DEVONO configurare le Status List con almeno 100.000 voci di stato. Se vengono emessi ulteriori Attestati Elettronici, il Fornitore di Attestati Elettronici PUÒ creare SLT aggiuntive. Il Fornitore di Attestati Elettronici PUÒ aumentare il numero di entry nell'array. La scelta dipende da considerazioni pratiche quali la dimensione totale di ciascuna SLT e la gestione di più endpoint.

10.5.4.1.4. Verifica degli Stati degli Attestati Elettronici

Il recupero, l'elaborazione e la verifica di un Status List Token possono essere eseguiti dall'Istanza del Wallet oppure da una Relying Party. La procedura seguente è descritta per l'Istanza del Wallet. Le stesse regole si applicano alla Relying Party.

Fig. 10.5 Flusso di Status List.

10.5.4.1.4.1. Richiesta HTTP di Status List

Per ottenere il Token di Status List, la Relying Party DEVE inviare una richiesta HTTP GET all'URI specificato dal riferimento alla status list dell'Attestato Elettronico.

La Relying Party DOVREBBE inviare un header Accept che contiene application/statuslist+jwt per un Token di Status List JWT oppure application/statuslist+cwt per un Token di Status List CWT.

Di seguito è riportato un esempio non normativo di una richiesta di Token di Status List:

GET /statuslists HTTP/1.1
Host: example-issuer.com
Accept: application/statuslist+jwt

10.5.4.1.4.2. Risposta HTTP di Status List

L'Endpoint di Status List risponde con un Token di Status List e DEVE utilizzare un codice di stato HTTP nell'intervallo 2xx. Nella risposta andata a buon fine, lo Status Provider DEVE utilizzare application/statuslist+jwt per un Token di Status List JWT oppure application/statuslist+cwt per un Token di Status List CWT.

La risposta HTTP DOVREBBE utilizzare la Content-Encoding gzip come definito in [RFC 9110].

Se nella risposta HTTP sono presenti header relativi alla cache, le Relying Party DOVREBBERO dare priorità ai claim exp e ttl all'interno del Token di Status List rispetto agli header HTTP per determinare il comportamento della cache.

Di seguito è riportato un esempio non normativo di una risposta per un Token di Status List di tipo application/statuslist+jwt:

HTTP/1.1 200 OK
Content-Type: application/statuslist+jwt

eyJhbGciOiJFUzI1NiIsImtpZCI6IjEyIiwidHlwIjoic3RhdHVzbGlzdCtqd3QifQ.eyJleHAiOjIyOTE3MjAxNzAsImlhdCI6MTY4NjkyMDE3MCwiaXNzIjoiaHR0cHM6Ly9leGFtcGxlLmNvbSIsInN0YXR1c19saXN0Ijp7ImJpdHMiOjQsImxzdCI6ImVKeGpjRkFFQUFDa0FHSSJ9LCJzdWIiOiJodHRwczovL2V4YW1wbGUuY29tL3N0YXR1c2xpc3RzLzEiLCJ0dGwiOjQzMjAwfQ.SSdg3AnTHsyRtCHziLy-QnXg-YRldMEXkdEgDXgE_ZvIvjM0eULQlzEbLBLfCeGhlqKJSReC-m85K79CTjJDzg

Al ricevimento di un Attestato Elettronico, una Relying Party DEVE prima eseguire la validazione dell'Attestato Elettronico stesso (ad esempio, il controllo degli attributi attesi, della firma valida e del tempo di scadenza). Se questa validazione non ha successo, l'Attestato Elettronico DEVE essere rifiutato. Se la validazione ha avuto successo, la Relying Party DEVE eseguire i seguenti passaggi di validazione per valutare lo stato dell'Attestato Elettronico:

• Per un Attestato Elettronico SD-JWT, controllare il riferimento status.status_list. Per un MSO mdoc, controllare il riferimento issuerAuth.status_list. In entrambi i casi, validare il riferimento alla status list secondo Token Status List (Profilo degli Attestati Elettronici).

• Risolvere il Token di Status List dall'URI fornito.

• Validare il Token di Status List:

  • Validare la firma del Token di Status List secondo la Sezione 7.2 di RFC 7519 per una SLT JWT oppure la Sezione 7.2 di RFC 8392 per una SLT CWT. Questo passaggio richiede la risoluzione di una chiave pubblica come descritto in Infrastructure of Trust.

  • Controllare l'esistenza dei claim richiesti come definito in Token Status List (Profilo degli Attestati Elettronici).

  • Controllare tutti gli altri claim nel Token di Status List secondo Token Status List (Profilo degli Attestati Elettronici):

    • Il claim sub di una SLT JWT, oppure il claim 2 di una SLT CWT, DEVE essere uguale al membro uri nel riferimento alla status list dell'Attestato Elettronico.

    • Se la Relying Party ha una politica di freschezza, DOVREBBE controllare il claim JWT iat oppure il claim CWT 6.

    • Se presente, il claim JWT exp oppure il claim CWT 4 DEVE essere controllato per determinare se il Token di Status List è scaduto.

    • Se la Relying Party utilizza un sistema di cache, DOVREBBE controllare il claim JWT ttl oppure il claim CWT 65534 e recuperare una copia aggiornata quando resolution_time + ttl < current_time.

• Decomprimere la Status List con un decompressore compatibile con DEFLATE (RFC 1951) e con il formato dati ZLIB (RFC 1950).

• Recuperare il valore di stato all'indice specificato nel riferimento alla status list dell'Attestato Elettronico, come descritto in Verifica degli Stati degli Attestati Elettronici. Il controllo fallisce se l'indice fornito è fuori dai limiti della Status List.

• Controllare il valore di stato come descritto in Verifica degli Stati degli Attestati Elettronici.

Se uno di questi controlli fallisce, non è possibile fare alcuna dichiarazione sullo stato dell'Attestato Elettronico. L'Attestato Elettronico DOVREBBE essere rifiutato.

Ad esempio, l'array di byte decompresso [0x00, 0x40, 0x21] corrisponde all'array di bit [0, 0, 0, 0, 0, 0, 0, 0; 0, 1, 0, 0, 0, 0, 0, 0; 0, 0, 1, 0, 0, 0, 0, 1]. Lo stato dell'Attestato Elettronico il cui claim idx ha valore 5 si riferisce all'ultima coppia di 4 bit (cioè [0, 0, 1, 0] = 0x02), il cui stato è SUSPENDED.

Se si verifica un errore mentre l'Endpoint di Status List genera una risposta, DEVONO essere supportati i seguenti codici di stato HTTP:

Codice di Stato	Descrizione
500 Internal Server Error [OBBLIGATORIO]	Il Provider di Status List ha riscontrato un problema interno.
503 Service Unavailable [OBBLIGATORIO]	Il Provider di Status List è temporaneamente non disponibile.
504 Gateway Timeout [OPZIONALE]	Il Provider di Status List non può soddisfare la richiesta entro l'intervallo di tempo definito.