8. Onboarding System and Lifecycle Management

Avvertimento

Questa sezione è un lavoro in corso ed è pubblicata in forma di bozza. La struttura generale è definita, mentre diverse parti sono ancora da scrivere e il contenuto può cambiare. Le sottosezioni contrassegnate come bozza di seguito contengono solo una breve descrizione di ciò che forniranno.

L'Onboarding System è l'insieme di componenti, servizi, processi e procedure che ammette un'Entità nell'ecosistema IT-Wallet, pubblica le informazioni di cui gli altri partecipanti hanno bisogno per riconoscerla e gestisce ciò che avviene dopo la registrazione.

L'Onboarding System copre:

• Entità: le Wallet-Relying Party, i Fornitori di Wallet e le Fonti Autentiche, dalla loro registrazione fino alla cancellazione di tale registrazione. Un'Entità è registrata, aggiornata, eventualmente sospesa e riattivata, e infine rimossa.

• Trust Artifact: i certificati, i certificati di registrazione e i federation statement che sono emessi come risultato di una registrazione, e che da essa sono sempre derivati.

• Tipi di Attestato: le definizioni versionate pubblicate nel Catalogo degli Attestati Elettronici, con i claim, gli schemi e le Fonti Autentiche da cui dipendono. Un tipo di Attestato è registrato, attivato, versionato e disattivato.

• Registri e cataloghi: i registri Nazionali che il sistema scrive, e i cataloghi europei e le Lists of Trusted Entities verso i quali il sistema si allinea o notifica.

Per ciascuno di questi, l'Onboarding System copre l'intero ciclo di vita e non solo il primo onboarding.

Tutti gli eventi relativi alle Entità e ai tipi di Attestato producono effetti sui Trust Artifact e sui registri, e tali effetti sono descritti in questa Sezione, insieme agli eventi che li causano.

Come definito in Infrastructure of Trust, nell'IT-Wallet coesistono due Trust Framework, EUDIW e Trust Framework Nazionale, e l'Onboarding System rende le Entità registrate in grado di operare su entrambi.

Il Trust Framework Nazionale è il livello di registrazione per tutte le Entità dell'ecosistema e fornisce i meccanismi che i componenti dell'Onboarding System utilizzano per autenticarsi reciprocamente.

Le strutture dati dei registri sono definite in Registry Infrastructure, i profili dei Trust Artifact in Infrastructure of Trust, i meccanismi tecnici che pubblicano lo stato di un certificato in Revocation Mechanisms, e il modo in cui gli artifact sono consumati a runtime in Trust Evaluation Process.

La sezione è organizzata in cinque parti. La Overview presenta gli attori, i componenti e il modo in cui i due Trust Framework sono utilizzati. Il Registration Model fornisce la vista statica, ossia ciò che ciascun ruolo fornisce e ciò che ottiene. Gli Onboarding Processes forniscono la vista dinamica, ossia come ciascuna procedura è eseguita. La Notification and Publication fornisce la procedura che porta le categorie notificate nelle Lists of Trusted Entities, di cui l'Onboarding System gestisce la raccolta dei dati. Il Lifecycle Management presenta gli stati, gli eventi e i loro effetti sui registri e sui Trust Artifact.

8.1. Overview

Questa Sezione introduce gli attori che partecipano all'onboarding, i componenti e i servizi del Sistema di Onboarding che li realizzano, e il modo in cui i due Trust Framework si combinano. Fornisce al lettore il contesto necessario per seguire il modello di registrazione, i processi e il ciclo di vita descritti nelle Sezioni che seguono.

8.1.1. System Actors and Roles

Due famiglie di attori partecipano all'onboarding, le entità che vengono onboardate e le entità dell'infrastruttura di trust che operano l'onboarding stesso. I ruoli dell'infrastruttura di trust sono realizzati dai componenti e dai servizi del Sistema di Onboarding, descritti nella sottosezione successiva.

8.1.1.1. System Actors and Roles: Entità oggetto di onboarding

• Fonti Autentiche: si onboardano per rendere i propri dati disponibili ai Credential Issuer, in modo che i dati possano essere inclusi negli Attestati.

• Wallet-Relying Parties: si onboardano per essere autorizzate a fare affidamento sulle Wallet Unit e per ottenere i Trust Artifact di cui necessitano per operare. Sono ulteriormente suddivise nei ruoli seguenti.

  • Credential Issuer, che si onboardano per essere autorizzati a emettere i tipi di Credenziale che dichiarano.

  • Relying Party e Intermediari di Relying Party, che si onboardano per essere autorizzati a richiedere attributi dell'Utente dalle Wallet Unit.

• Fornitori di Wallet: si onboardano per far riconoscere la propria Soluzione Wallet nell'ecosistema e per essere notificati.

8.1.1.2. System Actors and Roles: Entità dell'infrastruttura di trust

• Organismo di Supervisione: durante l'onboarding l'Organismo di Supervisione verifica l'eleggibilità e la conformità delle entità. L'Organismo di Supervisione si avvale del Registrar per la registrazione tecnica. L'Organismo di Supervisione agisce come punto di contatto unico nazionale per la notifica alla Commissione Europea.

• Registrar e Register: il Registrar esegue la registrazione tecnica delle Wallet-Relying Party e scrive i loro record nel Register come definito da [CIR2025/848].

• Provider of WRPAC e Provider of WRPRC: emettono, rispettivamente, il WRPAC e il WRPRC. Il profilo del WRPAC è definito in Wallet-Relying Party Access Certificate (WRPAC) Profile. L'emissione automatica del WRPRC è definita in Wallet-Relying Party Registration Certificate Issuance.

• National Federation Authorities: il Federation Trust Anchor e i suoi Federation Intermediate, che registrano le Entità di Federazione e applicano le metadata policy. Ciascuna Federation Authority emette i certificati X.509 e i Trust Mark per le Entità di Federazione che registra. Il Trust Mark di registrazione è emesso solo dal Federation Trust Anchor, come descritto in Trust Mark registration-entity. In IT-Wallet il National Trust Anchor opera anche la Certification Authority radice della PKI nazionale di firma X.509, il cui certificato radice e la cui distribuzione sono descritti in PKI Architecture.

8.1.1.3. System Actors and Roles: Entità che interagiscono con il Sistema di Onboarding senza essere onboardate

• Attestation Scheme Provider: possiedono l'Attestation Rulebook di un tipo di Credenziale. Richiedono la registrazione della corrispondente voce versionata nel Digital Credentials Catalog. Forniscono la definizione e lo schema tratti dal Rulebook, si veda Credential Type Registration. Un Attestation Scheme Provider non è registrato come Entità per questo ruolo. All'interno di IT-Wallet il ruolo è ricoperto da un'organizzazione che possiede il Rulebook.

Nota

Una singola organizzazione PUÒ svolgere contemporaneamente diverse di queste funzioni.

Le Istanze del Wallet non sono Entità di Federazione e non sono onboardate direttamente. Un'Istanza del Wallet è registrata indirettamente, tramite il proprio Fornitore di Wallet, si veda Inizializzazione e Registrazione dell'Istanza del Wallet. L'Istanza del Wallet è ritenuta affidabile tramite una Wallet Instance Attestation emessa e firmata da tale Fornitore di Wallet, si veda Emissione della Wallet Instance Attestation.

La notifica di un'entità notificata è un processo dello Stato membro definito da [CIR2024/2980], descritto in Notification and Publication.

8.1.2. System Components and Services

I ruoli dell'infrastruttura di trust sono realizzati, all'interno del Sistema di Onboarding, da un insieme di componenti, ciascuno dei quali fornisce uno o più servizi. Un'entità in onboarding interagisce con il sistema tramite un unico punto di ingresso, l'Onboarding UI. L'Onboarding UI orchestra il flusso e instrada ciascuna richiesta al componente responsabile. L'Onboarding UI pertanto non è rappresentata come componente distinto nel diagramma seguente.

La tabella seguente elenca i componenti, i servizi che ciascuno di essi fornisce e il processo di onboarding che ciascun servizio realizza.

Tabella 8.1 Componenti, Servizi e Processi

Component	Services	Realized process
National Federation Management	Registrazione di federazione, emissione dei Trust Mark, pubblicazione dei registri firmati	Entity Registration, Entity Update, Entity Suspension and Removal, Registration Trust Mark Issuance
EUDIW Registration Management	Verifica e registrazione delle Wallet-Relying Party nel Register	Entity Registration, Entity Update, Entity Suspension and Removal
Certificate Management	Emissione e aggiornamento di WRPAC, WRPRC, certificati Sign/Seal e National Authentication	Certificate and Trust Artifact Issuance, Entity Update
Notification Dataset Management	Raccolta e mantenimento, nel dataset di notifica, delle informazioni oggetto di notifica	Entity Registration, Entity Update, Entity Suspension and Removal
Authentic Source Management	Registrazione, aggiornamento e rimozione delle Fonti Autentiche nell'AS Registry	Authentic Source Registration, Authentic Source Update, Authentic Source Removal
Claims and Schema Management	Registrazione dei claim e provisioning degli schema	Claim Registration, Schema Provisioning
Catalog Management	Registrazione, attivazione e versionamento dei tipi di Credenziale nel Digital Credentials Catalog	Credential Type Registration, Credential Type Activation and Deactivation, Credential Type Update

I componenti scrivono nei registri nazionali e negli store di dati descritti in Registry Infrastructure, raggruppati per finalità come in Registries and Catalogues of the Ecosystem.

Due store di dati sono mantenuti distinti di proposito. Il Register contiene i record di registrazione delle Wallet-Relying Party definiti da [CIR2025/848] e guida l'emissione dei certificati. Il dataset di notifica contiene le informazioni notificabili definite da [CIR2024/2980]. Si sovrappongono solo nei dati di identificazione, così che la separazione mantiene distinta la registrazione dalla notifica.

Il diagramma seguente raggruppa i componenti per responsabilità e mostra gli store di dati con cui interagiscono. Un componente può realizzare processi di più di una famiglia, quindi i gruppi del diagramma non coincidono con le famiglie di Onboarding Processes, e la corrispondenza è quella data dalla tabella precedente. Le Fonti Autentiche si registrano solo nell'AS Registry, senza un record nel Register e senza Trust Artifact, poiché non sono né Wallet-Relying Party né Entità di Federazione. I Credential Issuer, invece, si registrano come Entità e dichiarano inoltre i tipi di Credenziale che emettono, e sono aggiunti agli issuer dei tipi che dichiarano nel Digital Credentials Catalog.

Fig. 8.1 IT-Wallet Onboarding System.

8.2. Registration Model

Questa sezione fornisce la vista statica della registrazione, con l'obiettivo di definire le informazioni che ciascuna entità deve fornire, quali condizioni deve soddisfare e quali artifact e voci di registro ottiene. È organizzata in una parte comune e in un profilo per ciascun ruolo.

8.2.1. Registration Data Model

Questa sezione definisce l'insieme completo dei dati che le entità forniscono al Sistema di Onboarding, insieme ai dati che definiscono un tipo di Credenziale, con la relativa semantica e, ove applicabile, il relativo riferimento normativo. I dati sono identificati da un Data Identifier indipendente dal formato.

Le tabelle seguenti forniscono:

• Dati di registrazione di base forniti da ogni entità, indipendentemente dal proprio ruolo.

• Dati di registrazione estesi forniti da un'entità in funzione del proprio ruolo, dove ciascuna istanza di Registration Profiles specifica quali dati estesi il ruolo fornisce e come l'entità li popola.

• Dati di definizione del tipo di Credenziale che descrivono un tipo di Credenziale.

A seconda del ruolo, i dati di registrazione sono poi codificati in un data model diverso. Per una Wallet-Relying Party il data model è lo schema WalletRelyingParty del Register (Register of WRPs). Per una Fonte Autentica il data model è la voce dell'AS Registry (Authentic Source Registry). Per un'Entità notificabile il data model è il dataset di notifica. I dati di definizione del tipo di Credenziale sono codificati nella voce versionata del Digital Credentials Catalog (Catalogo degli Attestati Elettronici). La mappatura verso i data model di destinazione è data in Mapping to the Registry Data Models.

Tabella 8.2 Base Registration Data

Data Identifier	Description	Normative reference
legal_name	Il nome dell'organizzazione come compare nei registri ufficiali.	[CIR2025/848], Annex I
identifier	Uno o più identificativi ufficiali dell'organizzazione. All'interno di IT-Wallet il Value Added Tax Identification Number (VATIN) è OBBLIGATORIO per ogni entità, e un ente pubblico DEVE inoltre fornire il proprio identificativo nazionale di tipo NTR, valorizzato con il proprio codice IPA, ossia il codice dell'Indice delle Pubbliche Amministrazioni italiano. Un'organizzazione che possiede un European Unique Identifier (EUID) DEVE fornirlo. Gli altri tipi di identificativo della Table 2, quali il Legal Entity Identifier (LEI), sono OPZIONALI e non sono supportati nella versione corrente. Per maggiori dettagli si fa riferimento alla sintassi dell'organizationIdentifier definita nella clausola 5.1.4 di [ETSI EN 319 412-1].	[ETSI TS 119 475], Table 2
legal_nature	Se l'entità è un organismo del settore pubblico o un'entità privata.	[CIR2025/848], Annex I
contact_information	L'indirizzo postale, la pagina web informativa e i contatti dell'organizzazione. I contatti includono almeno un contatto istituzionale per le comunicazioni amministrative, per il quale è RACCOMANDATO un indirizzo di posta elettronica certificata (PEC), e un contatto tecnico per il supporto utente del servizio.	[CIR2025/848], Annex I
service_policies	I termini e le condizioni e l'informativa sulla privacy del servizio, ciascuno pubblicato al proprio URL.	[CIR2025/848], Annex I
data_protection_authority	L'indirizzo e-mail di contatto dell'autorità competente per la vigilanza dell'entità ai sensi della normativa sulla protezione dei dati. DEVE essere fornito per ciascun intended use della Wallet-Relying Party.	[CIR2025/848], Annex I, in conformità al Regolamento (UE) 2016/679.

I dati di registrazione estesi sono forniti nella tabella seguente. Una data entità fornisce solo il sottoinsieme che si applica al proprio ruolo, come definito nel corrispondente profilo in Registration Profiles.

Tabella 8.3 Extended Registration Data

Data Identifier	Description	Normative reference
entitlements	Gli entitlement che l'entità richiede, i quali dichiarano i ruoli che intende svolgere nell'ecosistema.	[ETSI TS 119 475], Annex A.2
service_description	Il nome commerciale e la descrizione localizzata di ciascun Relying Party Service che l'entità offre alle Wallet Unit. Nel Trust Framework EUDIW questi dati sono forniti per Service, si veda relying_party_services. Come tale nome commerciale sia recato in più di un WRPAC o WRPRC è rinviato come specificato in Register of WRPs.	[CIR2025/848], Annex I; [EIDAS-ARF] Reg_34
intended_use	Gli attributi che una Relying Party intende richiedere dalle Wallet Unit, registrati sui propri Relying Party Service, si veda relying_party_services. Un WRPRC distinto per ciascuna combinazione di intended use e Service è rinviato come specificato in Register of WRPs.	[CIR2025/848], Annex I
relying_party_services	I Relying Party Service registrati dall'entità, come oggetti WalletRelyingPartyService di EUDI-TS 5. serviceIdentifier non è richiesto. Il WRPRC è emesso automaticamente come definito in Wallet-Relying Party Registration Certificate Issuance.	[CIR2026/1730]; EUDI-TS 5, WalletRelyingPartyService; Register of WRPs
provided_attestations	I tipi di Attestato che un Credential Issuer intende emettere. All'interno di IT-Wallet ciascuno di essi fa riferimento a una voce versionata già presente nel Digital Credentials Catalog, e la dichiarazione aggiunge il Credential Issuer al campo issuers di tale voce, insieme alle capacità di emissione offerte per quel tipo di Credenziale (i flussi di emissione supportati, i parametri dell'emissione differita e la documentazione del servizio di emissione), si veda Catalogo degli Attestati Elettronici.	[CIR2025/848], Annex I
intermediary_relationship	Vincolato a un Relying Party Service. Per un Relying Party Service intermediato, il riferimento all'Intermediary Service che utilizza (usesIntermediaries). Per un Relying Party Intermediary Service, la dichiarazione che agisce come intermediario (isIntermediary) e gli identificativi di Service che serve (servedWRPServices, [CIR2026/1730], Annex I). Un Intermediary Service puro NON DEVE registrare un entitlement (EUDI-TS 5).	[ETSI TS 119 475], Table 10; [EIDAS-ARF] RPRC_04; EUDI-TS 5
trust_framework_scope	La dichiarazione del Trust Framework in cui l'entità intende operare, secondo Infrastructure of Trust e Trust Framework Selection. La dichiarazione è fornita dai ruoli per i quali questa scelta non è già fissata dalla notifica, e determina i Trust Artifact che l'entità ottiene e il modo in cui gli altri Data Identifier del profilo sono forniti. Si applica all'entità, mentre trustedAuthorities di un tipo di Credenziale si applica alla validazione di un Attestato di quel tipo.	La presente specifica
federation_entity_identifier	L'identificativo dell'Entità di Federazione nel National Trust Framework, ossia l'iss e il sub della sua Entity Configuration.	OID-FED, Section 3
federation_entity_key	La chiave pubblica con cui l'Entità di Federazione firma la propria Entity Configuration. DEVE essere fornita in formato JWK. Il resto della configurazione di federazione è pubblicato nell'Entity Configuration raggiungibile all'endpoint .well-known/openid-federation.	OID-FED, Section 3
certificate_signing_requests	Un array di Certificate Signing Request in formato PKCS #10, una per ciascun certificato X.509 che l'entità necessita di ottenere, ossia, a seconda del ruolo, il WRPAC, il Sign/Seal Certificate o il National Authentication Certificate. Una Wallet-Relying Party che opera nel Trust Framework EUDIW fornisce una Certificate Signing Request per il WRPAC. Una Certificate Signing Request per il WRPAC per ciascun Service registrato, e una per ciascun Relying Party Service intermediato, sono rinviate come specificato in Register of WRPs. Ciascuna richiesta reca la chiave pubblica da certificare. DEVE essere distinta dalla Federation Entity Key. Il loro profilo è definito in Certificate Signing Request Profile e sono l'input di Certificate and Trust Artifact Issuance, dove sono presentate nell'ordine ACME.	RFC 2986
provided_claims_purposes	I claim che compongono un Attestato, selezionati dal Claims Registry, e gli scopi che utilizza, selezionati dalla Taxonomy, insieme alle capacità di fornitura dei dati. Raggruppa i data_capabilities della voce dell'AS Registry, si veda Authentic Source Registry.	La presente specifica
visual_identity	Gli asset visivi di una Fonte Autentica, ossia il logo dell'organizzazione e il logo e il colore di sfondo associati a un dataset fornito, ciascuno con il proprio digest di integrità e il proprio testo alternativo.	La presente specifica
conformity_assessment	L'esito della valutazione di conformità dell'entità, quale il Conformity Assessment Report o le valutazioni effettuate nell'ambito dello schema di certificazione nazionale operato dall'Agenzia per la Cybersicurezza Nazionale (ACN) e i test funzionali nell'ambito del EU functional conformity assessment framework (FCAF). DEVE essere fornito dalle categorie notificate.	[EIDAS-ARF], Annex 2
service_supply_point	L'URL presso cui una Wallet Unit avvia il processo di richiesta e ottenimento di un Attestato dall'Issuer. DEVE essere fornito dalle categorie notificate che emettono un Attestato richiesto dalla Wallet Unit.	[EIDAS-ARF], Annex 2
signing_trust_anchor	Il trust anchor a supporto della validazione degli Attestati che l'entità emette, ossia la chiave pubblica e il nome. DEVE essere fornito come input solo dalle categorie il cui Sign/Seal Certificate non è emesso dalla National Root Certification Authority, si veda PKI Architecture. Per le altre categorie il trust anchor deriva dal Sign/Seal Certificate emesso tramite le Certificate Signing Request.	[EIDAS-ARF], Annex 2
verification_endpoint	L'interfaccia di verifica transfrontaliera esposta ai Qualified Trust Service Provider per gli attributi dell'Annex VI esportati nel EUDIW Catalogue of Attributes, conforme a ETSI TS 119 478 e dichiarata nei data_capabilities della voce dell'Authentic Source Registry, si veda Authentic Source Registry. È fornita dalla Fonte Autentica.	[EUDI-TS 11], Section 2.1

I dati seguenti definiscono un tipo di Credenziale e non un'entità. Per questo motivo non sono dati di registrazione, non seguono un profilo di Registration Profiles e sono l'input di Credential Type Registration. Sono forniti dall'Attestation Scheme Provider, che possiede l'Attestation Rulebook del tipo di Credenziale, e sono tratti dal Rulebook stesso. Lo stesso criterio si applica alla definizione di un claim, registrato tramite Claim Registration.

Tabella 8.4 Credential Type Definition Data

Data Identifier	Description	Normative reference
credential_type_declaration	Il tipo di Credenziale, ancorato al proprio Rulebook. Crea la voce versionata del Digital Credentials Catalog e raggruppa i Digital Credential Metadata del tipo (l'identificativo univoco e la versione, il nome leggibile, la classificazione per domain e class, i metodi di autenticazione dell'Utente e il Livello di Garanzia minimo), insieme al riferimento alle Fonti Autentiche, o ai tipi di Credenziale padre, che ne forniscono i dati, si veda Catalogo degli Attestati Elettronici.	[CIR2025/848], Annex I
credential_technical_specification	Definizione tecnica di un tipo di Credenziale, che raggruppa i campi Technical Specification del Digital Credentials Catalog, ossia gli schema della Credenziale, i formati della Credenziale e la policy di autenticazione, si veda Catalogo degli Attestati Elettronici.	[CIR2025/848], Annex I
credential_policies	Condizioni di uso di un tipo di Credenziale, che raggruppano i campi Terms of Use del Digital Credentials Catalog, ossia la validità della Credenziale, la restriction policy, la pricing policy e gli scopi della Credenziale, si veda Catalogo degli Attestati Elettronici.	[CIR2025/848], Annex I
trustedAuthorities	Le autorità fidate che definiscono il trust framework del tipo di Credenziale nel Digital Credentials Catalog, ossia i trust anchor su cui un verificatore fa affidamento per validare l'Attestato, si veda Catalogo degli Attestati Elettronici.	[EUDI-TS 11], Section 4.3
rulebookURI	L'URI dell'Attestation Rulebook in forma leggibile che definisce gli aspetti non machine-readable del tipo di Credenziale nel Digital Credentials Catalog, si veda Catalogo degli Attestati Elettronici.	[EUDI-TS 11], Section 4.3
bindingType	Il tipo di associazione crittografica della chiave richiesto per l'emissione del tipo di Credenziale nel Digital Credentials Catalog, uno tra claim, key, biometric o none, si veda Catalogo degli Attestati Elettronici.	[EUDI-TS 11], Section 4.3
attestationLoS	Il livello di sicurezza (Level of Security) dell'attestazione del tipo di Credenziale nel Digital Credentials Catalog, ossia la resistenza al potenziale di attacco richiesta per l'autenticazione dell'utente e per l'archiviazione delle chiavi, si veda Catalogo degli Attestati Elettronici.	[EUDI-TS 11], Section 4.3

Nota

Il provided_attestations resta parte dei dati di registrazione di un Credential Issuer, perché è la dichiarazione dei tipi di Credenziale che il Credential Issuer intende emettere e non la definizione di tali tipi. I due sono distinti: la definizione crea la voce versionata, la dichiarazione aggiunge il Credential Issuer al suo campo issuers.

8.2.2. Mapping to the Registry Data Models

Il Sistema di Onboarding raccoglie i dati di registrazione e i dati di definizione del tipo di Credenziale. Tali dati sono poi codificati nel data model di destinazione. Per i dati di registrazione il data model dipende dal ruolo. La tabella seguente mappa ciascun Data Identifier sui campi dei data model di destinazione, per i Data Identifier la cui mappatura non è uno-a-uno con un singolo campo.

Tabella 8.5 Mapping of the Data Identifiers to the destination data models

Data Identifier	Destination fields
legal_name	Nel Register, il legalName del legalPerson. Nell'AS Registry, l'organization_name_l10n_id. Nel Trust Mark di registrazione, l'organization_name. Nel Digital Credentials Catalog, l'organization_name_l10n_id dell'elemento issuers del Credential Issuer.
identifier	Nel Register, l'array identifier, ciascun elemento recante il proprio type e il proprio valore. Nel Trust Mark di registrazione, il vat_number per un'entità privata, l'ipa_code per un ente pubblico e il legal_identifier. Nel Digital Credentials Catalog, l'organization_code dell'elemento issuers del Credential Issuer.
legal_nature	Nel Register, il flag isPSB. Nell'AS Registry, l'organization_type. Nel Trust Mark di registrazione, il public_body.
contact_information	Nel Register: postalAddress, email, phone, infoURI, supportURI. Nell'AS Registry: contacts, homepage_uri. Nel Trust Mark di registrazione, l'email e il support_uri. Nell'Entity Configuration, i contacts e l'homepage_uri dei metadata federation_entity. Nel Digital Credentials Catalog, i contacts e l'homepage_uri dell'elemento issuers del Credential Issuer.
service_policies	Nel Register, il policyURI di ciascun elemento dell'array policy, distinto dal proprio type. Nel Trust Mark di registrazione, la privacy_policy. Nell'Entity Configuration, il policy_uri e il tos_uri dei metadata federation_entity. Nel Digital Credentials Catalog, il policy_uri e il tos_uri dell'elemento issuers del Credential Issuer.
data_protection_authority	Nel Register, la supervisoryAuthority. Nell'AS Registry, il dpa_contact. Nel Trust Mark di registrazione, la supervisory_authority.
entitlements	Nel Register, l'array entitlements di ciascun elemento services[]. Nel Trust Mark di registrazione, gli entitlements. Nel Digital Credentials Catalog, il legal_type dell'elemento issuers del Credential Issuer.
service_description	Nel Register, il tradeName a livello di entità ove presente, e per Service il serviceTradeName e la srvDescription di ciascun elemento services[]. Nel Trust Mark di registrazione, la srv_description. Il vincolo di subject.commonName e del name del WRPRC a un Service è rinviato come specificato in Register of WRPs.
relying_party_services	Nel Register, l'array services di oggetti WalletRelyingPartyService, ciascuno recante i membri definiti in EUDI-TS 5, inclusi serviceTradeName, srvDescription, intendedUses, entitlements, providesAttestations, isIntermediary, usesIntermediaries e servedWRPServices. serviceIdentifier resta opzionale. L'identificativo del Service nel WRPAC e il srv_id del WRPRC sono rinviati come specificato in Register of WRPs.
intended_use	Nel Register, l'array intendedUses del corrispondente elemento services[], ciascun elemento recante il proprio intendedUseIdentifier, purpose, privacyPolicy e credentials. Nel Trust Mark di registrazione, i credentials e il purpose.
provided_attestations	Nel Register, l'array providesAttestations del corrispondente elemento services[], ciascun ProvidedAttestation recante format e type come definito in EUDI-TS 5. Nel Trust Mark di registrazione, i provides_attestations. Nel Digital Credentials Catalog, l'elemento dell'array issuers di ciascun tipo di Credenziale dichiarato, inclusi i suoi issuance_flows e il suo service_documentation_uri.
provided_claims_purposes	Nell'AS Registry, i data_capabilities, ossia available_claims, intended_purposes, integration_method, integration_endpoint, api_specification, data_provision, update_frequency, service_documentation_uri.
visual_identity	Nell'AS Registry i logo_uri dell'organization_info, background_color dei data_capabilities, ciascuno con il proprio digest di integrità e il proprio testo alternativo.
credential_type_declaration	Nel Digital Credentials Catalog: credential_type, version, credential_name_l10n_id, domains, classes, authentication, e le authentic_sources, o le parent_credentials, che forniscono i dati del tipo di Credenziale.
credential_technical_specification	Nel Digital Credentials Catalog, schemaId. I formati e i documenti di schema sono i supportedFormats e gli schemaURIs dello SchemaMeta identificato da tale schemaId.
credential_policies	Nel Digital Credentials Catalog: validity_info, restriction_policy, pricing_policy, purposes, legal_type.
conformity_assessment	Nel dataset di notifica, il rapporto di valutazione di conformità.
service_supply_point	Nel dataset di notifica, il service supply point.
signing_trust_anchor	Nel dataset di notifica, il trust anchor.

Alcune informazioni sono presenti sia nei dati registrati sia nell'Entity Configuration auto-firmata dell'Entità. Il valore registrato è autorevole, asserito dal Registrar nel Register e dal Federation Trust Anchor nel Trust Mark di registrazione, mentre i parametri informativi dei metadata federation_entity sono pubblicati sotto la responsabilità dell'Entità. Ove il Sistema di Onboarding richieda un valore che l'Entità pubblica anche nella propria Entity Configuration, il Sistema di Onboarding DEVE leggere l'Entity Configuration. Il Sistema di Onboarding DEVE verificare la corrispondenza. Una mancata corrispondenza DEVE bloccare la registrazione. Dopo la registrazione, una mancata corrispondenza DEVE essere risolta tramite un Entity Update. All'interno di IT-Wallet la metadata_policy del Subordinate Statement fissa l'organization_name dei metadata federation_entity al valore registrato, così che il nome mostrato all'Utente non possa divergere da quello recato dal WRPAC e dal WRPRC. Gli altri parametri informativi non sono fissati.

8.2.3. Eligibility and Compliance Preconditions

Prima di qualsiasi registrazione tecnica, l'eleggibilità e la conformità di un'entità DEVONO essere verificate dall'Organismo di Supervisione. L'Organismo di Supervisione si avvale del Registrar per le entità che il Registrar registra. Per le categorie notificate, l'Organismo di Supervisione agisce come punto di contatto nazionale verso la Commissione Europea. Ove un obbligo nazionale e un obbligo EUDIW si sovrappongano, l'obbligo EUDIW è autorevole.

La verifica si applica alle Fonti Autentiche, ai Fornitori di Wallet e alle Wallet-Relying Party, e il suo contenuto dipende dal ruolo.

• Fonti Autentiche: l'Organismo di Supervisione valida la posizione legale e l'autorità sui dati dell'organizzazione e la classifica come pubblica o privata. La trust di una Fonte Autentica è governata dal framework PDND ed è al di fuori dei Trust Framework EUDIW e Nazionale.

• Fornitori di Wallet: l'eleggibilità è accertata e la valutazione di conformità della Soluzione Wallet è condotta. La valutazione copre la sicurezza dell'architettura del wallet, i suoi meccanismi di protezione dei dati e le sue funzionalità di privacy dell'utente, ed è la precondizione affinché la Soluzione Wallet sia certificata. La certificazione della Soluzione Wallet è un processo esterno, e questa fase ne utilizza l'esito come input. La certificazione segue lo schema di certificazione nazionale operato dall'Agenzia per la Cybersicurezza Nazionale (ACN), e i test funzionali seguono il EU functional conformity assessment framework (FCAF).

• PID Provider: validati per designazione nazionale come fornitori di Person Identification Data. I PID Provider sono soggetti allo schema di certificazione nazionale operato dall'Agenzia per la Cybersicurezza Nazionale (ACN). I PID Provider sono soggetti ai test funzionali nell'ambito del EU functional conformity assessment framework (FCAF).

• QEAA Provider: validati tramite la qualificazione e la vigilanza del Qualified Trust Service Provider emittente.

• PuB-EAA Provider: validati tramite la valutazione di conformità richiesta dall'Articolo 45f del Regolamento eIDAS2.

• Non-qualified EAA Provider: validati per l'eleggibilità a emettere. Il loro trust anchor è distribuito tramite il National Trust Framework ed è definito nell'Attestation Rulebook applicabile.

• Relying Party: l'Organismo di Supervisione esegue un'autorizzazione basata su policy, valutando il tipo organizzativo, ossia pubblica amministrazione o entità privata, la classificazione del settore di attività e i requisiti legittimi del servizio.

• Intermediari di Relying Party: dimostrano inoltre la propria eleggibilità ad agire per conto delle Relying Party, ai sensi dell'Articolo 5b(8) del Regolamento eIDAS2 ([EU_2024_1183]).

Nota

Il Credential Issuer dichiara i tipi di Credenziale che intende emettere, ciascuno ancorato al proprio Rulebook, e la sua integrazione con le Fonti Autentiche rilevanti è autorizzata ove necessario.

L'Organismo di Supervisione approva inoltre i claim, gli schema e i tipi di Credenziale prima che siano registrati nei registri, e tale approvazione è una precondizione di Claim Registration, di Schema Provisioning e di Credential Type Registration.

L'identity proofing delle Wallet-Relying Party DEVE essere effettuato dal Registrar secondo [ETSI TS 119 461]. La verifica degli entitlement DEVE seguire l'Annex III di [CIR2025/848]. All'interno di IT-Wallet l'identity proofing è applicato a ogni entità che si onboarda, comprese le entità che non operano nel Trust Framework EUDIW, anche ove non sia strettamente richiesto per esse.

Per le entità notificate le certificazioni sono un input obbligatorio dell'onboarding, e in ogni caso la verifica di eleggibilità e conformità è una precondizione obbligatoria per la registrazione tecnica.

8.2.4. Trust Artifacts Registration Outcomes

Una registrazione riuscita produce, a seconda del ruolo e dell'ambito di operatività, i Trust Artifact. Per le categorie notificate, la voce in una List of Trusted Entities consegue da Notification and Publication, che è un processo distinto. Il modo in cui ciascun artifact è prodotto è descritto in Onboarding Processes, e gli effetti delle modifiche successive in Events, Registries and Trust Artifacts.

La tabella mostra gli artifact che variano per ruolo. La colonna del certificato X.509 raggruppa i certificati X.509 che l'entità ottiene, in particolare il WRPAC, il Sign/Seal Certificate e il National Authentication Certificate. Il WRPRC è mostrato a parte. Il WRPRC non è un certificato X.509 ma un JSON Web Token o un CBOR Web Token.

Tabella 8.6 Trust Artifacts Registration Outcomes by Entity Type

Entity type	Register record	WRPRC	X.509 certificate	LoTE entry
PID Provider	sì	sì	il WRPAC e il Sign/Seal Certificate	PID Providers LoTE
QEAA Provider	sì	sì	il WRPAC. Il Sign/Seal Certificate è il certificato qualificato emesso dal QTSP	EUMS TL, referenziato nella LOTL
PuB-EAA Provider	sì	sì	il WRPAC. Il Sign/Seal Certificate è il certificato qualificato emesso dal QTSP	PuB-EAA Providers LoTE
Non-qualified EAA Provider	sì solo se emette un Attestato pubblicato in un EU Rulebook	sì solo se emette un Attestato pubblicato in un EU Rulebook	il WRPAC solo se emette un Attestato pubblicato in un EU Rulebook, e il Sign/Seal Certificate	Nessuna, distribuzione del trust anchor definita nell'Attestation Rulebook applicabile
Relying Party	sì, solo per RP che opera in EUDIW	sì, solo per RP che opera in EUDIW	il WRPAC se ha un record nel register, e l'Authentication Certificate ove la RP non ha un record nel register e opera nel Proximity Flow	Nessuna
Relying Party Intermediary	sì	No	il WRPAC	Nessuna
Wallet Provider	no	no	il Sign/Seal Certificate	Wallet Providers LoTE

Nota

La registrazione di federazione è comune a ogni entità e, come suo risultato, ogni entità ottiene un Subordinate Statement emesso dalla propria Federation Authority, e un Trust Mark di registrazione.

Nota

Per una Wallet-Relying Party che opera nel Trust Framework EUDIW, la colonna WRPAC è un certificato di accesso e la colonna WRPRC è un certificato di registrazione, emesso automaticamente come definito in Wallet-Relying Party Registration Certificate Issuance. Un WRPAC per ciascun Service registrato, un insieme distinto di WRPAC per ciascuna Relying Party intermediata, e un WRPRC per ciascuna combinazione di intended use e Service sono rinviati come specificato in Register of WRPs.

Nota

Un'entità che opera solo a livello nazionale non ottiene né un record nel Register, né un WRPAC né un WRPRC. Detiene la propria Entity Statement e il proprio Trust Mark di registrazione dalla registrazione di federazione e, ove il proprio ruolo lo richieda, il proprio certificato X.509, ossia il Sign/Seal Certificate per un Credential Issuer nazionale o l'Authentication Certificate per una Relying Party che opera nel Proximity Flow.

8.2.5. Registration Profiles

Questa Sezione descrive la registrazione di ciascun ruolo come un profilo. Ogni profilo fornisce i dati di registrazione di base definiti in Registration Data Model. Ciascun profilo seguente indica solo i dati di registrazione estesi che il ruolo fornisce e come l'entità li popola, insieme a qualsiasi specializzazione dei dati di base. Un'entità può detenere più di un entitlement in un unico record di registrazione e per più di un ruolo, quindi i profili non sono mutuamente esclusivi e si compongono. Ad esempio, un'entità può essere contemporaneamente una Relying Party e un QEAA Provider, e in tal caso il suo input è l'unione dei due profili e il suo esito è l'unione dei due. Un Non-Qualified EAA Provider e una Relying Party DEVONO dichiarare, per ciascun ruolo e per ciascun tipo di Attestato, se tale ruolo opera nel Trust Framework EUDIW oppure soltanto all'interno del perimetro nazionale. A runtime l'Attestato richiesto seleziona il Trust Framework, come specificato in Trust Framework Selection.

Nota

La definizione di un tipo di Credenziale non fa parte di alcun profilo di registrazione, come descritto in Registration Data Model. È fornita dall'Attestation Scheme Provider, si veda System Actors and Roles, tramite Credential Type Registration.

8.2.5.1. PID Provider

Un PID Provider è un'Entità di Federazione che è notificata e registrata nel Trust Framework EUDIW, e il suo trust anchor Sign/Seal è pubblicato nella PID Providers LoTE. Oltre ai dati di registrazione di base, un PID Provider fornisce i seguenti dati di registrazione estesi, come definiti in Registration Data Model:

• entitlements.

• service_description.

• relying_party_services.

  • I Service del PID Provider, come oggetti WalletRelyingPartyService di EUDI-TS 5. Il Service reca provided_attestations per il tipo PID. serviceIdentifier non è richiesto.

• provided_attestations.

• federation_entity_identifier.

• federation_entity_key.

• certificate_signing_requests.

  • Una Certificate Signing Request per il WRPAC, con cui il PID Provider si autentica verso le Wallet Unit.

  • Una Certificate Signing Request per il Sign/Seal Certificate, con cui firma il PID emesso.

• conformity_assessment.

• service_supply_point.

8.2.5.2. QEAA Provider

Un QEAA Provider è un'Entità di Federazione che emette Qualified Electronic Attestations of Attributes, e il suo Sign/Seal Certificate è il certificato qualificato emesso dal Qualified Trust Service Provider a cui appartiene. Gli Attestati Elettronici che emette DEVONO seguire Modello di Dati QEAA e PuB-EAA. Oltre ai dati di registrazione di base, un QEAA Provider fornisce i seguenti dati di registrazione estesi, come definiti in Registration Data Model:

• entitlements.

• service_description.

• relying_party_services.

  • I Service del QEAA Provider, come oggetti WalletRelyingPartyService di EUDI-TS 5. Il Service reca provided_attestations. serviceIdentifier non è richiesto.

• provided_attestations.

• federation_entity_identifier.

• federation_entity_key.

• certificate_signing_requests.

  • Una Certificate Signing Request per il WRPAC, con cui il QEAA Provider si autentica verso le Wallet Unit.

• conformity_assessment.

• service_supply_point.

• signing_trust_anchor.

  • Fornito come input perché la Qualified Certification Authority del QEAA Provider non è subordinata alla National Root Certification Authority ma appartiene al perimetro di un Qualified Trust Service Provider.

8.2.5.3. PuB-EAA Provider

Un PuB-EAA Provider è un'Entità di Federazione che è notificata e registrata nel Trust Framework EUDIW, e il suo trust anchor Sign/Seal è pubblicato nella PuB-EAA Providers LoTE. Gli Attestati Elettronici che emette DEVONO seguire Modello di Dati QEAA e PuB-EAA. Oltre ai dati di registrazione di base, un PuB-EAA Provider fornisce i seguenti dati di registrazione estesi, come definiti in Registration Data Model:

• entitlements.

• service_description.

• relying_party_services.

  • I Service del PuB-EAA Provider, come oggetti WalletRelyingPartyService di EUDI-TS 5. Il Service reca provided_attestations. serviceIdentifier non è richiesto.

• provided_attestations.

• federation_entity_identifier.

• federation_entity_key.

• certificate_signing_requests.

  • Una Certificate Signing Request per il WRPAC, con cui il PuB-EAA Provider si autentica verso le Wallet Unit.

• conformity_assessment.

  • Il Conformity Assessment Report emesso da un Conformity Assessment Body ai sensi dell'Articolo 45f di [EIDAS].

• service_supply_point.

• signing_trust_anchor.

  • Fornito come input perché la Qualified Certification Authority del PuB-EAA Provider non è subordinata alla National Root Certification Authority ma appartiene al perimetro di un Qualified Trust Service Provider.

8.2.5.4. Non-Qualified EAA Provider

Oltre ai dati di registrazione di base, un Non-Qualified EAA Provider fornisce i seguenti dati di registrazione estesi, come definiti in Registration Data Model:

• entitlements.

• service_description.

• relying_party_services.

  • OBBLIGATORIO ove il Non-Qualified EAA Provider operi nel Trust Framework EUDIW. I Service del Provider, come oggetti WalletRelyingPartyService di EUDI-TS 5. serviceIdentifier non è richiesto.

• provided_attestations.

• federation_entity_identifier.

• federation_entity_key.

• certificate_signing_requests.

  • Una Certificate Signing Request per il Sign/Seal Certificate, con cui il Non-Qualified EAA Provider firma l'EAA emessa.

  • Un Non-Qualified EAA Provider che opera nel Trust Framework EUDIW fornisce inoltre una Certificate Signing Request per il WRPAC, con cui si autentica verso le Wallet Unit.

• service_supply_point.

• trust_framework_scope.

  • Un Non-Qualified EAA Provider che opera nel Trust Framework EUDIW ottiene il record nel Register, il WRPAC e il Sign/Seal Certificate. Un Non-Qualified EAA Provider che opera solo all'interno del perimetro nazionale ottiene il solo Sign/Seal Certificate. La Wallet Unit autentica tale Provider tramite il National Trust Framework. Gli Attestati di tale Provider sono validati rispetto al trust anchor distribuito dall'Entity Configuration del Federation TA. L'IT-Wallet ID, l'Attestato Elettronico di Dati di Identificazione Personale di ambito nazionale, è un esempio di Attestato emesso da un Non-Qualified EAA Provider che opera all'interno del perimetro nazionale, si veda Modello di Dati dell'IT-Wallet ID e IT-Wallet ID. È un EAA e NON DEVE essere confuso con i Person Identification Data EUDI, che non sono un EAA.

8.2.5.5. Relying Party

Oltre ai dati di registrazione di base, una Relying Party fornisce i seguenti dati di registrazione estesi, come definiti in Registration Data Model:

• entitlements.

• service_description.

• relying_party_services.

  • OBBLIGATORIO ove la Relying Party operi nel Trust Framework EUDIW. I Service della Relying Party, come oggetti WalletRelyingPartyService di EUDI-TS 5. serviceIdentifier non è richiesto.

• intended_use.

  • Annidato in relying_party_services. Il tipo di Attestato e opzionalmente gli attributi che la Relying Party intende richiedere dalle Wallet Unit.

• intermediary_relationship.

  • Annidato in relying_party_services. Nel Trust Framework EUDIW, OBBLIGATORIO ove il Relying Party Service operi tramite un RP Intermediary, e in tal caso fa riferimento all'identificativo dell'Intermediary Service (usesIntermediaries). Nel National Trust Framework la Relying Party non lo dichiara, perché la relazione con l'RP Intermediary è istituita tramite la federazione, in quanto la Relying Party imposta i propri authority_hints sull'RP Intermediary che la federa. Il lato dell'RP Intermediary è descritto in Relying Party Intermediary.

• federation_entity_identifier.

• federation_entity_key.

  • OBBLIGATORIO per una Relying Party che opera senza intermediario. Una Relying Party che opera tramite un RP Intermediary NON DEVE fornirlo, perché è registrata dal proprio RP Intermediary secondo il National Trust Framework.

• certificate_signing_requests.

  • Una Certificate Signing Request per ciascun certificato X.509 di cui la Relying Party ha bisogno. Tale richiesta è un WRPAC quando la Relying Party opera nel Trust Framework EUDIW. Tale richiesta è il National Authentication Certificate quando la Relying Party opera solo nel National Trust Framework e supporta il Proximity Flow.

• trust_framework_scope.

  • Gli artifact seguono la dichiarazione di questo ruolo. Il Trust Framework di ciascuna presentazione è selezionato come specificato in Trust Framework Selection.

Nota

Una Relying Party (intermediata o meno) DEVE registrarsi tramite il Sistema di Onboarding per ottenere un Trust Mark di registrazione (si veda Trust Mark registration-entity) e, nel caso di una Mobile Relying Party Instance, per ottenere un Authentication X.509 Certificate. Una Relying Party che opera nel Trust Framework EUDIW DEVE avere un record nel Register of WRP, DEVE ottenere il proprio WRPAC e DEVE ricevere il proprio WRPRC automaticamente, come specificato in Wallet-Relying Party Registration Certificate Issuance.

8.2.5.6. Relying Party Intermediary

Un Intermediario di Relying Party dichiara di agire come intermediario sia nel National Trust Framework sia nel Trust Framework EUDIW. Nel National Trust Framework l'Intermediario di Relying Party è un Federation Intermediate, ossia effettua l'onboarding delle Relying Party intermediate in autonomia, pubblicandone i Subordinate Statement, come descritto in Trust Mark registration-entity. Nel Trust Framework EUDIW è registrato con isIntermediary impostato, e federa le Relying Party intermediate che operano nel Trust Framework EUDIW, come dichiarato nel loro trust_framework_scope. Fornisce gli stessi Data Identifier di una Relying Party, con le differenze nella tabella seguente. I Data Identifier non elencati qui sono forniti come per una Relying Party.

Tabella 8.7 Relying Party Intermediary Registration Data, differences from the Relying Party

Data Identifier	Value
intended_use	NON DEVE essere fornito. Un Intermediario di Relying Party non richiede attributi per sé, ma per conto delle Relying Party intermediate. Nel Register, ciascuno dei suoi elementi services[] ha isIntermediary impostato a true, omette intendedUses e elenca in servedWRPServices gli identificativi di Service che serve ([CIR2026/1730], Annex I).
entitlements	NON DEVE essere fornito per un Intermediary Service puro (EUDI-TS 5).
relying_party_services	OBBLIGATORIO. Ciascun Service è un Intermediary Service: isIntermediary è true, e servedWRPServices elenca i Relying Party Service che serve. serviceIdentifier non è richiesto.
certificate_signing_requests	Una Certificate Signing Request per il WRPAC. Il WRPAC emesso autentica l'Intermediario. Un WRPAC per ciascun Relying Party Service intermediato è rinviato come specificato in Register of WRPs.
intermediary_relationship	Impostato sull'Intermediary Service, ossia la Relying Party dichiara che il Service è un intermediario designato. È dichiarato in entrambi i framework.
federation_entity_identifier	Il Federation Entity Identifier dell'Intermediario di Relying Party all'interno del National Trust Framework.
federation_entity_key	La Federation Entity Key dell'Intermediario di Relying Party.

Nota

La registrazione di un Intermediario di Relying Party e la registrazione delle sue Relying Party intermediate sono collegate, l'Intermediario dichiara di agire come intermediario e ciascuna Relying Party intermediata lo referenzia nel proprio profilo Relying Party.

8.2.5.7. Wallet Provider

Un Fornitore di Wallet è un'Entità di Federazione che è notificata, ma non è registrata nel Register, perché non agisce come Wallet-Relying Party. I suoi dati di registrazione fanno parte del dataset di notifica, e il suo trust anchor Sign/Seal è pubblicato nella Wallet Providers LoTE. Oltre ai dati di registrazione di base, un Fornitore di Wallet fornisce i seguenti dati di registrazione estesi, come definiti in Registration Data Model:

• entitlements.

• service_description.

• federation_entity_identifier.

• federation_entity_key.

• certificate_signing_requests.

  • Una Certificate Signing Request per il Sign/Seal Certificate, con cui il Fornitore di Wallet firma le Wallet Unit Attestation.

• conformity_assessment.

8.2.5.8. Authentic Source

Una Fonte Autentica è al di fuori dei Trust Framework EUDIW e Nazionale, e la sua trust è governata dal framework PDND. Non è registrata nel Register e non è un'Entità di Federazione, quindi non fornisce i dati di federazione e non ottiene alcun Trust Artifact. I suoi dati di registrazione sono la voce dell'AS Registry. Oltre ai dati di registrazione di base, una Fonte Autentica fornisce i seguenti dati di registrazione estesi, come definiti in Registration Data Model:

• provided_claims_purposes.

• visual_identity.

• verification_endpoint.

  • Fornito solo ove la Fonte Autentica sia responsabile di un attributo esportato nel EUDIW Catalogue of Attributes. Lo scopo è consentire a un Qualified Trust Service Provider di un altro Stato membro di raggiungere la sua interfaccia di verifica.

8.3. Onboarding Processes

Questa parte fornisce la vista dinamica dell'onboarding. Ciascun processo è descritto con il proprio Input, il proprio Outcome e il proprio Process, ossia la sequenza di passi.

I processi sono organizzati in tre famiglie.

• Il Entity Onboarding copre la registrazione di un'entità e di una Fonte Autentica, e il loro aggiornamento, sospensione e rimozione.

• Il Certificate and Trust Artifact Issuance copre l'emissione dei certificati e dei Trust Mark che un'entità ottiene.

• Il Attestation Onboarding copre la registrazione dei claim, degli schema e dei tipi di Credenziale, e il ciclo di vita dei tipi di Credenziale.

Le Sezioni Process Dependency Map e Notification and Publication seguenti forniscono rispettivamente l'ordine dei processi e le dipendenze tra essi, e il processo di notifica delle entità che ne sono soggette.

8.3.1. Process Dependency Map

Questa sezione mappa ogni processo di onboarding rispetto a quattro relazioni:

• Preconditions sono le condizioni che DEVONO sussistere prima che il processo possa essere eseguito. Includono il completamento di un altro processo e le condizioni esterne al Sistema di Onboarding, quali la certificazione di una Soluzione Wallet o lo status qualificato di un Qualified Trust Service Provider.

• Started by è chi o che cosa avvia il processo. Un processo è avviato da una parte esterna che lo richiede, oppure è invocato da un altro processo, oppure non ha una richiesta esplicita ed è una rivalutazione di condizioni.

• Activates sono i processi che si avviano come conseguenza di questo.

• Enables sono le capacità che diventano possibili in seguito, che non sono processi del Sistema di Onboarding.

I processi sono eseguiti dai componenti descritti in System Components and Services, e viene fornita una tabella per ciascuna famiglia di Onboarding Processes.

Tabella 8.8 Process Map of the Entity Onboarding Processes

Process	Preconditions	Started by	Activates	Enables
Entity Registration	Verifica di eleggibilità e conformità, compreso l'identity proofing e la verifica degli entitlement	L'Entità, che richiede la registrazione	Registration Trust Mark Issuance; Credential Type Activation and Deactivation, if it completes a versioned entry	La richiesta, da parte dell'Entità, del WRPAC if EUDIW Trust Framework, del Sign/Seal Certificate if National PKI, e del National Authentication Certificate if Proximity Flow; la Notification and Publication dell'Entità, if notified category, per la quale il Sistema di Onboarding mantiene le informazioni notificabili
Entity Update	Entity Registration	L'Entità, che presenta una modifica di una o più categorie dei propri dati di registrazione	Registration Trust Mark Issuance, ove la modifica incida sui dati che reca; Wallet-Relying Party Registration Certificate Issuance, ove la modifica incida sui dati di registrazione	La richiesta, da parte dell'Entità, della riemissione dei certificati X.509 che recano i dati modificati; la revoca e la riemissione automatizzate del WRPRC da parte del relativo Provider; la ri-verifica dell'eleggibilità ove la modifica incida sull'Authorization Information; e la Notification and Publication della modifica, if notified category
Entity Suspension and Removal	Entity Registration	L'autorità competente o l'Entità, che richiede una sospensione, una riattivazione o una cancellazione	Credential Type Activation and Deactivation, if Credential Issuer	La Notification and Publication del nuovo stato dell'Entità, if notified category
Authentic Source Registration	Verifica di eleggibilità e conformità da parte dell'Organismo di Supervisione; la sottoscrizione della Fonte Autentica a PDND e la pubblicazione del proprio e-Service	La Fonte Autentica, che dichiara i propri dati di registrazione	Claim Registration, if a claim is missing	La registrazione dei tipi di Credenziale che referenziano la Fonte Autentica come propria fonte dati
Authentic Source Update	Authentic Source Registration	La Fonte Autentica, o la notifica tramite PDND della modifica di un e-Service	Credential Type Activation and Deactivation, if a type loses its data source	—
Authentic Source Removal	Authentic Source Registration	Una richiesta di rimozione	Credential Type Activation and Deactivation, if a type loses its data source	—

Tabella 8.9 Process Map of the Certificate and Trust Artifact Issuance Processes

Process	Preconditions	Started by	Activates	Enables
Wallet-Relying Party Access Certificate Issuance	Entity Registration, con un record dell'Entità nel Register, if EUDIW Trust Framework	L'Entità, con un ordine ACME, per la prima emissione o per una riemissione	Wallet-Relying Party Registration Certificate Issuance	L'autenticazione dell'Entità verso le Wallet Unit
Wallet-Relying Party Registration Certificate Issuance	Entity Registration, con un record con uno stato di registrazione valido nel Register e un WRPAC valido, if EUDIW Trust Framework	Il Provider of WRPRC, invocato senza una richiesta dell'Entità quando esiste un WRPAC valido o quando il record del Register cambia	—	La presentazione dei dati di registrazione dell'Entità alle Wallet Unit
Signature and Seal Certificate Issuance	Entity Registration, if National PKI. Per un QEAA Provider e un PuB-EAA Provider il certificato è qualificato ed è emesso da un Qualified Trust Service Provider al di fuori di questo processo	L'Entità, con un ordine ACME, per la prima emissione o per una riemissione	—	La firma o il sigillo degli Attestati che l'Entità emette
National Authentication Certificate Issuance	Entity Registration, if Proximity Flow	L'Entità, con un ordine ACME, per la prima emissione o per una riemissione	—	L'autenticazione dell'Entità nel Proximity Flow
Registration Trust Mark Issuance	Il completamento della registrazione di federazione dell'Entità	Invocato dall'Entity Registration, e dall'Entity Update ove la modifica incida sui dati che il Trust Mark reca	—	Il riconoscimento dell'Entità come partecipante registrato del National Trust Framework, e la lettura dei suoi dati di autorizzazione ove non abbia un record nel Register

Tabella 8.10 Process Map of the Attestation Onboarding Processes

Process	Preconditions	Started by	Activates	Enables
Claim Registration	—	Invocato dall'Authentic Source Registration, dallo Schema Provisioning o dal Credential Type Registration, if a claim is missing	—	Lo Schema Provisioning e il Credential Type Registration che utilizzano il claim
Schema Provisioning	I claim che compongono lo schema sono disponibili nel Claims Registry	Invocato dal Credential Type Registration, if the schema is missing	Claim Registration, if a claim is missing	L'attivazione di un tipo di Credenziale, come una delle sue condizioni
Credential Type Registration	La definizione e la disponibilità dell'Attestation Rulebook applicabile; l'Authentic Source Registration, o un tipo di Credenziale padre, come fonte dati	L'Attestation Scheme Provider, che richiede la registrazione	Claim Registration, if a claim is missing; Schema Provisioning, if the schema is missing; Credential Type Activation and Deactivation	La dichiarazione del tipo di Credenziale da parte di un Credential Issuer in sede di Entity Registration
Credential Type Activation and Deactivation	Credential Type Registration	Nessuna richiesta esplicita. La voce versionata è rivalutata ogni volta che una delle sue tre condizioni cambia	—	L'emissione del tipo di Credenziale da parte dei Credential Issuer elencati nella voce versionata
Credential Type Update	Credential Type Registration	L'Attestation Scheme Provider, che pubblica una nuova versione	Credential Type Registration per la nuova voce versionata; Credential Type Activation and Deactivation	—

I processi che agiscono sul ciclo di vita di un'entità o di un tipo di Credenziale sono governati come descritto in Lifecycle Management, e gli effetti di ciascun evento sui registri e sui Trust Artifact sono dati in Events, Registries and Trust Artifacts.

8.3.2. Entity Onboarding

Questa sezione descrive i processi che gestiscono il ciclo di vita delle entità e delle Fonti Autentiche. Ciascun processo è descritto con il proprio Input, il proprio Outcome e il proprio Process. La governance dei corrispondenti eventi, ossia chi è titolato a decidere e entro quali condizioni, è data in Registration Events and Their Governance.

8.3.2.1. Entity Registration

Il processo Entity Registration prende in input i dati di registrazione di un'Entità. Il processo verifica i dati di registrazione, li registra e registra l'Entità nel National Trust Framework. Ove il ruolo e la dichiarazione dell'Entità lo richiedano, il processo registra l'Entità nel EUDIW Register. Il processo è parametrizzato dal profilo di registrazione del ruolo, e il suo esito è la transizione dell'Entità allo stato REGISTERED. Abilita i processi di Certificate and Trust Artifact Issuance, che portano l'Entità a OPERATIONAL, e, per un Credential Issuer, il Credential Type Registration. L'emissione dei certificati e del Trust Mark di registrazione, e la governance degli stati, sono descritte nei processi referenziati e in Lifecycle Management.

8.3.2.1.1. Entity Registration: Input

L'input è costituito dai dati di registrazione dell'Entità, secondo il profilo del suo ruolo definito in Registration Data Model e in Registration Profiles. I dati sono organizzati nelle tre categorie di dati registrati definite in Lifecycle Management, e per ciascuna categoria una parte è fornita dall'Entità e una parte è derivata dal Sistema di Onboarding.

• Identity Information, fornita dall'Entità:

  • legal_name,

  • identifier,

  • legal_nature,

  • contact_information,

  • service_policies,

  • data_protection_authority.

• Technical Configuration, fornita dall'Entità, in particolare il federation_entity_identifier e la federation_entity_key della propria Entity Configuration.

• Authorization Information, fornita dall'Entità, ossia:

  • entitlements,

  • relying_party_services,

  • intended_use,

  • provided_attestations per un Credential Issuer,

  • intermediary_relationship ove applicabile,

  • conformity_assessment per le categorie che ne hanno bisogno.

Il record firmato, i certificati e i loro Trust Anchor non sono un input ma sono derivati dalla registrazione. In particolare, le certificate_signing_requests non sono un input diretto di questo processo ma dei processi di Certificate and Trust Artifact Issuance. Per un PID Provider e un Fornitore di Wallet il signing_trust_anchor deriva dall'emissione nazionale. Per un QEAA Provider e un PuB-EAA Provider il signing_trust_anchor è fornito all'interno delle eIDAS Trusted Lists. L'Entità non fornisce il signing_trust_anchor come input.

L'eleggibilità e la conformità dell'Entità sono una precondizione e non una parte di questo processo, e sono descritte in Eligibility and Compliance Preconditions.

8.3.2.1.2. Entity Registration: Outcome

L'esito è l'Entità nello stato REGISTERED, ossia il momento in cui il record di registrazione esiste ed è stato verificato, come definito in Lifecycle Management. La registrazione è registrata nei due Trust Framework secondo il ruolo e la dichiarazione dell'Entità.

• Nel National Trust Framework l'Entità è registrata nella federazione, e il suo Subordinate Statement, che reca il Trust Mark di registrazione, è pubblicato dal National Federation Management.

• Nel Trust Framework EUDIW, per le Wallet-Relying Party, un record firmato è scritto nel Register, e guida la successiva emissione del WRPAC e l'emissione automatizzata del WRPRC.

Il National Trust Framework è sempre lo strato di registrazione, mentre il Trust Framework EUDIW è aggiunto per le categorie notificate e per le Entità che dichiarano l'operatività transfrontaliera, come descritto in Overview. Il Register e il dataset di notifica sono mantenuti distinti, come descritto in Trust Artifacts Registration Outcomes.

8.3.2.1.3. Entity Registration: Process

1. L'eleggibilità e la conformità dell'Entità DEVONO essere state verificate, compreso l'identity proofing e la verifica degli entitlement, come descritto in Eligibility and Compliance Preconditions. Questa verifica è la precondizione della registrazione.

2. Il Sistema di Onboarding raccoglie i dati di registrazione del profilo, li valida e instrada ciascuna parte al componente responsabile di essa.

3. Il National Federation Management registra l'Entità nella federazione. Il National Federation Management valida l'Entity Configuration pubblicata dall'Entità, data dal federation_entity_identifier e dalla federation_entity_key. Il National Federation Management prepara la metadata policy che vincola i metadata di protocollo dell'Entità ai valori approvati in sede di onboarding. Invoca quindi Registration Trust Mark Issuance per ottenere il Trust Mark di registrazione, e pubblica il Subordinate Statement sull'Entità, che reca la metadata policy e il Trust Mark. Quindi, l'Entità DEVE includere il Trust Mark ricevuto nella propria Entity Configuration, che punta al proprio superiore immediato tramite gli authority_hints. Durante la stessa registrazione le chiavi pubbliche del Federation Trust Anchor sono rese disponibili all'Entità fuori banda, tramite il canale di contatto della registrazione. Tale disponibilità avvia la trust dell'Entità nel Trust Anchor, si veda Federation Trust Anchor Distribution and Validation. La struttura dell'Entity Configuration e del Subordinate Statement è definita in National Trust Artifacts.

4. Ove il ruolo e la dichiarazione dell'Entità richiedano il Trust Framework EUDIW, l'EUDIW Registration Management verifica l'Entità e scrive il suo record nel Register, e il Registrar lo firma o lo sigilla. Il record guida la successiva emissione del WRPAC e l'emissione automatizzata del WRPRC, e il suo data model e la sua API pubblica sono definiti in Register of WRPs. Per un Credential Issuer, i provided_attestations dichiarati in sede di registrazione aggiungono il Credential Issuer al campo issuers della voce versionata di ciascun tipo di Credenziale dichiarato, come descritto in Credential Type Registration. La stessa dichiarazione è recata nel record e nel WRPRC.

5. Ove l'Entità appartenga a una categoria soggetta a notifica, il Notification Dataset Management raccoglie le sue informazioni notificabili nel dataset di notifica, come descritto in Notification and Publication.

6. La registrazione produce l'evento registration, che la Federation Authority pubblica sul Federation Subordinate Events Endpoint come descritto in Registration Events and Their Governance. Al termine del processo l'Entità è REGISTERED. Il record abilita i processi di Certificate and Trust Artifact Issuance che portano l'Entità a OPERATIONAL. Per un Credential Issuer, la dichiarazione può attivare i tipi di Credenziale dichiarati, come descritto in Credential Type Activation and Deactivation.

Nota

Il Register è il registro nazionale delle Wallet-Relying Party che ciascuno Stato membro istituisce ai sensi dell'Articolo 3 di [CIR2025/848] e opera tramite il Registrar. È distinto dai componenti semantici della Registry Infrastructure, che detengono la semantica delle Credenziali e i dati di discovery, ed è documentato come Register of WRPs.

8.3.2.2. Entity Update

Il processo Entity Update modifica le informazioni registrate di un'Entità, nella sua Identity Information, nella sua Technical Configuration, compresa la rotazione e la richiesta di chiavi, e nella sua Authorization Information. L'Entità è responsabile dell'accuratezza delle proprie informazioni e le aggiorna senza indebito ritardo. Questo processo descrive ciò che l'Entità presenta e quali passi i componenti eseguono, mentre la relazione tra le categorie di dati registrati e i Trust Artifact è data in Entity Updates and Their Effects on Trust Artifacts.

8.3.2.2.1. Entity Update: Input

I dati di registrazione aggiornati definiti in Registration Data Model. Per una modifica dell'Identity Information l'input è il nuovo legal_name, identifier, legal_nature, contact_information, service_policies o data_protection_authority. Per una modifica della Technical Configuration relativa al nuovo materiale crittografico, la federation_entity_key e le certificate_signing_requests sono fornite rispettivamente per l'identità di federazione e per i certificati X.509. Per una modifica dell'Authorization Information l'input è il nuovo entitlements, relying_party_services, intended_use, provided_attestations o intermediary_relationship, a seconda del ruolo.

8.3.2.2.2. Entity Update: Outcome

Le informazioni registrate aggiornate dell'Entità. Una modifica che incide sull'Authorization Information attiva la ri-verifica dell'eleggibilità, perché un nuovo entitlement non è auto-dichiarato, come descritto in Eligibility and Compliance Preconditions.

8.3.2.2.3. Entity Update: Process

1. L'Entità presenta la modifica di una o più categorie dei propri dati di registrazione.

2. Per una modifica dell'Identity Information o dell'Authorization Information, l'EUDIW Registration Management aggiorna il record nel Register. Il National Federation Management aggiorna il Subordinate Statement e il Trust Mark di registrazione. L'Entità richiede la riemissione dei certificati X.509 che recano i dati modificati, come descritto in Certificate and Trust Artifact Issuance. Il Provider of WRPRC revoca i WRPRC interessati. Il Provider of WRPRC DEVE riemettere i WRPRC automaticamente ove la registrazione resti valida. Ove l'Entità appartenga a una categoria notificata, il Notification Dataset Management aggiorna la notifica, come descritto in Notification and Publication.

3. Per una modifica della federation_entity_key, il National Federation Management esegue la rotazione specificata in Federation Entity Key Rotation. La rotazione delle chiavi dei certificati X.509 è una riemissione. Tale riemissione è gestita dai processi di Certificate and Trust Artifact Issuance. L'Entità fornisce le nuove certificate_signing_requests nell'ordine ACME.

4. Una modifica dell'Authorization Information è soggetta alla ri-verifica dell'eleggibilità da parte dell'Organismo di Supervisione. Per un Credential Issuer, una modifica delle capacità di fornitura delle Credenziali aggiunge il Credential Issuer al campo issuers della voce versionata di un tipo di Credenziale, o lo rimuove da tale campo, come descritto in Credential Type Registration.

5. L'aggiornamento produce l'evento corrispondente. Un metadata_update copre una modifica dell'Identity Information o della Technical Configuration. Un jwks_update copre una rotazione di chiavi. L'evento è pubblicato sul Federation Subordinate Events Endpoint come descritto in Registration Events and Their Governance.

Nota

I parametri informativi dei metadata federation_entity, con l'eccezione dell'organization_name, non sono inclusi nella metadata_policy e possono essere gestiti autonomamente dall'Entità nella propria Entity Configuration auto-firmata. Le chiavi di firma di protocollo (jwks), gli endpoint di servizio e gli URI di request, response e redirect sono invece vincolati dalla metadata_policy del Subordinate Statement ai valori approvati in sede di onboarding, come definito in National Trust Artifacts, quindi una loro modifica è un Entity Update che riemette il Subordinate Statement.

Nota

Una modifica degli attributi di identità registrati di un'Entità è un Entity Update, compresa una modifica del suo legal_name, della sua legal_nature o del suo identifier, ove la persona giuridica resti la stessa. Ove la persona giuridica stessa cambi, come in una fusione o in una scissione, la registrazione dell'Entità precedente DEVE essere cancellata e la nuova persona giuridica DEVE essere registrata come una nuova Entità, perché l'identity proofing è vincolato alla persona giuridica.

Nota

La rotazione di una chiave di protocollo, quella fornita all'interno dei metadata di protocollo, è effettuata tramite l'aggiornamento della metadata_policy. La rotazione di una chiave di protocollo DEVE seguire Federation Entity Key Rotation. La coesistenza copre la finestra di validità di tali Trust Chain, in modo che un verificatore che fa ancora affidamento su una Trust Chain con la vecchia chiave possa validare fino a quando non la ricostruisce.

8.3.2.3. Entity Suspension and Removal

Il processo Entity Suspension and Removal sospende, riattiva o cancella la registrazione di un'Entità. La richiesta proviene da un Organismo di Supervisione, dall'Entità stessa o da un'altra parte esterna titolata alla richiesta come descritto in Registration Events and Their Governance. Il processo si applica nei due Trust Framework. Questo processo descrive i passi che i componenti eseguono, mentre chi è titolato a innescare ciascun evento, su quale base normativa e entro quali condizioni, è dato in Registration Events and Their Governance.

8.3.2.3.1. Entity Suspension and Removal: Input

La richiesta di sospensione, riattivazione o cancellazione, dall'autorità competente o dall'Entità, con il relativo motivo.

8.3.2.3.2. Entity Suspension and Removal: Outcome

L'Entità ha cambiato lo stato in SUSPENDED in caso di sospensione, torna al proprio stato precedente in caso di riattivazione e passa a CANCELLED in caso di cancellazione, come descritto in Lifecycle Management. Una sospensione e una cancellazione revocano i Trust Artifact dell'Entità e, per un Credential Issuer, disattivano i suoi tipi di Credenziale.

8.3.2.3.3. Entity Suspension and Removal: Process

1. La richiesta di sospensione, riattivazione o cancellazione è ricevuta dall'autorità competente o dall'Entità.

2. In caso di sospensione, l'EUDIW Registration Management sospende il record nel Register ove l'Entità sia una Wallet-Relying Party. Il National Federation Management ritira il Subordinate Statement valido dell'Entità. I Trust Artifact dell'Entità non sono più oggetto di affidamento. L'Entità passa a SUSPENDED.

3. In caso di riattivazione, una volta rimossa la condizione che ha causato la sospensione, la stessa parte che ha deciso la sospensione ripristina la registrazione, e l'Entità torna a REGISTERED.

4. In caso di cancellazione, l'EUDIW Registration Management cancella il record nel Register ove l'Entità sia una Wallet-Relying Party. Il National Federation Management ritira il Subordinate Statement. I Trust Artifact dell'Entità sono revocati. L'Entità passa a CANCELLED.

5. Per un Credential Issuer, una sospensione o una cancellazione disattiva i tipi di Credenziale del Credential Issuer. Il Credential Issuer notifica le Fonti Autentiche. Le Fonti Autentiche possono quindi ritirare le corrispondenti autorizzazioni all'interno di PDND, come descritto in Authentic Source Lifecycle and PDND Alignment.

6. Dopo una sospensione, una riattivazione o una cancellazione, ove l'Entità appartenga a una categoria notificata, il Notification Dataset Management aggiorna la notifica. Lo stato dell'Entità nella corrispondente List of Trusted Entities è aggiornato di conseguenza, come descritto in Notification and Publication.

7. Ciascun evento, una suspension o una revocation, è pubblicato sul Federation Subordinate Events Endpoint come descritto in Registration Events and Their Governance.

8.3.2.4. Authentic Source Registration

Il processo Authentic Source Registration scrive le informazioni della Fonte Autentica nell'AS Registry in modo che i Credential Issuer possano scoprire quali dati sono disponibili e tramite quale e-Service. Una Fonte Autentica non è né una Wallet-Relying Party né un'Entità di Federazione, quindi non passa attraverso la registrazione di federazione né la registrazione di Wallet-Relying Party, e non ottiene alcun Trust Artifact. La trust, l'autorizzazione e gli aspetti operativi di una Fonte Autentica sono governati dal framework PDND, si veda e-Service PDND. IT-Wallet non definisce un ciclo di vita delle Fonti Autentiche. Questo processo non produce una transizione di stato. Abilita il Credential Type Registration, come fonte dati che un tipo di Credenziale referenzia, e può attivare il Claim Registration quando un claim dichiarato non è ancora nel Claims Registry.

8.3.2.4.1. Authentic Source Registration: Input

L'input è costituito dai dati di registrazione della Fonte Autentica, secondo il suo profilo in Registration Data Model e in Registration Profiles. In aggiunta ai dati di registrazione di base, l'input comprende i provided_claims_purposes e la visual_identity. La Fonte Autentica seleziona dal Claims Registry gli identificativi di claim standardizzati che fornisce, e dalla Taxonomy gli scopi che serve. Una Fonte Autentica non fornisce i dati di federazione né le certificate_signing_requests, e non ha entitlements. Da questi dati l'Authentic Source Management compone la voce della Fonte Autentica nell'AS Registry, la cui struttura è definita in Authentic Source Registry. L'Authentic Source Management genera i campi a livello di registro. Tali campi sono l'identificativo del registro, la sua versione, l'ora dell'ultima modifica e la sua configurazione di localizzazione. L'eleggibilità della Fonte Autentica, che valida la sua posizione legale e la sua autorità sui dati e la classifica come pubblica o privata, è una precondizione ed è descritta in Eligibility and Compliance Preconditions.

8.3.2.4.2. Authentic Source Registration: Outcome

Una voce nell'AS Registry, che rende la Fonte Autentica scopribile dai Credential Issuer, con le sue informazioni organizzative, le sue capacità dati dichiarate, il suo metodo di integrazione e i suoi scopi previsti. La registrazione della Fonte Autentica è completa e indipendente dall'integrazione di qualsiasi Credential Issuer, perché una Fonte Autentica dichiara le proprie capacità prima che esista qualsiasi tipo di Credenziale. Il processo non produce uno stato in IT-Wallet. La trust, l'autorizzazione e gli aspetti operativi della Fonte Autentica restano all'interno del framework PDND. Gli effetti che il ciclo di vita PDND produce all'interno di IT-Wallet sono descritti in Authentic Source Lifecycle and PDND Alignment.

8.3.2.4.3. Authentic Source Registration: Process

1. L'eleggibilità e la conformità della Fonte Autentica DEVONO essere state verificate dall'Organismo di Supervisione, come descritto in Eligibility and Compliance Preconditions. L'Organismo di Supervisione valida la posizione legale e l'autorità sui dati della Fonte Autentica. L'Organismo di Supervisione classifica la Fonte Autentica come pubblica o privata. Questa verifica è la precondizione della registrazione.

2. La Fonte Autentica dichiara i propri dati di registrazione.

3. I claim dichiarati sono verificati rispetto al Claims Registry e gli scopi dichiarati rispetto alla Taxonomy. Un claim che non è ancora nel Claims Registry attiva il Claim Registration.

4. L'Authentic Source Management scrive la voce nell'AS Registry, la cui struttura è definita in Authentic Source Registry. La Fonte Autentica diventa scopribile dai Credential Issuer.

La voce abilita il Credential Type Registration, in quanto la Fonte Autentica è la fonte dati che un tipo di Credenziale referenzia.

Nota

L'integrazione tra una Fonte Autentica e un Credential Issuer avviene all'interno di PDND ed è una precondizione per l'attivazione di un tipo di Credenziale, non un processo del Sistema di Onboarding. Il suo effetto sul ciclo di vita del tipo di Credenziale è descritto in Authentic Source Lifecycle and PDND Alignment.

8.3.2.5. Authentic Source Update

L'Authentic Source Update modifica la voce di una Fonte Autentica nell'AS Registry, con effetto sulle voci versionate dei tipi di Credenziale che dipendono da essa. Una Fonte Autentica non ha un ciclo di vita in IT-Wallet, quindi l'effetto che una modifica produce sui tipi di Credenziale è quello descritto in Authentic Source Lifecycle and PDND Alignment.

8.3.2.5.1. Authentic Source Update: Input

I dati di registrazione modificati della Fonte Autentica, ossia una modifica dei suoi provided_claims_purposes o della sua visual_identity, secondo il suo profilo in Registration Data Model.

8.3.2.5.2. Authentic Source Update: Outcome

La voce della Fonte Autentica nell'AS Registry è aggiornata. Quando la modifica riduce la disponibilità dei dati da cui un tipo di Credenziale dipende, la condizione per l'attivazione di tale tipo di Credenziale non è più soddisfatta. Il tipo di Credenziale passa a INACTIVE, come descritto in Authentic Source Lifecycle and PDND Alignment.

8.3.2.5.3. Authentic Source Update: Process

1. La Fonte Autentica, o la notifica tramite PDND della modifica di un e-Service, presenta la modifica della voce.

2. L'Authentic Source Management aggiorna la voce nell'AS Registry, la cui struttura è definita in Authentic Source Registry.

3. I tipi di Credenziale che dipendono dalla Fonte Autentica sono aggiornati, e un tipo di Credenziale che perde la disponibilità dei dati da cui dipende passa a INACTIVE, come descritto in Authentic Source Lifecycle and PDND Alignment.

8.3.2.6. Authentic Source Removal

Il processo Authentic Source Removal rimuove la voce di una Fonte Autentica dall'AS Registry, con la disattivazione delle voci versionate dei tipi di Credenziale che dipendono da essa.

8.3.2.6.1. Authentic Source Removal: Input

La richiesta di rimozione della Fonte Autentica.

8.3.2.6.2. Authentic Source Removal: Outcome

La voce della Fonte Autentica è rimossa dall'AS Registry. I tipi di Credenziale che perdono la Fonte Autentica come propria fonte dati passano a INACTIVE. Tali tipi di Credenziale restano registrati in modo da poter essere riattivati se la fonte dati è ripristinata, come descritto in Authentic Source Lifecycle and PDND Alignment.

8.3.2.6.3. Authentic Source Removal: Process

1. La richiesta di rimozione della Fonte Autentica è ricevuta.

2. L'Authentic Source Management rimuove la voce dall'AS Registry.

3. I tipi di Credenziale che dipendono dalla Fonte Autentica perdono la propria fonte dati e passano a INACTIVE. Tali tipi di Credenziale restano registrati e possono essere riattivati se l'integrazione è ripristinata, come descritto in Authentic Source Lifecycle and PDND Alignment.

8.3.3. Certificate and Trust Artifact Issuance

Questa sezione descrive i processi che emettono i Trust Artifact. Ciascun processo copre sia la prima emissione sia la riemissione, ad esempio dopo una rotazione di chiavi o una richiesta di chiavi aggiuntive. Ciascun processo è descritto con il proprio Input, il proprio Outcome e il proprio Process.

8.3.3.1. Issuance of the X.509 Certificates through ACME and OpenID Federation

Il WRPAC, il Signature/Seal Certificate e il National Authentication Certificate sono emessi tramite ACME RFC 8555 con il profilo OpenID Federation di [ACME-OIDFED].

L'Entità si autentica presso la Certification Authority con la propria Federation Trust Chain, tramite la challenge openid-federation-01. L'autenticazione riusa la valutazione di trust del National Trust Framework, quindi la validazione della Trust Chain e l'autenticazione dell'Entità seguono Trust Chain Validation e Federation Entity Authentication.

Una volta autenticata l'Entità, la Certification Authority applica la propria policy. La Certification Authority legge gli entitlement e i valori di profilo innanzitutto dal record dell'Entità nel Register, tramite le Register Open APIs. Quando l'Entità non ha un record ivi, la Certification Authority li legge dal Trust Mark di registrazione incluso nei Resolved Metadata della Trust Chain. Entrambe le fonti forniscono i dati di autorizzazione con la stessa logica di [ETSI TS 119 475].

L'emissione di questi certificati è un processo a sé stante, distinto dalla registrazione e eseguito machine-to-machine. L'Entità presenta le proprie certificate_signing_requests nell'ordine ACME solo dopo che il processo di registrazione è stato completato con successo.

Un servizio ACME distinto è fornito per ciascuna finalità, quindi il tipo del certificato è determinato dal servizio, e il profilo di ciascun certificato è fissato dal suo tipo.

All'interno di IT-Wallet il ciclo di vita di questi certificati è mantenuto distinto dal ciclo di vita della Trust Chain. Un certificato ha i propri notBefore e notAfter ed è governato dalla revoca X.509. La perdita dell'appartenenza alla federazione di un'Entità è riflessa dalla revoca dei suoi certificati, si veda Entity Suspension and Removal. Tale perdita non è riflessa dalla scadenza della Trust Chain.

Il Wallet-Relying Party Registration Certificate e il Trust Mark di registrazione non certificano chiavi, quindi non sono emessi tramite ACME. Il Trust Mark di registrazione è emesso durante la registrazione dell'Entità. Il Wallet-Relying Party Registration Certificate è emesso automaticamente come definito in Wallet-Relying Party Registration Certificate Issuance.

Fig. 8.2 Issuance of an X.509 certificate through ACME and the OpenID Federation profile.

8.3.3.2. Certificate Signing Request Profile

Questa sezione definisce il profilo che le certificate_signing_requests DEVONO seguire, si veda Registration Data Model. L'Entità fornisce una Certificate Signing Request per ciascun certificato X.509 di cui ha bisogno. A seconda del ruolo, tale certificato è il WRPAC, il Sign/Seal Certificate o il National Authentication Certificate. L'Entità presenta ciascuna Certificate Signing Request nell'ordine ACME del servizio corrispondente. Il Wallet-Relying Party Registration Certificate e il Trust Mark di registrazione non certificano una chiave, quindi non sono richiesti tramite una Certificate Signing Request, si veda Wallet-Relying Party Registration Certificate Issuance e Registration Trust Mark Issuance.

Una Certificate Signing Request reca la chiave pubblica da certificare, prova il possesso della corrispondente chiave privata e richiede i valori dei campi del certificato forniti dall'Entità. La Certificate Signing Request non determina il contenuto del certificato emesso. La Certification Authority DEVE validare i valori richiesti rispetto ai dati di registrazione e al profilo di certificato applicabile. La Certification Authority DEVE aggiungere o determinare i valori dipendenti dall'emittente richiesti da tale profilo.

La Certificate Signing Request DEVE essere una CertificationRequest come definita in RFC 2986 (PKCS #10), codificata in DER, ed è recata nell'ordine ACME come richiesto da RFC 8555#section-7.4.

Tabella 8.11 Certificate Signing Request Fields

Field	Description	Reference
certificationRequestInfo	OBBLIGATORIO. Contiene la versione, il subject, la chiave pubblica e gli attributi della richiesta.	RFC 2986#section-4.1
version	OBBLIGATORIO. DEVE essere 0, che denota una richiesta PKCS #10 versione 1.	RFC 2986#section-4.1
subject	OBBLIGATORIO. I suoi attributi DEVONO essere coerenti con i dati di registrazione dell'Entità e con [ETSI EN 319 412-2] per le persone fisiche o [ETSI EN 319 412-3] per le persone giuridiche. Il subject non è autorevole, quindi la Certification Authority PUÒ sostituirlo con il valore derivato dal record dell'Entità nel Register o, in sua assenza, dal Trust Mark di registrazione.	RFC 2986#section-4.1, [ETSI EN 319 412-2], [ETSI EN 319 412-3]
subjectPKInfo	OBBLIGATORIO. Reca la chiave pubblica da certificare. La chiave DEVE utilizzare uno degli algoritmi a chiave pubblica definiti in Algoritmi Crittografici. DEVE essere distinta dalla Federation Entity Key, e una chiave distinta DEVE essere utilizzata per ciascun certificato richiesto.	RFC 2986#section-4.1
attributes	OBBLIGATORIO. DEVE contenere esattamente un attributo extensionRequest. Altri attributi POSSONO essere inclusi solo quando supportati dal profilo di certificato applicabile.	RFC 2986#section-4.1, RFC 2985#section-5.4.2
extensionRequest	OBBLIGATORIO all'interno di attributes. DEVE avere l'object identifier 1.2.840.113549.1.9.14 e un singolo valore di tipo Extensions. Le estensioni richieste DEVONO essere coerenti con il profilo di certificato applicabile e con i dati di registrazione autorevoli.	RFC 2985#section-5.4.2
signatureAlgorithm	OBBLIGATORIO. DEVE essere compatibile con la chiave privata corrispondente a subjectPKInfo e DEVE essere uno degli algoritmi di firma definiti in Algoritmi Crittografici.	RFC 2986#section-4.2
signature	OBBLIGATORIO. La richiesta DEVE essere firmata con la chiave privata corrispondente a subjectPKInfo, il che prova il possesso di tale chiave.	RFC 2986#section-4.2

La tabella seguente definisce i valori di estensione richiesti dall'Entità e i valori di estensione determinati dalla Certification Authority. La criticità di ciascuna estensione richiesta DEVE seguire il profilo di certificato applicabile.

Tabella 8.12 Certificate Signing Request Extension Fields

Extension	Description	Reference
extensions	OBBLIGATORIO come valore di extensionRequest. DEVE contenere i campi di estensione richiesti come sequenza Extensions codificata in DER. DEVE includere keyUsage e subjectAltName e, quando richiesto dal profilo di certificato applicabile, certificatePolicies. Le estensioni i cui valori dipendono dalla Certification Authority emittente DOVREBBERO essere omesse dalla richiesta.	RFC 2985#section-5.4.2, RFC 5280#section-4.2
keyUsage	OBBLIGATORIO. DEVE essere marcato critical e DEVE contenere esattamente una delle impostazioni di key-usage consentite dal profilo di certificato applicabile. Per un WRPAC, un National Authentication Certificate o un Registrar Sign/Seal Certificate, DEVE contenere uno (e uno solo) tra Type A, Type B o Type F. Per un Entity Sign/Seal Certificate, DEVE contenere uno (e uno solo) tra Type A, Type B, Type C o Type F. Per un WRPAC, Type A DOVREBBE essere utilizzato come da LEG-4.3.1-4 nella Clausola 4.3.1 [ETSI EN 319 412-3].	RFC 5280#section-4.2.1.3, Wallet-Relying Party Access Certificate (WRPAC) Profile, Registrar Sign/Seal Certificate Profile, Entity Sign/Seal Certificate Profile
subjectAltName	OBBLIGATORIO. DEVE essere marcato non-critical e DEVE contenere almeno un GeneralName consentito dal profilo di certificato applicabile. Per un WRPAC o un National Authentication Certificate, DEVE contenere almeno uno dei seguenti valori di contatto: un uniformResourceIdentifier per un sito web di helpdesk/supporto, un otherName con type-id impostato a 2.5.4.20 (id-at-telephoneNumber), o un rfc822Name per un indirizzo e-mail di registrazione/utilizzo.	RFC 5280#section-4.2.1.6, Wallet-Relying Party Access Certificate (WRPAC) Profile

Le estensioni non applicabili, o non elencate, nel profilo di certificato applicabile NON DEVONO essere incluse nel certificato emesso, indipendentemente da qualsiasi valore richiesto nella Certificate Signing Request.

Nota

La Certificate Signing Request certifica una chiave distinta dalla Federation Entity Key. La Federation Entity Key è vincolata all'Entità tramite l'Entity Configuration e il Subordinate Statement, validati tramite la Federation Trust Chain e non tramite una catena di certificati, si veda PKI Architecture.

Di seguito un esempio non normativo di una Certificate Signing Request per un WRPAC, con dati di test.

CertificationRequest csr = {
  certificationRequestInfo: {
    version: 0,

    subject: DistinguishedName {
      countryName: "IT",
      organizationName: "Example of Relying Party",
      commonName: "ExampleBank Mobile",                   // serviceTradeName (Reg_34)
      organizationIdentifier: "VATIT-12345678901"
    },

    subjectPKInfo: {
      algorithm: AlgorithmIdentifier {
        oid: "1.2.840.10045.2.1",
        params: "1.2.840.10045.3.1.7"
      },

      subjectPublicKey: "BASE64(SPKI_PUBLIC_KEY_BYTES)"
    },

    attributes: [
      Attribute {
        type: "1.2.840.113549.1.9.14",                    // extensionRequest
        values: [
          Extensions [
            Extension {
              oid: "2.5.29.15",                           // keyUsage
              critical: true,
              value: KeyUsage {
                nonRepudiation: true                       // Type A
                // All other bits set to false
              }
            },

            Extension {
              oid: "2.5.29.32",                           // certificatePolicies
              critical: false,
              value: CertificatePolicies [
                PolicyInformation {
                  policyIdentifier: "0.4.0.194118.1.2",   // NCP-l-eudiwrp
                  policyQualifiers: [
                    CPSuri("https://rpca.example.test/cps")
                  ]
                }
              ]
            },

            Extension {
              oid: "2.5.29.17",                           // subjectAltName
              critical: false,
              value: SubjectAltName [
                GeneralName.uniformResourceIdentifier("https://rp.example.test/support"),
                GeneralName.rfc822Name("support@rp.example.test"),
                GeneralName.otherName(
                  type-id: "2.5.4.20",                    // id-at-telephoneNumber
                  value: "+39100000000"
                )
              ]
            }
          ]
        ]
      }
    ]
  },

  signatureAlgorithm: AlgorithmIdentifier {
    oid: "1.2.840.10045.4.3.2"
  },

  signature: "BASE64(SIGN(subjectPrivateKey, DER(certificationRequestInfo)))"
}

8.3.3.3. Wallet-Relying Party Access Certificate Issuance

Il processo Wallet-Relying Party Access Certificate Issuance emette il WRPAC, definito nel Wallet-Relying Party Access Certificate (WRPAC) Profile, tramite il meccanismo di Issuance of the X.509 Certificates through ACME and OpenID Federation. Il WRPAC appartiene al Trust Framework EUDIW. Gli attributi del WRPAC DEVONO sempre essere derivati dal Register, come richiesto dalla clausola 5.1.2 di [ETSI TS 119 475]. Il fallback al Trust Mark non si applica al WRPAC. L'Entità ottiene un solo WRPAC. Un WRPAC per ciascun Service registrato, e un insieme distinto di WRPAC per ciascuna Relying Party intermediata, sono rinviati come specificato in Register of WRPs.

8.3.3.3.1. Wallet-Relying Party Access Certificate Issuance: Input

Le certificate_signing_requests dell'Entità per il WRPAC, e la Federation Trust Chain utilizzata nella challenge openid-federation-01. Gli attributi del certificato provengono dal record dell'Entità nel Register.

8.3.3.3.2. Wallet-Relying Party Access Certificate Issuance: Outcome

Il WRPAC, emesso dalla WRPAC Certification Authority, che l'Entità utilizza per autenticarsi verso le Wallet Unit.

8.3.3.3.3. Wallet-Relying Party Access Certificate Issuance: Process

1. L'Entità richiede il WRPAC al servizio ACME della WRPAC Certification Authority, presentando le proprie certificate_signing_requests e autenticandosi con la propria Federation Trust Chain, validata come in Federation Entity Authentication.

2. La Certification Authority verifica che l'Entità abbia un record nel Register e deriva gli attributi del certificato da tale record.

3. La Certification Authority emette il WRPAC e l'Entità lo recupera.

8.3.3.4. Wallet-Relying Party Registration Certificate Issuance

Il Wallet-Relying Party Registration Certificate Issuance emette il WRPRC, descritto nel Wallet-Relying Party Registration Certificate (WRPRC) Profile. Il Provider of WRPRC DEVE emettere un solo WRPRC automaticamente e senza indebito ritardo, senza una richiesta dell'Entità. Il Provider of WRPRC lo fa una volta che l'Entità ha un record con uno stato di registrazione valido nel Register e un WRPAC valido. Ciò è richiesto da [EIDAS-ARF] RPRC_09 e RPRC_13 e dall'Annex V, punto 3(c) di [CIR2025/848] come modificato da [CIR2026/1730]. Il Provider of WRPRC monitora il Register, secondo [CIR2025/848], revoca il WRPRC quando la registrazione dell'Entità cambia, e DEVE riemettere automaticamente un nuovo WRPRC ove la registrazione resti valida.

Un WRPRC distinto per ciascuna combinazione di intended use e Relying Party Service, e un WRPRC distinto per ciascun Service registrato di un PID o Attestation Provider, sono rinviati come specificato in Register of WRPs. Un Intermediario di Relying Party che non dichiara intended use non riceve un WRPRC proprio. La Wallet Unit fa affidamento sul WRPRC della Relying Party intermediata.

8.3.3.4.1. Wallet-Relying Party Registration Certificate Issuance: Input

Il record firmato dell'Entità nel Register e il suo WRPAC valido. Gli attributi del certificato provengono da tale record.

8.3.3.4.2. Wallet-Relying Party Registration Certificate Issuance: Outcome

Il WRPRC, firmato dal Provider of WRPRC con il proprio Sign/Seal Certificate ed emesso all'Entità, che l'Entità presenta alle Wallet Unit insieme ai propri dati di registrazione.

8.3.3.4.3. Wallet-Relying Party Registration Certificate Issuance: Process

1. Il Provider of WRPRC è invocato senza una richiesta dell'Entità quando un WRPAC valido diventa disponibile, o quando il record del Register cambia dopo che il WRPRC precedente è stato revocato.

2. Il Provider of WRPRC verifica che l'Entità abbia un record con uno stato di registrazione valido nel Register. Il Provider of WRPRC verifica che le informazioni recate dal certificato siano coerenti con tale record. Il Provider of WRPRC verifica che il WRPAC dell'Entità sia valido, come richiesto dall'Annex V, punto 3(c) di [CIR2025/848].

3. Il Provider of WRPRC costruisce il WRPRC dal record dell'Entità nel Register e lo firma con il proprio Sign/Seal Certificate, emesso dalla WRPRC Sign/Seal Certification Authority.

4. Il Provider of WRPRC emette il WRPRC all'Entità.

5. Il Provider of WRPRC monitora qualsiasi modifica del Register in modo automatizzato. Il Provider of WRPRC revoca il WRPRC ove la registrazione dell'Entità sia modificata, sospesa o cancellata, o ove il contenuto del certificato non sia più coerente con il record, come richiesto dall'Annex V, punto 3(d) di [CIR2025/848]. La revoca è pubblicata tramite la Token Status List (WRPRC Profile). Ove la registrazione resti valida, il Provider of WRPRC DEVE riemettere un nuovo WRPRC senza indebito ritardo.

8.3.3.5. Signature and Seal Certificate Issuance

Il Signature and Seal Certificate Issuance copre i certificati emessi dalla PKI nazionale, ossia il Sign/Seal Certificate del PID Provider, del Fornitore di Wallet e dell'EAA Provider, tramite il meccanismo di Issuance of the X.509 Certificates through ACME and OpenID Federation. Il Sign/Seal Certificate di un QEAA Provider e di un PuB-EAA Provider è un certificato qualificato emesso da un Qualified Trust Service Provider. Tale certificato è al di fuori della National Root e al di fuori di questo processo. Il suo status qualificato è valutato nell'eleggibilità, si veda Eligibility and Compliance Preconditions.

8.3.3.5.1. Signature and Seal Certificate Issuance: Input

Le certificate_signing_requests dell'Entità per il Sign/Seal Certificate, e la Federation Trust Chain utilizzata nella challenge openid-federation-01. Gli attributi del certificato provengono dal record dell'Entità nel Register o, in sua assenza, dal Trust Mark di registrazione.

8.3.3.5.2. Signature and Seal Certificate Issuance: Outcome

Il Sign/Seal Certificate, emesso dalla Certification Authority del ruolo dell'Entità, che l'Entità utilizza per firmare o sigillare gli Attestati che emette.

8.3.3.5.3. Signature and Seal Certificate Issuance: Process

1. L'Entità richiede il Sign/Seal Certificate al servizio ACME della Certification Authority del proprio ruolo, presentando le proprie certificate_signing_requests e autenticandosi con la propria Federation Trust Chain, validata come in Federation Entity Authentication.

2. La Certification Authority applica la propria policy, leggendo gli attributi dal record nel Register o, in sua assenza, dal Trust Mark di registrazione.

3. La Certification Authority emette il Sign/Seal Certificate e l'Entità lo recupera.

8.3.3.6. National Authentication Certificate Issuance

Il processo National Authentication Certificate Issuance emette il certificato X.509 che una Relying Party utilizza per autenticarsi nel Proximity Flow, tramite l'mdoc reader authentication di [ISO18013-5]. Il certificato segue lo stesso profilo del WRPAC, ed è emesso dalla National Authentication Certification Authority, tramite il meccanismo di Issuance of the X.509 Certificates through ACME and OpenID Federation.

8.3.3.6.1. National Authentication Certificate Issuance: Input

Le certificate_signing_requests dell'Entità per il National Authentication Certificate, e la Federation Trust Chain utilizzata nella challenge openid-federation-01.

8.3.3.6.2. National Authentication Certificate Issuance: Outcome

Il National Authentication Certificate, emesso dalla National Authentication Certification Authority, che l'Entità utilizza per autenticarsi nel Proximity Flow.

8.3.3.6.3. National Authentication Certificate Issuance: Process

1. L'Entità richiede il certificato al servizio ACME della National Authentication Certification Authority, presentando le proprie certificate_signing_requests e autenticandosi con la propria Federation Trust Chain, validata come in Federation Entity Authentication.

2. La Certification Authority applica la propria policy, leggendo gli attributi dal record nel Register o, in sua assenza, dal Trust Mark di registrazione.

3. La Certification Authority emette il National Authentication Certificate e l'Entità lo recupera.

8.3.3.7. Registration Trust Mark Issuance

Il Registration Trust Mark Issuance emette il Trust Mark di registrazione, definito in Trust Mark registration-entity. Il Trust Mark è emesso durante la registrazione dell'Entità e non tramite ACME, ed è invocato dall'Entity Registration al completamento della registrazione di federazione.

8.3.3.7.1. Registration Trust Mark Issuance: Input

I dati di autorizzazione dell'Entità: i suoi entitlement e, ove applicabile, le Credenziali e gli attributi che è autorizzata a emettere o a richiedere, seguendo la logica di [ETSI TS 119 475].

8.3.3.7.2. Registration Trust Mark Issuance: Outcome

Il Trust Mark di registrazione, emesso dal Federation Trust Anchor e recato nel Subordinate Statement sull'Entità. Rende l'Entità riconoscibile come partecipante registrato del National Trust Framework, ed è la fonte dei dati di autorizzazione quando l'Entità non ha un record nel Register.

8.3.3.7.3. Registration Trust Mark Issuance: Process

1. Al completamento della registrazione di federazione, il National Federation Management costruisce il Trust Mark di registrazione con i dati di autorizzazione dell'Entità.

2. Il Federation Trust Anchor firma il Trust Mark, che è recato nel Subordinate Statement, come descritto in Entity Registration.

8.3.4. Attestation Onboarding

Questa sezione descrive i processi che gestiscono i claim, gli schema e i tipi di Credenziale. Ciascun processo è descritto con il proprio Input, il proprio Outcome e il proprio Process.

8.3.4.1. Claim Registration

Il Claim Registration aggiunge una definizione di claim standardizzata al Claims Registry, quando un claim di cui una Fonte Autentica o un tipo di Credenziale ha bisogno non è ancora disponibile. Il Claims Registry è mantenuto dall'Organismo di Supervisione e fornisce definizioni semantiche degli attributi delle Credenziali, quali il loro tipo di dato, le loro regole di validazione e i loro mapping di interoperabilità. Le definizioni dei claim sono allineate al Catalogue of Attributes. Questo processo abilita lo Schema Provisioning e il Credential Type Registration che utilizzano il claim.

8.3.4.1.1. Claim Registration: Input

L'input è la definizione del claim da registrare, secondo i Claim Entry Parameters del Claims Registry. La definizione comprende il nome canonico del claim, la sua descrizione e il suo type (string, boolean, array o object). Comprende il format e l'encoding utilizzati quando una stringa reca un valore qualificato. Comprende gli aliases che mappano i nomi alternativi utilizzati in altri standard sul claim canonico. Comprende la struttura nidificata di un claim object o array. Il nome canonico e gli alias sono allineati al Catalogue of Attributes. Un claim è una definizione semantica e non un'Entità, quindi l'input non è costituito da dati di registrazione e non segue un profilo del Registration Data Model. I campi a livello di registro, ossia l'identificativo del registro, la sua versione, l'ora dell'ultima modifica e la sua configurazione di localizzazione, sono generati dal Claims and Schema Management.

8.3.4.1.2. Claim Registration: Outcome

L'esito è la definizione del claim nel Claims Registry, che le Fonti Autentiche, gli schema e i tipi di Credenziale possono referenziare. Un claim non è mai rimosso dal Claims Registry, perché le Credenziali già emesse continuano a referenziarlo, quindi un claim deprecato è sostituito da una nuova versione, come descritto in Claims and Schemas Lifecycle.

8.3.4.1.3. Claim Registration: Process

1. Un Attestation Scheme Provider, durante un Credential Type Registration, o una Fonte Autentica che agisce come Attestation Scheme Provider, durante la propria Authentic Source Registration, richiedono un nuovo claim non ancora presente nel Claims Registry.

2. La definizione del claim è stabilita con il suo nome canonico, il suo type, il suo format, i suoi aliases e la sua struttura nidificata. La definizione è allineata al Catalogue of Attributes e senza conflitti con i claim già registrati.

3. Il Claims and Schema Management registra la definizione nel Claims Registry.

4. Il claim diventa disponibile e abilita lo Schema Provisioning e il Credential Type Registration che lo utilizzano.

8.3.4.2. Schema Provisioning

Lo Schema Provisioning rende disponibile lo schema di un tipo di Credenziale nello Schema Registry. Lo schema è generato dal data model per le Credenziali definite a livello nazionale, oppure è registrato in allineamento con un Rulebook o uno standard esterno. Lo schema è uno dei requisiti per l'attivazione di un tipo di Credenziale, quindi questo processo è una precondizione di Credential Type Activation and Deactivation.

8.3.4.2.1. Schema Provisioning: Input

Lo schema del tipo di Credenziale è uno SchemaMeta registrato tramite il Catalogo delle Attestazioni: la sua version, i supportedFormats, il documento di schema specifico del formato a schemaURIs[].uri e il rulebookURI. Il documento specifico del formato segue la Section 4.3.4 di [EUDI-TS 11]. L'integrità, quando usata, è il suffisso #integrity di tale URI come definito in [W3C-SRI]. Lo schema è fornito dall'Attestation Scheme Provider insieme alla definizione del tipo di Credenziale, ed è composto dai claim definiti in Claims Registry. Un claim ancora mancante attiva il Claim Registration.

8.3.4.2.2. Schema Provisioning: Outcome

L'esito è lo schema nello Schema Registry, per almeno uno dei formati supportati, che il tipo di Credenziale referenzia. Ciò soddisfa il requisito di schema dell'attivazione del tipo di Credenziale, come descritto in Credential Type Activation and Deactivation.

8.3.4.2.3. Schema Provisioning: Process

1. I claim che compongono lo schema sono disponibili nel Claims Registry, altrimenti il Claim Registration è attivato per il claim mancante.

2. Lo schema è generato dal data model per una Credenziale definita a livello nazionale, oppure è registrato in allineamento con il Rulebook esterno.

3. Il Claims and Schema Management registra uno SchemaMeta nel Catalogue of Attestations, che copre ogni formato supportato.

8.3.4.3. Credential Type Registration

Il processo Credential Type Registration crea una voce versionata di un tipo di Credenziale nel Digital Credentials Catalog, nello stato INACTIVE, con la propria fonte dati e il riferimento al Rulebook applicabile. La voce versionata è la coppia data dal credential_type e dalla version, che DEVE essere univoca nel catalogo. Il processo è richiesto dall'Attestation Scheme Provider del tipo di Credenziale, ed è indipendente dalla registrazione dei Credential Issuer, che sono aggiunti alla voce in un momento successivo.

8.3.4.3.1. Credential Type Registration: Input

La definizione del tipo di Credenziale è fornita tramite i dati di definizione del tipo di Credenziale definiti in Registration Data Model. Tali dati sono la credential_type_declaration, la credential_technical_specification, le credential_policies, il rulebookURI, il bindingType, l'attestationLoS e i trustedAuthorities. La definizione reca il credential_type, i metodi di autenticazione dell'Utente e il Livello di Garanzia minimo. Reca il riferimento agli schema e ai formati e il riferimento al Rulebook. La fonte dati è data da una o più authentic_sources o, quando un altro tipo di Credenziale fornisce i dati, da una o più parent_credentials. La struttura della voce versionata è definita in Digital Credentials Catalog Structure.

L'input è fornito dall'Attestation Scheme Provider, che possiede l'Attestation Rulebook del tipo di Credenziale e ne trae i valori, si veda System Actors and Roles. La definizione del Rulebook è esterna al Sistema di Onboarding ed è una precondizione di questo processo, come elencato in Process Dependency Map. Questo processo registra in forma strutturata ciò che il Rulebook già definisce in forma leggibile.

8.3.4.3.2. Credential Type Registration: Outcome

Una voce versionata del tipo di Credenziale nel Digital Credentials Catalog, nello stato INACTIVE quando non ha ancora issuers. Abilita il Credential Type Activation and Deactivation, la dichiarazione del tipo di Credenziale da parte di un Credential Issuer in sede di Entity Registration e, per le categorie notificate, la Notification and Publication.

8.3.4.3.3. Credential Type Registration: Process

1. L'Attestation Scheme Provider richiede la registrazione del tipo di Credenziale. L'Attestation Scheme Provider fornisce la definizione tratta dal Rulebook applicabile, insieme al riferimento allo schema nello Schema Registry e alla fonte dati (le authentic_sources o le parent_credentials).

2. L'Organismo di Supervisione verifica la richiesta e approva il tipo di Credenziale, come descritto in Eligibility and Compliance Preconditions.

3. Il Catalog Management crea la voce versionata nel Digital Credentials Catalog nello stato INACTIVE, e il Federation Trust Anchor pubblica il catalogo firmato.

4. La voce versionata è attivata quando le condizioni di Credential Type Activation and Deactivation sono soddisfatte.

La voce versionata esiste quindi prima che qualsiasi Credential Issuer sia elencato in essa, e questo rende disponibile l'identificativo del tipo di Credenziale. Un Credential Issuer DEVE dichiarare i tipi di Credenziale che intende emettere al momento della propria Entity Registration, e questa dichiarazione lo aggiunge al campo issuers della voce versionata.

Nota

Il campo issuers non è mai fornito come input di questo processo. Ciascuno dei suoi elementi deriva dai provided_attestations che un Credential Issuer dichiara nei propri dati di registrazione, quindi un tipo di Credenziale è registrato indipendentemente dai Credential Issuer e resta registrato quando essi cambiano. La fornitura dell'intera voce versionata è sintetizzata in Digital Credentials Catalog Usage.

8.3.4.4. Credential Type Activation and Deactivation

Il processo Credential Type Activation and Deactivation verifica le condizioni per l'emissione di un tipo di Credenziale e cambia la sua voce versionata tra gli stati ACTIVE e INACTIVE. Un tipo di Credenziale può essere emesso da una voce versionata solo se tale voce è ACTIVE, e una sola voce versionata dello stesso credential_type DEVE essere ACTIVE in un dato momento.

8.3.4.4.1. Credential Type Activation and Deactivation: Input

Lo stato delle tre condizioni della voce versionata, ossia i suoi issuers, la sua fonte dati e il suo schema.

8.3.4.4.2. Credential Type Activation and Deactivation: Outcome

La voce versionata è ACTIVE finché tutte e tre le condizioni sono soddisfatte, e passa a INACTIVE non appena una di esse cessa di valere, come definito in Digital Credentials Catalog Structure. La disattivazione impedisce una nuova emissione dalla voce versionata, ma non revoca le Credenziali già emesse da essa, che conservano il proprio stato, come descritto in Ciclo di Vita degli Attestati Elettronici.

8.3.4.4.3. Credential Type Activation and Deactivation: Process

1. Il Catalog Management verifica le tre condizioni della voce versionata, consultando i registri corrispondenti.

   • Almeno un Credential Issuer è elencato nel campo issuers, e ciascuno di essi detiene l'entitlement corrispondente al legal_type del tipo di Credenziale.

   • La Fonte Autentica che fornisce i dati, o il tipo di Credenziale padre, è registrata e disponibile. Per una Fonte Autentica integrata tramite PDND, l'e-Service è pubblicato e l'enrolment del Credential Issuer è approvato, come descritto in Authentic Source Lifecycle and PDND Alignment.

   • Lo schema del tipo di Credenziale è registrato nello Schema Registry per almeno uno dei formati supportati.

2. La voce versionata diventa ACTIVE quando tutte e tre le condizioni sono soddisfatte, e torna a INACTIVE non appena una di esse cessa di valere. Lo stato segue le condizioni e non è un'azione esplicita.

8.3.4.5. Credential Type Update

Il Credential Type Update pubblica una nuova versione di un tipo di Credenziale, attivando la nuova voce versionata e disattivando la precedente. Un tipo di Credenziale non è mai modificato in place, quindi una modifica della sua definizione diventa una nuova voce versionata, con una nuova version.

8.3.4.5.1. Credential Type Update: Input

La definizione aggiornata del tipo di Credenziale, fornita dall'Attestation Scheme Provider come per il Credential Type Registration, con una nuova version.

8.3.4.5.2. Credential Type Update: Outcome

Una nuova voce versionata del tipo di Credenziale, attivata quando le sue condizioni sono soddisfatte, mentre la voce versionata della versione precedente DEVE diventare INACTIVE. Le Credenziali già emesse dalla versione precedente conservano il proprio stato e non sono revocate dal versionamento, e il Credential Issuer può guidarne la riemissione, come descritto in Ciclo di Vita degli Attestati Elettronici.

8.3.4.5.3. Credential Type Update: Process

1. L'Attestation Scheme Provider pubblica una nuova versione dell'Attestation Rulebook, o la definizione del tipo di Credenziale cambia per un altro motivo.

2. Il Catalog Management registra una nuova voce versionata, con la nuova version, come nel Credential Type Registration.

3. La nuova voce versionata è attivata quando le condizioni di Credential Type Activation and Deactivation sono soddisfatte, e la voce versionata della versione precedente passa a INACTIVE.

8.4. Notification and Publication

Questa Sezione descrive la notifica alla Commissione Europea delle entità che ne sono soggette, e la conseguente pubblicazione nelle Lists of Trusted Entities. La presentazione è un atto dello Stato membro (tramite il Single Point Of Contact). La pubblicazione è un atto della Commissione Europea. La notifica non è uno dei Onboarding Processes. Il Sistema di Onboarding gestisce solo la raccolta e il mantenimento delle informazioni notificabili.

All'interno di IT-Wallet l'Organismo di Supervisione è il National Single Point Of Contact con la Commissione e si avvale del Registrar per le entità che il Registrar registra. Il suo esito è l'inclusione dell'entità nella List of Trusted Entities del proprio tipo, la cui struttura e firma sono descritte in Trusted List, Lists of Trusted Lists, and Lists of Trusted Entities.

Le categorie soggette a notifica secondo gli Articoli 4 e 5 di [CIR2024/2980], adottato ai sensi dell'Articolo 5a(23) di [EIDAS], sono le seguenti:

• Fornitori di Wallet.

• PID Provider.

• Provider of WRPAC.

• Provider of WRPRC, ove applicabile.

• Registrar delle Wallet-Relying Party, insieme ai registri.

I PuB-EAA Provider sono notificati ai sensi dell'Articolo 45f(3) di [EIDAS], e le regole di dettaglio sono stabilite in [CIR2025/1569]. Le Wallet-Relying Party che non appartengono a una categoria notificata non sono notificate individualmente, e sono rese disponibili tramite il loro registro.

8.4.1. Notification and Publication: Input

L'input è costituito dalle informazioni notificabili dell'entità. Tali informazioni sono il sottoinsieme dei suoi dati di registrazione che si applica alla categoria. Il sottoinsieme è definito dall'Annex II di [CIR2024/2980] e, per i PuB-EAA Provider, dall'Annex III di [CIR2025/1569]. Le informazioni sono una proiezione del Registration Data Model:

• legal_name.

• identifier.

• contact_information.

• service_policies.

• signing_trust_anchor.

• conformity_assessment.

Per un PID Provider e un Fornitore di Wallet il Sign/Seal Certificate è emesso dalla PKI nazionale, quindi il signing_trust_anchor non è fornito come input dall'entità ma deriva dall'emissione descritta in Signature and Seal Certificate Issuance.

Per un PuB-EAA Provider il Sign/Seal Certificate è un certificato qualificato emesso da un Qualified Trust Service Provider. Il suo Trust Anchor è veicolato dalle eIDAS Trusted Lists che sono al di fuori di questo processo. Pertanto, il Sign/Seal Trust Anchor non è richiesto come input per un PuB-EAA Provider. Lo status qualificato del suo certificato è valutato nella valutazione di conformità richiesta per l'eleggibilità e la conformità, si veda Eligibility and Compliance Preconditions.

Le informazioni notificabili sono raccolte nel dataset di notifica, che è mantenuto distinto dal Register come descritto in Trust Artifacts Registration Outcomes. Il dataset è scritto e mantenuto aggiornato dal Notification Dataset Management durante Entity Registration, Entity Update e Entity Suspension and Removal.

Nota

Il Sign/Seal Trust Anchor non è il certificato che l'entità utilizza per firmare, la cui chiave pubblica è veicolata dalle certificate_signing_requests.

8.4.2. Notification and Publication: Outcome

L'esito è l'inclusione dell'entità nella List of Trusted Entities del proprio tipo. L'inclusione è l'asserzione, a livello UE, del ruolo e dell'autorizzazione dell'entità. L'inclusione consente a una Wallet Unit o a una Wallet-Relying Party di un altro Stato membro di validare l'entità.

8.4.3. Notification and Publication: Process

1. L'entità DEVE aver completato la propria Entity Registration. Per le categorie notificate la valutazione di conformità DEVE essere stata verificata come descritto in Eligibility and Compliance Preconditions. Il completamento della registrazione è la precondizione della notifica.

2. Il Sistema di Onboarding raccoglie le informazioni notificabili della categoria dal dataset di notifica, seguendo l'Annex II di [CIR2024/2980] o, per i PuB-EAA Provider, l'Annex III di [CIR2025/1569].

3. L'Organismo di Supervisione, in qualità di National Single Point Of Contact, presenta le informazioni al sistema elettronico sicuro di notifica che la Commissione mette a disposizione. La presentazione DEVE essere effettuata almeno in inglese. Il sistema e i suoi requisiti sono definiti nell'Annex I di [CIR2024/2980].

4. La Commissione PUÒ richiedere informazioni aggiuntive o chiarimenti per verificare la completezza e la coerenza delle informazioni notificate.

5. La Commissione pubblica la List of Trusted Entities che compila le informazioni notificate. L'entità compare nella List of Trusted Entities del proprio tipo, il cui data model, formato e firma sono descritti in Trusted List, Lists of Trusted Lists, and Lists of Trusted Entities.

6. Ove la registrazione dell'entità cambi, in particolare ove sia sospesa o cancellata, il Sistema di Onboarding DEVE riflettere la modifica nel dataset di notifica.

Nota

Le Lists of Trusted Entities definite da [CIR2024/2980] e le Trusted Lists definite da [CID2015/1505] sono descritte in Trusted List, Lists of Trusted Lists, and Lists of Trusted Entities.

8.5. Lifecycle Management

Dopo l'evento di registrazione, un'Entità può essere aggiornata, sospesa, riattivata o cancellata. Un tipo di Credenziale può diventare emettibile o cessare di esserlo. Queste modifiche si riflettono sui Trust Artifact e sui registri.

Questa sezione descrive gli stati e gli eventi che causano il cambiamento di stato di un'entità o di un tipo di Credenziale. Mappa inoltre ciascun evento sui registri e sui Trust Artifact impattati dall'evento, si veda Events, Registries and Trust Artifacts.

I formati, i parametri e gli stati dei Trust Artifact sono definiti in Trust Artifacts Lifecycle State Machine, e i meccanismi di revoca sono definiti in Revocation Mechanisms. Il ciclo di vita dei singoli Attestati Elettronici emessi agli Utenti è una materia distinta ed è definito in Ciclo di Vita degli Attestati Elettronici.

8.5.1. Entity Lifecycle State Machine

Questa sezione si applica alle WRP e ai WP in quanto direttamente coinvolti nelle fasi operative. Come mostrato in Fig. 8.3, un'Entità ha cinque stati distinti e mutuamente esclusivi: UNREGISTERED, REGISTERED, OPERATIONAL, SUSPENDED e CANCELLED. Ciascuno stato determina il livello di autorizzazione e le capacità operative dell'Entità.

Fig. 8.3 Entity Lifecycle States.

8.5.1.1. Transition from UNREGISTERED to REGISTERED

• UNREGISTERED: l'Entità non detiene una registrazione valida all'interno dell'ecosistema IT-Wallet. Questo è lo stato di base predefinito. Le Entità in questo stato sono al di fuori del perimetro di trust e NON DEVONO partecipare ad alcuna operazione.

• REGISTERED: l'Entità ha completato il processo di registrazione e la sua identità è stata verificata.

  • EUDIW Trust Framework: le WRP sono nello stato REGISTERED quando le loro informazioni sono state aggiunte al Register. I Fornitori di Wallet diventano REGISTERED quando i record di certificazione e di onboarding sono stati raccolti e verificati.

  • National Trust Framework: le WRP e i Fornitori di Wallet sono nello stato REGISTERED quando i record di onboarding sono stati raccolti e verificati.

8.5.1.2. Transition from REGISTERED to OPERATIONAL

OPERATIONAL indica che l'Entità è stata autorizzata a eseguire le operazioni relative al proprio ruolo.

• EUDIW Trust Framework: le WRP sono OPERATIONAL se erano REGISTERED e hanno ottenuto un WRPAC, i corrispondenti WRPRC e, a seconda del ruolo, un Sign/Seal Certificate. Il signing Trust Anchor di tale certificato DEVE essere stato aggiunto alla LoTE o alla EUMS TL. I Fornitori di Wallet sono OPERATIONAL se erano REGISTERED e hanno ottenuto un Sign/Seal Certificate il cui signing Trust Anchor è stato aggiunto alla LoTE.

• National Trust Framework: le WRP e i Fornitori di Wallet sono OPERATIONAL se erano REGISTERED. Hanno ottenuto i Sign/Seal Certificate e i Trust Mark di registrazione. Il loro Subordinate Statement è stato pubblicato dalla Federation Authority.

8.5.1.3. Transition from OPERATIONAL to REGISTERED

Un'Entità torna a REGISTERED quando non detiene più Trust Artifact validi. Ciò può essere innescato dalla loro scadenza o revoca a seguito di un aggiornamento dell'Entità. Per tornare a OPERATIONAL è richiesta una nuova emissione dei Trust Artifact.

8.5.1.4. Transition from REGISTERED or OPERATIONAL to SUSPENDED

SUSPENDED indica che la registrazione non è temporaneamente valida. A differenza della cancellazione, la sospensione è reversibile. Una WRP la cui registrazione è sospesa NON DEVE emettere Credenziali alle Wallet Unit. Tale WRP NON DEVE richiedere attributi dalle Wallet Unit. Le Credenziali che tale WRP ha emesso non sono accettate dalle Relying Party, come descritto nella Section 4.6.5 di [EIDAS-ARF].

Gli eventi che conducono a questo stato, e le parti titolate a deciderli, sono elencati in Registration Events and Their Governance.

8.5.1.5. Transition from SUSPENDED to REGISTERED

La sospensione può essere revocata dalla stessa parte che l'ha decisa. Poiché i Trust Artifact interessati dalla sospensione sono stati revocati, l'Entità torna a REGISTERED e non direttamente a OPERATIONAL. È richiesta una nuova emissione dei Trust Artifact per tornare OPERATIONAL.

8.5.1.6. Transition from REGISTERED, OPERATIONAL or SUSPENDED to CANCELLED

CANCELLED indica che la registrazione è cessata. Lo stato è lo stesso sia che la cancellazione sia stata richiesta dall'Entità stessa sia che sia stata decisa dall'autorità competente, e differisce solo l'evento innescante.

• EUDIW Trust Framework: per le WRP la cancellazione comporta la revoca del WRPAC, del WRPRC e, ove applicabile, dei Sign/Seal Certificate. La cancellazione comporta la rimozione della voce dal Register. La cancellazione comporta l'aggiornamento dello stato del signing Trust Anchor nella LoTE o nella EUMS TL. Per i Fornitori di Wallet comporta l'aggiornamento della Wallet Providers LoTE.

• National Trust Framework: sia per le WRP sia per i Fornitori di Wallet comporta la rimozione del Subordinate Statement e del Trust Mark di registrazione, e la revoca dei National X509 Certificates.

Un'Entità DEVE rifiutare nuove interazioni o transazioni avviate da un'Entità CANCELLED. Tutte le chiavi crittografiche, gli attestati attivi e le capacità operative associate all'Entità DEVONO essere revocati. Le Entità POSSONO tuttavia continuare a validare dati storici, firme e Credenziali generate prima del timestamp di cancellazione, soggette alle policy di rischio locali. Un'Entità in stato CANCELLED che vuole partecipare nuovamente all'ecosistema DEVE completare una nuova registrazione.

Nota

La Section 4.6.5 di [EIDAS-ARF] descrive per i PID Provider e gli Attestation Provider gli stati Registered, Suspended e Cancelled. All'interno di IT-Wallet lo stato Registered è suddiviso in REGISTERED e OPERATIONAL, per distinguere il momento in cui il record di registrazione esiste dal momento in cui l'Entità detiene tutti i Trust Artifact di cui ha bisogno per operare.

Nota

Il ciclo di vita delle Fonti Autentiche e delle Entità dell'infrastruttura di trust, quali il Registrar e i Provider of WRPAC e of WRPRC, non è definito in questa sezione. Le Fonti Autentiche seguono il framework PDND, e gli effetti che il loro ciclo di vita produce all'interno di IT-Wallet sono descritti in Authentic Source Lifecycle and PDND Alignment.

8.5.2. Registration Events and Their Governance

Ogni transizione della state machine delle Entità è causata da un evento. Per ciascun evento, questa sezione indica chi è titolato a innescare, chi ne è responsabile e, quando applicabile, su quale base normativa e entro quali condizioni. Gli eventi che riguardano i tipi di Credenziale e le Fonti Autentiche sono descritti nelle sezioni dedicate seguenti.

Tabella 8.13 Registration Events

Event	Trigger	Responsible	Normative reference	Condition
Registration	Richiesta dell'Entità, dopo la verifica delle condizioni di eleggibilità applicabili al proprio ruolo.	Registrar, per la voce del Register. Federation Authority, per la registrazione di federazione.	Articoli 5 e 6 di [CIR2025/848].	Non definito.
Update	Modifica delle informazioni registrate. La WRP è responsabile dell'accuratezza delle proprie informazioni e le aggiorna.	Registrar, per la voce del Register. Federation Authority, per il Subordinate Statement e il Trust Mark di registrazione.	Articolo 5(2) e 5(3) di [CIR2025/848].	Senza indebito ritardo.
Suspension	Richiesta di un Organismo di Supervisione, richiesta della WRP stessa, o iniziativa del Registrar nei casi elencati dopo questa tabella.	Registrar per il Trust Framework EUDIW, Federation Authority per il National Trust Framework.	Articolo 9(1), 9(2), 9(3) e 9(5) di [CIR2025/848].	Informazione della WRP e dei Provider dei suoi certificati entro 24 ore.
Reactivation	Rimozione della condizione che ha causato la sospensione.	La stessa parte che ha deciso la sospensione.	Section 4.6.5 di [EIDAS-ARF].	Non definito.
Cancellation	Richiesta di un Organismo di Supervisione, richiesta della WRP stessa compreso quando non intende più fare affidamento sulle Wallet Unit, o iniziativa del Registrar nei casi elencati dopo questa tabella.	Registrar per il Trust Framework EUDIW, Federation Authority per il National Trust Framework.	Articolo 9(1), 9(2), 9(3) e 9(5) di [CIR2025/848].	Informazione della WRP e dei Provider dei suoi certificati entro 24 ore.

Due ruoli eseguono un evento, uno per ciascun Trust Framework. All'interno del Trust Framework EUDIW il Registrar agisce sul Register e notifica i Provider dei Trust Artifact interessati. All'interno del National Trust Framework la Federation Authority agisce sul Subordinate Statement e sul Trust Mark di registrazione, e pubblica l'evento sul Federation Subordinate Events Endpoint. La decisione che innesca l'evento è la stessa per entrambi, ed è descritta di seguito con riferimento al Registrar, in quanto gli obblighi sono posti sul Registrar da [CIR2025/848].

Il Registrar DEVE sospendere o cancellare la registrazione di una WRP ove la sospensione o la cancellazione sia richiesta da un Organismo di Supervisione, e ove sia richiesta dalla stessa WRP. Il Registrar PUÒ sospendere o cancellare la registrazione di propria iniziativa ove:

• la registrazione contenga informazioni inesatte, non aggiornate o fuorvianti.

• la WRP non sia conforme alla policy di registrazione.

• la WRP stia richiedendo più attributi di quelli che ha registrato.

• la WRP stia altrimenti agendo in violazione del diritto dell'Unione o nazionale in un modo connesso al proprio ruolo.

Prima di sospendere o cancellare una registrazione di propria iniziativa, il Registrar DEVE condurre una valutazione di proporzionalità. La valutazione tiene conto dell'impatto sui diritti fondamentali, sulla privacy, sulla sicurezza e sulla riservatezza degli Utenti dell'ecosistema. La valutazione tiene conto della gravità della discontinuità causata dal provvedimento e dei costi associati, sia per la WRP sia per l'Utente.

Il Registrar DEVE informare la WRP e i rilevanti Provider of WRPAC e of WRPRC senza indebito ritardo. Il Registrar DEVE informare tali soggetti non oltre 24 ore dopo la sospensione o la cancellazione, come stabilito dall'Articolo 9(5) di [CIR2025/848]. L'informazione DEVE includere i motivi della sospensione o della cancellazione e i mezzi di ricorso o di appello disponibili. Dopo la notifica, i Provider DEVONO revocare i certificati interessati senza indebito ritardo, ove applicabile, come stabilito dall'Articolo 9(6) di [CIR2025/848].

Il Registrar DEVE conservare i record della registrazione, dei dati di emissione e delle modifiche per 10 anni. All'interno di IT-Wallet la stessa conservazione si applica alla Federation Authority per i record del National Trust Framework, per analogia.

Nota

Gli obblighi descritti sopra sono posti dagli Articoli 9 e 10 di [CIR2025/848] e si applicano al Registrar e alla registrazione delle WRP. All'interno di IT-Wallet l'obbligo di conservazione è esteso per analogia alla Federation Authority per i record che mantiene per il National Trust Framework, poiché [CIR2025/848] non disciplina il National Trust Framework. I Fornitori di Wallet non sono registrati come WRP, quindi la sospensione e la cancellazione di un Fornitore di Wallet conseguono dalla certificazione della propria Soluzione Wallet e dalla notifica, e non dall'Articolo 9.

Oltre all'Organismo di Supervisione, al Registrar e all'Entità stessa, una sospensione o una cancellazione di un'Entità PUÒ inoltre essere richiesta o innescata da altre parti esterne al Sistema di Onboarding. Esempi sono un'autorità giudiziaria, un'autorità amministrativa competente per l'Entità e un'autorità competente per la cybersicurezza. Ulteriori esempi sono un organismo di valutazione della conformità che ritira una certificazione, o lo Stato membro che ritira una notifica. In ogni caso la sospensione o la cancellazione è eseguita tramite i meccanismi descritti sopra. La Federation Authority che ha registrato l'Entità agisce sul suo Subordinate Statement e sul Trust Mark di registrazione. I Trust Artifact dell'Entità sono revocati. Per un'Entità registrata tramite un Federation Intermediate, il Subordinate Statement è servito dall'Intermediate. L'Intermediate ritira il Subordinate Statement per sospendere o cancellare l'Entità. Il Trust Mark di registrazione resta emesso dal Federation Trust Anchor. Il Federation Trust Anchor è responsabile di qualsiasi effetto sul ciclo di vita del Trust Mark di registrazione. La sospensione o la cancellazione di un Federation Intermediate DEVE propagarsi alle Entità affiliate, la cui Trust Chain passa attraverso di esso, come descritto in Federation Trust Chain.

Indipendentemente dalla notifica descritta sopra, i Provider of WRPAC e i Provider of WRPRC monitorano le modifiche nel Register su base continua. Tali Provider revocano o riemettono i certificati quando le modifiche lo richiedono. Per un WRPRC la riemissione è automatica, come definito in Wallet-Relying Party Registration Certificate Issuance. Ciò è stabilito dall'Annex IV di [CIR2025/848] per i Provider of WRPAC e dall'Annex V di [CIR2025/848] come modificato da [CIR2026/1730] per i Provider of WRPRC.

All'interno del National Trust Framework gli eventi che modificano la registrazione di un'Entità DEVONO essere pubblicati dalla Federation Authority come eventi firmati sul Federation Subordinate Events Endpoint (federation_subordinate_events_endpoint). Gli altri partecipanti possono così tracciare il ciclo di vita di un'Entità nel tempo. L'endpoint e il formato della sua risposta sono descritti in Federation API Endpoints.

Ciascun evento della state machine DEVE essere pubblicato come un oggetto dell'array federation_registration_events, utilizzando i tipi di evento definiti in [OID-FED-SUBORDINATE-EVENTS]. La tabella seguente fornisce, per ciascun evento, il valore del parametro event e come i parametri dell'oggetto evento sono popolati.

Tabella 8.14 Mapping of the Lifecycle Events to the Subordinate Events

Lifecycle event	event	iat	event_description
Registration	registration	Orario a cui la registrazione è relativa.	Non utilizzato.
Update of Identity Information or Technical Configuration	metadata_update	Orario a cui l'aggiornamento è relativo.	PUÒ essere utilizzato per fornire ulteriori dettagli sull'aggiornamento.
Key rotation/update of a Federation Entity Key	jwks_update	Orario a cui la rotazione/aggiornamento della chiave è relativo.	Non utilizzato.
Suspension	suspension	Orario a cui la sospensione è relativa.	PUÒ essere utilizzato per fornire ulteriori dettagli sulla sospensione.
Cancellation	revocation	Orario a cui la cancellazione è relativa.	PUÒ essere utilizzato per fornire ulteriori dettagli sulla revoca.

Quando è presente un evento registration, gli eventi metadata_update e jwks_update NON DEVONO essere forniti contemporaneamente. Si assume che la registrazione configuri lo stato iniziale dell'Entità, come specificato in [OID-FED-SUBORDINATE-EVENTS].

8.5.3. Entity Updates and Their Effects on Trust Artifacts

Le Entità sono caratterizzate da tre categorie principali di dati registrati.

• Identity Information: il nome dell'organizzazione, le informazioni di contatto e le policy organizzative.

• Technical Configuration: il materiale crittografico, ossia le chiavi di firma e sigillo e le chiavi di autenticazione, e gli endpoint tecnici necessari per le interazioni nell'ecosistema.

• Authorization Information: gli entitlement dell'Entità, le capacità di fornitura delle Credenziali e le capacità di richiesta degli attributi. Comprende anche i permessi di utilizzo dell'Intermediario, gli intended use, le embedded disclosure policy e la conformità agli schemi di certificazione.

L'infrastruttura del Trust Framework DEVE propagare queste modifiche ai Trust Artifact rilevanti. Gli effetti specifici dipendono dal ruolo dell'Entità e dai Trust Artifact che utilizza.

Le procedure che eseguono un aggiornamento, ossia ciò che l'Entità presenta e quali passi il Registrar, la Federation Authority e le Certificate Authority eseguono, sono descritte nel processo Entity Update. Questa sezione fornisce la relazione tra le categorie di dati registrati e i Trust Artifact che li contengono.

8.5.3.1. Registered Data and Associated Trust Artifact

La tabella seguente fornisce la relazione tra le categorie di dati registrati e i Trust Artifact in cui sono contenuti, per ciascun tipo di Entità.

Tabella 8.15 Entity Data and Trust Artifacts

Entity Type	Data Category	EUDIW Trust Artifacts	National Trust Artifacts
WRP (all)	Identity Information	Register, WRPAC, WRPRC, LoTE (solo per PID, PuB-EAA e non-qualified EAA Provider notificati)	Entity Configuration, Trust Mark di registrazione
WRP (all)	Technical Configuration (Authentication key)	WRPAC	Entity Configuration, Subordinate Statement
WRP (all)	Authorization Information (Entitlements, Intermediary, Service descriptions, Supervision information)	Register, WRPRC, LoTE (solo per PID, PuB-EAA e non-qualified EAA Provider notificati)	Entity Configuration, Trust Mark di registrazione
Credential Issuer or Wallet Provider	Technical Configuration (Signature/Seal key)	X.509 Sign/Seal Certificate	X.509 Sign/Seal Certificate
Credential Issuer or Wallet Provider	Technical Configuration (Metadata, Signature/Seal Trust Anchor)	LoTE	Trust Anchor Entity Configuration
Credential Issuer	Authorization Information (RP permissions)	EDP nei metadata del Credential Issuer	n/a
Credential Issuer	Authorization Information (Credential provision capabilities)	Register, WRPRC	Subordinate Statement, Trust Mark di registrazione
Relying Party or Relying Party Intermediary	Authorization Information (Attribute request capabilities)	Register, WRPRC	Subordinate Statement, Trust Mark di registrazione
Wallet Provider	Identity Information	LoTE	Entity Configuration, Trust Mark di registrazione
Wallet Provider	Authorization Information (Service status)	LoTE	Subordinate Statement, Trust Mark di registrazione

Nota

L'inclusione dei Fornitori di Wallet e dei Credential Issuer nella LoTE è un'asserzione implicita del loro ruolo e della loro autorizzazione all'interno dell'ecosistema. In particolare, la loro inclusione è il risultato del completamento con successo delle procedure di registrazione e notifica come definite in [CIR2025/848] per la registrazione delle WRP e in [CIR2024/2980] per la notifica delle WRP e dei Fornitori di Wallet. Analogamente, la possibilità di recuperare il Subordinate Statement di un'Entità significa che l'Entità fa attualmente parte dell'ecosistema nazionale.

Nota

Le QEAA sono fornite da Qualified Trust Service Provider. Le loro informazioni di identità, tecniche e di autorizzazione sono disponibili nella EUMS TL dedicata.

Le informazioni di identità, tecniche e di autorizzazione dei Registrar, dei Provider of WRPAC e dei Provider of WRPRC sono disponibili in LoTE dedicate.

8.5.4. Credential Type Lifecycle

Un tipo di Credenziale è registrato nel Digital Credentials Catalog come voce versionata. L'unione di credential_type e version DEVE essere univoca nel catalogo, come specificato in Digital Credentials Catalog Structure, quindi versioni diverse dello stesso tipo di Credenziale esistono nel catalogo come voci distinte.

Per questo motivo il ciclo di vita si applica alla singola voce versionata, ossia la coppia data da credential_type e version, e non al tipo di Credenziale nel suo insieme. Ciascuna voce versionata ha due stati, ACTIVE e INACTIVE, la cui semantica è definita in Digital Credentials Catalog Structure. In sintesi, un tipo di Credenziale può essere emesso da una voce versionata solo finché tale voce è ACTIVE.

Nota

Lo stato della voce versionata è una cosa distinta dallo stato dei singoli Attestati Elettronici emessi agli Utenti, che è definito in Ciclo di Vita degli Attestati Elettronici.

All'interno di IT-Wallet, una voce versionata è ACTIVE solo finché tutte le seguenti condizioni sono soddisfatte, e torna a INACTIVE non appena una di esse cessa di valere.

• Almeno un Credential Issuer è elencato nel campo issuers della voce, e ciascuno di essi detiene l'entitlement corrispondente al legal_type del tipo di Credenziale.

• La Fonte Autentica che fornisce i dati, o il tipo di Credenziale padre, è registrata e disponibile. Per una Fonte Autentica integrata tramite PDND, ciò significa che l'e-Service è pubblicato e che l'enrolment del Credential Issuer è stato approvato.

• Lo schema del tipo di Credenziale è registrato nello Schema Registry per almeno uno dei formati supportati.

Una sola voce versionata dello stesso tipo di Credenziale è ACTIVE in un dato momento.

8.5.4.1. Versioning

Un tipo di Credenziale non è mai modificato in place. Quando la sua definizione cambia, una nuova voce versionata è registrata e attivata, e la voce della versione precedente è portata a INACTIVE.

Le Credenziali già emesse dalla versione precedente conservano il proprio stato e non sono revocate dal versionamento. Ove il Credential Issuer necessiti che gli Utenti ottengano la nuova versione, il Credential Issuer può guidare la riemissione tramite lo stato 0x03 (UPDATE) o 0x0F (ATTRIBUTE_UPDATE) dei singoli Attestati Elettronici, come descritto in Ciclo di Vita degli Attestati Elettronici.

La registrazione di un tipo di Credenziale e il suo versionamento sono descritti nei processi di registrazione, e la struttura della voce di catalogo in Digital Credentials Catalog Structure.

Nota

Registrare prima il tipo di Credenziale, nello stato INACTIVE e senza Credential Issuer, rende disponibile l'identificativo del tipo di Credenziale prima della registrazione del Credential Issuer, in quanto DEVE dichiarare in sede di registrazione i tipi di Credenziale che intende emettere, e questa dichiarazione finisce nel Register e nel WRPRC.

Inoltre, il passaggio di una voce versionata a INACTIVE impedisce a qualsiasi Wallet Unit di richiedere una nuova emissione da tale voce. Non revoca le Credenziali già emesse da essa, che conservano il proprio stato. Ove il motivo che ha causato la disattivazione richieda anche la revoca delle Credenziali già emesse, la revoca è una decisione distinta, assunta dal Credential Issuer come descritto in Ciclo di Vita degli Attestati Elettronici.

8.5.5. Claims and Schemas Lifecycle

Come descritto sopra per l'aggiornamento del tipo di Credenziale, i claim e gli schema registrati nei rispettivi registri non sono rimossi. Le Credenziali già emesse continuano a referenziarli. Rimuovere un claim o uno schema renderebbe tali Credenziali impossibili da interpretare.

Quando un claim o uno schema è deprecato, ne viene registrata una nuova versione, e i tipi di Credenziale che lo utilizzano passano a una nuova versione come descritto sopra.

8.5.6. Authentic Source Lifecycle and PDND Alignment

Una Fonte Autentica non è una WRP e non è un'Entità di Federazione. La sua trust, la sua autorizzazione e i suoi aspetti operativi sono governati dal framework PDND, come descritto in e-Service PDND. IT-Wallet si affida a PDND per tutti essi. All'interno di IT-Wallet una Fonte Autentica è registrata solo nell'Authentic Source Registry, descritto in Authentic Source Registry, in modo che i Credential Issuer possano scoprire quali dati sono disponibili e tramite quale e-Service.

Per questo motivo il profilo implementativo di IT-Wallet non definisce un ciclo di vita delle Fonti Autentiche. Quanto questa sezione definisce è l'effetto che il ciclo di vita PDND produce all'interno di IT-Wallet, perché i tipi di Credenziale e i Credential Issuer dipendono da esso.

Quando una Fonte Autentica cessa di fornire, tramite PDND, i dati da cui un tipo di Credenziale dipende, la condizione per l'attivazione di tale tipo di Credenziale non è più soddisfatta. Esempi sono un e-Service non più pubblicato, o un enrolment del Credential Issuer che è stato ritirato. Il tipo di Credenziale DEVE essere portato a INACTIVE. Il tipo di Credenziale resta registrato e il suo identificativo resta valido, in modo che il tipo possa essere riattivato quando l'integrazione è ripristinata.

Il processo di allineamento non è automatico e opera in entrambe le direzioni.

• Da PDND a IT-Wallet, una Fonte Autentica che modifica la disponibilità di un e-Service utilizzato da un tipo di Credenziale DEVE notificare la modifica. Lo stato del tipo di Credenziale può così essere aggiornato.

• Da IT-Wallet a PDND, un Credential Issuer la cui registrazione è sospesa o cancellata DEVE notificare la modifica alla Fonte Autentica, che potrà quindi decidere di ritirare le corrispondenti autorizzazioni all'interno del framework PDND.

Avvertimento

La sospensione o la cancellazione di una registrazione in IT-Wallet non produce alcun effetto all'interno di PDND. Finché le autorizzazioni non sono ritirate sul lato PDND, un Credential Issuer la cui registrazione non è più valida può ancora ottenere un Voucher e accedere all'e-Service di una Fonte Autentica, anche se non può più emettere Credenziali alle Wallet Unit. All'interno di IT-Wallet la notifica è pertanto un obbligo del Credential Issuer e della Fonte Autentica.

8.5.7. Events, Registries and Trust Artifacts

La tabella seguente sintetizza, per ciascun evento, quali registri e cataloghi sono impattati e dove sono descritti gli effetti sui Trust Artifact. Copre sia la registrazione iniziale sia i successivi eventi di ciclo di vita. La relazione tra un aggiornamento di un'Entità e i Trust Artifact che incide è data in Entity Updates and Their Effects on Trust Artifacts, e i meccanismi tecnici che pubblicano lo stato di un Trust Artifact in Revocation Mechanisms.

Tabella 8.16 Events and Impacted Registries

Event	Decided by	Impacted registries and catalogs	Effects on Trust Artifacts
Registration of an Entity	Registrar, Federation Authority	Register (nuova voce). Notifica alla Commissione per le categorie notificate.	L'Entità ottiene i propri Trust Artifact, si veda Entity Data and Trust Artifacts.
Update of an Entity	Registrar, Federation Authority	Register (voce aggiornata).	A seconda della categoria di dati aggiornata, si veda Entity Data and Trust Artifacts.
Key rotation of an Entity	Certificate Authority, Provider of WRPAC, Federation Authority	Nessun registro è impattato, a meno che la chiave sia una chiave di Trust Anchor, nel qual caso la LoTE.	Revoca e riemissione del certificato che detiene la chiave, si veda Entity Data and Trust Artifacts.
Suspension of an Entity	Registrar, Federation Authority	Register (stato di registrazione non più valido). Aggiornamento della LoTE o della EUMS TL per le categorie notificate.	Revoca dei WRPAC, WRPRC e Trust Mark di registrazione interessati, e aggiornamento del Subordinate Statement.
Reactivation of an Entity	Registrar, Federation Authority	Register (stato di registrazione nuovamente valido). Aggiornamento della LoTE o della EUMS TL per le categorie notificate.	Nuova emissione dei Trust Artifact revocati al momento della sospensione.
Cancellation of an Entity	Registrar, Federation Authority	Register (voce rimossa). Aggiornamento della LoTE o della EUMS TL per le categorie notificate.	Revoca dei WRPAC, WRPRC e Sign/Seal Certificate, e rimozione del Subordinate Statement e del Trust Mark di registrazione.
Registration of a Credential type version	Organismo di Supervisione, pubblicato dal Federation Trust Anchor	Digital Credentials Catalog (nuova voce versionata, INACTIVE). Schema Registry, per lo schema della nuova versione.	Nessuno.
Activation or deactivation of a Credential type version	Organismo di Supervisione, pubblicato dal Federation Trust Anchor	Digital Credentials Catalog (stato della voce versionata).	Nessuno.
New version of a Credential type	Organismo di Supervisione, pubblicato dal Federation Trust Anchor	Digital Credentials Catalog (nuova voce versionata ACTIVE, voce versionata precedente INACTIVE). Schema Registry.	Nessuno.
Registration of a new claim or of a new schema	Organismo di Supervisione, pubblicato dal Federation Trust Anchor	Claims Registry o Schema Registry (nuova voce). Allineamento verso il Catalogue of Attributes o il Catalogue of Schemes.	Nessuno.
Registration of an Authentic Source	Organismo di Supervisione, pubblicato dal Federation Trust Anchor	Authentic Source Registry (nuova voce).	Nessuno.
Change of availability of an Authentic Source	Fonte Autentica, tramite PDND	Authentic Source Registry. Digital Credentials Catalog, per le voci versionate che dipendono da essa.	Nessuno.

Nota

La cancellazione di una registrazione è l'evento, mentre l'uscita completa di un'Entità dall'ecosistema, che copre entrambi i Trust Framework, è il processo Entity Removal descritto nei processi di onboarding. L'obbligo del Registrar di conservare i record per 10 anni sopravvive alla cancellazione, quindi la rimozione della voce dal Register non è una rimozione dei record di tale registrazione.

Nota

Il Register è un insieme di record per WRP, quindi un evento impatta solo il record dell'Entità interessata. L'Authentic Source Registry, il Claims Registry e la Taxonomy sono singoli documenti firmati, quindi ogni scrittura richiede una nuova firma e una nuova pubblicazione dell'intero documento. Il Digital Credentials Catalog è servito mediante risposte firmate in modo indipendente, come specificato in Digital Credentials Catalog Retrieval. Il Catalogue of Attestations è servito mediante risposte firmate in modo indipendente, come specificato in Catalogo delle Attestazioni.