Differenze tra le versioni di "ConsultazioneProfiliDiGaranziaIDEM"

Da WIKI IDEM GARR.
Jump to navigation Jump to search
 
(17 versioni intermedie di 3 utenti non mostrate)
Riga 19: Riga 19:
 
!Inizio
 
!Inizio
 
!Termine
 
!Termine
 +
!Note
 
|-
 
|-
 
|Prima consultazione
 
|Prima consultazione
 
|11 Aprile 2023
 
|11 Aprile 2023
|26 Apirle 2023
+
|26 Aprile 2023
 +
|Terminata
 
|-
 
|-
 
|Seconda consultazione
 
|Seconda consultazione
 
|2 Maggio 2023
 
|2 Maggio 2023
 
|16 Maggio 2023
 
|16 Maggio 2023
 +
|Terminata
 
|-
 
|-
|Votazione (Assemblea IDEM)
+
|Votazione
|data da definire
+
|17 Maggio 2023
| -
+
|24 Maggio 2023 (Assemblea IDEM)
 +
|In corso
 
|}
 
|}
  
Riga 37: Riga 41:
 
*
 
*
  
 +
===Versione 1.0===
 +
[[:File:Profili di garanzia delle identita digitali della Federazione IDEM.pdf|File:Profili di garanzia delle identità digitali della Federazione IDEM-v1.pdf]]
 +
 +
===Seconda consultazione===
 +
[[:File:Profili di garanzia delle identità digitali della Federazione IDEM-BOZZA2.pdf|File:Profili di garanzia delle identità digitali della Federazione IDEM-BOZZA2.pdf]]
 +
 +
===Prima consultazione===
 
[[:File:Profili di garanzia delle identità digitali della Federazione IDEM-BOZZA1.pdf|File:Profili di garanzia delle identità digitali della Federazione IDEM-BOZZA1.pdf]]
 
[[:File:Profili di garanzia delle identità digitali della Federazione IDEM-BOZZA1.pdf|File:Profili di garanzia delle identità digitali della Federazione IDEM-BOZZA1.pdf]]
  
 
==Commenti==
 
==Commenti==
 
Invitiamo tutti gli interessati ad inserire i propri commenti sul documento proposto nella tabella sottostante. In "Riferimento" inserire il testo che si intente commentare, o il numero di linea, pagina o sezione interessate (nel caso di commenti generali, inserire "generale").
 
Invitiamo tutti gli interessati ad inserire i propri commenti sul documento proposto nella tabella sottostante. In "Riferimento" inserire il testo che si intente commentare, o il numero di linea, pagina o sezione interessate (nel caso di commenti generali, inserire "generale").
 +
 +
===Seconda consultazione===
 +
{| class="wikitable"
 +
!Riferimento
 +
!Commento
 +
!Autore
 +
!Risposta (a cura del CTS)
 +
|-
 +
|Linea 309
 +
|"indicati per l’autenticazione a singolo fattore (vedi 4.4.1)."
 +
 +
Forse dovrebbe essere:
 +
 +
"indicati per l’autenticazione a singolo fattore (vedi 4.5.1)." ?
 +
|Maurizio Festi (UNITN)
 +
|Modificato.
 +
|-
 +
|Linea 252
 +
|eduPersonPrimaryAffiliation: secondo me l'affiliazione primaria è una questione un po' ostica, il problema di base è che può dipendere dal contesto del service provider, non solo dal contesto dell'identity provider (es: un servizio che rilascia funzionalità agli studenti potrebbe volere "student", uno che le rilascia a docenti e ricercatore preferirebbe avere "faculty" come affiliazione primaria).
 +
La definizione di refeds (<nowiki>https://wiki.refeds.org/display/STAN/eduPerson+2020-01#eduPerson202001-eduPersonPrimaryAffiliation</nowiki>) fa riferimento più che altro ad una sorta di "fama pubblica" del ruolo in Ateneo, ma rimane comunque ambigua e sempre dipendente dal contesto.
 +
 +
Per mitigare questa ambiguità di fondo, IDEM potrebbe rilasciare una linea guida con un "ordine di importanza" a cui riferirsi per scegliere l'affiliazione principale in caso di affiliazioni multiple?
 +
 +
Così da avere almeno un'uniformità all'interno della federazione e minore ambiguità per i service provider? (es, dal più importante al meno importante: faculty, staff, student, member, alumn, affliate)
 +
|Maurizio Festi (UNITN)
 +
|E' stata indicata esplicitamente l'opzionalita' di rilascio di eduPersonPrimaryAffiliation (ePPA), che infatti non e' nemmeno incluso nelle Specifiche Tecniche Attributi IDEM.
 +
 +
Sulle modalita' di utilizzo di ePPA il CTS potra' intervenire come suggerito se si dimostrera' necessario.
 +
|-
 +
|Paragrafo 4.5.2 punto 4
 +
|forse si potrebbe indicare come esempio accettabile anche un concetto di "finestra temporale" in cui per un utente è possibile può attivarsi in self service il secondo fattore partendo dal primo fattore.
 +
Questo semplificherebbe due fasi:
 +
 +
- il rilascio del secondo fattore ai nuovi utenti (es: ai nuovi studenti in periodo di iscrizioni ai test d'ingresso o immatricolazione)
 +
 +
- il deploy del secondo fattore a tutta la popolazione di un'organizzazione al momento del rilascio iniziale delle procedure MFA e dei relativi fattori di autenticazione aggiuntivi
 +
 +
Fuori da queste finestre temporali dovrebbe essere necessario l'intervento di un operatore di backoffice, per reinizializzare la finestra temporale in cui è possibile ottenere il secondo fattore in self service su richiesta degli utenti (e previo reidentificazione)
 +
|Maurizio Festi (UNITN)
 +
|E' stato ulteriormente specificato il processo di attivazione di un "ulteriore" fattore di autenticazione in modo da dare indicazioni sui limiti temporali dei segreti trasmessi a questo fine.
 +
|-
 +
|Paragrafo "3.3. Procedure di verifica"
 +
|per i membri che gestiscono un IdP sarebbe comodo avere una checklist di autovalutazione, la stessa che poi applicherà la Federazione IDEM quando farà le verifiche vere e proprie.
 +
|Maurizio Festi (UNITN)
 +
|E' stata inserita la definizione di una lista di autovalutazione per il fine indicato.
 +
|-
 +
|Generale
 +
|una volta approvato il documento, potrebbe rilasciare degli esempi di configurazione di shibboleth idp da applicare in questo contesto? Es: filtro per rilasciare i valori "IDEM" in eduPersonAssurance solo ai service provider di IDEM, e non ad eduGain in generale (anche se credo che non dovrebbero creare problemi rilasciando questi valori in eduPersonAssurance per tutti).
 +
|Maurizio Festi (UNITN)
 +
|Certamente.
 +
|-
 +
|Generale
 +
|come faranno i service provider a richiedere all'idp uno specifico profilo di garanzia tra quelli supportati da IDEM (acr e authncontexclass fanno riferimento più che altro a metodi di autenticazione, non direttamente al profili)?
 +
Faranno una verifica a posteriori dopo l'avvenuta autenticazione? O chiederanno semplicemente "<nowiki>https://refeds.org/profile/mfa</nowiki>" per implicitamente richiedere P2/P3?
 +
|Maurizio Festi (UNITN)
 +
|Negli allegati al documento sono gia' contenute alcune indicazioni sul tema. Maggiori approfondimenti saranno rilasciati con l'estensione di linee guida.
 +
|-
 +
|Generale
 +
|un'organizzazione che ha ottenuto il profilo P2, deve sempre emettere autenticazioni verso la federazione IDEM con autenticazione MFA?
 +
|Maurizio Festi (UNITN)
 +
|No, ed e' stata esplicitata tale non obbligatorieta'.
 +
|-
 +
|Paragrafo "4.3.2. Controllo e verifica dell’identità"
 +
|si fa riferimento ad "un documento di identita’ riconosciuto dallo Stato italiano" si fa riferimento a soli documenti italiani?Immagino che si faccia riferimento anche a documenti di identità esteri per gli stranieri, se l'interpretazione è questa, che voi sappiate, c'è da qualche parte un riferimento a quali sono questi documenti riconosciuti dallo Stato italiano?
 +
|Maurizio Festi (UNITN)
 +
|Il riferimento e' ai documenti di identita' riconosciuti dallo Stato italiano, non ai documenti italiani. Come sotto categoria utile per determinare i documenti d'identita' riconosciuti dallo Stato italiano, si puo' consultare il "PRADO - Registro pubblico online dei documenti di identità e di viaggio autentici" dell'Unione Europea (e a cui rimanda la Polizia di Stato stessa): https://www.consilium.europa.eu/prado/it/prado-recognised-documents.html
 +
<br />
 +
|-
 +
|Paragrafo "4.3.2. Controllo e verifica dell’identità"
 +
|riguardo un documento di identità si indica "che sia stato verificato per stabilirne l'autenticità oppure, secondo una fonte autorevole, esiste ed è collegato a una persona reale.", implicitamente si sta richiedendo alla persona che dovrà visionare il documento una competenza e una formazine tale da essere in grado di fare questo tipo di valutazioni oltre alla possibilità di utilizzare un qualche strumento per accedere ad informazioni sullo stato dei documenti di identità (almeno italiani).
 +
Come IDEM potreste valutare l'interesse della comunità (e nel caso la possibilità concreta di organizzararlo) per un corso di formazione specifico su questi aspetti? Il target sarebbero le persone che nelle organizzazioni rilasciano credenziali agli utenti.
 +
 +
Sarebbe anche utile l'indicazione di quali strumenti sono disponibili in Italia per fare questo tipo di verifiche e come si può chiederne l'accesso.
 +
 +
Probabilmente un corso del genere andrebbe organizzato con del personale esperto al riguardo, immagino qualcuno di qualche questura o delle dogane o di qualche funzione statale simile.
 +
|Maurizio Festi (UNITN)
 +
|Come CTS accogliamo la proposta e ci attiveremo sulla base della condivisione della necessita' da parte della comunita' IDEM.
 +
|}
 +
 +
===Prima consultazione===
 
{| class="wikitable"
 
{| class="wikitable"
 
|+
 
|+
Riga 51: Riga 142:
 
|I profili indicati IDEM-P0 e IDEM-P1 dovrebbero essere IDEM-P2 e IDEM-P3
 
|I profili indicati IDEM-P0 e IDEM-P1 dovrebbero essere IDEM-P2 e IDEM-P3
 
|Federico Giorgetti (UNIPG)
 
|Federico Giorgetti (UNIPG)
|
+
|Modificato.
 
|-
 
|-
 
|Riga 58
 
|Riga 58
 
|"Profiles" => "Profile" perchè i termini inglesi inseriti in un testo italiano non vanno declinati al plurale
 
|"Profiles" => "Profile" perchè i termini inglesi inseriti in un testo italiano non vanno declinati al plurale
 
|Marco Malavolti (GARR)
 
|Marco Malavolti (GARR)
|
+
|Modificato.
 
|-
 
|-
 
|Riga 84,85
 
|Riga 84,85
 
|Il "può registrare" mi fa pensare che un Partner possa aderire a IDEM senza entità, ma ciò non è possibile secondo quanto riportato dalle Procedure di Adesione.
 
|Il "può registrare" mi fa pensare che un Partner possa aderire a IDEM senza entità, ma ciò non è possibile secondo quanto riportato dalle Procedure di Adesione.
 
|Marco Malavolti (GARR)
 
|Marco Malavolti (GARR)
|
+
|Sì, specificato "che gestisce un Service Provider".
 
|-
 
|-
 
|Riga 106
 
|Riga 106
|"indicato." => "desiderato."
+
|"indicato." => "desiderato." o, meglio, "scelto."
  
 
Questa modifica viene proposta per riprendere quanto scritto nel punto precedente.
 
Questa modifica viene proposta per riprendere quanto scritto nel punto precedente.
 
|Marco Malavolti (GARR)
 
|Marco Malavolti (GARR)
|
+
|No, il termine corretto e' proprio "indicato" dato che in quella fase si tratta della dichiarazione di conformita' effettiva.
 
|-
 
|-
|
+
|Righe 127-130
|
+
|Registrare tutte le informazioni pertinenti al processo di erogazione e gestione delle
|
+
 
|
+
credenziali,<s>e</s> conservarle nella misura consentita dalla legislazione nazionale e
 +
 
 +
renderle disponibili in caso di indagini e verifiche sulla sicurezza delle credenziali e
 +
 
 +
dei dati degli interessati.
 +
|Marco Malavolti (GARR)
 +
|Modificato.
 +
|-
 +
|Riga 264
 +
|"tra 72 e 52 caratteri" => "tra 52 e 72 caratteri"
 +
|Marco Malavolti (GARR)
 +
|Modificato.
 +
|-
 +
|Riga 327
 +
|"IDEM P1, IDEM P2, IDEM P3" => "IDEM-P1, IDEM-P2, IDEM-P3"
 +
|Marco Malavolti (GARR)
 +
|Modificato.
 +
|-
 +
|Riga 381
 +
|Manca il punto finale per coerenza con gli altri punti indicati
 +
|Marco Malavolti
 +
 
 +
(GARR)
 +
|Modificato.
 +
|-
 +
|Riga 424
 +
|E' corretto l' * in "<nowiki>https://refeds.org/assurance/ID/eppn-unique-no-reassign*</nowiki>" ? Se SI, manca la spiegazione dell' * .
 +
|Marco Malavolti
 +
(GARR)
 +
|Modificato.
 +
|-
 +
|Riga 213
 +
|Forse è utile specificare che i link per scaricare le credenziali siano utilizzabili un'unica volta e per un intervallo limitato di tempo.
 +
|Lorenzo Iannuzzi
 +
 
 +
(UNIFI)
 +
|Sì, aggiunto rimando alla sezione 4.5.1 punto 2.
 
|}
 
|}

Versione attuale delle 08:48, 10 giu 2023

Consultazione

il CTS della Federazione IDEM ed il Servizio IDEM GARR AAI propongono l'adozione del documento che definisce i Profili di garanzia dell'identità digitale per la Federazione IDEM elaborato dal Gruppo di Lavoro Identity Assurance, vedi Gruppo di Lavoro Identity Assurance 2022.


L'adozione di un quadro regolatorio condiviso per esprimere la garanzia di affidabilità delle identità digitali ha il fine di:

  • Permettere ai membri della Federazione IDEM di accedere ai servizi della ricerca che richiedono il supporto dei profili di garanzia dell'identità digitale definitii dal REFEDS Assurance Framework.
  • Allineare le pratiche di gestione dell'identità digitale dei membri della Federazione IDEM alle norme che regolano l'identità digitale governativa europea e italiana (eIDAS, SPID e CIE) e agli standard internazionali di riferimento (ITU X.1254 e NIST 800-63).
  • Aumentare il grado di sicurezza e affidabilità dei sistemi di gestione dell'identità digitale dei membri della Federazione IDEM.
  • Alimentare la diffusione di metodi di autenticazione a più fattori.


NOTA BENE: L'approvazione del documento non implica alcun nuovo obbligo per le organizzazioni che non intendono adottare i profili di garanzia definiti.

Calendario

Evento Inizio Termine Note
Prima consultazione 11 Aprile 2023 26 Aprile 2023 Terminata
Seconda consultazione 2 Maggio 2023 16 Maggio 2023 Terminata
Votazione 17 Maggio 2023 24 Maggio 2023 (Assemblea IDEM) In corso

Documenti

Versione 1.0

File:Profili di garanzia delle identità digitali della Federazione IDEM-v1.pdf

Seconda consultazione

File:Profili di garanzia delle identità digitali della Federazione IDEM-BOZZA2.pdf

Prima consultazione

File:Profili di garanzia delle identità digitali della Federazione IDEM-BOZZA1.pdf

Commenti

Invitiamo tutti gli interessati ad inserire i propri commenti sul documento proposto nella tabella sottostante. In "Riferimento" inserire il testo che si intente commentare, o il numero di linea, pagina o sezione interessate (nel caso di commenti generali, inserire "generale").

Seconda consultazione

Riferimento Commento Autore Risposta (a cura del CTS)
Linea 309 "indicati per l’autenticazione a singolo fattore (vedi 4.4.1)."

Forse dovrebbe essere:

"indicati per l’autenticazione a singolo fattore (vedi 4.5.1)." ?

Maurizio Festi (UNITN) Modificato.
Linea 252 eduPersonPrimaryAffiliation: secondo me l'affiliazione primaria è una questione un po' ostica, il problema di base è che può dipendere dal contesto del service provider, non solo dal contesto dell'identity provider (es: un servizio che rilascia funzionalità agli studenti potrebbe volere "student", uno che le rilascia a docenti e ricercatore preferirebbe avere "faculty" come affiliazione primaria).

La definizione di refeds (https://wiki.refeds.org/display/STAN/eduPerson+2020-01#eduPerson202001-eduPersonPrimaryAffiliation) fa riferimento più che altro ad una sorta di "fama pubblica" del ruolo in Ateneo, ma rimane comunque ambigua e sempre dipendente dal contesto.

Per mitigare questa ambiguità di fondo, IDEM potrebbe rilasciare una linea guida con un "ordine di importanza" a cui riferirsi per scegliere l'affiliazione principale in caso di affiliazioni multiple?

Così da avere almeno un'uniformità all'interno della federazione e minore ambiguità per i service provider? (es, dal più importante al meno importante: faculty, staff, student, member, alumn, affliate)

Maurizio Festi (UNITN) E' stata indicata esplicitamente l'opzionalita' di rilascio di eduPersonPrimaryAffiliation (ePPA), che infatti non e' nemmeno incluso nelle Specifiche Tecniche Attributi IDEM.

Sulle modalita' di utilizzo di ePPA il CTS potra' intervenire come suggerito se si dimostrera' necessario.

Paragrafo 4.5.2 punto 4 forse si potrebbe indicare come esempio accettabile anche un concetto di "finestra temporale" in cui per un utente è possibile può attivarsi in self service il secondo fattore partendo dal primo fattore.

Questo semplificherebbe due fasi:

- il rilascio del secondo fattore ai nuovi utenti (es: ai nuovi studenti in periodo di iscrizioni ai test d'ingresso o immatricolazione)

- il deploy del secondo fattore a tutta la popolazione di un'organizzazione al momento del rilascio iniziale delle procedure MFA e dei relativi fattori di autenticazione aggiuntivi

Fuori da queste finestre temporali dovrebbe essere necessario l'intervento di un operatore di backoffice, per reinizializzare la finestra temporale in cui è possibile ottenere il secondo fattore in self service su richiesta degli utenti (e previo reidentificazione)

Maurizio Festi (UNITN) E' stato ulteriormente specificato il processo di attivazione di un "ulteriore" fattore di autenticazione in modo da dare indicazioni sui limiti temporali dei segreti trasmessi a questo fine.
Paragrafo "3.3. Procedure di verifica" per i membri che gestiscono un IdP sarebbe comodo avere una checklist di autovalutazione, la stessa che poi applicherà la Federazione IDEM quando farà le verifiche vere e proprie. Maurizio Festi (UNITN) E' stata inserita la definizione di una lista di autovalutazione per il fine indicato.
Generale una volta approvato il documento, potrebbe rilasciare degli esempi di configurazione di shibboleth idp da applicare in questo contesto? Es: filtro per rilasciare i valori "IDEM" in eduPersonAssurance solo ai service provider di IDEM, e non ad eduGain in generale (anche se credo che non dovrebbero creare problemi rilasciando questi valori in eduPersonAssurance per tutti). Maurizio Festi (UNITN) Certamente.
Generale come faranno i service provider a richiedere all'idp uno specifico profilo di garanzia tra quelli supportati da IDEM (acr e authncontexclass fanno riferimento più che altro a metodi di autenticazione, non direttamente al profili)?

Faranno una verifica a posteriori dopo l'avvenuta autenticazione? O chiederanno semplicemente "https://refeds.org/profile/mfa" per implicitamente richiedere P2/P3?

Maurizio Festi (UNITN) Negli allegati al documento sono gia' contenute alcune indicazioni sul tema. Maggiori approfondimenti saranno rilasciati con l'estensione di linee guida.
Generale un'organizzazione che ha ottenuto il profilo P2, deve sempre emettere autenticazioni verso la federazione IDEM con autenticazione MFA? Maurizio Festi (UNITN) No, ed e' stata esplicitata tale non obbligatorieta'.
Paragrafo "4.3.2. Controllo e verifica dell’identità" si fa riferimento ad "un documento di identita’ riconosciuto dallo Stato italiano" si fa riferimento a soli documenti italiani?Immagino che si faccia riferimento anche a documenti di identità esteri per gli stranieri, se l'interpretazione è questa, che voi sappiate, c'è da qualche parte un riferimento a quali sono questi documenti riconosciuti dallo Stato italiano? Maurizio Festi (UNITN) Il riferimento e' ai documenti di identita' riconosciuti dallo Stato italiano, non ai documenti italiani. Come sotto categoria utile per determinare i documenti d'identita' riconosciuti dallo Stato italiano, si puo' consultare il "PRADO - Registro pubblico online dei documenti di identità e di viaggio autentici" dell'Unione Europea (e a cui rimanda la Polizia di Stato stessa): https://www.consilium.europa.eu/prado/it/prado-recognised-documents.html


Paragrafo "4.3.2. Controllo e verifica dell’identità" riguardo un documento di identità si indica "che sia stato verificato per stabilirne l'autenticità oppure, secondo una fonte autorevole, esiste ed è collegato a una persona reale.", implicitamente si sta richiedendo alla persona che dovrà visionare il documento una competenza e una formazine tale da essere in grado di fare questo tipo di valutazioni oltre alla possibilità di utilizzare un qualche strumento per accedere ad informazioni sullo stato dei documenti di identità (almeno italiani).

Come IDEM potreste valutare l'interesse della comunità (e nel caso la possibilità concreta di organizzararlo) per un corso di formazione specifico su questi aspetti? Il target sarebbero le persone che nelle organizzazioni rilasciano credenziali agli utenti.

Sarebbe anche utile l'indicazione di quali strumenti sono disponibili in Italia per fare questo tipo di verifiche e come si può chiederne l'accesso.

Probabilmente un corso del genere andrebbe organizzato con del personale esperto al riguardo, immagino qualcuno di qualche questura o delle dogane o di qualche funzione statale simile.

Maurizio Festi (UNITN) Come CTS accogliamo la proposta e ci attiveremo sulla base della condivisione della necessita' da parte della comunita' IDEM.

Prima consultazione

Riferimento Commento Autore Risposta (a cura del CTS)
Riga 256 I profili indicati IDEM-P0 e IDEM-P1 dovrebbero essere IDEM-P2 e IDEM-P3 Federico Giorgetti (UNIPG) Modificato.
Riga 58 "Profiles" => "Profile" perchè i termini inglesi inseriti in un testo italiano non vanno declinati al plurale Marco Malavolti (GARR) Modificato.
Riga 84,85 Il "può registrare" mi fa pensare che un Partner possa aderire a IDEM senza entità, ma ciò non è possibile secondo quanto riportato dalle Procedure di Adesione. Marco Malavolti (GARR) Sì, specificato "che gestisce un Service Provider".
Riga 106 "indicato." => "desiderato." o, meglio, "scelto."

Questa modifica viene proposta per riprendere quanto scritto nel punto precedente.

Marco Malavolti (GARR) No, il termine corretto e' proprio "indicato" dato che in quella fase si tratta della dichiarazione di conformita' effettiva.
Righe 127-130 Registrare tutte le informazioni pertinenti al processo di erogazione e gestione delle

credenziali,e conservarle nella misura consentita dalla legislazione nazionale e

renderle disponibili in caso di indagini e verifiche sulla sicurezza delle credenziali e

dei dati degli interessati.

Marco Malavolti (GARR) Modificato.
Riga 264 "tra 72 e 52 caratteri" => "tra 52 e 72 caratteri" Marco Malavolti (GARR) Modificato.
Riga 327 "IDEM P1, IDEM P2, IDEM P3" => "IDEM-P1, IDEM-P2, IDEM-P3" Marco Malavolti (GARR) Modificato.
Riga 381 Manca il punto finale per coerenza con gli altri punti indicati Marco Malavolti

(GARR)

Modificato.
Riga 424 E' corretto l' * in "https://refeds.org/assurance/ID/eppn-unique-no-reassign*" ? Se SI, manca la spiegazione dell' * . Marco Malavolti

(GARR)

Modificato.
Riga 213 Forse è utile specificare che i link per scaricare le credenziali siano utilizzabili un'unica volta e per un intervallo limitato di tempo. Lorenzo Iannuzzi

(UNIFI)

Sì, aggiunto rimando alla sezione 4.5.1 punto 2.