fix: removed some useless empty spaces

Author: pcerqua-ipzs

docs/it/brand-identity.rst

@@ -58,7 +58,7 @@ Di seguito i requisiti generali per il suo utilizzo, validi sia in riferimento a
 Trust Mark 
 """"""""""
 
-Il Trust Mark è l'elemento grafico ufficiale che dà prova agli Utenti dell'appartenenza al Sistema IT-Wallet degli attori del Sistema IT-Wallet e delle relative Soluzioni Tecniche con cui interagisce.  
+Il Trust Mark è l'elemento grafico ufficiale che dà prova agli Utenti dell'appartenenza al Sistema IT-Wallet degli attori del Sistema IT-Wallet e delle relative Soluzioni Tecniche con cui interagisce.
 
 Di seguito i requisiti generali per il suo utilizzo, validi sia in riferimento a contesti di utilizzo fisici che digitali (e.g. siti web, applicazioni, documenti cartacei, materiali informativi stampati o video, etc.): 
 
@@ -81,7 +81,7 @@ Di seguito i requisiti generali per il suo utilizzo, validi sia in riferimento a
 Componenti 
 """"""""""
 
-Sono definiti componenti gli elementi del Sistema IT-Wallet che abilitano l'Utente a interagire con le diverse Soluzioni Tecniche tramite la propria Istanza del Wallet.  
+Sono definiti componenti gli elementi del Sistema IT-Wallet che abilitano l'Utente a interagire con le diverse Soluzioni Tecniche tramite la propria Istanza del Wallet.
 
 Le Risorse Ufficiali mettono a disposizione sia componenti complessi, ovvero template relativi a interi flussi, sia componenti atomici, ovvero singoli elementi da integrare all'interno di interfacce preesistenti (e.g. i Pulsanti di Ingaggio). 
 
@@ -97,7 +97,7 @@ Pulsante di Autenticazione
 """"""""""""""""""""""""""
 
 Il Pulsante di Autenticazione è un esempio di Pulsante di Ingaggio. 
-I Verificatori di Attestati Elettronici DEVONO rendere disponibile il Pulsante di Autenticazione all'interno della Discovery Page delle proprie Soluzioni Tecniche per permettere all'Utente di Autenticarsi ai propri servizi tramite un'Istanza del Wallet.  
+I Verificatori di Attestati Elettronici DEVONO rendere disponibile il Pulsante di Autenticazione all'interno della Discovery Page delle proprie Soluzioni Tecniche per permettere all'Utente di Autenticarsi ai propri servizi tramite un'Istanza del Wallet.
 
 Le modalità di integrazione del Pulsante di Autenticazione nella Discovery Page possono essere molteplici a seconda del layout della pagina stessa. Di seguito alcuni esempi illustrativi e non esaustivi di Discovery Page, rispettivamente con struttura a griglia, a tab e in lista. 
 
@@ -123,7 +123,7 @@ Il Pulsante di Autenticazione è caratterizzato dai seguenti requisiti:
 
 - il Pulsante di Autenticazione DEVE essere usato come delineato nelle Risorse Ufficiali; 
 
-- il Pulsante di Autenticazione DEVE essere visivamente distinto da altri Pulsanti di Autenticazione o altri pulsanti di azione;  
+- il Pulsante di Autenticazione DEVE essere visivamente distinto da altri Pulsanti di Autenticazione o altri pulsanti di azione;
 
 - il Pulsante di Autenticazione DEVE essere utilizzato esclusivamente nelle forme, dimensioni e proporzioni stabilite dalle Risorse Ufficiali e NON DEVE essere alterato, distorto o nascosto; 
 

docs/it/credential-issuance-endpoint.rst

@@ -130,7 +130,7 @@ Il payload del JWT ``request`` contenuto nel messaggio HTTP POST contiene i segu
       - DEVE essere valorizzato con ``code``.
       - :rfc:`6749`
     * - **response_mode**
-      - DEVE essere una stringa che indica il "*response_mode*", come specificato in [`OAUTH-MULT-RESP-TYPE`_]. DEVE essere valorizzato con uno dei valori supportati (*response_modes_supported*) forniti nei Metadata del Credential Issuer. Tale claim informa il Credential Issuer sul meccanismo da utilizzare per la restituizione dei parametri da parte dell' Authorization Endpoint. In caso di *HTTP 302 Redirect Response* il valore DEVE essere *query*. In questa modalità, i parametri dell'Authorization Response sono codificati nella stringa di query aggiunta al ``redirect_uri`` durante il redirect all'Istanza del Wallet. In caso di *HTTP POST Response* il valore DEVE essere *form_post.jwt* secondo [`JARM`_]. In questa modalità, i parametri dell'Authorization Response sono riportati in un JWT codificato in un form HTML che viene inviato automaticamente nell'user-agent, e quindi viene trasmesso tramite il metodo HTTP POST all'Istanza del Wallet, con i parametri risultanti codificati nel body utilizzando il formato *application/x-www-form-urlencoded*. L'attributo *action* del form DEVE contenere il  *Redirection URI* dell'Istanza del Wallet. L'attributo *method* del form DEVE essere POST.
+      - DEVE essere una stringa che indica il "*response_mode*", come specificato in [`OAUTH-MULT-RESP-TYPE`_]. DEVE essere valorizzato con uno dei valori supportati (*response_modes_supported*) forniti nei Metadata del Credential Issuer. Tale claim informa il Credential Issuer sul meccanismo da utilizzare per la restituizione dei parametri da parte dell' Authorization Endpoint. In caso di *HTTP 302 Redirect Response* il valore DEVE essere *query*. In questa modalità, i parametri dell'Authorization Response sono codificati nella stringa di query aggiunta al ``redirect_uri`` durante il redirect all'Istanza del Wallet. In caso di *HTTP POST Response* il valore DEVE essere *form_post.jwt* secondo [`JARM`_]. In questa modalità, i parametri dell'Authorization Response sono riportati in un JWT codificato in un form HTML che viene inviato automaticamente nell'user-agent, e quindi viene trasmesso tramite il metodo HTTP POST all'Istanza del Wallet, con i parametri risultanti codificati nel body utilizzando il formato *application/x-www-form-urlencoded*. L'attributo *action* del form DEVE contenere il *Redirection URI* dell'Istanza del Wallet. L'attributo *method* del form DEVE essere POST.
       - Vedi [`OAUTH-MULT-RESP-TYPE`_] e [`JARM`_].
     * - **client_id**
       - DEVE essere valorizzato come indicato nella :ref:`Tabella dei parametri HTTP <table_http_request_claim>`.
@@ -442,7 +442,7 @@ La token request contiene i seguenti claim:
       - OBBLIGATORIO solo se il *grant type* è ``refresh_token``. Il Refresh Token precedentemente emesso all'Istanza del Wallet. NON DEVE essere presente se il *grant type* è ``authorization_code``.
       - [:rfc:`6749`].
     * - **scope**
-      - OPZIONALE solo se il *grant type* è ``refresh_token``. Lo scope richiesto NON DEVE includere alcun valore di scope non originariamente concesso dall'Utente, e se omesso è da intendersi  uguale allo scope originariamente concesso dall'Utente. NON DEVE essere presente se il *grant type* è ``authorization_code``.
+      - OPZIONALE solo se il *grant type* è ``refresh_token``. Lo scope richiesto NON DEVE includere alcun valore di scope non originariamente concesso dall'Utente, e se omesso è da intendersi uguale allo scope originariamente concesso dall'Utente. NON DEVE essere presente se il *grant type* è ``authorization_code``.
       - [:rfc:`6749`].
 
 
@@ -496,7 +496,7 @@ Il payload del **JWT DPoP Proof** DEVE contenere i seguenti claim:
 Token Response
 .................
 
-Se la Token Request viene validata con successo, l'Authorization Server fornisce una Token Response con *status code HTTP 200 (OK)*. La Token Response  contiene i seguenti claim.
+Se la Token Request viene validata con successo, l'Authorization Server fornisce una Token Response con *status code HTTP 200 (OK)*. La Token Response contiene i seguenti claim.
 
 .. list-table::
     :class: longtable
@@ -807,7 +807,7 @@ Il *proof type* del JWT DEVE contenere i seguenti parametri per l'header JOSE e
     - DEVE essere valorizzato con l'identificativo del Credential Issuer.
     - [`OpenID4VCI`_].
   * - **iat**
-    - Timestamp UNIX con data e orario  di emissione del JWT, codificato come NumericDate come indicato nel :rfc:`7519`.
+    - Timestamp UNIX con data e orario di emissione del JWT, codificato come NumericDate come indicato nel :rfc:`7519`.
     - [`OpenID4VCI`_], [:rfc:`7519`. Sezione 4.1.6].
   * - **nonce**
     - Il tipo di valore di questo claim DEVE essere una stringa, dove il valore è un **c_nonce** fornito dal Credential Issuer tramite la Nonce Response.

docs/it/credential-revocation.rst

@@ -524,13 +524,13 @@ La Status Assertion DEVE contenere i parametri e i claim definiti di seguito
     - Un identificatore di algoritmo di firma digitale come per il registro IANA "JSON Web Signature and Encryption Algorithms". DEVE essere uno degli algoritmi supportati nella Sezione :ref:`Cryptographic Algorithms <algorithms:Algoritmi Crittografici>` e NON DEVE essere impostato su ``none`` o su un identificatore di algoritmo simmetrico (MAC).
     - [:rfc:`7515`], [:rfc:`7517`].
   * - **typ**
-    - DEVE  corrispondere a `status-assertion+jwt`.
+    - DEVE corrispondere a `status-assertion+jwt`.
     - [:rfc:`7515`], [:rfc:`7517`], `OAUTH-STATUS-ASSERTION`_.
   * - **kid**
     - Identificatore univoco del JWK del Fornitore di Attestati Elettronici. È RICHIESTO quando ``x5c`` non viene utilizzato.
     - [:rfc:`7515`], `OAUTH-STATUS-ASSERTION`_.
   * - **x5c**
-    -  Catena di certificati X.509 relativa al Fornitore di Attestati Elettronici. È RICHIESTO quando ``kid`` non viene utilizzato.
+    - Catena di certificati X.509 relativa al Fornitore di Attestati Elettronici. È RICHIESTO quando ``kid`` non viene utilizzato.
     - [:rfc:`7515`], `OAUTH-STATUS-ASSERTION`_.
 
 .. list-table::
@@ -848,7 +848,7 @@ Gestione dello Stato degli Attestati Elettronici con Token di Status List
 I Fornitori di Attestati Elettronici, una volta che un Attestato Elettronico è stato generato, DEVONO:
 
   - Memorizzarlo localmente con il set minimo di dati necessari per gestire il suo ciclo di vita, incluso lo stato di validità di quell'Attestato Elettronico;
-  - Includere un claim ``status_list`` all'interno dell'Oggetto JSON ``status`` claim  dell'Attestato Elettronico.
+  - Includere un claim ``status_list`` all'interno dell'Oggetto JSON ``status`` claim dell'Attestato Elettronico.
 
 Il valore del claim ``status_list`` DEVE essere a sua volta un Oggetto JSON con i seguenti parametri
 

docs/it/defined-terms.rst

@@ -43,7 +43,7 @@ Di seguito le descrizioni di acronimi e definizioni, correlati al presente docum
 
     **Fonte Autentica**
       Soggetto pubblico o privato responsabile di un archivio o sistema che è considerato fonte primaria per gli Attributi o per i Dati di Identificazione Personale.
-      Conforme con ARF 1.10.    
+      Conforme con ARF 1.10.
 
     **Processo di Certificazione**
       Procedura svolta dagli Organismi di Valutazione della conformità (CABs) per certificare le Soluzioni Wallet, che comprende anche le valutazioni tecniche periodiche.
@@ -175,7 +175,7 @@ Di seguito le descrizioni di acronimi e definizioni, correlati al presente docum
       Attestato Elettronico di Attributi che contiene Attributi destinati ad attestare il rilascio, da parte dello Stato o di altre pubbliche amministrazioni, di autorizzazioni, certificazioni, abilitazioni, documenti di identità e riconoscimento, ricevute di introiti, ovvero ad assumere un valore fiduciario e di tutela della fede pubblica in seguito alla loro emissione o alle scritturazioni su di essi effettuate e, in generale, quando sono considerati carte valori ai sensi dell'articolo 2, comma 10-bis, della legge 13 luglio 1966, n. 559.
       Non presente in ARF 1.10; specifico di IT-Wallet.
 
-    **Attestato Elettronico di Dati di Identificazione Personale**  
+    **Attestato Elettronico di Dati di Identificazione Personale**
       Attestato Elettronico che consente di autenticare il soggetto a cui si riferiscono i Dati Personali Identificativi.
       Conforme con ARF 1.10.