6. Trust Evaluation Process

Ogni processo di trust evaluation coinvolge i seguenti ruoli:

• Il Trust Evaluator è la parte che esegue la valutazione.

• La Trust Evaluated Party è l'entità, o l'attestazione, che è oggetto della valutazione.

La stessa entità può agire in entrambi i ruoli in momenti diversi dei flussi. Le sezioni specifiche di ciascun framework definiscono quale entità agisce in quale ruolo, quando e per quale scopo.

Ciascun processo richiede come precondizione una radice di fiducia validata. Ciascun Trust Framework definisce come la propria radice di fiducia è istituita, distribuita e mantenuta. Nel Trust Framework Nazionale questa è il Federation Trust Anchor (vedere Federation Trust Anchor Distribution and Validation). Nel Trust Framework EUDIW queste sono i Trust Anchor ottenuti dalle Trusted List e dalle List of Trusted Entities applicabili (vedere List of Trusted Entities Validation).

I processi di trust evaluation sono i seguenti:

• Authentication. Attesta l'identità crittografica di un'entità che partecipa alla transazione. Il Trust Evaluator vincola l'identificatore della Trust Evaluated Party alla prova di possesso di una chiave privata la cui parte pubblica è fidata rispetto alla radice di fiducia applicabile.

• Authorization. Valuta un artifact di registrazione per attestare gli entitlement della Trust Evaluated Party, ossia le capacità specifiche che l'entità è autorizzata a eseguire, quali l'emissione di un dato tipo di Attestato o la richiesta di un dato insieme di attributi.

• Metadata Retrieval and Validation. Ottiene e valida la configurazione tecnica della Trust Evaluated Party, quali endpoint, chiavi pubbliche e algoritmi supportati.

• Signing Trust Anchor Validation. Prende in ingresso un'attestazione e produce la radice di fiducia validata, l'identificatore e la chiave pubblica, da utilizzare per la verifica della issuer data authentication di tale attestazione.

I primi tre processi hanno come oggetto un'entità. Il quarto ha come oggetto un'attestazione e questo include gli Attestati Elettronici e la Wallet Instance Attestation.

6.1. Trust Framework Selection

Questa sezione definisce quale Trust Framework si applica a un'interazione. I due Trust Framework sono descritti in Infrastructure of Trust. Le procedure di ciascun framework sono definite nelle sezioni seguenti. I percorsi di onboarding e gli artifact di ciascun tipo di entità sono definiti in Onboarding Processes.

L'interazione è l'autenticazione e l'autorizzazione delle parti per un'emissione o una presentazione. La Wallet Unit DEVE selezionare esattamente un Trust Framework per ciascuna interazione, prima di Authentication, Authorization o Metadata Retrieval and Validation. Il Trust Framework selezionato si applica all'intera interazione. Una valutazione fallita è gestita come specificato in Failure Handling.

Il trust anchor di firma di un'attestazione segue il Rulebook del tipo di Attestato, in ogni fase e qualunque sia la parte che esegue la verifica. I PID, le QEAA e le PuB-EAA DEVONO essere validati rispetto ai Trust Anchor della List of Trusted Entities o della Trusted List applicabile (vedere OIA_12, OIA_13, OIA_14 e OIA_15 dell'ARF Annex 2, EIDAS-ARF). La procedura per un Attestato ancorato al Trust Framework Nazionale è definita in Signing Trust Anchor Validation Procedure.

La dichiarazione resa in onboarding da un Non-Qualified EAA Provider o da una Relying Party è specificata in Registration Profiles. A runtime l'Attestato richiesto seleziona il Trust Framework dell'interazione. Lo stesso Credential Issuer PUÒ essere valutato nell'ambito di framework diversi in interazioni diverse.

Ove la configurazione pubblicata attraverso i meccanismi EUDIW e la configurazione pubblicata attraverso la federazione divergono, la configurazione EUDIW DEVE prevalere.

Tabella 6.1 Trust Framework applicabile per interazione

Interazione	Condizione	Trust Framework
Emissione, Credential Issuer	L'Attestato richiesto è un PID, una QEAA o una PuB-EAA, oppure un Attestato Elettronico di Attributi non qualificato ancorato al Trust Framework EUDIW dal suo Rulebook, oppure il Credential Issuer è di un altro Stato membro.	La Wallet Unit DEVE usare il Trust Framework EUDIW.
Emissione, Credential Issuer	Il Credential Issuer è un'entità nazionale e l'Attestato richiesto è un Attestato Elettronico di Attributi non qualificato di ambito nazionale. L'IT-Wallet ID è un Attestato di questo tipo (vedere IT-Wallet ID).	La Wallet Unit DEVE usare il Trust Framework Nazionale.
Emissione, Wallet Instance Attestation	La Wallet Unit è di un altro Stato membro.	Il Credential Issuer DEVE validarla attraverso la Wallet Providers List of Trusted Entities.
Emissione, Wallet Instance Attestation	La Wallet Unit è nazionale e l'Attestato richiesto è un PID, una QEAA o una PuB-EAA, oppure un Attestato Elettronico di Attributi non qualificato ancorato al Trust Framework EUDIW dal suo Rulebook.	Il Credential Issuer DEVE validare la Wallet Instance Attestation attraverso la Wallet Providers List of Trusted Entities.
Emissione, Wallet Instance Attestation	La Wallet Unit è nazionale e l'Attestato richiesto è un Attestato Elettronico di Attributi non qualificato di ambito nazionale. L'IT-Wallet ID è un Attestato di questo tipo (vedere IT-Wallet ID).	Il Credential Issuer PUÒ validarla attraverso il Trust Framework Nazionale (vedere Wallet Unit Authentication).
Presentazione	La richiesta include un PID, una QEAA o una PuB-EAA, oppure un Attestato Elettronico di Attributi non qualificato ancorato al Trust Framework EUDIW dal suo Rulebook, oppure un Attestato di un altro Stato membro, oppure la Relying Party offre il servizio al di fuori del pubblico nazionale.	La Relying Party DEVE usare il Trust Framework EUDIW per l'intera richiesta.
Presentazione	La Relying Party è nazionale e la richiesta contiene soltanto un Attestato Elettronico di Attributi non qualificato di ambito nazionale.	La Relying Party DEVE usare il Trust Framework Nazionale.

6.1.1. Selection at Issuance

All'emissione la Wallet Unit avvia l'interazione e conosce l'Attestato richiesto (vedere Catalogo degli Attestati Elettronici). La riga applicabile di Trust Framework applicabile per interazione seleziona il Trust Framework.

Nel percorso EUDIW, Authentication, Authorization e Metadata Retrieval and Validation del Credential Issuer seguono EUDIW Authentication, EUDIW Authorization e EUDIW Metadata Retrieval and Validation. Nel percorso Nazionale seguono Federation Entity Authentication, Authorization e Metadata Retrieval and Validation.

Gli header degli artifact firmati del Credential Issuer DEVONO essere coerenti con il framework selezionato. Un header x5c reca il certificato di accesso nel percorso EUDIW. Un header kid, con l'header trust_chain opzionale, reca la chiave di federazione nel percorso Nazionale.

6.1.2. Selection at Presentation

La Relying Party non autentica la Wallet Unit. Non può selezionare il Trust Framework in funzione dello Stato membro di quella Wallet Unit o Soluzione Wallet. La riga applicabile di Trust Framework applicabile per interazione seleziona il Trust Framework.

Nel flusso remoto la Relying Party dichiara tale framework attraverso il prefisso client_id della richiesta (vedere OpenID4VP, Section 5.9). Il prefisso x509_hash seleziona il Trust Framework EUDIW, come richiesto dalla clausola 6 di [ETSI TS 119 472-2] (OIDFVP-HAIP_COMMON_GEN_REQ-02). Il prefisso openid_federation seleziona il Trust Framework Nazionale. La Wallet Unit DEVE elaborare x509_hash secondo EUDIW Authentication. La Wallet Unit DEVE elaborare openid_federation secondo Trust Evaluation Processes by Context quando la Trust Chain della Relying Party è valida rispetto al National Trust Anchor. Se tale Trust Chain non può essere validata, la Wallet Unit DEVE trattare la Relying Party come non affidabile. La Wallet Unit DEVE interrompere l'interazione.

Nel flusso di prossimità entrambi i framework utilizzano la mdoc reader authentication definita in [ISO18013-5 #12.5]. L'Istanza della Relying Party fornisce un certificato X.509 nell'header x5chain del ReaderAuth. Sul percorso EUDIW la Wallet Unit DEVE autenticare e validare il Wallet-Relying Party Access Certificate come specificato in EUDIW Authentication. Sul percorso nazionale la Wallet Unit DEVE validare il certificato di reader come specificato in Relying Party Proximity Authentication. La Wallet Unit DEVE eseguire l'Authorization esclusivamente nell'ambito del framework selezionato. La Relying Party utilizza il certificato che corrisponde alla riga selezionata.

Il requisito seguente si applica nel flusso remoto e nel flusso di prossimità. Quando la presentazione segue il Trust Framework Nazionale, la Wallet Unit DEVE interrompere l'interazione prima dell'Authorization se la richiesta include uno qualsiasi dei seguenti Attestati.

• un PID.

• una QEAA.

• una PuB-EAA.

• un Attestato Elettronico di Attributi non qualificato ancorato al Trust Framework EUDIW dal suo Rulebook.

• un Attestato di un altro Stato membro.

6.1.3. Failure Handling

Il fallimento della trust evaluation nell'ambito del framework selezionato NON DEVE essere valutato nuovamente nell'ambito dell'altro framework.

Quando la presentazione segue il Trust Framework Nazionale e Selection at Presentation richiede che la Wallet Unit interrompa l'interazione prima dell'Authorization, tale interruzione è un fallimento della selezione del Trust Framework. La Wallet Unit NON DEVE trattarla come overasking. Tale fallimento non è overridable.

Se l'autenticazione della Relying Party fallisce per qualsiasi motivo, la Wallet Unit DEVE informare l'Utente. Inoltre, la Wallet Unit DEVE non presentare gli attributi richiesti alla Relying Party, oppure dare all'Utente la scelta di presentare o meno gli attributi richiesti ([EIDAS-ARF] RPA_06a). Lo stesso vale nell'ambito del Trust Framework Nazionale: un esito NON_AUTHENTICATED DEVE interrompere l'interazione.

Se l'Authentication ha successo e l'Authorization fallisce, la Wallet Unit DEVE applicare Authorization Decision and Override Rules. Durante la presentazione, una scelta dell'Utente di proseguire è consentita solo per gli esiti di Authorization overridable ivi definiti. Il fallimento dell'Authentication non è overridable.

Durante l'Emissione, quando l'Authentication o l'Authorization non ha successo, la Wallet Unit DEVE mostrare un avviso all'Utente. La Wallet Unit NON DEVE richiedere l'emissione ([EIDAS-ARF] RPRC_22a). All'emissione non è offerta alcuna scelta all'Utente.

6.2. Trust Evaluation in the EUDIW Trust Framework

Le procedure definite in questa sezione profilano le seguenti specifiche esterne.

• ETSI TS 119 615 e ETSI TS 119 612, che definiscono la procedura e le strutture dati per autenticare e interpretare la List of Trusted Lists e le Trusted List degli Stati membri, applicate qui alle List of Trusted Entities.

• ETSI EN 319 102-1 e ETSI TS 119 182-1, che definiscono, rispettivamente, la validazione delle firme AdES e il formato JAdES della firma di una List of Trusted Entities.

• ETSI TS 119 411-8, ETSI TS 119 475 e ETSI EN 319 412-1, che definiscono, rispettivamente, il Wallet-Relying Party Access Certificate, il Wallet-Relying Party Registration Certificate insieme alle sue entitlement, e gli attributi del subject del certificato.

• ETSI TS 119 472-2 e ETSI TS 119 472-3, che profilano rispettivamente i protocolli di Presentazione e di Emissione, attraverso i quali una Wallet-Relying Party è autenticata e le sue informazioni di registrazione sono rese disponibili alla Wallet Unit. Quest'ultima definisce inoltre l'Embedded Disclosure Policy.

• IETF RFC 5280 (RFC 5280) e IETF RFC 6960 (RFC 6960), che definiscono la validazione della catena di certificati X.509 e l'Online Certificate Status Protocol.

Nota

Il modello dati dei Trust Artifact referenziati da queste procedure, insieme alle specifiche che li definiscono, è definito in EUDIW Trust Artifacts.

Le procedure definite in questa sezione sono eseguite all'interno dei flussi operativi di Emissione e Presentazione (vedi Flussi relativi agli Attestati Elettronici). I parametri su cui operano, come il Request Object firmato, la mdoc Request, i Metadata di tutte le Entità coinvolte e il modello dati degli Attestati Elettronici ricevuti, sono definiti nelle rispettive sezioni (vedi Entità, Request Object per il Remote Flow, Richiesta mdoc per il Proximity Flow, e Formato Attestato Elettronico SD-JWT-VC e Formato Attestato Elettronico mdoc-CBOR per i formati degli Attestati Elettronici).

6.2.1. EUDIW Trust Evaluation Processes by Context

Le procedure sono definite in forma generale, con un Trust Evaluator e una Trust Evaluated Party, e la tabella seguente definisce quale entità agisce in quale ruolo, quando e per quale scopo.

Tabella 6.2 Processi di Trust Evaluation per Entità e Contesto nel Trust Framework EUDIW

Entità	Contesto	In qualità di Trust Evaluator, implementa	In qualità di Trust Evaluated Party, fornisce
Wallet Unit	Emissione di una Credenziale nel catalogo UE	Sul Credential Issuer: EUDIW Authentication EUDIW Authorization EUDIW Metadata Retrieval and Validation Sull'Attestato ricevuto: EUDIW Attestation Signature Validation	La Wallet Instance Attestation, validata rispetto alla List of Trusted Entities dei Wallet Provider.
Wallet Unit	Presentazione remota, prefisso x509_hash	Sulla Relying Party: EUDIW Authentication EUDIW Authorization EUDIW Metadata Retrieval and Validation	Nessun artifact a livello di entità è richiesto dalla Wallet Unit.
Wallet Unit	Presentazione in prossimità	Sulla Relying Party: EUDIW Authentication, basata sull'mdoc reader authentication EUDIW Authorization	Nessun artifact a livello di entità è richiesto dalla Wallet Unit.
Credential Issuer	Emissione di Credenziali nel catalogo UE	Sulla Wallet Unit: EUDIW Attestation Signature Validation, applicata alla Wallet Instance Attestation	Il Wallet-Relying Party Access Certificate e il Wallet-Relying Party Registration Certificate, inclusi per valore nei Metadata del Credential Issuer ([EIDAS-ARF] RPRC_22).
Relying Party	Presentazione remota o in prossimità	Sugli Attestati ricevuti: EUDIW Attestation Signature Validation	Il Wallet-Relying Party Access Certificate e il Wallet-Relying Party Registration Certificate inclusi per valore nella richiesta di presentazione ([EIDAS-ARF] RPRC_19).
Relying Party Intermediary	Presentazione, per conto di una Relying Party intermediata	Non agisce come Trust Evaluator nei flussi operativi.	Il proprio Wallet-Relying Party Access Certificate e il Wallet-Relying Party Registration Certificate della Relying Party intermediata, inclusi per valore nella richiesta di presentazione ([EIDAS-ARF] RPRC_19).

6.2.2. EUDIW Trust Anchor Validation

Questa sezione specifica il Trust Anchor Validation Process che una Wallet Unit o una Wallet-Relying Party utilizza per stabilire l'integrità crittografica e l'autenticità di una List of Trusted Entities, o di una Trusted List, al fine di:

• validare l'affidabilità di un Trust Anchor (vedi Trust Anchor Certificate Profile) per autenticare, autorizzare o validare un'entità o un artifact durante il runtime.

• validare le informazioni contenute nella List per scopi storici.

A seconda del Trust Artifact o dell'Attestation in verifica, il Trust Evaluator DEVE recuperare, scaricare e validare la List che referenzia il Trust Anchor appropriato:

1. La List of Trusted Entities DEVE essere usata per recuperare i Trust Anchor per validare:

   • WRPAC nella LoTE dei Provider of WRPAC.

   • WRPRC nella LoTE dei Provider of WRPRC.

   • Wallet Unit Attestation Sign/Seal Certificates nella LoTE dei Wallet Provider.

   • PID Sign/Seal Certificates nella LoTE dei PID Provider.

   • PuB-EAA Sign/Seal Certificates nella LoTE dei PuB-EAA Provider.

   • Registrar Sign/Seal Certificates nella LoTE dei Registrar.

2. Le Trusted List sono usate per recuperare i Trust Anchor per validare:

   • QEAA Sign/Seal Certificates nella Trusted List dello Stato membro corrispondente.

3. Per i PuB-EAA Sign/Seal Certificates, la Trusted List dello Stato membro corrispondente DEVE essere usata per stabilire lo status qualificato della CA emittente e del certificato. NON DEVE sostituire l'inserimento del Trust Anchor nella LoTE dei PuB-EAA Provider.

Per verificare l'autenticità delle List recuperate, l'Entità DEVE eseguire le seguenti validazioni:

• List of Trusted Entities Validation: Validare la firma digitale della List of Trusted Entities verificandola rispetto al certificato del List of Trusted Entities Provider. Questo certificato è pubblicato nella Gazzetta ufficiale dell'Unione europea.

• Trusted List Validation: Validare la firma digitale della TL verificandola rispetto alle chiavi pubbliche dello Stato membro corrispondente pubblicate nella List Of Trusted Lists (LOTL). La List Of Trusted Lists (LOTL) stessa è autenticata validando la sua firma digitale rispetto alla Gazzetta ufficiale dell'Unione europea.

6.2.2.1. EUDIW Trust Anchor Validation: Input

L'Entità che valida DEVE basare le decisioni di validazione del Trust Anchor solo su informazioni derivate da:

• La Gazzetta ufficiale dell'UE (OJEU) che ancora la fiducia nei certificati root che hanno firmato le List of Trusted Entities e la List of Trusted Lists. La versione corrente dell'OJEU è OJEU.

• Una List of Trusted Entities o una List of Trusted Lists e le Trusted List a livello di Stato membro validate.

6.2.2.2. EUDIW Trust Anchor Validation: Esito

Ciascuna procedura di validazione (definita in List of Trusted Entities Validation e Trusted List Validation) produce un codice di risultato di verifica granulare quando rileva una condizione negativa. Questi codici confluiscono nella decisione finale:

• Se gli algoritmi di validazione terminano con:

  • LoTE-Status == LoTE_VERIFICATION_PASSED, o

  • LOTL-Status == LOTL_VERIFICATION_PASSED, o

  • EU-TL-Status == EU-TL_VERIFICATION_PASSED.

  Allora la List of Trusted Entities o la Trusted List è valida e i certificati Trust Anchor (vedi Trust Anchor Certificate Profile) ivi contenuti DEVONO essere considerati affidabili.

• Se gli algoritmi di validazione terminano con:

  • LoTE-Status == LoTE_VERIFICATION_FAILED, o

  • LOTL-Status == LOTL_VERIFICATION_FAILED, o

  • EU-TL-Status == EU-TL_VERIFICATION_FAILED.

  Allora la List of Trusted Entities o la Trusted List non è valida e i certificati Trust Anchor (vedi Trust Anchor Certificate Profile) ivi contenuti NON DEVONO essere considerati affidabili.

Nota

All'interno di IT-Wallet, una Wallet Unit è attesa a mettere in cache le List of Trusted Lists, le List of Trusted Entities e le Trusted List degli Stati membri validate, in modo da non recuperarle a ogni interazione. La frequenza degli aggiornamenti e i tipi di list da mettere in cache rappresentano un compromesso tra interoperabilità e utilizzo delle risorse.

6.2.2.3. List Key Rotation and Historical Verification

Per supportare la rotazione continua delle chiavi e gli aggiornamenti regolari, la LoTE e la LOTL implementano un pivoting mechanism. Questo meccanismo consiste nel pubblicare la versione più recente della List all'URI primario referenziato nella Gazzetta ufficiale dell'Unione europea, archiviando le versioni precedenti ad altri URI distinti chiamati pivot. Ciascuna versione della List è firmata con una chiave pubblica referenziata all'interno del pivot immediatamente precedente. L'ultimo pivot è firmato con la chiave referenziata nell'OJEU. La versione più recente della List contiene esplicitamente gli URI in cui sono ospitate tutte le versioni storiche.

Un'Entità valida questa catena di pivot dalla versione più recente a quella più vecchia verificando che ciascun artifact successivo sia correttamente firmato dalla chiave pubblica autorizzata nella versione precedente. La validazione finale è ottenuta verificando l'affidabilità della chiave pubblica più vecchia, tramite una ricerca nell'OJEU oppure direttamente rispetto a una versione della List in cache, precedentemente validata. Questo assicura che un'entità in possesso dell'ultima versione valida nota possa scoprire in modo affidabile la versione successiva e validarla tramite una catena di fiducia ininterrotta radicata nell'OJEU.

Sebbene il pivoting mechanism consenta aggiornamenti continui dei parametri della LoTE, alcuni aggiornamenti possono richiedere l'aggiunta di un oggetto ServiceHistory alla LoTE per preservare le chiavi e le configurazioni storiche necessarie a validare le firme legacy. Gli scenari specifici in cui un aggiornamento di un'Entità innesca una migrazione della sua configurazione in ServiceHistory sono dettagliati in Trust Management and Lifecycle.

Indipendentemente dall'obiettivo di un'Entità quando valida la LoTE (sia che recuperi una configurazione corrente o storica), il meccanismo di validazione DEVE seguire rigorosamente la Sezione List of Trusted Entities Validation.

6.2.2.4. List of Trusted Entities Validation

Questa sezione definisce la validazione di una List of Trusted Entities. La List of Trusted Entities, il suo modello dati e i tipi di List of Trusted Entities usati all'interno dell'ecosistema EUDIW, uno per ciascuna categoria di provider notificato, sono definiti in Trusted List, Lists of Trusted Lists, and Lists of Trusted Entities.

Una List of Trusted Entities è una list firmata. La sua autenticità è radicata nella Gazzetta ufficiale dell'Unione europea e supporta la rotazione continua delle chiavi attraverso il pivoting mechanism descritto in List Key Rotation and Historical Verification. I Trust Anchor che pubblica sono forniti nel ServiceDigitalIdentity delle sue entry di servizio delle entità fidate, come definito nella clausola 6.6.3 di [ETSI TS 119 602].

La procedura di autenticazione seguente segue la clausola 4.1 di [ETSI TS 119 615], che specifica l'autenticazione della List of Trusted Lists compilata dalla CE (LOTL) con il suo meccanismo di pivot. Qui tale procedura è applicata al modello dati della List of Trusted Entities di [ETSI TS 119 602] e alla sua firma JAdES ([ETSI TS 119 182-1]), al posto della LOTL XML. Le variabili usate di seguito sono gli analoghi della List of Trusted Entities delle variabili LOTL preconfigurate nella clausola 4.0 (GPR-4.0-02) di [ETSI TS 119 615]. Corrispondono come segue:

• OJEU-LoTE-Loc corrisponde a OJEU-LOTL-Loc.

• OJEU-LoTE-Certs-Set corrisponde a OJEU-LOTL-Certs-Set.

• LoTESO-Cert corrisponde a LOTLSO-Cert.

• i claim PointersToOtherLoTE e SchemeInformationURI corrispondono ai componenti Pointers to other TSLs (clausola 6.3.13 di [ETSI TS 119 602]) e Scheme information URI (clausola 6.3.7).

6.2.2.4.1. List of Trusted Entities Validation Algorithm

L'Entità che valida inizializza le seguenti variabili, corrispondenti ai parametri preconfigurati in GPR-4.0-02 di [ETSI TS 119 615] per la LOTL.

Le variabili di input dell'algoritmo di validazione della List of Trusted Entities sono le seguenti.

• OJEU-Loc: URI dell'ultima pubblicazione nota della Gazzetta ufficiale dell'Unione europea.

• OJEU-LoTE-Loc: URI dell'ultima List of Trusted Entities elaborata. Il valore predefinito è quello in OJEU-Loc.

• OJEU-LoTE-Certs-Set: l'insieme dei certificati fidati dalla pubblicazione OJEU-Loc.

• LoTE: il JWT della List of Trusted Entities attualmente in elaborazione. Inizializzato come NULL.

• LoTE-Signer-Cert: il certificato estratto dal parametro di header x5c della List of Trusted Entities.

• LoTESO-Cert: variabile temporanea per il certificato del Scheme Operator in validazione. Inizializzata come NULL.

• LoTESO-Certs-Set: certificati fidati estratti dal claim PointersToOtherLoTE (SchemeTerritory EU, clausola 6.3.10 di [ETSI TS 119 602]) di una List of Trusted Entities.

Le variabili di output dell'algoritmo di validazione della List of Trusted Entities sono le seguenti.

• Authenticated-LoTE: il payload JSON validato.

• LoTE-Status: il risultato della validazione (ad es., LoTE_VERIFICATION_PASSED).

• LoTE-Sub-Status: codici di errore dettagliati.

Il processo dell'algoritmo di validazione della List of Trusted Entities è il seguente.

La validazione DEVE eseguire i seguenti passi. Ciascun passo indica il requisito corrispondente della clausola 4.1 di [ETSI TS 119 615].

1. (Inizializzazione) Scaricare il file JWT da OJEU-LoTE-Loc e assegnarlo a LoTE. (PRO-4.1.4-01)

2. (Parsing) Estrarre il primo certificato dall'header x5c di LoTE e assegnarlo a LoTE-Signer-Cert. (PRO-4.1.4-02)

3. (Pivot Discovery) Iterare sui claim uriValue nel componente SchemeInformationURI (clausola 6.3.7 di [ETSI TS 119 602]). Contare il numero di URI validi che precedono l'URI corrispondente a OJEU-Loc e assegnarlo a n. (PRO-4.1.4-03 per la ricerca di OJEU-Loc, PRO-4.1.4-04 per il conteggio di n)

   • Se nessun URI corrisponde a OJEU-Loc: la validazione DEVE fallire con LoTE-Status impostato a LoTE_VERIFICATION_FAILED e LoTE-Sub-Status impostato a OJEU_LOCATION_INPUT_NOT_MATCHING_OJEU_LOCATION_IN_LoTE.

4. (LoTE Location Conflict) Verificare la condizione OJEU-LoTE-Loc != LoTE Location AND LoTE != Content at LoTE Location, dove LoTE Location è l'URI LoTELocation nel componente PointersToOtherLoTE di LoTE con SchemeTerritory EU (clausola 6.3.13 di [ETSI TS 119 602]). (PRO-4.1.4-05).

   • Se TRUE: la validazione DEVE interrompersi con LoTE-Status impostato a LoTE_VERIFICATION_FAILED e LoTE-Sub-Status impostato a LoTE_FILE_CONFLICT.

   • Se FALSE, procedere al passo successivo.

5. (LoTE Freshness) Verificare la condizione OJEU-LoTE-Loc == LoTE Location AND LoTE != Content at LoTE Location. (PRO-4.1.4-06).

   • Se TRUE: impostare OJEU-LoTE-Loc a LoTE Location e ricominciare dal Passo 1.

   • Se FALSE, procedere al passo successivo.

6. (Digital Signature Validation) Validare la firma della LoTE corrente usando la chiave pubblica da LoTE-Signer-Cert come certificato direttamente fidato, seguendo la validazione di firma di base di [ETSI EN 319 102-1] come richiesto da PRO-4.1.4-07. I campi Country code e Organization nel Subject Distinguished Name del certificato che supporta la firma digitale AdES DEVONO corrispondere rispettivamente al scheme territory e a uno dei valori del scheme operator name all'interno della LoTE. (PRO-4.1.4-07, PRO-4.1.4-08, clausola 6.8.0 di [ETSI TS 119 602])

   • Se la validazione fallisce: interrompere con LoTE-Status impostato a LoTE_VERIFICATION_FAILED e LoTE-Sub-Status impostato a LoTE_SIGNATURE_VERIFICATION_FAILED.

   • Se ha successo:

     • Impostare LoTESO-Cert a LoTE-Signer-Cert.

     • Impostare LoTESO-Certs-Set ai certificati trovati nel claim PointersToOtherLoTE (scheme territory EU) del payload della LoTE corrente. (PRO-4.1.4-09).

7. (Intermediate Pivot Validation) (PRO-4.1.4-10 per il caso n = 0, PRO-4.1.4-11 per il ciclo sui pivot)

   • Caso n = 0 (Nessun Pivot): procedere direttamente al Passo 8.

   • Caso n != 0 (Catena Storica):

     • Iterare i da 1 a n (dal Pivot più recente al più vecchio). Sia Pivot il file scaricato dall'i-esimo URI.

     • (Link Check) Impostare Pivot-Certs-Set ai certificati nel claim PointersToOtherLoTE (territory EU) di Pivot. Se LoTESO-Cert (il firmatario del file precedente nella catena) non è in Pivot-Certs-Set, la validazione DEVE fallire con LoTE-Sub-Status impostato a PIVOT_i-1_SIGNER_CERT_NOT_AUTHENTICATED_BY_PIVOT_i.

     • (Update Signer) Impostare LoTESO-Cert al primo certificato nel parametro di header x5c di Pivot.

     • (Verify Signature) Validare la firma di Pivot usando LoTESO-Cert come descritto nel passo 6. (Digital Signature Validation). Se fallisce, la validazione DEVE fallire con LoTE-Status impostato a LoTE_VERIFICATION_FAILED e LoTE-Sub-Status impostato a PIVOT_i_SIGNATURE_VERIFICATION_FAILED.

     • Il ciclo continua, procedendo a ritroso fino a quando LoTESO-Cert rappresenta il firmatario del Pivot più vecchio.

8. (Trust Root Validation) Verificare la fine della catena. Se LoTESO-Cert (dall'ultimo Pivot, o dalla LoTE corrente quando non esiste alcun Pivot) non è in OJEU-LoTE-Certs-Set (l'insieme dei certificati fidati), la validazione DEVE fallire con LoTE-Sub-Status impostato a PIVOT_n_SIGNER_CERT_NOT_AUTHENTICATED_BY_OJEU. (PRO-4.1.4-12)

9. (Expiration) Se l'ora corrente è maggiore del valore NextUpdate di LoTE, oppure è impostato a NULL (clausola 6.3.15 di [ETSI TS 119 602]), la validazione DEVE fallire. (PRO-4.1.4-13)

10. (Success) Impostare Authenticated-LoTE a LoTE e LoTE-Status a LoTE_VERIFICATION_PASSED. (PRO-4.1.4-14, PRO-4.1.4-15)

11. (Update Bookmark) Se OJEU-LoTE-Loc non corrisponde alla LoTE Location in Authenticated-LoTE (scheme territory EU), aggiornare OJEU-LoTE-Loc a tale valore. (PRO-4.1.4-16)

12. (Update Trust Root) [Attenzione: questo passo modifica la configurazione del Root of Trust] (PRO-4.1.4-17)

    • Se OJEU-Loc non corrisponde al primo URI in SchemeInformationURI, aggiornare OJEU-LoTE-Loc.

    • Aggiornare OJEU-LoTE-Certs-Set in base al nuovo insieme di certificati fidati, sia in Authenticated-LoTE sia da una nuova pubblicazione della Gazzetta ufficiale dell'Unione europea.

Nota

• I passi 4, 5 e 11 consentono di modificare la location del file della List of Trusted Entities senza cambiare la chiave pubblica del firmatario fidato iniziale, purché sia la vecchia sia la nuova location abbiano lo stesso contenuto, altrimenti la validazione fallisce con LoTE_FILE_CONFLICT. Questo consente di recuperare la List of Trusted Entities da location diverse senza influire sulla validazione del Trust Anchor, purché il contenuto sia lo stesso.

• In caso di errore OJEU_LOCATION_INPUT_NOT_MATCHING_OJEU_LOCATION_IN_LoTE, è probabile che la pubblicazione della Gazzetta ufficiale dell'Unione europea sia stata aggiornata con una nuova location per la List of Trusted Entities. L'Entità che valida DOVREBBE ripetere il processo di validazione dopo aver scaricato la versione più recente della Gazzetta ufficiale dell'Unione europea.

• Nel passo 8, l'Entità che valida stabilisce il binding del certificato firmatario della LoTE con il certificato referenziato nella Gazzetta ufficiale dell'Unione europea, usando di fatto quest'ultima come fonte di certificati fidati.

Di seguito un diagramma di flusso che sintetizza i passi precedenti per la validazione della List of Trusted Entities:

Fig. 6.1 Diagramma di flusso dell'algoritmo di validazione della List of Trusted Entities.

Di seguito sono elencati i codici di errore Sub-Status della List of Trusted Entities in formato tabellare.

Tabella 6.3 Codici di Errore Sub-Status della List of Trusted Entities

Code	Fase	Significato
OJEU_LOCATION_INPUT_NOT_MATCHING_OJEU_LOCATION_IN_LoTE	both	Nessun URI corrisponde all'OJEU-Loc atteso all'interno del SchemeInformationURI della List of Trusted Entities. Ciò implica tipicamente che è disponibile una versione più recente della pubblicazione della Gazzetta ufficiale dell'Unione europea.
LoTE_FILE_CONFLICT	both	È rilevato un conflitto di location in cui la location tracciata della List of Trusted Entities differisce da quella attiva, e il contenuto di questi file non corrisponde.
LoTE_SIGNATURE_VERIFICATION_FAILED	both	La validazione della firma del file corrente della List of Trusted Entities è fallita usando il certificato firmatario estratto, indicando un potenziale manomissione o corruzione.
PIVOT_i-1_SIGNER_CERT_NOT_AUTHENTICATED_BY_PIVOT_i	both	La catena storica di fiducia è interrotta perché il certificato di firma del pivot o file precedente (i-1) non è trovato nell'insieme di certificati fidati del pivot successivo (i).
PIVOT_i_SIGNATURE_VERIFICATION_FAILED	both	La validazione della firma è fallita per un file pivot intermedio (i) all'interno della catena storica.
PIVOT_n_SIGNER_CERT_NOT_AUTHENTICATED_BY_OJEU	both	Il certificato finale alla radice della catena di pivot, o il firmatario della List of Trusted Entities corrente quando non esiste alcun pivot, non è trovato nell'insieme di certificati fidati OJEU-LoTE-Certs-Set.

6.2.2.5. Trusted List Validation

Questa sezione definisce la validazione della Trusted List. Per validare la Trusted List, l'Entità che valida DEVE:

1. Validare la List of Trusted Lists dell'UE usando l'algoritmo descritto nella sezione 4.1 di [ETSI TS 119 615]. Se questo fallisce, la validazione si interrompe e la Wallet Unit DEVE considerare l'Entità con cui sta interagendo come non fidata. Il processo di validazione è analogo a List of Trusted Entities Validation eccetto per il formato della LOTL che è sempre XML.

2. Analizzare la List of Trusted Lists dell'UE validata per scoprire il certificato necessario a validare la Trusted List dello Stato membro rilevante.

3. Ottenere e validare la Trusted List rilevante come descritto nella sezione 4.2 di [ETSI TS 119 615].

6.2.3. X509 Certificate Chain Validation Algorithm

Questa procedura valida la catena di certificati. È invocata da EUDIW Authentication e da Authorization Artifacts Validation per validare le catene del Wallet-Relying Party Access Certificate, del Wallet-Relying Party Registration Certificate e del Registrar Sign/Seal Certificate. Il Trust Anchor consumato come trust_anchor è profilato in Trust Anchor Certificate Profile.

La validazione della catena di certificati è la path validation X.509 standard definita in RFC 5280#section-6, con il controllo dello status di revoca definito in RFC 5280 e RFC 6960. Il ciclo di vita dei certificati e i meccanismi di revoca, inclusi i formati e i parametri di CRL e OCSP, sono definiti in Revocation Mechanisms. I dettagli dell'algoritmo non sono ridefiniti qui. Questa è la stessa validazione della catena di certificati usata nel Trust Framework Nazionale (vedi X.509 Certificate Chain Validation), dove la differenza è l'origine del trust anchor e l'estrazione aggiuntiva del Federation Entity Identifier.

All'interno del Trust Framework EUDIW si applica quanto segue.

• Il trust_anchor è il certificato fidato ottenuto dal componente ServiceDigitalIdentity della List of Trusted Entities (vedi List of Trusted Entities Validation) o della Trusted List (vedi Trusted List Validation) applicabile e validata, cioè la LoTE dei Provider of WRPAC per il Wallet-Relying Party Access Certificate, la LoTE dei Provider of WRPRC per il Wallet-Relying Party Registration Certificate, e la LoTE dei Registrar per il Registrar Sign/Seal Certificate.

• Il controllo dello status di revoca PUÒ essere omesso per un certificato che reca entrambe le estensioni noRevAvail e ETSIValAssuredCertMod (vedi Wallet-Relying Party Access Certificate (WRPAC) Profile), il cui status è allora determinato unicamente dal suo periodo di validità.

Nota

Come definito in Revocation Trust Anchors, il Trust Anchor recuperato dalla LoTE o dalla Trusted List applicabile è il Trust Anchor notificato per la catena di certificati corrispondente. Lo stesso Trust Anchor DEVE essere usato per validare le firme delle CRL o delle risposte OCSP usate per il controllo di revoca, come specificato in RFC 5280#section-6 e RFC 6960.

6.2.3.1. X509 Certificate Chain Validation Algorithm: Input

• path: la sequenza di n certificati C_1, ..., C_n fornita dall'Entità. C_1 DEVE essere il certificato end-entity corrispondente alla chiave privata usata per firmare l'artifact o l'Attestation. C_n DEVE essere il certificato firmato dal trust_anchor. Il certificato Trust Anchor NON DEVE essere incluso in path. Per ogni i in 1, ..., n-1, C_i+1 DEVE essere l'issuer di C_i.

• trust_anchor: il certificato fidato ottenuto dal ServiceDigitalIdentity della List of Trusted Entities o della Trusted List validata. Il trust_anchor DEVE contenere la chiave pubblica usata per firmare C_n. Le implementazioni DEVONO supportare sia certificati Trust Anchor self-signed sia non self-signed.

• current_time: la data e l'ora correnti.

6.2.3.2. X509 Certificate Chain Validation Algorithm: Esito

• Il certificato end-entity validato C_1, oppure un fallimento.

6.2.3.3. X509 Certificate Chain Validation Algorithm: Processo

1. Costruire la catena di certificati dal certificato end-entity C_1 verso il trust_anchor, terminando con C_n.

2. Eseguire la path validation definita in RFC 5280#section-6, usando il trust_anchor come input trust anchor dell'algoritmo e current_time come tempo di validazione. La validazione di RFC 5280 elabora i certificati da C_n a C_1. Questo non cambia l'ordine del path presentato.

3. Verificare lo status di revoca dei certificati nel path secondo RFC 5280 e RFC 6960, a meno che il controllo non sia omesso come descritto sopra.

Se un qualsiasi passo fallisce, la catena di certificati DEVE essere considerata non valida. La firma dell'artifact NON DEVE essere verificata con la catena di certificati presentata.

6.2.4. EUDIW Attestation Signature Validation

Questo processo valida la firma su un'Attestation (Attestato Elettronico o Wallet Instance Attestation) usando il Sign/Seal Certificate appropriato come profilato in Entity Sign/Seal Certificate Profile. È invocato durante i flussi di emissione e presentazione per validare la firma sull'Attestation.

Il processo DEVE essere strutturato come segue.

• La procedura di validazione della firma seguente si applica quando l'Attestation è un PID, una PuB-EAA, una QEAA o una Wallet Instance Attestation. La procedura di validazione della firma DEVE usare il Sign/Seal Certificate e la catena di fiducia X.509 associata contenuti nell'Attestation. Il Trust Anchor è quello presente nella LoTE rilevante per un PID, una WIA o una PuB-EAA. Il Trust Anchor è quello presente nella Trusted List per una QEAA.

• Se l'Attestation la cui firma è in verifica è una EAA non qualificata, allora le informazioni relative alla trust evaluation sono governate dal Rulebook corrispondente.

La procedura di validazione della firma è strutturata come segue:

6.2.4.1. EUDIW Attestation Signature Validation: Input

• L'Attestation ricevuta e la catena di certificati del firmatario ivi contenuta.

• Il tipo di artifact (cioè, il tipo di Attestato Elettronico o Wallet Instance Attestation) usato per selezionare la List of Trusted Entities o la Trusted List applicabile.

6.2.4.2. EUDIW Attestation Signature Validation: Esito

• L'Attestation validata, oppure un fallimento di validazione.

6.2.4.3. EUDIW Attestation Signature Validation: Processo

Questo processo dipende dal tipo di Attestation:

• PID o WIA.

  1. Verificare la firma dell'Attestation con il certificato Sign/Seal fornito nell'Attestation.

  2. Selezionare la List of Trusted Entities applicabile in base al tipo dell'Attestation ricevuta, validarla come definito in List of Trusted Entities Validation, ed estrarre il Trust Anchor appropriato dal campo ServiceDigitalIdentity dell'Entità rilevante.

  3. Estrarre la catena del certificato Sign/Seal dall'Attestation e validarla rispetto al Trust Anchor ottenuto, come definito in X509 Certificate Chain Validation Algorithm.

• QEAA.

  1. Verificare la firma dell'Attestation usando il certificato Sign/Seal fornito nell'Attestation. Per una QEAA, la firma o il sigillo elettronico qualificato DEVE essere validato in conformità all'Articolo 32 di [EIDAS].

  2. Recuperare la Trusted List appropriata in base alla nazionalità del Credential Issuer, validarla come definito in Trusted List Validation, ed estrarre il Trust Anchor appropriato dal campo ServiceDigitalIdentity dell'Entità rilevante.

  3. Estrarre la catena di certificati del firmatario dall'Attestation e validarla rispetto al Trust Anchor ottenuto, come definito in X509 Certificate Chain Validation Algorithm.

• PuB-EAA.

  1. Verificare la firma dell'Attestation con il Sign/Seal Certificate fornito nell'Attestation. Una firma elettronica qualificata DEVE essere validata in conformità all'Articolo 32 di [EIDAS]. Ove il Provider sia una persona giuridica che usa un sigillo elettronico, si applicano gli Articoli 37 e 40.

  2. Recuperare e validare la LoTE dei PuB-EAA Provider come definito in List of Trusted Entities Validation, abbinare il Provider e il suo Sign/Seal Certificate con l'oggetto TrustedEntityList rilevante, ed estrarre il suo Trust Anchor.

  3. Estrarre la catena di certificati del firmatario dall'Attestation e validarla rispetto al Trust Anchor ottenuto dalla LoTE, come definito in X509 Certificate Chain Validation Algorithm.

  4. Recuperare la Trusted List dello Stato membro corrispondente alla CA emittente, validarla come definito in Trusted List Validation, e stabilire lo status qualificato della CA emittente e del Sign/Seal Certificate.

Nota

In ciascuno dei casi precedenti, per un'Attestation in formato mdoc, il Mobile Security Object reca il certificato Document Signer nell'header x5chain, come definito in [ISO18013-5]. Per un'Attestation in formato SD-JWT VC, la catena di certificati dell'issuer è recata nell'header x5c della firma JOSE.

Nota

Quando si verificano firme o sigilli realizzati da chiavi storiche, si applica lo stesso processo con la seguente differenza: il Trust Anchor è recuperato dall'elemento ServiceHistory.ServiceDigitalIdentity invece che dall'elemento ServiceInformation.ServiceDigitalIdentity.

Se la validazione della firma fallisce, l'Attestation NON DEVE essere considerata emessa da un'Entità fidata.

6.2.5. EUDIW Authentication

Il Processo di Autenticazione consente alla Wallet Unit di autenticare una Wallet-Relying Party durante un'interazione. Stabilisce la fiducia validando la catena di certificati X.509 della Wallet-Relying Party, da un Provider of Wallet-Relying Party Access Certificate fidato fino al Wallet-Relying Party Access Certificate presentato, e verificando che la Wallet-Relying Party possieda la corrispondente chiave privata. Il Wallet-Relying Party Access Certificate è profilato in Wallet-Relying Party Access Certificate (WRPAC) Profile.

Per la verifica del certificato di accesso, la Wallet Unit DEVE accettare solo i Trust Anchor pubblicati nelle List of Trusted Entities dei Provider of Wallet-Relying Party Access Certificate notificati dagli Stati membri (vedi List of Trusted Entities Validation). La Wallet Unit DEVE eseguire essa stessa questa autenticazione e validazione. La Wallet Unit NON DEVE delegarla a un browser del sistema operativo o a un'altra applicazione intermediaria ([CIR2024/2982] articolo 3, paragrafo 1, come sostituito da [CIR2026/1731]).

6.2.5.1. EUDIW Authentication: Input

L'esito dell'Autenticazione DEVE basarsi solo su informazioni derivate da:

• il Trust Anchor appropriato ottenuto da un'istanza valida della List of Trusted Entities dei Provider of Wallet-Relying Party Access Certificate.

• la catena di certificati X.509 che inizia con il certificato end-entity del Wallet-Relying Party Access Certificate.

• una firma della Wallet-Relying Party sull'artifact dell'interazione, recante la prova di possesso della chiave privata referenziata nel Wallet-Relying Party Access Certificate.

6.2.5.2. EUDIW Authentication: Esito

La Wallet Unit DEVE produrre una decisione: la Wallet-Relying Party è AUTHENTICATED oppure NON_AUTHENTICATED. Se AUTHENTICATED, la Wallet Unit procede nel flusso di interazione. Se NON_AUTHENTICATED, la Wallet Unit DEVE informare l'Utente che l'identità della Wallet-Relying Party non ha potuto essere verificata. La Wallet Unit DEVE interrompere l'interazione, poiché l'entità non è affidabile.

6.2.5.3. EUDIW Authentication: Processo

La Wallet Unit DEVE verificare l'autenticità e l'integrità del Wallet-Relying Party Access Certificate presentato come segue:

1. Retrieve the Trust Anchor: ottenere l'entry del Provider of Wallet-Relying Party Access Certificate dalla List of Trusted Entities validata (vedi List of Trusted Entities Validation). Per selezionare l'entry corretta, abbinare l'issuer.organizationIdentifier del primo certificato della catena, la cui semantica è definita nella clausola 5.1.4 di [ETSI EN 319 412-1], con il TrustedEntitiesList[].TrustedEntity.TETradeName della List of Trusted Entities. I certificati nel campo TrustedEntityServices[].ServiceInformation.ServiceDigitalIdentity costituiscono il Trust Anchor.

2. Costruzione della catena di certificati: costruire una catena di certificati a partire dal Wallet-Relying Party Access Certificate presentato dalla Wallet-Relying Party (C_1) e terminante con il certificato emesso dal Provider of Wallet-Relying Party Access Certificate (C_n). Il path più semplice consiste in un singolo certificato, dove n = 1.

3. Execute Path Validation: validare la catena di certificati come definito in X509 Certificate Chain Validation Algorithm, usando il Trust Anchor recuperato al passo 1, come descritto in Wallet-Relying Party Access Certificate Validation.

4. Verify the Signature: usare la chiave pubblica del Wallet-Relying Party Access Certificate validato per verificare la firma della Wallet-Relying Party sull'artifact che firma nella specifica interazione. La catena di certificati e l'artifact firmato dipendono dal flusso:

   • Remote Flow: la catena è recata nell'header x5c del Request Object firmato dalla Wallet-Relying Party, e la Relying Party è autenticata attraverso il Client Identifier Prefix x509_hash, come definito in [OpenID4VP] e [OPENID4VC-HAIP].

   • Proximity Flow: la catena è recata nell'mdoc reader authentication (ReaderAuth) firmata dalla Wallet-Relying Party, nell'header COSE x5chain (label 33), come definito in [ISO18013-5].

   • Issuance Flow: la catena è recata nell'header x5c dei Metadata del Credential Issuer firmati dalla Wallet-Relying Party, come definito in [OpenID4VCI].

Avvertimento

Una Wallet-Relying Party DEVE distinguere tra autenticazione transitoria (ad es., controllo di accesso) e impegno sul contenuto (non ripudio). Per impedire a un attaccante di mascherare un impegno legale come un nonce di protocollo, la Wallet-Relying Party NON DEVE usare la chiave privata del Wallet-Relying Party Access Certificate per firmare dati arbitrari che potrebbero essere controllati da una parte esterna.

6.2.5.4. Wallet-Relying Party Access Certificate Validation

L'Entità che esegue la validazione del Wallet-Relying Party Access Certificate inizializza l'algoritmo in X509 Certificate Chain Validation Algorithm con il path e il trust_anchor ivi definiti. Gli input sono i seguenti:

• C_1 è il primo certificato della catena fornita dalla Wallet-Relying Party ed è il Wallet-Relying Party Access Certificate usato per firmare l'artifact.

• C_n è l'ultimo certificato della catena ed è firmato dal trust_anchor.

• trust_anchor è un certificato del Provider of Wallet-Relying Party Access Certificate ottenuto dalla List of Trusted Entities.

Avvertimento

Come descritto nella Sezione 6.1.1 di OPENID4VC-HAIP, il Trust Anchor Certificate necessario per la validazione del WRPAC NON DEVE essere incluso nella catena di certificati. Il Trust Anchor Certificate DEVE essere sempre recuperato dalla LoTE appropriata.

6.2.6. EUDIW Authorization

Questa sezione specifica il Processo di Autorizzazione EUDIW che una Wallet Unit DEVE eseguire per determinare se un'interazione con una Wallet-Relying Party è consentita all'interno dell'ecosistema EUDI Wallet. Il Processo di Autorizzazione EUDIW DEVE iniziare solo dopo che la Wallet-Relying Party è stata autenticata con successo secondo EUDIW Authentication. Se la Wallet-Relying Party non è stata autenticata, il Processo di Autorizzazione EUDIW NON DEVE iniziare.

I dati di autorizzazione di una Wallet-Relying Party sono recati dal Wallet-Relying Party Registration Certificate. Durante la Presentazione di Credenziali il Wallet-Relying Party Registration Certificate DEVE essere incluso per valore nella richiesta ([EIDAS-ARF] RPRC_19) ed è l'unica fonte autorevole per l'autorizzazione alla presentazione ([EIDAS-ARF] RPRC_17, RPRC_21). Durante l'Emissione di Credenziali un PID Provider o un Attestation Provider DEVE includere il Wallet-Relying Party Registration Certificate per valore nei Metadata del Credential Issuer ([EIDAS-ARF] RPRC_22).

Il Processo di Autorizzazione EUDIW è suddiviso in:

• Authorization Artifacts Validation, che valida l'integrità e l'autenticità del Trust Artifact recante i dati di autorizzazione. E.

• Authorization Validation, che valida il contenuto informativo dell'artifact validato. In particolare questa validazione copre:

  • Autorizzazione all'emissione: determina se un Credential Issuer è registrato per il ruolo rilevante e autorizzato a emettere lo specifico Attestato Elettronico. Questo si applica ai PID, QEAA, PuB-EAA e EAA Provider che operano all'interno dell'ecosistema EUDIW.

  • Autorizzazione alla presentazione: determina se una richiesta di Relying Party ricade nel suo ambito registrato, se un'Embedded Disclosure Policy consente la disclosure, e se l'Utente approva. Questo si applica alle interazioni che coinvolgono sia Relying Party sia Relying Party Intermediary, sia nel Remote Flow sia nel Proximity Flow.

• Authorization Decision and Override Rules, che produce una Authorization Decision espressa come AUTHORIZED o NOT_AUTHORIZED sulla base dei risultati di Authorization Artifacts Validation e Authorization Validation. A seconda del tipo di Flow l'Utente PUÒ sovrascrivere la Authorization Decision.

All'interno della Authorization Validation, la Wallet Unit DEVE distinguere tra la Wallet-Relying Party autenticata e l'Authorization Subject, cioè l'entità la cui autorizzazione è in valutazione:

• Durante l'Emissione, l'Authorization Subject è il Credential Issuer.

• Durante la presentazione diretta, l'Authorization Subject è la Relying Party.

• Durante la presentazione intermediata, la Wallet-Relying Party autenticata è il Relying Party Intermediary, mentre l'Authorization Subject per la richiesta di dati è la Relying Party intermediata, il cui ambito registrato governa la richiesta. Il Relying Party Intermediary è esso stesso un'entità registrata, e la sua autorizzazione ad agire come intermediario è stabilita attraverso il binding intermediary dichiarato nei dati di autorizzazione della Relying Party intermediata (vedi la Binding verification di seguito).

La Wallet Unit DEVE supportare la risoluzione del contesto di autorizzazione dal Wallet-Relying Party Registration Certificate incluso nell'interazione. La Wallet Unit NON DEVE interrogare il Register come sostituto di un Wallet-Relying Party Registration Certificate mancante o non valido durante la Presentazione di Credenziali ([EIDAS-ARF] RPRC_16, RPRC_18 e RPRC_19a sono vuoti) o durante l'Emissione di Credenziali ([EIDAS-ARF] RPRC_22 e RPRC_22a).

6.2.6.1. Authorization Artifacts Validation

Il Wallet-Relying Party Registration Certificate reca i dati di autorizzazione di un'entità, nei profili JWT e CWT definiti nella Sezione 5.2.1 di [ETSI TS 119 475].

Ciascuna procedura di validazione specifica i propri input, la propria logica di elaborazione e il proprio output, un codice di risultato di verifica. Il risultato PUÒ essere sovrascritto dall'Utente alle condizioni dettagliate in Authorization Decision and Override Rules.

Il flusso di validazione dipende dall'interazione.

• Durante il flusso di Presentazione la Relying Party DEVE convogliare il Wallet-Relying Party Registration Certificate per valore ([EIDAS-ARF] RPRC_19):

  • come elemento registration_cert del parametro verifier_info del Request Object, nel Remote Flow, come definito in [ETSI TS 119 472-2] e nella Sezione 5.1 di [OpenID4VP].

  • nel membro euWrprc di requestInfo nell'ISO DeviceRequest, nel Proximity Flow, come definito nella Sezione 5.3 di [ETSI TS 119 472-2] e in [ISO18013-5].

  Nel Remote Flow, verifier_info DEVE contenere anche un elemento registrar_dataset per il trasporto e la trasparenza ETSI. Il dataset DEVE contenere l'identificatore registrato e i campi srvDescription, registryURI, intendedUseIdentifier, purpose e policyURI, come specificato nel Remote Flow. Il dataset NON DEVE sostituire né prevalere sul Wallet-Relying Party Registration Certificate come fonte di autorizzazione della presentazione ([EIDAS-ARF] RPRC_19a è vuoto).

  Nel Proximity Flow, ogni ItemsRequest DEVE contenere un requestInfo.euWrpRegistrarInfo non vuoto, con l'array identifier non vuoto, gli array srvDescription e purpose non vuoti, registryURI, intendedUseIdentifier e policyURI. I dati credential opzionali sono non vuoti quando presenti. Questi dati del Registrar servono alla trasparenza e al binding di identità. Tali dati NON DEVONO sostituire il WRPRC obbligatorio fornito per valore. Tali dati NON DEVONO innescare una consultazione del Register.

• Durante il flusso di Emissione un PID Provider o un Attestation Provider DEVE convogliare le informazioni di registrazione applicabili nei Metadata firmati del Credential Issuer ([EIDAS-ARF] RPRC_22), attraverso l'array issuer_info di primo livello definito nella Sezione 4.2.3 di [ETSI TS 119 472-3]. Ciascun elemento contiene format e data. L'array DEVE contenere un elemento registration_cert con il Wallet-Relying Party Registration Certificate per valore. L'array DEVE contenere un elemento registrar_dataset con le informazioni di registrazione. Il registrar_dataset NON DEVE sostituire la validazione del certificato quando registration_cert è presente. L'Embedded Disclosure Policy è distribuita come membro embedded_disclosure_policy di credential_metadata all'interno di credential_configurations_supported, come definito in [OpenID4VCI] e in Embedded Disclosure Policy (EDP).

Durante la Presentazione di Credenziali, se il Wallet-Relying Party Registration Certificate non è disponibile o la sua validazione fallisce, la Wallet Unit DEVE impostare authz_art_state a CERTIFICATE_INVALID. La Wallet Unit DEVE avvisare l'Utente ([EIDAS-ARF] RPRC_17). La Wallet Unit NON DEVE interrogare il Register come fallback ([EIDAS-ARF] RPRC_16 e RPRC_18 sono vuoti).

Durante l'Emissione di Credenziali, se il Wallet-Relying Party Registration Certificate non è disponibile o la sua validazione fallisce, la Wallet Unit DEVE impostare authz_art_state a CERTIFICATE_INVALID. La Wallet Unit DEVE avvisare l'Utente che la Wallet Unit non ha potuto ottenere o validare le informazioni registrate. La Wallet Unit NON DEVE richiedere l'emissione di un PID o di un'attestation ([EIDAS-ARF] RPRC_22a). La Wallet Unit NON DEVE interrogare il Register come fallback ([EIDAS-ARF] RPRC_22).

6.2.6.1.1. Wallet-Relying Party Registration Certificate Validation

Quando un Wallet-Relying Party Registration Certificate è disponibile, la Wallet Unit DEVE validarlo prima di farvi affidamento:

1. Format verification: confermare che typ è rc-wrp+jwt nel Remote Flow e durante l'Emissione di Credenziali, oppure rc-wrp+cwt nel Proximity Flow, come definito nella Sezione 5.2.1 di [ETSI TS 119 475].

2. Algorithm verification: verificare che l'algoritmo di firma sia conforme, cioè che alg non sia né none né un algoritmo deprecato.

3. Signature validation: verificare che la firma del Wallet-Relying Party Registration Certificate sia valida.

4. Trust Anchor validation: validare la LoTE dei Provider of WRPRC (vedi List of Trusted Entities Validation) e recuperare il Trust Anchor dal suo campo TrustedEntitiesList.ServiceDigitalIdentity.

5. Path validation: validare la catena del Wallet-Relying Party Registration Certificate come definito in X509 Certificate Chain Validation Algorithm, usando il trust_anchor ottenuto nel passo precedente. Per il WRPRC, il Trust Anchor usato per la validazione della firma, la validazione della catena di certificati e il controllo di revoca DEVE essere recuperato dall'entry di servizio applicabile nella LoTE dei Provider of WRPRC (cioè, sotto il ServiceDigitalIdentity corrispondente al ServiceTypeIdentifier con valore http://uri.etsi.org/19602/SvcType/WRPRC/Issuance).

6. Temporal validity: controllare iat e exp se presenti.

7. Status verification: controllare lo status di revoca attraverso il campo status del Wallet-Relying Party Registration Certificate, come definito in [ETSI TS 119 475]:

   • recuperare la SLT (vedi Token Status List (WRPRC Profile)) all'URI specificato dal membro status.status_list.uri del WRPRC.

   • validare la catena del certificato di firma della SLT come definito in X509 Certificate Chain Validation Algorithm, usando il Trust Anchor recuperato dall'entry di servizio applicabile nella LoTE dei Provider of WRPRC (cioè, sotto il ServiceDigitalIdentity corrispondente al ServiceTypeIdentifier con valore http://uri.etsi.org/19602/SvcType/WRPRC/Revocation per il servizio fornito dal Provider of WRPRC).

   • validare la firma della SLT usando la catena del certificato di firma validata, seguendo EUDIW Attestation Signature Validation.

   • validare il modello dati della SLT secondo Token Status List (WRPRC Profile).

   • decomprimere il valore status_list.lst, recuperare l'entry a un bit corrispondente al membro status.status_list.idx del WRPRC, e interpretare 0x00 come VALID e 0x01 come INVALID.

8. Consistency check: verificare che il subject e i campi del Wallet-Relying Party Registration Certificate siano coerenti con l'interazione.

Nota

Nel Passo 5 (Path validation), il Trust Anchor Certificate necessario per validare il WRPRC NON DEVE essere incluso nella catena di certificati e DEVE essere sempre recuperato dalla LoTE appropriata.

6.2.6.1.2. Authorization Artifacts Validation: Esito

• Se tutti i passi hanno successo e il Wallet-Relying Party Registration Certificate è nello stato VALID, la Wallet Unit DEVE impostare authz_art_state a CERTIFICATE_VALID.

• Se un qualsiasi passo fallisce, o se nessun Wallet-Relying Party Registration Certificate è incluso, la Wallet Unit DEVE impostare authz_art_state a CERTIFICATE_INVALID. Durante la Presentazione di Credenziali la Wallet Unit DEVE avvisare l'Utente ([EIDAS-ARF] RPRC_17). La Wallet Unit NON DEVE interrogare il Register. Durante l'Emissione di Credenziali la Wallet Unit DEVE avvisare l'Utente. La Wallet Unit NON DEVE richiedere l'emissione ([EIDAS-ARF] RPRC_22a). La Wallet Unit NON DEVE interrogare il Register come fallback ([EIDAS-ARF] RPRC_22).

Nota

Durante la Presentazione di Credenziali la richiesta DEVE recare per valore il Wallet-Relying Party Registration Certificate dell'Authorization Subject, anche quando la Wallet-Relying Party autenticata è un Relying Party Intermediary ([EIDAS-ARF] RPRC_19). Tale certificato identifica la Relying Party intermediata.

6.2.6.2. Authorization Validation

La Authorization Validation DEVE seguire la Authorization Artifacts Validation quando authz_art_state == CERTIFICATE_VALID. Se authz_art_state == CERTIFICATE_INVALID, la Wallet Unit NON DOVREBBE eseguire alcuna Authorization Validation, poiché non può modificare la Authorization Decision finale.

6.2.6.2.1. Authorization Validation: Input

La Wallet Unit DEVE basare la Authorization Validation solo su:

• la Wallet-Relying Party autenticata e il contesto di interazione, autorevoli solo per l'identità della Wallet-Relying Party.

• un Authorization Artifact validato, cioè un Wallet-Relying Party Registration Certificate, autorevole per l'identità del subject, le entitlement, l'uso previsto, l'ambito registrato, le relazioni di intermediario, i dati specifici dell'emissione e i riferimenti alla privacy policy, come definito in [ETSI TS 119 475].

• un'Embedded Disclosure Policy verificata, REQUIREDA quando fornita dall'Attestation Provider durante l'Emissione di Credenziali, autorevole quando presente.

Ove il contesto della Wallet-Relying Party autenticata sia in conflitto con l'identità o il binding di intermediario nel contesto di autorizzazione verificato, la Wallet Unit DEVE produrre NOT_AUTHORIZED, non sovrascrivibile.

6.2.6.2.2. Authorization Validation: Esito

La Wallet Unit DEVE produrre le variabili authz_val_state e edp_state, entrambe inizializzate a none.

6.2.6.2.3. Authorization Validation: Processo

1. Binding verification. La Wallet Unit DEVE assicurare che l'entità autenticata sia la stessa entità descritta nei dati di autorizzazione. L'identità della Wallet-Relying Party è l'organizationIdentifier del subject del Wallet-Relying Party Access Certificate (clausola 5.1.4 di [ETSI EN 319 412-1]. Il profilo del Wallet-Relying Party Access Certificate è definito in [ETSI TS 119 411-8]).

   • Credential Issuance. La Wallet Unit DEVE abbinare l'identificatore del Credential Issuer con il sub del Wallet-Relying Party Registration Certificate e con l'issuer_info.data.identifier dei Metadata del Credential Issuer ([EIDAS-ARF] RPRC_22b).

   • Credential Presentation. La Wallet Unit DEVE prima assumere lo scenario diretto e abbinare l'identificatore della Relying Party nel Wallet-Relying Party Access Certificate (organizationIdentifier o serialNumber) con il sub del Wallet-Relying Party Registration Certificate, e con il verifier_info.data.identifier del Request Object nel Remote Flow oppure il docRequest.itemsRequest[].requestInfo.EUWrpRegistrarInfo.identifier nel Proximity Flow. Se l'abbinamento fallisce, la Wallet Unit DEVE tentare lo scenario intermediato ([EIDAS-ARF] RPRC_17a): il subject del WRPAC è l'Intermediary, il WRPRC identifica una Relying Party diversa, e l'oggetto intermediary del WRPRC identifica questo Intermediary ([EIDAS-ARF] RPRC_04). L'associazione di un WRPAC distinto a quella Relying Party e a quel Service è rinviata come specificato in Register of WRPs.

   Se la Binding verification fallisce, la Wallet Unit DEVE interrompere la Authorization Validation e impostare authz_val_state a BINDING_FAILED. Se lo scenario diretto ha successo, la Wallet Unit DEVE rendere disponibili all'Utente l'identità e il Servizio della Relying Party, e l'uso previsto della richiesta. Se lo scenario intermediato ha successo, la Wallet Unit DEVE rendere disponibili all'Utente l'identità e il Servizio della Relying Party intermediata e l'uso previsto della richiesta. NON DEVE visualizzare i trade name dell'Intermediary o del Servizio dell'Intermediary ([EIDAS-ARF] RPI_07). Le modalità di presentazione di queste informazioni sono definite nelle sezioni rilevanti di interazione Utente della specifica IT-Wallet. Non è prevista una lookup opzionale da parte dell'Utente nel Registrar della relazione di intermediario ([EIDAS-ARF] RPI_07a è vuoto).

2. Entitlement verification. La Wallet Unit DEVE verificare che le entitlement dell'Authorization Subject corrispondano al ruolo atteso. La Wallet Unit DEVE analizzare il campo entitlements del Wallet-Relying Party Registration Certificate e controllare che contenga l'URI di entitlement atteso per l'interazione, tra quelli definiti nell'Allegato A.2 di [ETSI TS 119 475]:

   • https://uri.etsi.org/19475/Entitlement/PID_Provider per i PID Provider, durante l'Emissione di PID.

   • https://uri.etsi.org/19475/Entitlement/QEAA_Provider per i QEAA Provider, durante l'Emissione di QEAA.

   • https://uri.etsi.org/19475/Entitlement/PUB_EAA_Provider per i PuB-EAA Provider, durante l'Emissione di PuB-EAA.

   • https://uri.etsi.org/19475/Entitlement/Non_Q_EAA_Provider per gli EAA Provider, durante l'Emissione di EAA.

   • https://uri.etsi.org/19475/Entitlement/Service_Provider per le Relying Party, durante la Presentazione di Credenziali.

   Se l'entitlement attesa non è presente, la Wallet Unit DEVE impostare authz_val_state a WRONG_ENTITLEMENT.

3. Attestation Type verification. Durante l'Emissione di Credenziali, la Wallet Unit DEVE verificare che il PID o il Tipo di Attestation in emissione sia registrato per il Credential Issuer. Un PID Provider che emette PID PUÒ omettere questo passo. Altrimenti la Wallet Unit DEVE abbinare l'array provides_attestations del Wallet-Relying Party Registration Certificate (definito nella Tabella 8 di [ETSI TS 119 475] e in [EIDAS-ARF] RPRC_23) rispetto alle chiavi credential_configurations_supported dei Metadata del Credential Issuer ([OpenID4VCI]). L'abbinamento DEVE essere esatto e case sensitive, su vct per SD-JWT VC e su docType per mdoc. Se non trovato, la Wallet Unit DEVE impostare authz_val_state a ATTESTATION_TYPE_NOT_REGISTERED.

4. Scope Comparison. Durante la Presentazione di Credenziali, la Wallet Unit DEVE verificare che gli Attestati Elettronici e gli attributi richiesti ricadano nell'ambito registrato, recato nell'array credentials del Wallet-Relying Party Registration Certificate incluso nella richiesta (definito nella Tabella 9 di [ETSI TS 119 475] e in [EIDAS-ARF] RPRC_21).

   • Remote Flow: estrarre gli Attestati Elettronici e gli attributi richiesti dalla dcql_query del Request Object ([OpenID4VP]) e abbinarli rispetto alle entry credentials, confrontando format e meta (vct_values per SD-JWT VC) e gli attributi richiesti rispetto ai path claim.

   • Proximity Flow: estrarre il docType e i nameSpaces dai docRequests della mdoc Request ([ISO18013-5]) e abbinarli rispettivamente rispetto a credentials[].meta.doctype_value e credentials[].claim.

   L'abbinamento DEVE essere esatto e case sensitive. Se un qualsiasi Attestato Elettronico o attributo richiesto non è registrato, la Wallet Unit DEVE impostare authz_val_state a OVERASKING_DETECTED e identificare gli attributi o gli Attestati Elettronici non registrati.

   Se tutti i controlli precedenti applicabili all'interazione sono soddisfatti, la Wallet Unit DEVE impostare authz_val_state a VERIFICATION_PASSED.

5. Embedded Disclosure Policy evaluation. Durante l'Emissione di Credenziali, la Wallet Unit DEVE risolvere l'EDP identificata dai metadata della Credenziale selezionata. La Wallet Unit DEVE associare la policy risolta a ciascuna EAA emessa. Durante la Presentazione di Credenziali, per ciascun Attestato Elettronico e per ciascun attributo richiesto, la Wallet Unit DEVE valutare l'EDP associata prima del consenso dell'Utente. Se un URI di EDP non può essere risolto nella policy esatta inclusa o precaricata, la valutazione EDP DEVE fallire. Tale fallimento non è EDP_NOT_SATISFIED ed è non-overridable, come specificato in Authorization Decision and Override Rules. Un'EDP NON DEVE essere valutata per un PID. Secondo il policy_type definito nella Sezione 4.2.5 di [ETSI TS 119 472-3]:

   • no_policy: non si applica alcuna restrizione.

   • authorized_rp_only: solo le Relying Party nell'elenco authorized_parties sono autorizzate. La Wallet Unit DEVE recuperare l'identificatore univoco a livello UE dal WRPRC nella richiesta (sub) e confrontarlo con authorized_parties[].identifier ([EIDAS-ARF] EDP_02, Reg_32). L'identificatore di Service di tale coppia è rinviato come specificato in Register of WRPs. Ove un elemento authorized_parties identifichi la parte tramite entitlement_uri, la Wallet Unit DEVE abbinare tale URI rispetto alle entitlement o sub-entitlement dello stesso WRPRC. Un abbinamento sull'identificatore o su entitlement_uri è sufficiente. Se nessuno dei due corrisponde, la Wallet Unit DEVE considerare fallita la valutazione EDP. La Wallet Unit NON DEVE usare identificatori dal WRPAC, incluso il subject DN della Relying Party di un Wallet-Relying Party Access Certificate. Se authorized_parties[].subject_dn è presente, è la codifica ETSI definita in Embedded Disclosure Policy (EDP) e NON DEVE essere usato come sostituto di sub. In una presentazione intermediata il WRPRC nella richiesta è quello della Relying Party intermediata.

   • specific_root_of_trust: solo le Relying Party autenticate il cui Wallet-Relying Party Access Certificate è firmato sotto uno dei trusted_roots sono autorizzate ([EIDAS-ARF] EDP_03). La Wallet Unit DEVE abbinare ciascuna entry trusted_roots per issuer_dn usando il confronto LDAP DN e serial_number usando il confronto intero. DEVE confrontare tutti i certificati nel signing path del WRPAC con quei certificati root o intermedi autorizzati. Il path comprende il WRPAC presentato in x5c e il Trust Anchor recuperato dalla LoTE dei Provider of WRPAC. Se nessuno di questi certificati è incluso nell'elenco, la Wallet Unit DEVE considerare fallita la valutazione EDP. In una presentazione intermediata la Relying Party autenticata è l'Intermediary. La Wallet Unit DEVE confrontare il signing path del WRPAC di tale Intermediary.

   La Wallet Unit DEVE applicare la policy di base alla Credenziale e ogni regola specifica di attributo riconosciuta al path del claim nel formato di Credenziale selezionato. La Wallet Unit DEVE informare l'Utente dei risultati a livello di Credenziale e a livello di attributo, incluso il link alle informazioni sulla policy quando presente, prima del consenso. La Wallet Unit NON DEVE divulgare un attributo quando il risultato a livello di Credenziale o il risultato a livello di attributo applicabile di una policy risolta non è soddisfatto, salvo che l'Utente superi tale risultato come specificato in Authorization Decision and Override Rules. Le estensioni sconosciute POSSONO essere ignorate solo quando ciò non interrompe l'elaborazione delle regole riconosciute.

   Se i controlli applicabili di una policy risolta sono soddisfatti, o non è presente alcuna EDP per una EAA, la Wallet Unit DEVE impostare il risultato della Credenziale o dell'attributo a EDP_SATISFIED. Se una policy risolta non consente la Credenziale o l'attributo, la Wallet Unit DEVE impostare tale risultato a EDP_NOT_SATISFIED.

6.2.6.2.4. Authorization Validation: Esito finale

Al termine della Authorization Validation la Wallet Unit DEVE produrre i valori authz_val_state e edp_state. La tabella seguente sintetizza i codici.

Tabella 6.4 Codici di Stato della Authorization Validation

Variabile	Code	Fase	Significato
authz_art_state	CERTIFICATE_VALID	both	Il formato, la firma, il trust anchor e lo status del Wallet-Relying Party Registration Certificate sono verificati con successo.
authz_art_state	CERTIFICATE_INVALID	both	Un controllo di formato, firma, trust anchor o status fallisce sul certificato di registrazione presentato, oppure nessun Wallet-Relying Party Registration Certificate è incluso. Durante la presentazione la Wallet Unit DEVE avvisare l'Utente ([EIDAS-ARF] RPRC_17). La Wallet Unit NON DEVE interrogare il Register. Durante l'emissione la Wallet Unit DEVE avvisare l'Utente. La Wallet Unit NON DEVE richiedere l'emissione ([EIDAS-ARF] RPRC_22a). La Wallet Unit NON DEVE interrogare il Register come fallback ([EIDAS-ARF] RPRC_22).
authz_val_state	WRONG_ENTITLEMENT	both	Le entitlement dell'Authorization Subject non corrispondono al ruolo atteso per il contesto attivo.
authz_val_state	BINDING_FAILED	both	Il binding di identità tra la Wallet-Relying Party autenticata e i dati di autorizzazione fallisce.
authz_val_state	ATTESTATION_TYPE_NOT_REGISTERED	issuance	Il Tipo di Attestation in emissione non è trovato nei profili registrati del Credential Issuer.
authz_val_state	OVERASKING_DETECTED	presentation	La Relying Party richiede Attestati Elettronici, formati o namespace che eccedono il suo ambito registrato.
authz_val_state	VERIFICATION_PASSED	both	Il binding di identità, la verifica delle entitlement, l'abbinamento delle attestation e il controllo dell'ambito sono tutti superati.
edp_state	EDP_SATISFIED	presentation	Non si applica alcuna restrizione di Embedded Disclosure Policy, oppure la Credenziale o l'attributo e la Relying Party soddisfano la policy risolta.
edp_state	EDP_NOT_SATISFIED	presentation	Una Embedded Disclosure Policy risolta non consente questa Credenziale o questo attributo a questa Relying Party. La Wallet Unit informa l'Utente, che consente o nega la disclosure, come specificato in Authorization Decision and Override Rules ([EIDAS-ARF] EDP_07). Questo codice non si applica all'emissione.

La Authorization Decision finale, AUTHORIZED o NOT_AUTHORIZED, è elaborata dai valori authz_art_state, authz_val_state e edp_state, come definito in Authorization Decision and Override Rules.

Fig. 6.2 Diagramma di flusso dell'algoritmo di Autorizzazione EUDIW.

6.2.7. EUDIW Metadata Retrieval and Validation

All'interno del Trust Framework EUDIW i metadata di una Wallet-Relying Party sono ottenuti attraverso il flusso di protocollo e la loro autenticità è stabilita attraverso il Wallet-Relying Party Access Certificate. Questo si applica all'Emissione di Credenziali e alla Presentazione di Credenziali nel Remote Flow. Nel Proximity Flow non è eseguito un recupero di metadata separato: l'identità della Relying Party è stabilita attraverso l'mdoc reader authentication (vedi EUDIW Authentication).

6.2.7.1. Metadata Retrieval

La Wallet Unit ottiene i metadata della Wallet-Relying Party in base all'interazione:

• Durante l'Emissione di Credenziali, i Metadata del Credential Issuer sono ottenuti dall'endpoint well-known dei metadata del Credential Issuer, come definito in [OpenID4VCI] (vedi Endpoint Metadata).

• Durante la Presentazione di Credenziali nel Remote Flow, i metadata della Relying Party sono recati nel Request Object della richiesta di autorizzazione, come definito in [OpenID4VP] (vedi Request Object).

6.2.7.2. Metadata Validation

L'autenticità dei metadata recuperati è stabilita attraverso il Wallet-Relying Party Access Certificate. Durante l'Emissione di Credenziali, i Metadata del Credential Issuer sono firmati dall'Attestation Provider come definito nella Sezione 12.2.3 di [OpenID4VCI], fornendo la catena del Wallet-Relying Party Access Certificate nell'header x5c protetto della firma JOSE. Il primo certificato DEVE essere il certificato di accesso di firma. Il trust anchor DEVE essere escluso.

La Wallet Unit DEVE validare la catena di certificati e la firma prima di usare il payload. La Wallet Unit DEVE usare tale payload autenticato come unica fonte di metadata per l'interazione, inclusi issuer_info, i grant, la policy di riuso e l'EDP.

Durante la Presentazione di Credenziali nel Remote Flow, il Request Object è firmato dalla Relying Party e fornisce lo stesso header x5c. In entrambi i casi la Wallet Unit valida la firma e la catena di certificati come definito in EUDIW Authentication. La Wallet Unit DEVE usare solo i metadata la cui firma è verificata rispetto al Wallet-Relying Party Access Certificate autenticato.

6.3. Trust Evaluation in the National Trust Framework

Questa sezione definisce le procedure di trust evaluation del Trust Framework Nazionale. Gli Entity Type Identifier e i metadata di ciascun ruolo, usati durante queste procedure, sono definiti in Entity Type Identifiers and Metadata, secondo tale profilo. Le regole di selezione che definiscono quando queste procedure si applicano sono dettagliate in Trust Framework Selection. Queste procedure si applicano quando la Trust Evaluated Party è autenticata sotto il Trust Framework Nazionale.

I Trust Artifact usati durante queste procedure, cioè l'Entity Configuration, i Subordinate Statement, i Trust Mark, sono definiti in National Trust Artifacts.

Le procedure definite in questa sezione sono eseguite all'interno dei flussi operativi di Emissione e Presentazione (vedi Flussi relativi agli Attestati Elettronici). I parametri su cui operano, come il Request Object firmato, la mdoc Request, i Metadata di tutte le Entità coinvolte e il modello dati degli Attestati Elettronici ricevuti, sono definiti nelle rispettive sezioni (vedi Entità, Request Object per il Remote Flow, e Formato Attestato Elettronico SD-JWT-VC e Formato Attestato Elettronico mdoc-CBOR per i formati degli Attestati Elettronici).

6.3.1. Trust Evaluation Processes by Context

Le procedure sono definite in forma generale, con un Trust Evaluator e una Trust Evaluated Party e la tabella seguente definisce quale entità agisce in quale ruolo, quando e per quale scopo.

Tabella 6.5 Processi di Trust Evaluation per Entità e Contesto nel Trust Framework Nazionale

Entità	Contesto	In qualità di Trust Evaluator, implementa	In qualità di Trust Evaluated Party, fornisce
Wallet Unit	Emissione di una Credenziale esclusivamente nazionale	Sul Credential Issuer: Federation Entity Authentication Authorization Metadata Retrieval and Validation Sull'Attestato ricevuto: Signing Trust Anchor Validation Procedure	La Wallet Instance Attestation con la prova di possesso della chiave attestata, validata come definito in Wallet Unit Authentication.
Wallet Unit	Presentazione remota, prefisso openid_federation	Sulla Relying Party: Federation Entity Authentication Authorization, incluso l'Overasking Check Metadata Retrieval and Validation	Nessun artifact a livello di entità è richiesto dalla Wallet Unit.
Wallet Unit	Presentazione in prossimità	Sulla Relying Party: Relying Party Proximity Authentication Authorization, incluso l'Overasking Check, sul Trust Mark di registrazione fornito per valore in requestInfo.euWrprc di ogni ItemsRequest ISO	Nessun artifact a livello di entità è richiesto dalla Wallet Unit.
Credential Issuer	Emissione di Credenziali esclusivamente nazionali	Sulla Wallet Unit: Wallet Unit Authentication	L'Entity Configuration (Entity Configuration) con i Trust Mark di registrazione (Trust Mark registration-entity), e gli artifact di emissione firmati con chiavi risolvibili attraverso la federazione, validati come definito in Federation Entity Authentication. Per il formato mdoc, il certificato Document Signer nell'header x5chain, validato come definito in X.509 Certificate Chain Validation.
Relying Party	Presentazione remota, prefisso openid_federation	Sugli Attestati ricevuti: Signing Trust Anchor Validation Procedure Sul Wallet Provider, per invocare il Wallet attraverso il meccanismo di discovery nazionale (vedi la nota di seguito): Metadata Retrieval and Validation	L'Entity Configuration (Entity Configuration) con i Trust Mark di registrazione (Trust Mark registration-entity), e il Request Object firmato con chiavi risolvibili attraverso la federazione, incluso l'header trust_chain quando è attesa una validazione offline, validati come definito in Federation Entity Authentication e Authorization.
Relying Party Intermediary	Presentazione remota, in qualità di Federation Intermediate di una Relying Party affiliata	Non agisce come Trust Evaluator nei flussi operativi.	L'Entity Configuration (Entity Configuration) con il Trust Mark di registrazione intermediate (vedi Trust Mark Types and Schema), e i Subordinate Statement delle sue Relying Party affiliate. L'Intermediary è validato come parte della Trust Chain della Relying Party affiliata, i cui authority_hints puntano a esso. La Wallet Unit DEVE verificare che la Trust Chain della Relying Party affiliata sia validata attraverso un Intermediary riconosciuto o direttamente attraverso il Federation Trust Anchor, e informa l'Utente come definito in User Transparency.

Nota

Nel remote flow la Relying Party invoca il Wallet attraverso app link (universal link) invece di custom URL scheme. Questa scelta di IT-Wallet richiede che la Relying Party ottenga e validi preventivamente i metadata del Wallet Provider, costruendo la Trust Chain relativa al Wallet Provider (Metadata Retrieval and Validation), come parte del Wallet Metadata Retrieval Flow (vedi Flusso di Recupero dei Wallet Metadata e la Selection Page in Design dell'Esperienza Utente). Questo meccanismo è specifico del remote flow e non si applica al proximity flow.

6.3.2. Federation Trust Anchor Distribution and Validation

6.3.2.1. Federation Trust Anchor Distribution

La configurazione della federazione è pubblicata dal Federation Trust Anchor all'interno della sua Entity Configuration, disponibile al path web well-known .well-known/openid-federation. Tutte le Entità DEVONO ottenere la configurazione della federazione prima di entrare nella fase operativa. Tutte le Entità DEVONO mantenere aggiornata la configurazione della federazione. La configurazione della federazione contiene le chiavi pubbliche del Federation Trust Anchor per le operazioni di firma e gli endpoint di federazione (vedi Entity Configuration).

Il Federation Trust Anchor DEVE distribuire le proprie Federation Public Keys attraverso meccanismi sicuri out-of-band. Quando è richiesta una validazione del Federation Trust Anchor, tutte le Entità DEVONO confrontare le chiavi pubbliche del Federation Trust Anchor con quelle ottenute dall'Entity Configuration del Federation Trust Anchor. Tutte le Entità DEVONO scartare qualsiasi chiave che non corrisponda.

Nota

All'interno di IT-Wallet il canale out-of-band è il canale di contatto stabilito con l'Entità durante il processo di registrazione (vedi Entity Registration).

Le Entità POSSONO inoltre conservare una copia locale nota delle chiavi pubbliche del Federation Trust Anchor. Una copia locale nota PUÒ essere usata solo finché è valida. Una copia locale nota DEVE essere aggiornata quando si verifica una rotazione di chiave.

L'Entity Configuration del Federation Trust Anchor fornisce inoltre i Signing Trust Anchor della PKI di firma X.509, usati per verificare le Credenziali ancorate a questo framework, e i National Wallet Trust Anchor usati per verificare le Wallet Unit Attestation e le Key Attestation. La loro distribuzione e validazione sono definite in Signing Trust Anchor Distribution e Wallet Trust Anchor Distribution, rispettivamente, in quanto concernono la verifica di un'attestation e non la validazione del Federation Trust Anchor.

6.3.2.2. Federation Trust Anchor Validation

6.3.2.2.1. Federation Trust Anchor Validation: Input

• Il Federation Entity Identifier del Federation Trust Anchor.

• Le chiavi pubbliche del Federation Trust Anchor ottenute out-of-band, oppure una copia locale nota.

6.3.2.2.2. Federation Trust Anchor Validation: Esito

• L'insieme validato delle Federation Public Keys del Federation Trust Anchor.

• La configurazione della federazione, inclusi gli endpoint di federazione.

6.3.2.2.3. Federation Trust Anchor Validation: Processo

La verifica dell'Entity Configuration è la validazione dell'Entity Statement definita in OID-FED Sezione 3.2, applicata all'Entity Configuration self-issued del Federation Trust Anchor e completata, all'interno di IT-Wallet, con il confronto out-of-band delle chiavi.

1. Recuperare l'Entity Configuration dall'endpoint well-known del Federation Trust Anchor, servita con il media type application/entity-statement+jwt.

2. Verificare che l'Entity Configuration sia un JWT firmato con iss e sub uguali all'identificatore del Federation Trust Anchor, e verificare la sua firma con una delle chiavi contenute nel suo jwks. Gli algoritmi di firma supportati sono definiti in Algoritmi Crittografici.

3. Confrontare le chiavi in jwks con le chiavi ottenute out-of-band o con la copia locale nota, scartando le chiavi che non corrispondono.

4. Controllare la validità temporale dell'Entity Configuration attraverso i claim iat e exp.

5. Estrarre gli endpoint di federazione dai metadata federation_entity, e il claim trust_mark_issuers (vedi Entity Configuration).

Se un qualsiasi passo fallisce, la configurazione della federazione NON DEVE essere usata.

6.3.2.3. Federation Trust Anchor Key Rotation and Historical Verification

Quando è richiesto di validare una Trust Chain nel tempo, anche se il Federation Trust Anchor ha cambiato le proprie chiavi crittografiche per la firma digitale, l'endpoint Federation Historical Keys rende sempre disponibili le chiavi non più usate per le verifiche storiche delle firme. Questa proprietà supporta la non ripudiabilità delle attestation a lunga durata.

Quando il Federation Trust Anchor ruota le proprie chiavi, le nuove chiavi sono distribuite con lo stesso meccanismo out-of-band usato per la distribuzione iniziale. Le Entità che conservano una copia locale nota delle chiavi del Federation Trust Anchor DEVONO aggiornare di conseguenza quella copia.

6.3.3. Trust Chain Validation

La Trust Chain Validation è una procedura tecnica usata dai processi di trust evaluation definiti in questa sezione per scopi diversi. A seconda che un'entità stia valutando una dichiarazione di federazione o che un artifact rechi la catena di certificati X.509 usata per la sua firma, si applicano due procedure diverse di Trust Chain Validation.

6.3.3.1. Federation Trust Chain

La Trust Chain è una sequenza di dichiarazioni verificate che valida la conformità di un'Entità alla federazione. Ha una data di scadenza, oltre la quale DEVE essere rinnovata per ottenere metadata freschi e aggiornati. La data di scadenza della Trust Chain è determinata dal timestamp di scadenza più precoce tra tutte le dichiarazioni. Nessuna Entità può forzare la data di scadenza della Trust Chain a essere superiore a quella configurata dal Federation Trust Anchor.

Questa procedura verifica la Trust Chain. La derivazione dei metadata finali del subject, ottenuta applicando le metadata policy recate dalle dichiarazioni della Trust Chain, è definita in Metadata Retrieval and Validation. Secondo OID-FED, la verifica della catena e la derivazione dei metadata finali è indicata come la resolution of a Trust Chain.

La Trust Chain è costruita attraverso il processo di Federation Entity Discovery definito in OID-FED:

• Il Trust Evaluator recupera l'Entity Configuration del subject.

• Segue gli authority_hints per raccogliere i Subordinate Statement emessi dalle entità superiori.

• Continua fino a raggiungere il Federation Trust Anchor.

La Trust Chain PUÒ anche essere mantenuta valida con il fast renewal method definito in OID-FED Sezione 3.1.3, che evita un processo di discovery completo recuperando i Subordinate Statement direttamente attraverso il loro claim source_endpoint.

La Trust Chain PUÒ anche essere fornita staticamente dal subject all'interno di un artifact firmato, usando il parametro di header JOSE trust_chain definito in OID-FED Sezione 4.3. All'interno di IT-Wallet l'header trust_chain è recato nel Request Object del flusso di presentazione (vedi Request Object) e negli artifact firmati del flusso di emissione (OPENID4VCI Appendice F.1 e Sezione 12.2.3). Una Trust Chain fornita staticamente richiede di essere aggiornata solo quando è disponibile una connessione internet, mentre DEVE essere aggiornata quando risulta scaduta.

La revoca di un'Entità è realizzata con l'indisponibilità del Subordinate Statement a essa relativo. Se il Federation Trust Anchor o il suo Intermediate non pubblica un Subordinate Statement valido, o se ne pubblica uno scaduto o non valido, il subject del Subordinate Statement DEVE essere inteso come non valido o revocato. Per il Trust Evaluator, questo controllo in tempo reale dello status di revoca è possibile solo online, recuperando il Subordinate Statement al momento della verifica.

Le Trust Chain possono anche essere verificate offline, usando una delle chiavi pubbliche del Federation Trust Anchor. In questo caso il controllo in tempo reale della revoca non è disponibile, e si fa affidamento sulla freshness della Trust Chain.

La validità massima di una Trust Chain può essere imposta dal Federation Trust Anchor, che la imposta attraverso la scadenza delle proprie dichiarazioni, come descritto sopra. Indipendentemente da tale validità, ai fini dello status di revoca delle Entità una Trust Chain costruita più di 24 ore prima del momento della verifica NON DOVREBBE essere considerata valida. Quando è necessario fare affidamento sullo status di revoca di un'Entità e un controllo online in tempo reale non è disponibile, una Trust Chain più vecchia di 24 ore DOVREBBE essere rinnovata prima che l'interazione possa procedere. Questo limite di 24 ore si applica all'età della Trust Chain, calcolata dalla sua costruzione, ed è indipendente dalla sua data di scadenza.

6.3.3.1.1. Federation Trust Chain: Input

• Il Federation Entity Identifier del subject, oppure una Trust Chain fornita staticamente.

• Le Federation Public Keys del Federation Trust Anchor validate (vedi Federation Trust Anchor Distribution).

6.3.3.1.2. Federation Trust Chain: Esito

• Una Trust Chain validata, cioè l'insieme ordinato di dichiarazioni verificate, con la sua data di scadenza.

6.3.3.1.3. Federation Trust Chain: Processo

I passi seguenti verificano una Trust Chain secondo OID-FED, con il puntatore alla parte rilevante della specifica per ciascun passo:

1. Ottenere l'Entity Configuration del subject, oppure prendere il primo elemento della Trust Chain fornita staticamente.

2. Raccogliere i Subordinate Statement seguendo gli authority_hints fino al Federation Trust Anchor, oppure prenderli dalla Trust Chain statica. I Subordinate Statement sono ottenuti dal fetch endpoint (OID-FED Sezione 8.1).

3. Validare ciascuna dichiarazione come Entity Statement secondo OID-FED Sezione 3.2, cioè verificarne la firma, la coerenza dei claim iss e sub, e la sua validità temporale. Ciascun Subordinate Statement è verificato con le Federation Entity Keys del suo issuer, attestate dalla dichiarazione superiore.

   • La dichiarazione emessa dal Federation Trust Anchor è verificata con le chiavi validate del Federation Trust Anchor.

   • L'Entity Configuration del subject è verificata con le chiavi attestate nel Subordinate Statement a essa relativo.

4. Applicare i vincoli recati nei Subordinate Statement lungo la catena, come definito in OID-FED Sezione 6.2. In particolare, verificare che i metadata Entity Type pubblicati dal subject siano all'interno degli allowed_entity_types, considerando che l'Entity Type federation_entity è sempre consentito, e che il numero di Intermediate non ecceda il max_path_length impostato dai superiori.

5. Calcolare la scadenza della Trust Chain come il valore exp più precoce tra le dichiarazioni.

Se una qualsiasi verifica fallisce, la Trust Chain DEVE essere considerata non valida. Il subject NON DEVE essere considerato fidato sulla base di quella Trust Chain.

6.3.3.2. X.509 Certificate Chain Validation

Questa variante si applica quando un artifact è fornito insieme alla catena di certificati X.509 usata per la firma. Per gli artifact in formato JOSE la catena è recata nel parametro di header x5c, come definito in RFC 7515 e usato in IT-Wallet nel Request Object del flusso di presentazione (vedi Request Object). Per le Credenziali in formato mdoc la catena è recata nell'unprotected header x5chain (elemento 33) del Mobile Security Object, come definito in RFC 9360 e in Mobile Security Object. La catena contiene il certificato Document Signer e qualsiasi certificato intermedio. NON DEVE contenere il certificato Signing Trust Anchor, che è distribuito come definito in Signing Trust Anchor Distribution.

La validazione della catena di certificati è la path validation X.509 standard definita in RFC 5280#section-6, con il controllo dello status di revoca definito in RFC 5280 e RFC 6960. Il ciclo di vita dei certificati e i meccanismi di revoca, inclusa la CRL, sono definiti in Revocation Mechanisms. Questa è la stessa validazione della catena di certificati usata nel Trust Framework EUDIW (vedi X509 Certificate Chain Validation Algorithm). L'unica differenza è l'origine del trust anchor e l'estrazione aggiuntiva del Federation Entity Identifier. In questa sezione, per il Trust Framework Nazionale, i dettagli dell'algoritmo non sono ridefiniti.

All'interno del Trust Framework Nazionale si applica quanto segue.

• Il trust anchor della path validation è il Signing Trust Anchor applicabile, ottenuto come definito in Signing Trust Anchor Distribution.

• Il certificato end-entity reca l'OpenID Federation Entity Identifier del subject nell'URI subjectAltName. Questo è l'elemento che collega la firma X.509 all'identità di federazione del firmatario. Pertanto, la validazione estrae questo identificatore in modo che il processo chiamante possa verificare che il certificato che ha firmato l'artifact appartenga all'entità OpenID Federation attesa per quell'artifact. Il confronto rispetto all'identificatore atteso, per esempio l'iss della Credenziale, è eseguito dal processo chiamante (vedi Signing Trust Anchor Validation Procedure). Questa variante produce solo l'identificatore e non stabilisce di per sé quale identificatore sia atteso.

Nota

L'emissione di questi Certificati X.509 e l'operazione della PKI di firma sono definite nella procedura di onboarding e sono fuori dallo scope di questa sezione (vedi Onboarding Processes).

6.3.3.2.1. X.509 Certificate Chain Validation: Input

• La catena di certificati estratta dall'header dell'artifact, cioè il certificato Document Signer e qualsiasi certificato intermedio.

• Il certificato Signing Trust Anchor applicabile, ottenuto come definito in Signing Trust Anchor Distribution.

6.3.3.2.2. X.509 Certificate Chain Validation: Esito

• Il certificato end-entity validato.

• L'OpenID Federation Entity Identifier del firmatario, estratto dall'URI subjectAltName, da abbinare rispetto all'issuer atteso da parte del processo chiamante.

6.3.3.2.3. X.509 Certificate Chain Validation: Processo

1. Costruire la catena di certificati dal certificato end-entity al certificato Signing Trust Anchor.

2. Eseguire la path validation definita in RFC 5280#section-6, usando il Signing Trust Anchor come input trust anchor dell'algoritmo.

3. Verificare lo status di revoca dei certificati nel path, secondo RFC 5280 e RFC 6960.

4. Estrarre l'OpenID Federation Entity Identifier dall'URI subjectAltName del certificato end-entity, e restituirlo al processo chiamante per l'abbinamento rispetto all'issuer atteso.

Se un qualsiasi passo fallisce, la firma dell'artifact NON DEVE essere verificata con la catena di certificati presentata.

6.3.4. Signing Trust Anchor Distribution and Validation

Questo processo fornisce e valida la root of trust per la verifica dell'issuer data authentication di un'attestation.

Il Signing Trust Anchor è la root of trust della PKI X.509 usata per firmare gli Attestati Elettronici i cui Rulebook li ancorano al Trust Framework Nazionale.

È distinto dal Federation Trust Anchor di Federation Trust Anchor Distribution in quanto il Federation Trust Anchor è la root delle dichiarazioni di federazione, mentre un Signing Trust Anchor è la root di una catena di certificati che valida la firma di un'attestation. Il Federation Trust Anchor e un Signing Trust Anchor POSSONO essere operati dalla stessa organizzazione, ma sono relazioni di fiducia diverse, con cicli di vita diversi e canali di revoca diversi.

PUÒ esserci più di un Signing Trust Anchor. Ciascun Credential Issuer che firma Credenziali in questo framework usa un Signing Trust Anchor come root dei propri certificati Document Signer. Credential Issuer diversi PUÒ fare affidamento su Signing Trust Anchor diversi.

6.3.4.1. Signing Trust Anchor Distribution

I Signing Trust Anchor sono distribuiti attraverso l'Entity Configuration del Federation Trust Anchor. Ciascun certificato Signing Trust Anchor è fornito nel parametro x5c di una JWK dedicata, distinta dalle Federation Entity Keys usate per firmare le dichiarazioni di federazione. Questo meccanismo di distribuzione è un'implementazione specifica di IT-Wallet e non è definito da OID-FED.

Le Entità POSSONO conservare una copia locale nota di un Signing Trust Anchor. Una copia locale nota di un Signing Trust Anchor PUÒ essere usata solo finché è valida. Una copia locale nota di un Signing Trust Anchor DEVE essere aggiornata quando il Signing Trust Anchor è ruotato.

Il risultato di questa distribuzione è, per ciascun Trust Evaluator, l'insieme dei certificati Signing Trust Anchor validati, ciascuno associato al Federation Entity Identifier dei Credential Issuer che vi fanno affidamento. Questo insieme è il materiale di trust anchor consumato dalla procedura di validazione seguente.

Nota

L'emissione dei certificati Document Signer e l'operazione della PKI di firma sono definite nella procedura di onboarding e non sono nello scope di questa sezione (vedi Onboarding Processes).

6.3.4.2. Signing Trust Anchor Validation Procedure

La procedura dipende dal formato dell'attestation.

Per le attestation in formato JOSE, come gli Attestati Elettronici in formato SD-JWT VC e la Wallet Instance Attestation, l'issuer è identificato dal claim iss e la chiave di verifica della firma è referenziata dal parametro di header kid. La chiave DEVE essere risolta all'interno dei metadata finali dell'issuer, ottenuti attraverso la Federation Trust Chain. L'artifact PUÒ recare l'header JOSE trust_chain per consentire la validazione senza un nuovo processo di discovery.

Per le Credenziali in formato mdoc il Mobile Security Object reca il certificato Document Signer nell'header x5chain. La firma è verificata con tale certificato. Il Signing Trust Anchor dell'issuer è validato estraendo l'OpenID Federation Entity Identifier dall'URI subjectAltName e validando la catena di certificati rispetto al Signing Trust Anchor applicabile ottenuto come definito in Signing Trust Anchor Distribution.

6.3.4.2.1. Signing Trust Anchor Validation Procedure: Input

• L'attestation firmata.

• La configurazione validata del Federation Trust Anchor e il Signing Trust Anchor applicabile.

6.3.4.2.2. Signing Trust Anchor Validation Procedure: Esito

• Il trust anchor validato e la chiave o il certificato di firma per l'attestation.

• La conferma che la chiave di firma appartiene all'issuer dell'attestation.

6.3.4.2.3. Signing Trust Anchor Validation Procedure: Processo

1. Per gli artifact JOSE, derivare i metadata finali dell'issuer dalla Federation Trust Chain (vedi Federation Trust Chain e Metadata Retrieval and Validation) e selezionare la chiave referenziata dall'header kid.

2. Per gli artifact mdoc, validare l'x5chain come definito in X.509 Certificate Chain Validation e verificare che l'OpenID Federation Entity Identifier nell'URI subjectAltName corrisponda all'issuer atteso.

3. Verificare la firma dell'attestation con la chiave o il certificato selezionato.

Nota

Quando richiesto, l'endpoint Federation Historical Keys e le CRL pubblicate DEVONO essere usati per assicurare che l'attestation fosse valida al momento dell'emissione o della presentazione (vedi Federation Trust Anchor Key Rotation and Historical Verification per maggiori dettagli).

Il ciclo di vita dei certificati di firma DEVE essere mantenuto allineato all'insieme di configurazione di federazione delle chiavi dell'issuer. Quando una chiave di firma è ruotata o non è più valida, la JWK corrispondente DEVE essere rimossa dall'Entity Configuration o ruotata. Il certificato correlato DEVE essere revocato di conseguenza. All'interno di IT-Wallet, quando la configurazione di federazione e lo status del certificato divergono, lo stato più restrittivo DEVE prevalere. Una chiave revocata in una delle due viste DEVE essere considerata revocata.

6.3.5. Wallet Trust Anchor Distribution and Validation

Questo processo stabilisce e valida il National Wallet Trust Anchor usato per validare le Wallet Instance Attestation e le Key Attestation emesse da un Wallet Provider nel Trust Framework Nazionale.

Il National Wallet Trust Anchor è la root della PKI X.509 usata dal Wallet Provider per firmare le Wallet Unit Attestation. È distinto dal Federation Trust Anchor, che è la root delle dichiarazioni di federazione, e dal Signing Trust Anchor usato da un Credential Issuer per gli Attestati Elettronici.

6.3.5.1. Wallet Trust Anchor Validation

Per una Wallet Instance Attestation o una Key Attestation che reca una catena di certificati di firma X.509, il Trust Evaluator DEVE validare la catena rispetto al National Wallet Trust Anchor applicabile prima di accettare la firma dell'attestation.

6.3.5.1.1. Wallet Trust Anchor Validation: Input

• La Wallet Instance Attestation o Key Attestation firmata e la sua catena di certificati di firma.

• La Trust Chain validata del Wallet Provider.

• Il National Wallet Trust Anchor applicabile ottenuto come definito in Wallet Trust Anchor Distribution.

6.3.5.1.2. Wallet Trust Anchor Validation: Esito

• Il certificato di firma del Wallet Provider e l'attestation validati.

• La conferma che il certificato di firma appartiene al Wallet Provider identificato dalla Trust Chain validata.

6.3.5.1.3. Wallet Trust Anchor Validation: Processo

1. Validare la Trust Chain del Wallet Provider e derivarne i metadata finali come definito in Federation Trust Chain e Metadata Retrieval and Validation.

2. Estrarre la catena di certificati di firma dall'header JOSE x5c della Wallet Instance Attestation o Key Attestation. Il National Wallet Trust Anchor NON DEVE essere incluso in questa catena.

3. Validare la catena di certificati rispetto al National Wallet Trust Anchor applicabile come definito in X.509 Certificate Chain Validation.

4. Verificare la firma dell'attestation con il certificato end-entity validato.

5. Verificare che il Federation Entity Identifier estratto dal certificato end-entity corrisponda al Wallet Provider identificato dalla Trust Chain.

6. Controllare la validità temporale e lo status di revoca dell'attestation come richiesto dal profilo di attestation applicabile.

Se un qualsiasi passo fallisce, la Wallet Instance Attestation o Key Attestation NON DEVE essere considerata emessa da un Wallet Provider fidato.

6.3.5.2. Wallet Trust Anchor Distribution

Il National Wallet Trust Anchor DEVE essere distribuito attraverso l'Entity Configuration del Federation Trust Anchor. DEVE essere rappresentato da una JWK dedicata il cui parametro x5c contiene il certificato National Wallet Trust Anchor. La JWK dedicata DEVE essere distinta dalle Federation Entity Keys usate per firmare le dichiarazioni di federazione.

Il Trust Evaluator DEVE validare l'Entity Configuration del Federation Trust Anchor e la Trust Chain del Wallet Provider prima di accettare il National Wallet Trust Anchor. La configurazione risultante DEVE associare il National Wallet Trust Anchor al Federation Entity Identifier del Wallet Provider.

Le Entità POSSONO conservare una copia locale nota del National Wallet Trust Anchor. Una copia locale nota del National Wallet Trust Anchor PUÒ essere usata solo finché è valida. Una copia locale nota del National Wallet Trust Anchor DEVE essere aggiornata quando il National Wallet Trust Anchor è ruotato.

Quando un Wallet Provider opera in entrambi i Trust Framework, il National Wallet Trust Anchor è lo stesso certificato del Trust Anchor notificato alla Commissione europea, come specificato in Revocation Trust Anchors.

6.3.6. Authentication Trust Anchor Distribution

Gli Authentication Trust Anchor sono distribuiti attraverso l'Entity Configuration del Federation Trust Anchor con lo stesso meccanismo usato per i Signing Trust Anchor. Ciascun certificato Authentication Trust Anchor è fornito nel parametro x5c di una JWK dedicata, distinta dalle Federation Entity Keys.

Un Authentication Trust Anchor è la root della PKI di autenticazione X.509 che emette i certificati di autenticazione della Relying Party usati nel Proximity Flow. Questi certificati seguono lo stesso profilo del Wallet-Relying Party Access Certificate (vedi Wallet-Relying Party Access Certificate (WRPAC) Profile).

Nota

L'emissione dei certificati di autenticazione della Relying Party e l'operazione della PKI di autenticazione sono definite nella procedura di onboarding e non sono nello scope di questa sezione (vedi Onboarding Processes).

6.3.7. Authentication

Il processo di Authentication ha lo scopo di affermare l'identità della Trust Evaluated Party. Sono definite tre procedure:

• Federation Entity Authentication si applica alle entità che pubblicano un'Entity Configuration, nel Remote Flow.

• Wallet Unit Authentication si applica alla Wallet Unit, che non è una Federation Entity.

• Relying Party Proximity Authentication si applica alla Relying Party nel Proximity Flow.

6.3.7.1. Federation Entity Authentication

L'identità della Trust Evaluated Party e le sue chiavi sono stabilite attraverso la Trust Chain. La Trust Evaluated Party autentica se stessa in una data interazione firmando l'artifact di protocollo di tale interazione con una chiave privata la cui parte pubblica è pubblicata nei suoi metadata finali, ottenuti risolvendo la Trust Chain. Il parametro di header kid, come definito in RFC 7515, referenzia una chiave contenuta nei metadata finali della Trust Evaluated Party. L'insieme completo dei parametri di header di ciascun artifact firmato è definito nella corrispondente sezione di protocollo.

6.3.7.1.1. Federation Entity Authentication: Input

• L'artifact di protocollo firmato.

• Il Federation Entity Identifier dichiarato dalla Trust Evaluated Party.

• Una Trust Chain relativa alla Trust Evaluated Party, fornita staticamente o costruita attraverso la discovery.

6.3.7.1.2. Federation Entity Authentication: Esito

Il Trust Evaluator DEVE produrre AUTHENTICATED o NON_AUTHENTICATED. Nel secondo caso la Trust Evaluated Party NON DEVE essere considerata autenticata. L'interazione NON DEVE continuare. La notifica all'Utente e il divieto di retry cross scheme sono definiti in Failure Handling.

6.3.7.1.3. Federation Entity Authentication: Processo

1. Validare la Trust Chain relativa alla Trust Evaluated Party e derivarne i metadata finali (vedi Federation Trust Chain e Metadata Retrieval and Validation).

2. Verificare che l'identificatore di entità recato dall'artifact, per esempio il claim client_id o iss, corrisponda al subject della Trust Chain.

3. Selezionare all'interno dei metadata finali la chiave pubblica referenziata dall'header kid.

4. Verificare la firma dell'artifact con la chiave selezionata.

La verifica con successo fornisce sia l'autenticazione della Trust Evaluated Party sia la prova di possesso della sua chiave privata.

6.3.7.2. Wallet Unit Authentication

La Wallet Instance Attestation convoglia la chiave pubblica della Wallet Unit che è usata per validare la firma sulla Wallet Instance Attestation. Il formato e il flusso di emissione sono definiti in Emissione della Wallet Instance Attestation.

La valutazione DEVE seguire il modello definito in OpenID Federation for Wallet Architectures. La Wallet Unit si autentica con un meccanismo di Client authentication che fornisce la Wallet Instance Attestation emessa dal suo Wallet Provider, insieme alla prova di possesso della chiave attestata. Nel flusso di emissione questo è realizzato con OAuth 2.0 Attestation-Based Client Authentication, cioè i parametri OAuth-Client-Attestation e OAuth-Client-Attestation-PoP (OAUTH-ATTESTATION-CLIENT-AUTH), come descritto in OPENID4VCI. Per stabilire la fiducia nella Wallet Unit, il Trust Evaluator DEVE:

• Stabilire la fiducia nel Wallet Provider che ha emesso la Wallet Instance Attestation.

• Validare la Wallet Instance Attestation come definito in Wallet Trust Anchor Validation usando il National Wallet Trust Anchor.

6.3.7.2.1. Wallet Unit Authentication: Input

• La Wallet Instance Attestation presentata dalla Wallet Unit.

• La prova di possesso della chiave attestata nella Wallet Instance Attestation.

• Una Trust Chain relativa al Wallet Provider.

6.3.7.2.2. Wallet Unit Authentication: Esito

Il Trust Evaluator DEVE produrre AUTHENTICATED o NON_AUTHENTICATED per la Wallet Unit.

6.3.7.2.3. Wallet Unit Authentication: Processo

1. Validare la Trust Chain relativa al Wallet Provider che ha emesso la Wallet Instance Attestation e derivarne i metadata finali (vedi Federation Trust Chain e Metadata Retrieval and Validation).

2. Validare la Wallet Instance Attestation come definito in Wallet Trust Anchor Validation usando il National Wallet Trust Anchor.

3. Controllare la validità temporale e lo status di revoca della Wallet Instance Attestation.

4. Verificare la prova di possesso della chiave attestata, secondo il protocollo in uso.

6.3.7.3. Relying Party Proximity Authentication

Nel Proximity Flow la Relying Party è autenticata attraverso l'mdoc reader authentication definita in [ISO18013-5]. La Relying Party firma ciascun ReaderAuthentication con la chiave privata del suo certificato di autenticazione nazionale e fornisce la catena di certificati nell'header x5chain non protetto (label 33) di ciascun readerAuth. Il certificato end-entity è il primo e il path esclude l'Authentication Trust Anchor. La catena di certificati termina in un Authentication Trust Anchor distribuito come definito in Authentication Trust Anchor Distribution.

6.3.7.3.1. Relying Party Proximity Authentication: Input

• Ciascun readerAuth firmato dalla Relying Party, con la catena del certificato di autenticazione nell'header x5chain.

• L'Authentication Trust Anchor applicabile.

6.3.7.3.2. Relying Party Proximity Authentication: Esito

Il Trust Evaluator DEVE produrre AUTHENTICATED o NON_AUTHENTICATED. Nel secondo caso la Relying Party NON DEVE essere considerata autenticata. L'interazione NON DEVE continuare.

6.3.7.3.3. Relying Party Proximity Authentication: Processo

1. Estrarre la catena di certificati dall'header x5chain di ogni readerAuth e richiedere il certificato di autenticazione nazionale come end entity.

2. Validare la catena di certificati rispetto all'Authentication Trust Anchor applicabile come definito in X.509 Certificate Chain Validation.

3. Verificare la firma di ciascun readerAuth sui dati ReaderAuthentication con il certificato di autenticazione validato.

La verifica con successo fornisce sia l'autenticazione della Relying Party sia la prova di possesso della chiave privata del suo certificato di autenticazione. Questo risultato di autenticazione nazionale seleziona il percorso del Trust Framework Nazionale prima dell'autorizzazione, come specificato in Selection at Presentation. Un fallimento di questo risultato è gestito come specificato in Failure Handling.

6.3.8. Authorization

I dati di autorizzazione di un'entità sono forniti dal Trust Mark di registrazione emesso dal Registrar attraverso la Federation Authority. Il Trust Mark di registrazione è funzionalmente analogo al Wallet-Relying Party Registration Certificate del Trust Framework EUDIW, e riutilizza gli stessi nomi di campo per i dati di autorizzazione. Attesta la registrazione dell'entità e reca le sue entitlements e, ove applicabile, le provides_attestations o le credentials che è autorizzata a emettere o a richiedere. La sua struttura è definita in Trust Mark registration-entity e lo schema degli identificatori in Trust Mark Types and Schema.

Il processo di Authorization è composto dalle seguenti procedure:

1. Trust Mark Validation, che stabilisce la validità del Trust Mark di registrazione. Si applica a tutte le Entità registrate.

2. Entitlement Check, che verifica che il ruolo e, in emissione, i tipi di Credenziale della Trust Evaluated Party siano autorizzati. Si applica a tutte le Wallet-Relying Party, cioè Credential Issuer e Relying Party.

3. Overasking Check, che verifica in presentazione che una Relying Party richieda solo gli Attestati Elettronici e gli attributi che è autorizzata a richiedere. Si applica alle Relying Party.

L'autorizzazione di ruolo comune a entrambe le fasi è eseguita dall'Entitlement Check. I controlli specifici di fase sono il controllo del tipo di Credenziale in emissione, all'interno dell'Entitlement Check, e l'Overasking Check a livello di attributo in presentazione.

Il Trust Evaluator DEVE eseguire il processo di Authorization solo dopo che la Trust Evaluated Party è stata autenticata con successo. Nella prossimità diretta nazionale, la Wallet Unit DEVE validare il Trust Mark e vincolare l'identità del certificato di autenticazione nazionale, il subject del Trust Mark e gli identificatori ufficiali, e un identificatore in euWrpRegistrarInfo.identifier, alla stessa Relying Party diretta. La Wallet Unit DEVE validare l'entitlement, l'ambito di overasking esatto e case sensitive, e i claim di trasparenza del Trust Mark. La prossimità nazionale DEVE escludere le evidenze EUDIW e il fallback. La prossimità nazionale NON DEVE introdurre un trasporto di prossimità intermediata nazionale.

6.3.8.1. Trust Mark Validation

6.3.8.1.1. Trust Mark Validation: Input

• Il Trust Mark registration-entity, ottenuto nel Remote Flow dal claim trust_marks dell'Entity Configuration o dall'endpoint Federation Trust Mark (OID-FED Sezione 8.6), oppure fornito per valore nella byte string CBOR requestInfo.euWrprc di ogni ItemsRequest ISO nel Proximity Flow, come byte UTF-8 del suo JWT firmato compatto.

• La configurazione validata del Federation Trust Anchor.

6.3.8.1.2. Trust Mark Validation: Esito

Il Trust Evaluator DEVE produrre TRUST_MARK_VALID o TRUST_MARK_INVALID. Un esito TRUST_MARK_INVALID sul Trust Mark di registrazione significa che l'entità non è autorizzata a operare. In questo caso il Trust Evaluator DEVE trattare l'entità come non autorizzata. Il Trust Evaluator NON DEVE procedere con l'Entitlement Check.

6.3.8.1.3. Trust Mark Validation: Processo

1. Verificare che l'issuer del Trust Mark sia autorizzato per quel trust_mark_type, secondo il claim trust_mark_issuers dell'Entity Configuration del Federation Trust Anchor. Il Trust Mark di registrazione, cioè un Trust Mark il cui trust_mark_type ha lo scopo registration-entity, è soggetto a due controlli aggiuntivi. La Trust Mark Validation verifica che il trust_mark_type corrisponda all'identificatore di registrazione atteso per il ruolo del subject, e che l'issuer sia il Federation Trust Anchor, poiché il Trust Mark di registrazione DEVE essere emesso solo dal Federation Trust Anchor (vedi Trust Mark Types and Schema).

2. Verificare la firma del Trust Mark con le Federation Entity Keys del suo issuer, ottenute attraverso la Trust Chain quando l'issuer non è il Federation Trust Anchor.

3. Controllare la validità temporale del Trust Mark attraverso i claim iat e exp.

4. Quando online, controllare lo status del Trust Mark attraverso l'endpoint Federation Trust Mark Status (OID-FED Sezione 8.4).

6.3.8.2. Entitlement Check

Le entitlement definiscono ciò che l'entità è autorizzata a fare, come i tipi di Credenziale che può emettere o gli attributi che può richiedere. All'interno di IT-Wallet questi dati di autorizzazione sono recati nel Trust Mark di registrazione, nei claim entitlements, provides_attestations e credentials definiti in Trust Mark Types and Schema, e NON DEVONO essere derivati dai soli metadata.

6.3.8.2.1. Entitlement Check: Input

• I Trust Mark validati della Trust Evaluated Party.

• Il ruolo della Trust Evaluated Party e l'azione attesa nell'interazione corrente. In emissione, il tipo di Credential Issuer e i tipi di Credenziale che dichiara di emettere. In presentazione, gli Attestati Elettronici e gli attributi richiesti dalla Relying Party.

6.3.8.2.2. Entitlement Check: Esito

Il Trust Evaluator DEVE produrre ENTITLEMENT_VALID o WRONG_ENTITLEMENT.

6.3.8.2.3. Entitlement Check: Processo

1. Estrarre le entitlements dai Trust Mark validati e verificare che corrispondano al ruolo atteso nell'interazione corrente, per esempio che un'entità che agisce come Credential Issuer detenga un'entitlement di emissione di ETSI TS 119 475 Allegato A.2.

2. Durante l'emissione, verificare che il tipo di Credenziale offerto sia presente nelle provides_attestations del Trust Mark, confrontando il format e il meta della Credenziale offerta rispetto alle entry autorizzate.

3. Durante la presentazione, il controllo a livello di attributo rispetto alle credentials del Trust Mark è eseguito dall'Overasking Check seguente.

6.3.8.3. Overasking Check

6.3.8.3.1. Overasking Check: Input

• La richiesta di presentazione.

• Le credentials recate nel Trust Mark validato, cioè le query di Credenziale che la Relying Party è autorizzata a richiedere.

6.3.8.3.2. Overasking Check: Esito

La Wallet Unit DEVE produrre VERIFICATION_PASSED o OVERASKING_DETECTED, identificando gli attributi o gli Attestati Elettronici non registrati. Su OVERASKING_DETECTED la Wallet Unit NON DEVE divulgare gli attributi che non sono autorizzati. La Wallet Unit DEVE informare l'Utente dell'overasking rilevato.

6.3.8.3.3. Overasking Check: Processo

1. Estrarre gli Attestati Elettronici e gli attributi richiesti dalla richiesta, dalla query DCQL definita in OpenID4VP nel remote flow, oppure dai namespace richiesti nel proximity flow.

2. Per ciascuna Credenziale richiesta, selezionare nelle credentials del Trust Mark l'entry autorizzata con lo stesso format e meta, per esempio gli stessi vct_values o doctype_value.

3. Verificare che ogni attributo richiesto sia presente nei path claim dell'entry autorizzata selezionata. Se la richiesta contiene una Credenziale o un attributo senza una corrispondente entry autorizzata, l'output è OVERASKING_DETECTED.

4. L'abbinamento DEVE essere esatto e case sensitive.

6.3.8.4. User Transparency

Oltre ai controlli automatici precedenti, il Trust Mark di registrazione fornisce claim che non sono valutati come regola decisionale ma sono presentati all'Utente per trasparenza, a supporto della decisione di procedere con l'interazione prima che qualsiasi attributo sia divulgato. Prima della disclosure, la Wallet Unit DEVE informare l'Utente dell'identità della Relying Party e degli Attestati Elettronici e attributi richiesti, e presenta i claim di trasparenza aggiuntivi del Trust Mark a supporto della decisione informata. Questo è coerente con l'approvazione dell'Utente che conclude la presentazione, come definito in Authorization Decision and Override Rules.

I claim di trasparenza recati nel Trust Mark sono i seguenti:

• organization_name, la denominazione legale dell'entità.

• srv_description, la descrizione del servizio fornito dall'entità.

• purpose, le finalità di trattamento dei dati, per una Relying Party che richiede Credenziali.

• privacy_policy, l'URL della privacy policy, per una Relying Party che richiede Credenziali.

• supervisory_authority, l'Autorità di protezione dei dati a cui l'Utente può segnalare anomalie.

• public_body, se l'entità è un organismo del settore pubblico.

• support_uri, il contatto di supporto usato per una richiesta di cancellazione dei dati, come specificato in Eliminazione degli Attributi dell'Utente.

Le loro definizioni sono fornite in Trust Mark Types and Schema.

Quando la Relying Party opera attraverso un Relying Party Intermediary nel National Trust Framework, la Wallet Unit DEVE inoltre informare l'Utente che la Relying Party opera attraverso tale Intermediary, visualizzando l'identità di entrambi. L'Intermediary è il Federation Intermediate nella Trust Chain della Relying Party, registrato con il Trust Mark intermediate (vedi Trust Mark Types and Schema), ed è pertanto identificabile dalla Trust Chain validata senza artifact aggiuntivi.

Quando la stessa presentazione è valutata nel EUDIW Trust Framework, la Wallet Unit NON DEVE visualizzare i trade name dell'Intermediary o del Servizio dell'Intermediary ([EIDAS-ARF] RPI_07). Visualizza la Relying Party intermediata e il suo Servizio, come definito in EUDIW Authorization.

6.3.9. Metadata Retrieval and Validation

I metadata di una Federation Entity DEVONO essere consumati solo nella loro forma finale, cioè i metadata risultanti dall'applicazione delle metadata policy ai metadata pubblicati nell'Entity Configuration, lungo la Trust Chain validata (vedi Federation Trust Chain). I metadata pubblicati nell'Entity Configuration NON DEVONO essere usati senza questa elaborazione.

I tipi di metadata e i loro parametri sono definiti in Entity Type Identifiers and Metadata e nelle specifiche di protocollo ivi referenziate.

La configurazione della Wallet Unit è fornita dal Wallet Provider all'interno dei suoi metadata come definito in Metadati della Soluzione Wallet.

6.3.9.1. Metadata Retrieval and Validation: Input

• Una Trust Chain validata relativa al subject (vedi Federation Trust Chain).

6.3.9.2. Metadata Retrieval and Validation: Esito

• I metadata finali del subject, per ciascun tipo di metadata rilevante per l'interazione.

6.3.9.3. Metadata Retrieval and Validation: Processo

1. Applicare la metadata_policy delle dichiarazioni superiori ai metadata pubblicati nell'Entity Configuration del subject, lungo la Trust Chain, secondo OID-FED Sezione 6.1, ottenendo i metadata finali.

2. Selezionare il tipo di metadata corrispondente al ruolo del subject nell'interazione.

3. Verificare la presenza dei parametri che sono OBBLIGATORIO per quel tipo di metadata.

4. Usare gli endpoint, le chiavi e gli algoritmi solo dai metadata finali.

Quando i metadata sono ottenuti attraverso una Trust Chain fornita staticamente, DEVONO essere aggiornati quando la Trust Chain scade, come definito in Federation Trust Chain.

Nota

All'interno di IT-Wallet la metadata_policy copre solo i parametri di configurazione tecnica, come endpoint, chiavi crittografiche e algoritmi supportati. Le entitlement e le policy di autorizzazione NON DEVONO essere espresse attraverso metadata policy. Le entitlement e le policy di autorizzazione sono recate dai Trust Mark, come definito in Authorization.

6.4. Authorization Decision and Override Rules

La Authorization Decision può essere AUTHORIZED oppure NOT_AUTHORIZED. Le condizioni che determinano questo esito dipendono dalla specifica procedura di Authorization Validation seguita.

• Nel caso in cui la Wallet Unit segua il percorso di valutazione EUDIW Authorization, l'esito è:

  • durante la Presentazione di Attestati, AUTHORIZED se il processo termina con CERTIFICATE_VALID AND EDP_SATISFIED AND VERIFICATION_PASSED.

  • durante l'Emissione di Attestati, AUTHORIZED se il processo termina con CERTIFICATE_VALID AND VERIFICATION_PASSED.

  • NOT_AUTHORIZED altrimenti.

• Nel caso in cui la Wallet Unit segua il percorso di valutazione Nazionale Authorization, l'esito è:

  • AUTHORIZED se il processo termina con TRUST_MARK_VALID AND ENTITLEMENT_VALID AND VERIFICATION_PASSED, oppure

  • NOT_AUTHORIZED altrimenti.

6.4.1. Principi di Override

Una decisione NOT_AUTHORIZED può essere non-overridable (la Wallet Unit blocca l'interazione) oppure overridable (la Wallet Unit presenta l'esito negativo e l'Utente può scegliere di proseguire).

• Durante la fase di Emissione di Attestati, tutti gli esiti negativi di verifica DEVONO essere non-overridable. La Wallet Unit NON DEVE consentire all'Utente di interagire con i fornitori la cui registrazione non può essere confermata.

• Durante la fase di Presentazione, tutti gli esiti negativi di verifica DEVONO essere non-overridable, salvo i seguenti casi:

  • Overasking [EUDIW]. Quando il processo termina con CERTIFICATE_VALID AND OVERASKING_DETECTED, ossia la Authorization Artifact Validation ha avuto esito positivo, ma lo Scope Comparison rileva che la Relying Party richiede più del proprio scope registrato.

  • Valutazione negativa dell'Embedded Disclosure Policy [EUDIW]. Quando il processo termina con CERTIFICATE_VALID AND EDP_NOT_SATISFIED, ossia la Authorization Artifact Validation ha avuto esito positivo ma l'Embedded Disclosure Policy non consentirebbe la presentazione alla Relying Party. Se un URI di EDP non può essere risolto nella policy esatta inclusa o precaricata, il fallimento della valutazione non è EDP_NOT_SATISFIED. Tale fallimento NON DEVE essere overridable.

  • WRPRC mancante o non valido [EUDIW]. Quando il processo termina con CERTIFICATE_INVALID durante la Presentazione di Attestati, ossia il Wallet-Relying Party Registration Certificate è assente, malformato, non autentico o scaduto. La Wallet Unit DEVE avvisare l'Utente. La Wallet Unit NON DEVE interrogare il Register, come specificato in EUDIW Authorization. Se l'Utente possa comunque approvare dipende dalla policy del Fornitore di Wallet.

  • Overasking [National]. Quando il processo termina con TRUST_MARK_VALID AND OVERASKING_DETECTED, ossia la Trust Mark Validation ha avuto esito positivo, ma il Overasking Check rileva che la Relying Party richiede più del proprio scope registrato.

Tutti gli altri fallimenti di presentazione, inclusi i fallimenti di binding o i fallimenti di binding dell'intermediario, NON DEVONO essere overridable in quanto indicano un problema di integrità piuttosto che una scelta rivolta all'Utente.

In caso di fallimenti non-overridable, la Wallet Unit DEVE informare chiaramente l'Utente sull'esito negativo. Le informazioni rilevanti per l'Utente relative agli esiti overridable DEVONO essere presentate come avvisi. L'approvazione dell'Utente DEVE essere un passo distinto rispetto alla Authorization Decision finale.