Functional Requirements for Decentralized and Self-Sovereign Identities

1. Il Problema

I sistemi di gestione dell'identità centralizzati affrontano sfide continue in termini di sicurezza e privacy, come dimostrato da recenti violazioni dei dati (es. Optus, Ticketmaster) e dalla resistenza pubblica verso i sistemi di identità digitale governativi. Sebbene l'Identità Decentralizzata (DI) e l'Identità Sovrana (SSI) offrano alternative promettenti che permettono agli utenti di mantenere il controllo sui propri dati, la loro adozione rimane limitata.

Il principale ostacolo identificato dagli autori è la mancanza di approcci trasparenti e riproducibili per valutare la conformità dei sistemi DI/SSI alle qualità promesse (come privacy, decentralizzazione, consenso).

• La letteratura esistente valuta i sistemi basandosi quasi esclusivamente su Requisiti Non Funzionali (NFR) astratti (es. "l'utente deve avere autonomia").
• Questi NFR sono difficili da misurare operativamente, portando a risultati di valutazione ambigui, non riproducibili e privi di tracciabilità verso le funzionalità concrete del sistema.
• Esiste un vuoto nella letteratura riguardo alla operazionalizzazione sistematica dei principi SSI in requisiti funzionali (FR) misurabili.

2. Metodologia

Gli autori propongono una metodologia in quattro fasi per trasformare i requisiti non funzionali (NFR) in requisiti funzionali (FR) formalizzati, basandosi sulla metodologia Tropos e su categorie di requisiti esistenti.

1. Identificazione di Capacità e Vincoli:

   • Vengono analizzati gli attori del sistema (Proprietario dei Dati, Emittente, Verificatore, Sistema Globale, Portafoglio).
   • Le capacità di ciascun attore vengono mappate su pattern di progettazione esistenti.
   • Vengono definiti i vincoli (es. decentralizzazione, sicurezza, costi) che non aggiungono capacità ma limitano l'implementazione.

2. Sviluppo del Modello Funzionale:

   • Vengono formulate le dipendenze funzionali tra gli attori.
   • Il modello cattura le relazioni logiche (chi possiede cosa, chi offre quali servizi) distinguendosi dai modelli di dipendenza puri.
   • Viene effettuata una verifica incrociata tra le capacità identificate e i pattern di progettazione esistenti, rivelando lacune nei pattern attuali (es. mancanza di supporto per il consenso o l'autonomia).

3. Formalizzazione tramite Predicati e Assiomi:

   • Il modello funzionale viene formalizzato utilizzando logica matematica.
   • Predicati: Espressioni logiche che rappresentano comportamenti osservabili (es. owns, has, fulfills, presents, retrieves).
   • Assiomi: Regole di inferenza che permettono di derivare conclusioni corrette dalle interazioni tra attori e servizi (es. "Se un attore possiede un servizio e lo offre, allora lo soddisfa").

4. Formulazione dei Requisiti Funzionali (FR):

   • Vengono derivati i FR per ogni NFR utilizzando un "boilerplate" (modello standard) che include:
     • Obblighi legali (GDPR, eIDAS).
     • Processo o metodo (basato sulle capacità degli attori).
     • Tipo di attività di sistema (Autonoma, Interazione Utente, Requisito di Interfaccia).
     • Vincoli e condizioni logiche.
   • Questo processo garantisce che i requisiti siano tracciabili, verificabili e giuridicamente conformi.

3. Contributi Chiave

• Primo Framework di Operazionalizzazione Sistematica: Il lavoro fornisce il primo approccio strutturato per convertire i principi SSI (NFR) in requisiti funzionali concreti e misurabili.
• Modello Funzionale Formalizzato: Introduzione di un modello basato su logica predicativa e assiomi che definisce rigorosamente le interazioni tra gli attori (proprietario, emittente, verificatore) e i servizi.
• Set Completo di 39 Requisiti Funzionali: Derivazione di un set di FR per un caso d'uso generalizzato DI/SSI, che copre le operazioni fondamentali (creazione DID, emissione, verifica, revoca, consenso).
• Integrazione Legale: Incorporazione esplicita dei requisiti legali (GDPR, eIDAS) nella definizione dei FR, rendendoli pronti per l'implementazione nel mondo reale.
• Metodologia di Validazione: Un processo di validazione che ha portato alla revisione e alla suddivisione dei requisiti per garantire atomicità, chiarezza e precisione.

4. Risultati

• Derivazione dei FR: Sono stati generati 39 requisiti funzionali unici e tracciabili.
• Esempio di Applicazione (Consenso - NFR6): Il paper illustra dettagliatamente come il requisito "Consenso" venga tradotto in FR specifici (es. "Il sistema deve informare il proprietario sui dati", "Il sistema deve permettere il ritiro del consenso", "Il sistema deve usare linguaggio leggibile").
• Identificazione di Lacune nei Pattern Esistenti: L'analisi ha mostrato che i pattern di progettazione attuali non coprono adeguatamente capacità critiche come il consenso esplicito, l'autonomia e l'esistenza indipendente dell'identità.
• Distinzione tra DI e SSI: Il lavoro chiarisce che la differenza tra Identità Decentralizzata (DI) e SSI non risiede nelle funzionalità di base (che sono le stesse), ma nei vincoli di decentralizzazione applicati a tali funzionalità. Non esistono FR diretti per la decentralizzazione, ma vincoli su come i FR devono essere implementati.
• Struttura dei Requisiti: I requisiti sono organizzati in tabelle che collegano NFR, attori, responsabilità legali, assiomi logici e tipi di attività di sistema.

5. Significatività e Impatto

Questo lavoro rappresenta un passo fondamentale verso la creazione di un framework di valutazione trasparente e riproducibile per i sistemi DI/SSI.

• Riproducibilità: Fornisce criteri misurabili che permettono di valutare oggettivamente se un sistema soddisfa i principi SSI, superando l'ambiguità delle valutazioni basate solo su NFR.
• Fiducia e Adozione: Una valutazione trasparente può aumentare la fiducia degli utenti e degli enti regolatori, facilitando l'adozione reale della tecnologia.
• Base per il Futuro: Stabilisce le fondamenta per futuri lavori che mirano a formalizzare ulteriormente questi requisiti e a progettare framework di verifica automatica per rilevare violazioni e valutare la copertura dei requisiti in diversi casi d'uso.
• Compliance Legale: Integrando il GDPR e l'eIDAS fin dalla fase di definizione dei requisiti, il lavoro aiuta a colmare il divario tra teoria tecnica e conformità normativa.

In sintesi, il paper sposta il dibattito sull'identità decentralizzata da discussioni astratte sui principi a una ingegneria dei requisiti rigorosa, fornendo gli strumenti necessari per costruire e valutare sistemi SSI che siano realmente sicuri, privati e conformi.