9.1.1. Requisiti della Soluzione Wallet¶

Questa sezione elenca i requisiti relativi ai Fornitori di Wallet e alle Soluzioni Wallet con le loro Istanze del Wallet. Elenca anche i corrispondenti Wallet Instance Attestation, Key Attestation e i componenti di archiviazione sicura. Il Keystore è usato per tutte le Credenziali Digitali diverse dal PID a Livello di Garanzia Alto. Il WSCA/Remote WSCD è usato esclusivamente per il PID a Livello di Garanzia Alto.

Questi requisiti attuano, per l'Istanza del Wallet, le funzionalità principali di [CIR2024/2979] e il profilo di interfaccia di [CIR2024/2982], come specificato nell'ARF (EIDAS-ARF). L'interazione Wallet-to-Wallet e la creazione di firme elettroniche qualificate sono fuori dall'ambito di questa versione.

La Soluzione Wallet DEVE aderire alle specifiche stabilite da questo documento per ottenere Attestati Elettronici di Dati di Identificazione Personale (PID) e Attestati Elettronici di Attributi (Q)EAA.
Si veda Endpoint del Fornitore di Wallet. Il Fornitore di Wallet DEVE mantenere tali endpoint disponibili esclusivamente per le istanze della Soluzione Wallet di quel Fornitore di Wallet.
L'Istanza del Wallet DEVE periodicamente ristabilire la trust con il suo Fornitore di Wallet, ottenendo una nuova Wallet Instance Attestation (WP_018).
L'istanza del Wallet DEVE stabilire un rapporto di fiducia con gli altri partecipanti dell'ecosistema del Wallet, come i Fornitori di Attributi Elettronici. Nel caso dei Fornitori di Attributi Elettronici, l'istanza del Wallet presenta sia la Wallet Instance Attestation che la Key Attestation.
L'Istanza del Wallet DEVE supportare sia il Trust Framework EUDIW sia il Trust Framework Nazionale, come specificato in Trust Framework Selection.
L'Istanza del Wallet DEVE memorizzare PID e (Q)EAA, applicare la disclosure selettiva e presentarli in remoto e in prossimità, come specificato in Emissione di Attestati Elettronici e Presentazione dell'Attestato Elettronico.
L'emissione, la memorizzazione e la presentazione del PID sono specificate in Emissione del PID prima della notifica EUDIW.
L'Istanza del Wallet DEVE supportare i formati di Attestato Elettronico richiesti da [OPENID4VC-HAIP], inclusi dc+sd-jwt e mso_mdoc.
I grant di emissione sono specificati in Emissione di Attestati Elettronici.
La Wallet Unit DEVE richiedere un'autorizzazione basata sulla presenza fisica dell'Utente quando ottiene un PID tramite il Pre-Authorized Code Grant.
La Wallet Unit DEVE acquisire e associare un EDP consegnato tramite URI insieme ai dati di policy, oppure tramite il solo URI quando la policy esatta è già precaricata.
La Wallet Unit DEVE risolvere e valutare l'EDP applicabile prima della disclosure.
La Wallet Unit DEVE mostrare il risultato all'Utente.
La Wallet Unit DEVE richiedere l'override dell'Utente per la disclosure di ogni Credenziale o attributo che non soddisfa la policy applicabile.
L'Istanza del Wallet DEVE essere compatibile e funzionale sia sui sistemi operativi Android che iOS e disponibile rispettivamente sul Play Store e sull'App Store (WP_015).
L'Istanza del Wallet DEVE fornire un meccanismo per verificare l'effettivo possesso e il pieno controllo da parte dell'Utente del proprio dispositivo personale.
L'Istanza del Wallet DEVE fornire agli Utenti un elenco aggiornato delle Relying Party con cui l'Utente ha stabilito una connessione e, ove applicabile, tutti i dati scambiati.
L'Istanza del Wallet DEVE fornire agli Utenti un meccanismo per richiedere la cancellazione degli attributi personali da parte di una Relying Party ai sensi dell'articolo 17 del Regolamento (UE) 2016/679, e per registrare ogni Richiesta di Cancellazione effettuata.

Nota

Non esiste una corrispondenza stretta uno-a-uno tra i requisiti in questa sezione e i casi di test in Matrice di Test per Wallet Provider. Alcuni requisiti sono espressi a un livello troppo alto per poter essere rappresentati come casi di test atomici, mentre altri sono già affrontati in modo più dettagliato all'interno dei flussi correlati (ad es. Emissione della Wallet Instance Attestation).

9.1.1.1. Requisiti della Wallet Instance Attestation¶

la Wallet Instance Attestation contiene informazioni riguardanti il livello di sicurezza del dispositivo che ospita l'Istanza del Wallet. Esso dimostra principalmente l'autenticità, l'integrità, la sicurezza e in generale l'affidabilità di una particolare Istanza del Wallet.

I requisiti per la Wallet Instance Attestation sono definiti di seguito.

la Wallet Instance Attestation DEVE fornire tutte le informazioni rilevanti per attestare l'integrità e la sicurezza del dispositivo in cui è installata l'Istanza del Wallet (WP_019).
la Wallet Instance Attestation DEVE essere firmato dal Fornitore di Wallet che ha autorità e proprietà sulla Soluzione Wallet, come specificato dalla Registration Authority di supervisione. Questo garantisce che la Wallet Instance Attestation colleghi in modo univoco il Fornitore di Wallet a questa particolare Istanza del Wallet (WP_020).
Il Fornitore di Wallet DEVE periodicamente valutare e garantire l'integrità, l'autenticità e la genuinità dell'Istanza del Wallet. Il Fornitore di Wallet verifica l'Istanza del Wallet utilizzando il flusso più sicuro reso disponibile dalle API del Fornitore del Sistema Operativo. Esempi di tale flusso sono la Play Integrity API per Android e App Attest per iOS (WP_011).
la Wallet Instance Attestation DEVE essere vincolato in modo sicuro alla chiave pubblica effimera dell'Istanza del Wallet (WP_019b).
la Wallet Instance Attestation PUÒ essere utilizzato più volte durante il suo periodo di validità, consentendo autenticazioni e autorizzazioni ripetute senza la necessità di richiedere nuovi attestati ad ogni interazione. Tuttavia, è RACCOMANDATO che le Istanze del Wallet evitino di utilizzare ripetutamente lo stesso attestato, a causa di preoccupazioni sulla privacy come la possibilità di collegamento tra diverse interazioni.
La Wallet Instance Attestation DEVE avere un time-to-live inferiore a 24 ore. La differenza tra il tempo di scadenza (exp) e il tempo di emissione (iat) DEVE essere inferiore a 24 ore. Oltre tale differenza, la Wallet Instance Attestation NON DEVE più essere considerata valida (WP_028, WP_144).
la Wallet Instance Attestation NON DEVE essere rilasciato dal Fornitore di Wallet se l'autenticità, l'integrità e la genuinità dell'Istanza del Wallet che lo richiede non possono essere garantite (WP_019a).
Ogni Istanza del Wallet DOVREBBE essere in grado di richiedere più Wallet Instance Attestation utilizzando diverse chiavi pubbliche crittografiche associate ad essi.
la Wallet Instance Attestation NON DEVE contenere informazioni sull'Utente che controlla l'Istanza del Wallet (WP_029b).
L'Istanza del Wallet DEVE ottenere una Wallet Instance Attestation come prerequisito per passare allo stato Operativo, come definito da EIDAS-ARF.
Un Wallet Provider DEVE garantire che una Wallet Unit non revocata presenti in ogni momento una Wallet Instance Attestation temporalmente valida e non revocata. La Wallet Unit presenta tale attestazione a un PID Provider o a un Attestation Provider durante il processo di emissione di un PID o di un'attestazione. Nota: questo requisito si applica sia alle attestazioni associate a un dispositivo che a quelle non associate a un dispositivo, come definito da EIDAS-ARF.
Una Wallet Unit DEVE presentare una Wallet Instance Attestation esclusivamente a un PID Provider o a un Attestation Provider, e non a una Relying Party o a qualsiasi altra entità. La presentazione avviene nell'ambito del processo di emissione di un PID o di un'attestazione.

Nota

In questa sezione, i servizi utilizzati per attestare la genuinità dell'Istanza del Wallet e del dispositivo in cui è installata sono indicati come API del Servizio di Integrità del Dispositivo. L'API del Servizio di Integrità del Dispositivo è considerata in modo astratto e si presume sia un servizio fornito da una terza parte affidabile (cioè, l'API del Fornitore del Sistema Operativo) in grado di eseguire controlli di integrità sull'Istanza del Wallet e sul dispositivo in cui è installata.

9.1.1.2. Requisiti della Key Attestation¶

La Key Attestation contiene informazioni che garantiscono che le chiavi utilizzate per il key binding delle Credenziali Digitali siano generate e archiviate in modo sicuro in un ambiente hardware affidabile. Un Keystore è usato per le Credenziali Digitali device-bound standard. Un WSCA operante in un Remote WSCD (HSM remoto) è usato esclusivamente per il PID a Livello di Garanzia Alto. Inoltre, fornisce un metodo per autenticare il componente di archiviazione sicura presso il Credential Issuer e verifica che la Wallet Unit non sia stata revocata.

I requisiti per la Key Attestation sono definiti di seguito.

La Key Attestation DEVE fornire al PID Provider o all'Attestation Provider informazioni sulle proprietà del Keystore o del WSCA/Remote WSCD della Wallet Unit. Tali informazioni consentono una decisione ben fondata sull'opportunità di emettere un PID o un'attestazione per tale Wallet Unit.
La Key Attestation DEVE consentire ai PID Provider e agli Attestation Provider di verificare l'autenticità e lo stato di revoca della Wallet Unit.
Un Wallet Provider DEVE garantire che una Wallet Unit non revocata possa in ogni momento presentare una Key Attestation, quando richiesto da un PID Provider o da un Attestation Provider.
Durante l'emissione di un PID, la Wallet Unit DEVE fornire al PID Provider una Key Attestation (KA) valida che descriva il WSCA e il Remote WSCD che ha generato la nuova chiave privata del PID. Nota: una chiave privata del PID è sempre generata e gestita dal WSCA operante nel Remote WSCD (HSM remoto). Tale WSCA per definizione è conforme ai requisiti per il Livello di Garanzia Alto. Un Keystore hardware-backed NON DEVE essere trattato come prova di Livello di Garanzia Alto.
Durante l'emissione di un'attestazione device-bound diversa dal PID, la Wallet Unit DEVE fornire all'Attestation Provider una Key Attestation (KA) valida. La KA descrive il Keystore in cui è stata generata e archiviata la nuova chiave privata della Credenziale. La Wallet Unit DEVE recuperare dai metadati dell'Emittente i requisiti dell'Attestation Provider riguardanti l'archiviazione delle chiavi, come specificato in OpenID4VCI. La Wallet Unit DEVE determinare quale dei propri Keystore, se presente, soddisfi tali requisiti. Nota: una KA per un'attestazione device-bound descrive le proprietà del Keystore come attestate dalle OEM Key Attestation APIs. Tale KA contiene una o più chiavi pubbliche corrispondenti a chiavi private generate e archiviate in tale Keystore.
Se una Wallet Unit contiene più Keystore o WSCA, essa DEVE, in modo interno e sicuro, tenere traccia di quali PID e attestazioni sono associati a ciascun Keystore o WSCA.
Una Wallet Unit DEVE presentare una Key Attestation solo come parte del processo di emissione di un PID o di un'attestazione.
La Key Attestation DEVE consentire ai PID Provider di richiedere a un Wallet Provider la revoca di una Wallet Unit. La Key Attestation include un identificatore per la Wallet Unit all'interno della KA (ad esempio, un URI e un indice a una Attestation Status List). Il Wallet Provider DEVE garantire che tale identificatore della Wallet Unit non consenta il tracciamento dell'utente.
La Key Attestation DEVE contenere una o più chiavi pubbliche di Credenziali attestate associate allo stesso Keystore o WSCA/Remote WSCD.
La Key Attestation DEVE essere firmata dal Wallet Provider che ha autorità e proprietà sulla Wallet Solution, come specificato dall'Autorità di Registrazione di riferimento. I Wallet Provider DEVONO garantire che i certificati utilizzati per firmare le KA e le WIA siano conformi a tutti i requisiti applicabili della ETSI TS 119 412-6, in particolare alla Clausola 5.
Un Attestation Provider che emette attestazioni non vincolate al dispositivo DEVE indicare nei propri metadati di Credential Issuer che non necessita di una KA. Una Wallet Unit NON DEVE inviare una KA a un Attestation Provider quando richiede un'attestazione non vincolata al dispositivo. Nota: una Wallet Unit invia una WIA all'Attestation Provider indipendentemente dal fatto che le attestazioni da esso emesse siano vincolate al dispositivo o meno.
Un Wallet Provider DEVE garantire che la presentazione di una KA sia crittograficamente vincolata allo specifico contesto in cui è destinata a essere utilizzata. Nota: come specificato in OpenID4VCI, ciò si ottiene facendo sì che la KA firmata contenga essa stessa un nonce fornito dal PID Provider o dall'Attestation Provider durante il processo di emissione. In alternativa, la Wallet Unit presenta la KA insieme a una Proof-of-Possession costituita da una firma su tale nonce, creata dalla chiave privata corrispondente a una delle chiavi pubbliche attestate nella KA.
Durante l'emissione di un PID o di un'attestazione vincolata al dispositivo, il PID Provider o l'Attestation Provider DEVE verificare la KA in conformità ai requisiti dell'Appendice F.4 di OpenID4VCI.
Durante l'emissione di un PID o di un'attestazione vincolata al dispositivo, il PID Provider o l'Attestation Provider DEVE ricevere una prova di possesso. La prova mostra che la Wallet Unit possiede le chiavi private corrispondenti a tutte le chiavi pubbliche presenti nella KA.
Il WSCA, il Remote WSCD o il Keystore NON DEVONO consentire l'esportazione in chiaro delle chiavi private dell'Utente. Se un dispositivo segnala una chiave privata come esportabile, il Fornitore di Wallet DEVE rifiutare la Key Attestation. Il Fornitore di Wallet NON DEVE attivare l'Istanza del Wallet (WP_014b).
Un Wallet Provider DEVE considerare tutti i fattori rilevanti, inclusi l'uso offline, l'interoperabilità e il rischio che una KA diventi un vettore per tracciare l'Utente, nel decidere il periodo di validità di una KA.
La Key Attestation NON DEVE essere emessa dal Wallet Provider se l'affidabilità del Keystore o del WSCA/Remote WSCD non è garantita. In tal caso, l'Istanza del Wallet DEVE essere revocata.

9.1.1.2.1. Uso delle API di Key Attestation (OEM)¶

Quando emette una Key Attestation:

Per le chiavi vincolate a un PID, il Fornitore di Wallet NON DEVE utilizzare le Key Attestation APIs (OEM) (WP_140g).
Per le chiavi vincolate a un Attestato Elettronico diverso dal PID, il Fornitore di Wallet PUÒ utilizzare le Key Attestation APIs (OEM) (WP_140h).
Se la Richiesta di Emissione della Key Attestation include materiale delle API di Key Attestation (OEM), il Fornitore di Wallet DEVE validarlo secondo le linee guida del produttore del dispositivo (WP_143h).

9.1.1.3. Requisiti del Keystore¶

Il Keystore è il meccanismo di archiviazione sicuro hardware-backed di default per tutte le operazioni crittografiche della Wallet Unit e per tutte le Credenziali Digitali, ad eccezione del PID che richiede un WSCA/Remote WSCD. L'Utente DEVE mantenere il controllo esclusivo di tali chiavi private (Sole Control). Il Keystore DEVE richiedere l'autenticazione dell'Utente (sblocco del Wallet: PIN o biometrico) prima di qualsiasi firma o altra operazione con la chiave privata (WP_014c). Un Keystore hardware-backed NON DEVE essere trattato come prova di Livello di Garanzia Alto.

I requisiti del Keystore sono definiti di seguito.

Su dispositivi Android, il Keystore DOVREBBE utilizzare Strongbox. Il Trusted Execution Environment (TEE) PUÒ essere utilizzato come fallback quando Strongbox non è disponibile.
Su dispositivi iOS, il Keystore DEVE utilizzare il Secure Enclave.
Le proprietà del Keystore DEVONO essere attestate tramite le OEM Key Attestation APIs (Android Key Attestation API per Android, Apple DeviceCheck per iOS).
Il Wallet Provider DEVE utilizzare il Keystore per generare, archiviare e utilizzare tutte le chiavi crittografiche della Wallet Instance, ad eccezione delle chiavi del PID a LoA High.
Il Keystore DEVE fornire protezione hardware contro l'estrazione e la manipolazione non autorizzata delle chiavi private.
Le chiavi private vincolate a una Wallet Instance Attestation DEVONO essere generate e memorizzate nello stesso Keystore o WSCA/Remote WSCD descritto dall'attestato (WP_014e).
Un'Istanza di Relying Party Mobile che non memorizza chiavi di identità dell'Utente PUÒ usare un Keystore e non è tenuta a usare un WSCA/Remote WSCD (WP_014f).
Gli Attestati Elettronici le cui chiavi private vincolate sono memorizzate in un Keystore POSSONO essere presentati in prossimità o comunque offline. Gli Attestati Elettronici le cui chiavi private vincolate sono memorizzate in un Remote WSCD NON DEVONO essere presentati offline (WP_160).
La presentazione in prossimità o comunque offline di un Attestato Elettronico DEVE riuscire solo quando le chiavi private vincolate sono memorizzate in un Keystore locale o in un WSCD locale (WP_160).

Per informazioni più dettagliate, fare riferimento a Inizializzazione e Registrazione dell'Istanza del Wallet, Emissione della Wallet Instance Attestation e Emissione della Key Attestation di questo documento.

9.1.1.4. Requisiti WSCA/WSCD¶

Il WSCA/Remote WSCD è usato esclusivamente per l'emissione e la gestione del PID a LoA High. In IT-Wallet, il WSCD è implementato come Remote WSCD, ovvero un Hardware Security Module (HSM) remoto operato lato server.

I requisiti WSCA/WSCD sono definiti di seguito:

La chiave privata del PID DEVE essere generata e gestita dal WSCA operante nel Remote WSCD (HSM remoto).
Il Remote WSCD DEVE soddisfare i requisiti per il Livello di Garanzia Alto (LoA High) come definito da eIDAS 2.0.
Un WSCD DEVE essere certificabile come resistente ad attaccanti con potenziale di attacco elevato (almeno Common Criteria EAL4+ AVA_VAN.5).
Un Keystore hardware-backed NON DEVE essere trattato come prova di Livello di Garanzia Alto.
Il WSCA DEVE operare all'interno di un Remote WSCD basato su un HSM remoto, fornendo un livello di certificazione superiore rispetto al Keystore locale.
Il Wallet Provider DEVE garantire che solo il WSCA possa accedere alla chiave privata del PID memorizzata nel Remote WSCD.
Il WSCA/Remote WSCD DEVE richiedere l'autenticazione dell'Utente prima di qualsiasi firma o altra operazione con la chiave privata.

Nota

In futuro, il WSCA/Remote WSCD potrebbe essere esteso ad altre Credenziali che richiedono LoA High.