Source: https://www.opensipa.it/notizie/spid-faq-di-carattere-generale
Timestamp: 2019-03-23 20:34:26+00:00
Document Index: 126152058

Matched Legal Cases: ['art. 17', 'art. 640', 'art 13', 'art. 6', 'art. 7', 'art.1', 'art. 16']

#SPID: FAQ di carattere generale | opensipa.it
#SPID: FAQ di carattere generale
A1: Perché abbiamo bisogno di identity provider (IdP) e non di una amministrazione pubblica che faccia le stesse cose?
RA1: Ci sono 5 motivi principali per cui si preferisce avvalersi di IdP piuttosto che svolgere questo compito all'interno di strutture governative o equipollenti:
Principio della libertà di scelta dell'utente. Ogni cittadino potrà scegliere l’IdP che vorrà e smettere di usare un provider se lo desidera.
A2: Non bastava il documento digitale unificato (DDU) per provare l’identità digitale?
RA2: SPID realizza un modello federato adatto a vari scenari (tecnologici, organizzativi e di business), anche in mobilità, nel quale oltre alle identità personali sono gestiti i ruoli, i titoli e le qualifiche professionali, non gestiti con il DDU. Inoltre, il DDU e ogni altro supporto plastificato equivalente richiede un lettore di carte, al contrario, SPID è tecnologicamente neutrale e indipendente da qualunque specifico device.
A3: Perché lo Stato non ha deciso di finanziare l’identità digitale SPID?
RA3: Lo sviluppo di un’economia digitale può essere accompagnato dallo sviluppo di ruoli e segmenti di mercato specializzati. Non è un obbligo per il cittadino possedere un’identità SPID ma un’opportunità, il cui vantaggio genererà offerte capaci di soddisfare le diverse esigenze.
A4: SPID sarà un sistema tutto italiano non interoperabile con sistemi di altre nazioni?
RA4: Dopo l’emanazione del regolamento comunitario e-IDAS (Electronic Identity Authentication and Signature) e la notifica da parte del governo italiano del DPCM che regolamenta SPID alla Commissione europea, il sistema italiano sarà accettato dagli altri Stati membri dell’UE. Il combinato disposto dei due provvedimenti regolatori consente di realizzare l’interoperabilità del sistema SPID nel panorama tecnologico europeo. In questo quadro, SPID si basa sulle specifiche OASIS SAML v2.0 molto diffuse a livello europeo e adottate nel progetto sperimentale Stork (un progetto condiviso su larga scala da molti Paesi europei che mira a sviluppare un’infrastruttura comune per l’identità digitale, sia per le persone fisiche sia per quelle giuridiche).
A5: Rispetto alle carte elettroniche l’uso delle identità SPID sarà più semplice?
RA5: Assolutamente sì. Per l’uso dell’identità SPID non è obbligatorio l’uso di alcun lettore di carte ma potrà essere utilizzata in diverse modalità (es. PC, smartphone, tablet, etc.). Il cittadino sarà libero di scegliere la soluzione che offre il mercato e cambiarla quando vuole.
A6: L’uso di SPID assicura la protezione dei dati personali quanto l’uso delle carte elettroniche?
RA6: SPID protegge i dati personali più di una smart-card. Con le carte elettroniche i dati personali utili a verificare l’identità in rete sono tutti disponibili al service provider. Con SPID, sebbene l’utente sarà sempre autenticato con assoluta certezza, saranno forniti al service provider, previa autorizzazione dell’utente, solo i dati strettamente necessari per la specifica transazione. Ad esempio, per i servizi che necessitano solo di verificare la maggiore età del soggetto o di conoscere un indirizzo email, l’identity provider fornirà al service provider solo le informazioni strettamente necessarie.
A7: Il cittadino sarà comunque obbligato a usare sempre e comunque lo strumento di autenticazione scelto, così come è obbligato ad usare sempre una carta elettronica?
RA7: No, il cittadino potrà dotarsi di diversi strumenti (e quindi diverse identità SPID, eventualmente con livelli diversi di sicurezza) ed utilizzare quello più comodo nella singola occasione.
A8: SPID non è un ulteriore onere economico per le PA?
RA8: No, al contrario. Le PA non dovranno più gestire l’autenticazione degli utenti poiché sarà eseguita dai gestori di identità che forniranno il servizio di autenticazione alle PA a titolo gratuito. Le PA potranno così concentrarsi nella realizzazione di servizi utili a cittadini e imprese.
A9: Quali benefici avranno i service provider privati consentendo l’autenticazione in rete tramite SPID?
RA9: Disporre di un parco utenti senza bisogno di censirli, non avranno gli oneri derivanti dalla conservazione dei dati personali, non dovranno preoccuparsi di evitare attacchi volti al furto delle credenziali, infine, avranno soddisfatto per legge gli oneri previsti dall’art. 17,comma 2, del D.Lgs. 70/2003 riferendo semplicemente che l’accesso al proprio servizio è avvenuto tramite SPID.
A10: Una volta scelto un gestore di identità e ottenuta l’identità, il cittadino sarà indissolubilmente legato a quel soggetto?
RA10: No, il cittadino potrà revocare l’identità ottenuta in qualunque momento senza dover fornire alcuna spiegazione.
A11: Ipotizzando che il cittadino sia dotato di due identità SPID fornite da due diversi gestori, iniziando un processo amministrativo con una identità SPID, dovrà ricordarsi quale identità ha utilizzato per accedere nuovamente a quella PA per seguire la propria pratica o presentare altra documentazione?
RA11: No. La PA, sarà in grado di riconoscere il cittadino e consentirgli di accedere ai propri dati e alle proprie pratiche a prescindere dall’identità SPID utilizzata dal cittadino.
A12: Come è protetto il cittadino dalla legge a seguito di un furto di identità SPID perpetrato ai suoi danni?
RA12: È protetto da un punto di vista civile dalle norme che regolano SPID, ma anche dal codice penale che in questo caso prevede la reclusione fino a tre anni (oltre ad una multa) per il gestore di identità (art. 640-quinquies del codice penale). Altre norme sono applicabili al gestore di identità in quanto agisce in qualità di gestore di servizio pubblico.
A13: Un service provider non potrebbe inventarsi di sana pianta che un cittadino ha acceduto ad un servizio ed effettuato determinate azioni dopo essersi autenticato con una identità SPID?
RA13: Un tale crimine non si può escludere, ma differentemente dal caso in cui si utilizzasse una carta elettronica, con l’uso dell’identità SPID tale reato (sostituzione di persona, frode informatica, ecc.) sarebbe facilmente provabile. Il gestore dell’identità infatti deve mantenere traccia dei processi di autenticazione effettuati.
A14: Considerato che il cittadino può dotarsi di diverse identità fornite da diversi gestori, non corre il rischio di avere identità digitali attive di cui ha perso memoria?
RA14: No, il rischio è mitigato dalla previsione che prescrive al gestore dell’identità di tener traccia dell’uso delle singole identità emesse e, non rilevandone l’utilizzo per un periodo di 24 mesi, deve revocare l’identità non utilizzata.
Gruppo B – FAQ su implementazione delle interazioni
B1: E’ prevista una modalità di logout distribuito in SPID?
RB1: Al momento non è previsto per SPID un profilo di single logout.
B2: Quale sarà la validità temporale delle informazioni fornite dal Registro SPID e con che frequenza questo verrà tenuto aggiornato?
RB2: La validità temporale del contenuto del Registro SPID non sarà inferiore a 24h a partire dalla mezzanotte di ogni giorno. La frequenza di aggiornamento è legata agli eventi che possono determinarne una variazione, ovvero l’introduzione o la cessazione dell’attività di un IDP o di un SP.
B3: In che modo l'IDP o l'SP devono trattare richieste o risposte che non rispettano le specifiche fornite da AgID?
RB3: L’azione da compiere, qualora fosse mancante un elemento determinante nel formato delle richieste/risposte, dovrà essere l'interruzione del processo di autenticazione con conseguente notifica ad Agid dell’anomalia riscontrata.
B4: In virtù dell’art 13 comma 4 dello schema di DPCM i fornitori di servizio comunicano all'utente la verifica degli attributi presso IDP e AA. Quali sono le policy per l'invio degli attributi ai SP da parte degli IDP e AA degli attributi? Inoltre, per ridurre le interazioni con gli AA è possibile immaginare di mantenere in cache gli attributi degli utenti per la durata del loro periodo di validità?
RB4: In osservanza alle direttive del garante Privacy, un SP può ottenere da un IDP o da un AA solo gli attributi necessari per la verifica delle policy di accesso al servizio richiesto – comunicate agli utenti alla registrazione al servizio specifico e per le quali ha ricevuto esplicito assenso - e utilizzarli puntualmente solo a questo fine.
B5: Confidenzialità degli scambi: possiamo assumere SSL 3.0 o TLS 1.0 obbligatorio?
RB5: Il profilo SAML SSO raccomanda l’uso del protocollo TLS 1.0 nei colloqui tra Asserting party e le Relying party. Riteniamo in ambito SPID di rendere obbligatorio l’uso di un canale securizzato, consigliando l’impiego di protocolli TLS nella versione 1.0 o successive.
B6: E' prevista una semantica condivisa degli attributi e una nomenclatura dei nomi e dei valori da essi assunti?
RB6: Sarà definita una tassonomia per gli attributi qualificati riconosciuti in SPID con il relativi significati univoci identificatori e valori assunti;
B7: Un attributo qualificato potrà essere certificato da un’unica AA oppure potranno essere previste più AA certificanti lo stesso attributo? Esiste un tempo massimo di validità delle asserzioni di attributo?
RB7: Si prevede che vi sia una unica AA certificante un attributo qualificato; quanto alla validità dell’asserzione questa potrà dipendere dalla particolarità dell’attributo e dalle scelte dell’entità che lo governa.
B8: E’ ipotizzabile mantenere separati il processo di registrazione degli utenti e quello di rilascio delle credenziali?
RB8: Il processo di registrazione e quello del rilascio delle credenziali, come specificato anche dalle norme tecniche di riferimento indicate nel DPCM, sono due fasi distinte di uno stesso processo.
B9: Con riferimento all’art. 6 comma 3 dello schema DPCM, a cosa si riferisce quando si parla di “software necessario per effettuare l’autenticazione informatica” ?
RB9: L’articolo si riferisce al divieto per l’IDP di imporre ai SP l’acquisto di sw o hw di proprietà dell’IDP al fine di poter far accedere un soggetto dotato di identità SPID ai propri servizi.
B10: La generazione di credenziali tramite l’utilizzo di una credenziale esistente di pari livello, garantita dell’art. 7 comma 2c dello schema di DPCM, potrebbe aprire scenari di possibile “furto d’identità”. Infatti a seguito di un furto, anche solo temporaneo, di un’identità SPID, un soggetto terzo potrebbe generare in modo indiscriminato credenziali su altri IDP, senza che il soggetto titolare se ne possa averne contezza. Come si gestisce il rischio legato a questa eventualità?
RB10: La problematica evidenziata è governata dall’articolo 9 dello schema di DPCM, a cui si rimanda per una risposta al quesito.
B11. E’ presente un insieme minimo di attributi che gli identity provider sono tenuti a fornire? Per ciò che riguarda gli attributi secondari legati alle funzioni di comunicazione con il cittadino, quali di essi saranno obbligatori?
RB11: L’art.1 comma 1 c) dello schema di DPCM definisce gli attributi identificativi obbligatori, per quanto riguarda gli attributi non identificativi si veda lo stesso articolo al comma d), Si tenga presente che gli attributi non identificativi sono funzionali alle comunicazioni di servizio tra il gestore dell’identità digitale (ovvero l’Identity Provider ) e l’utente. Si precisa che per questi colloqui si prevede un canale di comunicazione “fuori linea” rispetto al meccanismo di autenticazione (si pensi all’uso del telefono).
B12. Quali sono i criteri da seguire in SPID per l’individuazione, a partire da un determinato attributo, dell’ AA in grado di certificarlo?
RB12: Ai sensi dell’art. 16 dello schema di DPCM, i metadati delle Asserting party (IDP e AA) riportano gli attributi che sono in grado di certificare. Per agevolare il compito dei SP nella ricerca delle entità in grado di certificare gli attributi di suo interesse si sta pensando di riportare gli elenchi di attributi certificabili da una entità direttamente sul Registro SPID.
B13: La specifica SPID fa riferimento al binding HTTP-GET. Dal punto di vista tecnico questo potrebbe comportare delle criticità date le limitazioni sulla lunghezza della query, inoltre dal punto di vista della privacy tutti i parametri di tutte le query verrebbero automaticamente loggati tra i log del webserver. Queste informazioni includono nomi, cognomi, codici fiscali e servizi usati.
RB13: L’uso di redirect con http-get è previsto dallo standard SAML, le limitazioni sulla lunghezza sono state tenute in conto e gestite (come suggerito dallo standard mediante codifica base64). Quanto alla problematica relativa alla privacy si fa osservare che l’uso del binding http-get è previsto solo per la veicolazione della <AUTHNREQUEST> , cioè della richiesta di autenticazione, dove non sono presenti dati personali riferibili all’identità digitale (nome, cognome, codice fiscale etc.). Queste informazioni sono contenute nelle asserzioni che, sempre secondo standard, sono veicolate solo tramite http-post. In ogni caso è prevista la possibilità e la modalità per veicolare l’<AUTHNREQUEST> anche mediante http-post.
Fonte: http://www.agid.gov.it/agenda-digitale/infrastrutture-architetture/spid/domande-frequenti