4. Sistema di Onboarding¶
Il sistema di onboarding registra le entità operative (PID Provider, Attestation Provider, Relying Party, Fornitori di Wallet e Fonti Autentiche) affinché possano partecipare all'ecosistema IT-Wallet con autorizzazioni e relazioni di trust chiaramente definite.
4.1. Architettura del Sistema di Onboarding¶
Il servizio di onboarding DEVE fornire processi di onboarding specializzati che corrispondano alle caratteristiche operative e agli obblighi normativi dei diversi tipi di partecipanti.
Tutti gli Attori Primari DEVONO sottoporsi alla registrazione amministrativa per la conformità legale e normativa, seguita da processi di registrazione tecnica specializzati che DEVONO riflettere i loro ruoli operativi nell'ecosistema degli Attestati Elettronici.
Registrazione Amministrativa: Tutte le entità (Fonti Autentiche, Relying Party, Fornitori di Wallet, Credential Issuer) DEVONO completare la registrazione amministrativa iniziale che convalida la loro posizione legale, conformità normativa ed eleggibilità organizzativa per partecipare all'ecosistema IT-Wallet.
Registrazione Tecnica: Dopo l'approvazione amministrativa, le entità completano la registrazione tecnica attraverso Journey specializzati:
Fonti Autentiche: Dichiarano i loro Attributi dell'Utente disponibili dal Registro degli Attributi dell'Utente e specificano gli scopi di verifica previsti e tipo di organizzazione (pubblica o privata) previsti.
Credential Issuer: Selezionano le Fonti Autentiche basate sugli Attributi dell'Utente richiesti, richiedono l'approvazione dell'integrazione (eccetto per i mandati normativi) e registrano i tipi di Credenziali con pubblicazione automatica del catalogo secondo la politica dell'Organismo di Supervisione.
Altre Entità di Federazione (Relying Party, Fornitori di Wallet): Subiscono registrazione basata su federazione per l'istituzione di trust crittografico.
Integrazione del Registro IT-Wallet:
Integrazione del Registro degli Attributi dell'Utente e della Tassonomia: Il Registro degli Attributi dell'Utente fornisce definizioni di dati standardizzate per i singoli Attributi delle Credenziali, mentre la Tassonomia definisce la classificazione gerarchica (domini, classi, scopi) che vengono poi referenziati nel Catalogo degli Attestati Elettronici per implementazioni specifiche di Credenziali. Tutti i partecipanti sfruttano questi registri per dichiarazioni di capacità di fornitura dati e requisiti di emissione/verifica.
Integrazione del Registro AS: Fonti Autentiche registrate con i loro Attributi dell'Utente dichiarati e relative specifiche, abilitando la discovery e coordinazione dei CI.
Integrazione del Registro di Federazione: Entità operative incluse per la validazione del trust durante le operazioni delle Credenziali.
Integrazione del Catalogo: Tipi di Credenziali automaticamente pubblicati nel Catalogo degli Attestati Elettronici basato sulle politiche dell'Organismo di Supervisione per l'eleggibilità alla discovery pubblica.
Registrazione dell'Istanza del Wallet: Le Istanze del Wallet sono registrate indirettamente attraverso i Fornitori di Wallet, stabilendo le specifiche di gestione delle Credenziali a livello utente. I dettagli tecnici sono forniti in Inizializzazione e Registrazione dell'Istanza del Wallet.
4.2. Processo di Registrazione della Fonte Autentica¶
La registrazione della Fonte Autentica consente ai fornitori di dati di stabilire il loro ruolo autorevole nell'ecosistema degli Attestati Elettronici attraverso la registrazione delle loro specifiche di fornire dati e meccanismi di accesso standardizzati basati sul Registro degli Attributi dell'Utente e sulle classificazioni della Tassonomia.
Le Fonti Autentiche DEVONO sottoporsi a procedure di registrazione che convalidano la loro autorità sui dati, dichiarano i loro Attributi dell'Utente disponibili dal Registro degli Attributi dell'Utente standardizzato e stabiliscono meccanismi di integrazione tecnica. Le Fonti Autentiche specificano casi d'uso previsti (formalmente purposes) che determinano l'eleggibilità del catalogo secondo le politiche dell'Organismo di Supervisione.
Le Fonti Autentiche Pubbliche DEVONO sfruttare l'integrazione PDND per fornire dati governativi attraverso l'infrastruttura nazionale standardizzata.
Le Fonti Autentiche Private POSSONO stabilire interfacce di servizio personalizzate che soddisfano requisiti organizzativi o normativi specifici.
Entrambe i flussi DEVONO assicurare standard di qualità dei dati e stabilire tracce di audit per tutte le attività di fornitura dati.
Processo di Coordinamento AS-CI: Dopo la registrazione AS, i Credential Issuer identificano entità AS adatte attraverso il Registro AS e richiedono autorizzazione all'integrazione durante la fase di registrazione amministrativa. Per i mandati normativi, l'autorizzazione DEVE essere automatica. Altrimenti, le entità Fonti Autentiche valutano e autorizzano le richieste dei Credential Issuer basate su criteri commerciali e tecnici. Dopo l'autorizzazione amministrativa, le procedure di integrazione tecnica stabiliscono le relazioni operative di accesso ai dati prima della pubblicazione del catalogo dei tipi di Credenziali.
Le Fonti Autentiche registrate con successo DEVONO essere incluse nel Registro AS con i loro Attributi dell'Utente dichiarati e le relative specifiche. I tipi di Credenziali DEVONO diventare pubblicamente scopribili nel Catalogo degli Attestati Elettronici solo dopo l'integrazione AS-CI riuscita e l'approvazione della politica dell'Organismo di Supervisione per l'eleggibilità del catalogo.
Le procedure di implementazione tecnica per la registrazione della Fonte Autentica sono fornite in Procedura di Registrazione AS.
4.3. Processo di Onboarding della Federazione¶
L'onboarding della federazione, inclusi i processi di registrazione amministrativa e tecnica, stabilisce le relazioni di trust crittografiche e le verifiche di conformità che consentono a tutte le entità (PID Provider, Attestation Provider, Relying Party, Fornitori di Wallet e Fonti Autentiche) di partecipare ad attività sicure del ciclo di vita delle Credenziali. Le entità operative DEVONO completare l'onboarding che include la verifica dell'eleggibilità amministrativa e la validazione tecnica. Per i Fornitori di Wallet, questo include la valutazione di conformità della Soluzione Wallet e i successivi flussi di notifica nelle Trusted Lists.
Per PID Provider, Attestation Provider e Relying Party, il processo di onboarding della federazione tipicamente include:
Registrazione dell'Entità: Raccolta dei dati principali (identificazione, diritti, punti di fornitura del servizio e chiavi pubbliche crittografiche e certificati) necessari per autorizzare le entità e descriverne le capacità.
Emissione dei Certificati: Emissione di certificati che autenticano le entità, fanno riferimento al registro per la verifica dei diritti, supportano la Certificate Transparency e descrivono lo stato di registrazione per Relying Party e Credential Issuer.
Pubblicazione del Registro: Pubblicazione di tutte le entità registrate nel registro, con un'API online (vedi Integrazione dell'Infrastruttura di Trust e del Registro) che può essere utilizzata per verificare la registrazione delle entità e gli attributi richiesti.
Nota
I PID Provider, i PuB-EAA Provider e i Wallet Provider sono registrati attraverso il sistema di onboarding dell'IT-Wallet e successivamente notificati alla Commissione Europea per l'inclusione nelle Trusted Lists. I Wallet Provider non ricevono certificati di accesso o certificati di registrazione dai Registrar nazionali. La Soluzione Wallet fornita dal Wallet Provider deve essere certificata da Organismi di Valutazione della Conformità (CAB) secondo il quadro nazionale di valutazione della conformità.
4.3.1. Requisiti sulle Informazioni del Modulo di Registrazione¶
Secondo i Requisiti di Alto Livello dell'Architettura e del Framework di Riferimento (ARF) e il Regolamento (UE) 2025/848, Allegato I, tutte le entità che si registrano presso i Registrar Nazionali DEVONO fornire le seguenti informazioni nel modulo di registrazione. Queste informazioni sono richieste per PID Provider, Attestation Provider (QEAA Provider, PuB-EAA Provider ed EAA Provider non qualificati) e Relying Party.
Il modulo di registrazione DEVE raccogliere almeno le seguenti informazioni come specificato nell'Allegato I del Regolamento (UE) 2025/848 e allineato con i casi d'uso definiti nella documentazione di onboarding dell'infrastruttura di trust:
Campo di Informazione |
Descrizione e Requisiti |
|---|---|
Nome Ufficiale |
OBBLIGATORIO. Il nome legale ufficiale della wallet-relying party (nome dell'entità come registrato nei registri aziendali o governativi). |
Identificatori Ufficiali |
OBBLIGATORIO. Uno o più identificatori ufficiali della wallet-relying party, come:
|
Indirizzo Fisico e Stato Membro |
OBBLIGATORIO. Indirizzo fisico dell'entità e Stato Membro se non presente nell'identificatore ufficiale. L'indirizzo DEVE includere:
|
URL |
OBBLIGATORIO. URL appartenente alla wallet-relying party dove applicabile (es., homepage dell'organizzazione, sito web del servizio). |
Informazioni di Contatto |
OBBLIGATORIO. Informazioni di contatto dettagliate inclusi:
|
Descrizione del Servizio |
OBBLIGATORIO. Descrizione del tipo di servizi forniti dall'entità, inclusi:
|
Elenco Attributi Richiesti |
OBBLIGATORIO, ove applicabile. Un elenco degli attributi che la wallet-relying party intende richiedere per ogni uso previsto. Questo DEVE fare riferimento a:
|
Descrizione dell'Uso Previsto |
OBBLIGATORIO, ove applicabile. Una descrizione dell'uso previsto dei dati, inclusi:
|
Indicazione Ente Pubblico |
OBBLIGATORIO. Indicazione se la wallet-relying party è un ente pubblico (valore booleano). |
Diritti Applicabili |
OBBLIGATORIO. Diritto/i applicabile/i della wallet-relying party scelto/i dalla seguente lista:
|
Indicazione Intermediario |
OBBLIGATORIO. Indicazione se la wallet-relying party intende agire come intermediario o fare affidamento su un intermediario (valore booleano). |
Informazioni Specifiche dell'Entità |
CONDIZIONALE. Informazioni aggiuntive richieste in base al tipo di entità:
|
Il modulo di registrazione DEVE essere progettato per supportare sia l'inserimento manuale dei dati che i processi di registrazione automatizzati attraverso registri autorevoli qualificati. Il Registrar PUÒ importare informazioni sull'entità da registri qualificati (es., registri aziendali, registri IVA, registri di qualificazione professionale, GLEIF per record LEI) per ridurre la duplicazione e semplificare l'onboarding.
Tutte le informazioni fornite nel modulo di registrazione DEVONO essere: - Accurate e aggiornate al momento della registrazione - Verificabili rispetto alla documentazione di supporto o alle fonti autorevoli - Mantenute e aggiornate senza indebito ritardo quando si verificano cambiamenti - Conformi alle normative applicabili sulla protezione dei dati e sulla privacy
Per i requisiti sulle informazioni di registrazione delle Fonti Autentiche, vedere Requisiti sulle Informazioni di Registrazione delle AS.
Per i requisiti sulle informazioni di registrazione dei Wallet Provider, vedere la sezione Notifica dello Stato Membro alla Commissione Europea, che specifica i requisiti di valutazione della conformità e le procedure di inclusione nelle Trusted Lists.
4.3.2. Matrice delle Responsabilità¶
La seguente tabella riassume il requisito di registrazione e l'autorità responsabile per la compilazione della Trusted List (TL) per ogni tipo di entità:
Tipo di Entità |
Processo di Registrazione |
Compilazione Trusted List (EC / MS TLP) |
Ruolo MS TLP |
|---|---|---|---|
PID Provider |
Registrazione presso il Registrar |
Commissione Europea (TL a livello UE per PID Provider) |
Nessuno (nessuna TL nazionale per PID Provider) |
Attestation Provider |
Registrazione presso il Registrar |
Stato Membro / MS TLP (TL QTSP nazionale per QEAA Provider; TL nazionale per EAA Provider non qualificati) |
Compila, firma e pubblica le Trusted Lists nazionali per QEAA Provider ed EAA Provider non qualificati secondo il quadro nazionale dei servizi fiduciari. |
Relying Party (RP) |
Registrazione presso il Registrar |
N/A (Utilizza Certificati di Accesso/Registro) |
Nessuno (non elencati nelle TL) |
Wallet Provider |
Solo notifica (verso EC) |
Commissione Europea (TL a livello UE per Wallet Provider) |
Non applicabile nel pilot (solo notifica da Stato Membro a EC) |
Access CA |
Solo notifica (verso EC) |
Commissione Europea (TL a livello UE per Access CA) |
Non applicabile nel pilot (solo notifica da Stato Membro a EC) |
Fornitore Cert. Reg. |
Solo notifica (verso EC) |
Commissione Europea (TL a livello UE per Fornitori Cert. Reg.) |
Non applicabile nel pilot (solo notifica da Stato Membro a EC) |
Nota
Trusted Lists e Registro di Federazione: Le entità elencate nelle Trusted Lists nazionali sono anche registrate nel Registro di Federazione nazionale, che mantiene informazioni tecniche aggiuntive (es., endpoint di federazione). La validazione delle chiavi può avvenire tramite entrambi i meccanismi: verifica rispetto alla Trusted List e verifica tramite gli endpoint di federazione.
4.3.3. Notifica dello Stato Membro alla Commissione Europea¶
Lo Stato Membro DEVE notificare tutti i PID Provider, PuB-EAA Provider, Wallet Provider, Autorità Certificatrici di Accesso e Fornitori di Certificati di Registrazione alla Commissione Europea. Le informazioni notificate variano per tipo di entità:
PID Provider: Dati di identificazione, chiavi pubbliche/certificati del PID Provider, chiavi pubbliche/certificati dell'Autorità Certificatrice di Accesso per PID Provider, Punto di Fornitura del Servizio (URL)
Wallet Provider: Dati di identificazione, chiavi pubbliche/certificati del Wallet Provider
PuB-EAA Provider: Dati di identificazione (incluso rapporto di valutazione della conformità), Punto di Fornitura del Servizio (URL)
Autorità Certificatrici di Accesso e Fornitori di Certificati di Registrazione: Dati di identificazione, chiavi pubbliche/certificati
La Commissione Europea compila, firma/sigilla e pubblica le Trusted Lists per Wallet Provider, PID Provider, Access CA e Fornitori di Certificati di Registrazione.
4.3.4. Pubblicazione delle Trusted Lists per Attestation Provider¶
Per gli Attestation Provider (sia QEAA che EAA non qualificati), il processo di registrazione attiva la pubblicazione delle Trusted Lists:
QEAA Provider: - Dopo la registrazione riuscita con il Registrar dello Stato Membro, i QEAA Provider sono inclusi nelle Trusted Lists QTSP degli Stati Membri pubblicate dagli Stati Membri per `EIDAS`_ Articolo 22 - Queste Trusted Lists QTSP sono notificate alla Commissione Europea per EIDAS Articolo 22(3) in modo che le posizioni delle TL QTSP e le chiavi di firma possano essere esposte tramite la Lista delle Trusted Lists (LoTL)
EAA Provider non qualificati: - Dopo la registrazione riuscita con il Registrar dello Stato Membro, gli EAA Provider non qualificati sono inclusi nelle Trusted Lists nazionali degli EAA Provider compilate e pubblicate dai Fornitori di Trusted Lists degli Stati Membri (MS TLP) - Queste Trusted Lists nazionali sono pubblicate utilizzando il profilo ETSI TS 119 602 Allegato H (Trusted Lists degli Attestation Provider), in formato JSON con firma compact JAdES Baseline B OPPURE formato XML con firma XAdES Baseline B - Il MS TLP invia l'URL della Trusted List pubblicata degli EAA Provider non qualificati alla Commissione Europea per l'inclusione nella LoTL
Il Fornitore di Trusted Lists dello Stato Membro (MS TLP): - Riceve la notifica della registrazione riuscita dal Registrar (o accede ai dati del Registro) - Estrae le chiavi pubbliche crittografiche, i certificati e i dati rilevanti dal Registro - Compila le Trusted Lists secondo le specifiche ETSI TS 119 612 o ETSI TS 119 602 - Firma/sigilla e pubblica le Trusted Lists agli URL pubblicamente accessibili - Invia l'URL della Trusted List alla Commissione Europea
4.4. Gestione del Ciclo di Vita delle Entità¶
Dopo l'onboarding riuscito, le entità richiedono una gestione continua del ciclo di vita per mantenere lo stato operativo e la conformità all'interno dell'ecosistema IT-Wallet. La gestione del ciclo di vita comprende aggiornamenti amministrativi, modifiche tecniche e processi di uscita dalla federazione che soddisfano i requisiti organizzativi e operativi in evoluzione.
4.4.1. Gestione delle Operazioni Continuative¶
Le entità DEVONO mantenere informazioni amministrative e tecniche aggiornate per assicurare la partecipazione alla federazione e la conformità.
Aggiornamenti Amministrativi
Le organizzazioni POSSONO aggiornare le informazioni amministrative attraverso canali di registro standard, come:
Cambiamenti dell'Entità Legale: Cambiamenti del nome dell'azienda, ristrutturazione organizzativa, modifiche dello stato legale.
Informazioni di Contatto: Aggiornamenti ai canali di contatto ufficiali e al personale responsabile.
Stato Normativo: Cambiamenti in licenze, certificazioni o stato di conformità normativa.
Ambito del Servizio: Modifiche alle offerte di servizio o alle caratteristiche della base utenti.
Gli aggiornamenti amministrativi DEVONO seguire processi di governance standard e NON DOVREBBERO influenzare le operazioni tecniche della federazione.
Gestione della Configurazione Tecnica
Gli aggiornamenti tecnici che influenzano le operazioni del protocollo di federazione richiedono procedure coordinate, inclusi:
Gestione dei Certificati: Rinnovo regolare dei certificati, sostituzione di emergenza, gestione della revoca.
Cambiamenti dell'Infrastruttura: Aggiornamenti degli endpoint, migrazioni di servizio, modifiche della capacità.
Aggiornamenti di Conformità: Aggiornamenti degli standard di sicurezza, cambiamenti delle politiche, requisiti di audit.
Modifiche delle Capacità: Aggiunta o rimozione di protocolli supportati, tipi di Credenziali o caratteristiche del servizio.
Gli aggiornamenti tecnici DEVONO essere validati dall'Organismo di Supervisione per mantenere le relazioni di trust della federazione e l'integrità operativa.
4.4.2. Processi di Uscita e Rimozione dalla Federazione¶
Le entità POSSONO uscire dalla federazione volontariamente o essere rimosse dall'Organismo di Supervisione per ragioni di conformità o sicurezza.
Uscita Volontaria dalla Federazione - Le organizzazioni POSSONO scegliere di uscire dalla federazione per ragioni commerciali o operative, inclusi:
Cambiamenti Commerciali: Ristrutturazione organizzativa o interruzione del servizio.
Migrazione Tecnica: Passaggio a soluzioni tecniche o fornitori alternativi.
Cambiamenti Normativi: Cambiamenti nell'ambiente normativo o nei requisiti di conformità.
L'uscita volontaria DEVE richiedere coordinamento con entità dipendenti e gestione appropriata delle Credenziali esistenti e delle relazioni con gli utenti.
Rimozione dell'Organismo di Supervisione - L'Organismo di Supervisione PUÒ avviare la rimozione dell'entità per:
Violazioni di Conformità: Mancato mantenimento della conformità normativa o aderenza alle politiche della federazione.
Incidenti di Sicurezza: Compromissione dell'infrastruttura di sicurezza o mancato mantenimento degli standard di sicurezza.
Fallimenti Operativi: Fallimenti tecnici persistenti che influenzano la sicurezza della federazione.
Violazioni delle Politiche: Violazioni delle politiche operative della federazione o degli accordi.
I processi di rimozione POSSONO includere indagini, rimedi e procedure di appello dove appropriato.
Avvertimento
Per incidenti di sicurezza critici o minacce immediate all'integrità della federazione, l'Organismo di Supervisione PUÒ implementare la sospensione di emergenza con effetto immediato.
4.4.3. Requisiti di Coordinamento del Ciclo di Vita¶
La gestione del ciclo di vita nell'ecosistema IT-Wallet necessita di coordinamento tra più partecipanti per mantenere le operazioni funzionanti e mantenere le relazioni di trust. Il framework di coordinamento copre tre aree principali:
Comunicazione degli stakeholder: Quando le entità devono apportare cambiamenti che impattano le operazioni dell'ecosistema IT-Wallet, DEVONO informare l'Organismo di Supervisione e i partecipanti della federazione rilevanti in anticipo.
Sincronizzazione del registro: Quando un'entità apporta cambiamenti che influenzano altre entità, tutti i sistemi di registro DEVONO essere aggiornati correttamente assicurando che tutti i cambiamenti siano registrati in modo sicuro con timestamp e ragioni.
Garanzia di continuità aziendale: Le entità DOVREBBERO bilanciare tra l'apportare aggiornamenti necessari e mantenere i loro obblighi verso utenti e normative. Questo include assicurare che il servizio sia il più disponibile possibile, gestire i dati personali correttamente durante i cambiamenti e rimanere conformi ai requisiti legali anche in situazioni di emergenza.
Le procedure tecniche e i requisiti di conformità specifici per la gestione del ciclo di vita sono dettagliati nella Sezione Onboarding delle Entità.
4.5. Onboarding Journey Maps¶
Le seguenti mappe dei Journey forniscono una vista dettagliata dell'esperienza di onboarding dalla prospettiva di ogni tipo di entità e dei loro operatori. Queste rappresentazioni grafiche aiutano le organizzazioni a comprendere i passaggi specifici, i requisiti e le interazioni che incontreranno durante il loro processo di onboarding.
Ogni mappa del Journey mostra il processo completo dalla pianificazione iniziale all'integrazione finale del registro, evidenziando i punti di contatto critici con l'Organismo di Supervisione e le dipendenze tra i diversi processi di onboarding delle entità.
4.5.1. Panoramica dell'Ecosistema¶
Fig. 4.2 Onboarding completo dell'ecosistema che mostra i processi principali¶
Il sistema Registro IT-Wallet coordina tutte le registrazioni attraverso cinque componenti principali:
Registro degli Attributi dell'Utente per definizioni semantiche standardizzate dei singoli Attributi delle Credenziali.
Registro AS per fonti di dati e capacità di fornitura dati.
Registro di Federazione per relazioni di trust operative.
Catalogo degli Attestati Elettronici (vedi Catalogo degli Attestati Elettronici) per la discovery dei tipi di Credenziali.
Tassonomia per la classificazione gerarchica che organizza le Credenziali per dominio e scopo.
Le seguenti mappe dei Journey illustrano due scenari di Credenziali distinti:
Scenario Catalogo Pubblico: Patente di Guida Mobile (mDL) fornita per una discovery pubblica tramite Catalogo delle Credenziali.
Scenario Credenziale Privata: Badge Dipendente Aziendale dall'Azienda (AS Privata, e quindi fornita per la discovery solo tramite Offerta di Credenziale).
4.5.2. Journey dell'Operatore della Fonte Autentica¶
Dalla prospettiva dell'operatore della Fonte Autentica, il processo di onboarding inizia con la valutazione delle capacità di fornire dati esistenti rispetto al Registro degli Attributi dell'Utente standardizzato e alle classificazioni della Tassonomia, determinando quali Attributi dell'Utente possono essere resi disponibili come Attestato Elettronico. L'operatore invia una richiesta di registrazione all'Organismo di Supervisione, dichiarando Attributi dell'Utente specifici dal Registro degli Attributi dell'Utente con i domini della Tassonomia e gli scopi previsti.
Esempio - Fonte Autentica Pubblica (Scenario mDL):
Dichiarazione degli Attributi dell'Utente: Seleziona Attributi dell'Utente standardizzati (
given_name,family_name,driving_privileges, ecc.) dal Registro degli Attributi dell'Utente.Classificazione della Tassonomia: Dominio
MOBILITY_TRAVEL, ScopoDRIVING_RIGHTS.Caso d'Uso: Servizio pubblico - verifica dell'autorizzazione alla guida (eleggibile per il Catalogo delle Credenziali).
Integrazione: Integrazione e-service PDND seguendo gli standard governativi (vedi e-Service PDND).
Risultato del Catalogo: mDL diventa pubblicamente scopribile dopo l'integrazione CI.
Esempio - AS Aziendale (Scenario Badge Dipendente):
Dichiarazione degli Attributi dell'Utente: Seleziona Attributi dell'Utente (
given_name,family_name,employee.job_title, ecc.) dal Registro degli Attributi dell'Utente.Classificazione della Tassonomia: Dominio
MEMBERSHIP, ScopoASSOCIATION.Caso d'Uso: Controllo accessi aziendale privato (non eleggibile per il Catalogo delle Credenziali).
Integrazione: API personalizzata per l'integrazione del Credential Issuer.
Risultato del Catalogo: Il badge rimane privato, disponibile solo tramite Offerta di Credenziale.
Le fasi critiche includono la verifica amministrativa da parte dell'Organismo di Supervisione (che coinvolge controlli di conformità normativa al di fuori dell'ambito tecnico) e la validazione tecnica. Il processo si conclude con la registrazione nel Registro AS, rendendo gli Attributi dell'Utente dichiarati scopribili dai Credential Issuer per le richieste di integrazione. Le richieste di integrazione possono essere inviate anche dalle Fonti Autentiche a specifici Credential Issuer.
Avvertimento
Dipendenza importante: Gli Attributi dell'Utente dichiarati nel Registro AS rimangono non disponibili agli utenti finali fino a quando un Credential Issuer completa la registrazione, l'approvazione dell'integrazione e l'implementazione tecnica. La pubblicazione del catalogo dipende dalle politiche dell'Organismo di Supervisione per l'eleggibilità alla discovery pubblica.
4.5.3. Journey dell'Operatore del Credential Issuer¶
Gli operatori del Credential Issuer iniziano effettuando la discovery delle Fonti Autentiche disponibili attraverso il Registro AS e valutando la fattibilità dell'integrazione basata sugli Attributi dell'Utente richiesti. La richiesta di registrazione specifica quali tipi di Credenziali intendono emettere, seleziona entità Fonte Autentica appropriate e dimostra la capacità tecnica di accedere alle fonti di dati richieste. In alternativa, gli operatori del Credential Issuer ricevono direttamente la richiesta di integrazione dalla Fonte Autentica.
Esempio - mDL (Scenario Pubblico):
discovery AS o AS Integration Request: Identifica la Fonte Autentica che fornisce Attributi mDL nel Registro AS con gli Attributi dell'Utente della patente di guida richiesti. In alternativa, il Credential Issuer riceve la richiesta di integrazione direttamente dalla Fonte Authentica.
Richiesta di Integrazione: Approvazione automatica dovuta al mandato normativo.
Configurazione Tecnica: Integrazione e-service PDND seguendo gli standard governativi (vedi e-Service PDND).
Pubblicazione del Catalogo: mDL automaticamente pubblicato nel Catalogo delle Credenziali.
Accesso Utente: I cittadini scoprono mDL attraverso un catalogo pubblico nel Wallet.
Esempio - CI per Badge Dipendente (Scenario Privato):
discovery AS o AS Integration Request: Identifica la Fonte Autentica nel Registro AS con gli Attributi dell'Utente di accesso dipendente. In alternativa, il Credential Issuer riceve la richiesta di integrazione direttamente dalla Fonte Authentica.
Richiesta di Integrazione: Richiede approvazione da parte del destinatario della richiesta.
Configurazione Tecnica: Integrazione API personalizzata con autenticazione.
Pubblicazione del Catalogo: Badge escluso dal catalogo pubblico per politica di supervisione.
Accesso Utente: I dipendenti ricevono badge solo tramite Offerta di Credenziale diretta dai sistemi aziendali.
La fase di configurazione tecnica offre due flussi di integrazione distinti a seconda del tipo di Fonte Autentica:
Integrazione AS Pubblica: Utilizza la piattaforma PDND per accedere ai dati governativi attraverso API standardizzate.
Integrazione AS Privata: Stabilisce connessioni API dirette con endpoint personalizzati forniti da organizzazioni private.
Dopo il test di integrazione riuscito e l'approvazione della Fonte Autentica, il Credential Issuer è registrato nel Registro di Federazione come Entità fidata, abilitando l'emissione effettiva di Credenziali agli utenti finali.
Avvertimento
Questo passaggio attiva la disponibilità delle Credenziali per gli utenti finali. Le Credenziali pubbliche diventano scopribili attraverso il catalogo, mentre altre Credenziali rimangono disponibili solo tramite Offerte di Credenziale dirette.
4.5.4. Journey dell'Operatore del Fornitore di Wallet¶
Gli operatori del Fornitore di Wallet seguono un Journey di onboarding indipendente che si concentra sulla certificazione dell'applicazione e sulla validazione della sicurezza. Il processo evidenzia lo sviluppo e la certificazione di applicazioni Wallet che possono memorizzare e gestire in modo sicuro gli Attestati Elettronici per i cittadini.
Un requisito tecnico chiave coinvolge l'implementazione di meccanismi di controllo dell'integrità e autenticità del Wallet. Questi controlli consentono al Wallet di ottenere un Wallet App Attestation, che serve come prova dello stato di sicurezza e conformità del Wallet durante le operazioni delle Credenziali.
Il processo di certificazione include la valutazione della sicurezza, coprendo l'architettura del Wallet, i meccanismi di protezione dei dati e le caratteristiche di privacy dell'utente. I fornitori di Wallet certificati con successo sono registrati nel Registro di Federazione e possono distribuire le loro applicazioni attraverso gli app store.
4.5.5. Journey dell'Operatore della Relying Party¶
Gli operatori della Relying Party iniziano identificando quali tipi di EAA sono richiesti per i loro servizi specifici e valutando la complessità dell'integrazione con i sistemi di autenticazione esistenti. La richiesta di registrazione fornisce evidenza di necessità legittime per accedere a tipi di Credenziale specifici e Attributi dell'Utente, delineando i casi d'uso del servizio previsti e le caratteristiche organizzative che giustificano l'accesso alle Credenziali.
Esempio - Servizio di Noleggio Auto (RP Privata):
Classificazione Aziendale: Codice ATECO 77.11 (servizi di noleggio auto).
Richiesta di Autorizzazione: Verifica dell'autorizzazione alla guida per l'eleggibilità al noleggio.
Requisiti degli Attributi dell'Utente:
given_name,family_name,driving_privileges, ecc., da mDL.Giustificazione del Caso d'Uso: Obbligo legale di verificare la patente di guida valida prima del noleggio del veicolo.
Ambito di Autorizzazione: Concesso accesso al dominio
MOBILITY_TRAVEL, scopoDRIVING_RIGHTS.
Esempio - Servizi Municipali (RP Pubblica):
Tipo di Organizzazione: Pubblica Amministrazione con requisito codice IPA.
Richiesta di Autorizzazione: Verifica dell'identità del cittadino per l'accesso ai servizi municipali.
Requisiti degli Attributi dell'Utente:
given_name,family_name,tax_id_codeda PID.Giustificazione del Caso d'Uso: Erogazione di servizi pubblici che richiede identificazione del cittadino.
Ambito di Autorizzazione: Concesso accesso più ampio riflettendo il mandato del servizio pubblico.
Esempio - Controllo Accessi Aziendale (RP Privata):
Classificazione Aziendale: Codice ATECO 62.01 (attività di programmazione informatica).
Richiesta di Autorizzazione: Verifica del dipendente per l'accesso alle strutture aziendali.
Requisiti degli Attributi dell'Utente:
given_name,family_name,employee.job_titledal Badge Dipendente Aziendale.Giustificazione del Caso d'Uso: Sicurezza del posto di lavoro che richiede identificazione del dipendente e controllo degli accessi.
Ambito di Autorizzazione: Concesso accesso al dominio
MEMBERSHIP, scopoASSOCIATION.Discovery delle Credenziali: Badge disponibile solo tramite Offerta di Credenziale privata (non eleggibile per il Catalogo delle Credenziali).
L'integrazione tecnica si concentra sullo sviluppo di flussi di autenticazione che possono verificare gli Attestati Elettronici presentati dagli Utenti. Questo include l'implementazione di meccanismi di verifica crittografica e l'istituzione di canali di comunicazione sicuri con l'infrastruttura di federazione.
L'autorizzazione del servizio da parte dell'Organismo di Supervisione DEVE coinvolgere una valutazione basata su politiche che considera il tipo di organizzazione (privata vs pubblica amministrazione), la classificazione del settore aziendale e i requisiti di servizio legittimi. Il processo di autorizzazione concede ambiti operativi specifici che definiscono quali domini di Credenziali e scopi la Relying Party può richiedere. Dopo l'approvazione, la Relying Party è registrata nel Registro di Federazione con profili di autorizzazione chiaramente definiti per l'accettazione degli Attestati Elettronici e degli Attributi dell'Utente.
4.6. Journey dell'Esperienza Utente¶
Quando tutti i processi di onboarding delle entità sono completati con successo, gli Utenti possono scoprire e installare Istanze del Wallet certificate, ottenere gli Attestati Elettronici disponibili e presentare i loro Attestati elettronici a Fornitori di Servizi registrati (vedi Panoramica delle Funzionalità).
Questa modalità di integrazione dipende dal fatto che tutte le entità rilevanti abbiano completato i rispettivi Journey di onboarding.