Cerca nel documento
Informazioni
Scarica
Sorgente
Azioni

# SPID - Regole Tecniche

SPID, il Sistema Pubblico di Identità Digitale, è la soluzione che permette di accedere a tutti i servizi online della Pubblica Amministrazione con un’unica Identità Digitale (username e password) utilizzabile da computer, tablet e smartphone. Maggiori informazioni sono riportate nel sito www.spid.gov.it

Le Regole Tecniche definiscono le specifiche per l’integrazione di Identity Provider, Service Provider ed Attribute Authority mediante il protocollo SAML.

Nota

Questo documento è la versione consolidata delle Regole Tecniche emanate dall’Agenzia per l’Italia Digitale, con applicati gli Avvisi che le emendano, per una facile consultazione da parte degli sviluppatori. I contenuti sono aderenti ai documenti ufficiali, disponibili nel sito AgID, ma sono presentati secondo una differente struttura dei capitoli e sono arricchiti da informazioni utili indicate con le diciture «Nota» e «Questo paragrafo ha scopo informativo e non normativo».

Questo Documento comprende le specifiche contenuto nell Avviso AgID n° 34 e precedenti.

## Indice dei contenuti

### Introduzione

SPID è basato sul framework SAML (Security Assertion Markup Language), sviluppato e manutenuto dal Security Services Technical Committee di OASIS, che permette la realizzazione di un sistema sicuro di Single Sign-On (SSO) federato. Grazie a SAML, un utente può accedere ad una moltitudine di servizi appartenenti a domini differenti effettuando un solo accesso.

Il sistema è composto da 3 entità:

- Gestore delle identità (Identity Provider o IdP) che gestisce gli utenti e la procedura di autenticazione;
- Fornitore di servizi (Service Provider o SP) che, dopo aver richiesto l’autenticazione dell’utente all’Identity Provider, ne gestisce l’autorizzazione sulla base degli attributi restituiti dal Gestore dell’identità, ed eroga il servizio richiesto;
- Gestore di attributi qualificati (Attribute Authority o AA) che fornisce attributi qualificati (ad esempio titoli di studio, iscrizione ad albi, ecc.) sulla base dell’utente autenticato.

Le modalità di funzionamento di SPID sono quelle previste da SAML v2 per il profilo «Web Browser SSO» - SAML V2.0 Technical Overview - Oasis par4.3.

### Metadata

Ciascuna entità presente nella federazione SPID è descritta da un file di metadati, che ne riporta il certificato X509, gli endpoint e le altre informazioni necessarie alla comunicazione con le altre entità.

Nota

La distribuzione dei metadati a tutti i soggetti è operata dall’Agenzia per l’Italia Digitale attraverso il Registro.

Avvertimento

I fornitori di servizi pubblici - come identificati nell’Avviso AgID numero 28/2020 - possono continuare ad utilizzare certificati self-signed. Per la richiesta di emissione dei certificati digitali ai fini del Sistema Pubblico delle Identità Digitali (SPID) si rimanda ai seguenti Avvisi: - Avviso AgID n23 - Avviso AgID n23 - modulo di richiesta

#### Disponibilità dei metadata

I metadata Identity Provider saranno disponibili per tutte le entità SPID federate attraverso la URL https://<dominioGestoreIdentita>/metadata, ove non diversamente specificato nel Registro SPID, e saranno firmate in modalita detached dall’Agenzia per l’Italia Digitale. L’accesso deve essere effettuato utilizzando il protocollo TLS nella versione più recente disponibile.

I metadata dei Service Provider saranno disponibili per tutte le entità SPID federate attraverso la URL https://<dominioServiceProvider>/metadata e saranno firmate dall’Agenzia per l’Italia Digitale. L’accesso deve essere effettuato utilizzando il protocollo TLS nella versione più recente disponibile.

Nota

Nonostante sia richiesta la pubblicazione dei metadata nel dominio del Service Provider, la distribuzione dei metadati agli Identity Provider è operata centralmente dall’Agenzia per l’Italia Digitale. Gli Identity Provider di conseguenza non ottengono i metadati direttamente dai Service Provider.

##### Certificati

Nota

spid-compliant-certificates è un tool che automatizza la creazione dei certificati per Privati ed Enti Pubblici.

I certificati di sigillo elettronico utilizzati dai SP pubblici e privati sono conformi a RFC-5280 e devono contenere le seguenti estensioni, valorizzate con il corretto uso di minuscole, maiuscole, lettere accentate e altri segni diacritici:

1. Nel campo SubjectDN:

   1. commonName (oid 2.5.4.3) — La denominazione che valorizza l’estensione organizationName, eventualmente senza esplicitazione degli acronimi, come riportata nel tag XML <OrganizationDisplayName> del metadata del SP (esempio: “AgID”).

   2. organizationName (oid 2.5.4.10) — Denominazione completa e per esteso del SP, così indicata nei pubblici registri e come riportata nel tag xml <OrganizationName> del metadata del SP (esempio: “Comune di Forlì” e non “COMUNE DI FORLI””);

   3. uri (oid 2.5.4.83) — EntityID del SP, così come riportato nell’attributo entityID del tag XML <EntityDescriptor> del metadata del SP.

   4. organizationIdentifier (oid 2.5.4.97)

        Codice identificativo unico del SP all’interno della federazione SPID, conforme alla sintassi prevista dalla norma ETSI en 319-412-1, 5.1.4:

      SP pubblici valorizzato con il prefisso ‘PA:IT-’ seguito dal codice ipa dell’Ente — esempio, per il Comune di Roma (codice ipa ‘c_h501’) tale estensione è valorizzata come “PA:IT-c_h501”;

      SP privati — la seguente alternativa di codici utilizzando, in ordine di preferenza:

      > il numero di partita iva, preceduto dal prefisso ‘VAT,’ seguito dal codice ISO 3166-1 α-2 del Paese, seguito dal carattere ‘-’ (esempio, “VATIT-12345678901”);

      > per i soggetti non provvisti di partita iva, il codice fiscale, preceduto dal prefisso ‘CF:IT-’ (esempio: “CF: IT-XYZABCAAMGGJ000W”);

      Altro codice alternativo fornito da AgID in casi particolari.

   5. countryName (oid 2.5.4.6) — il codice ISO 3166-1 del Paese ove è situata la sede legale del SP (esempio: “IT”);

   6. localityName (oid 2.5.4.7) — il nome completo della città ove è situata la sede legale del SP (esempio: Forlì e non Forli”).

2. Nel campo CertificatePolicies:

   policyIdentifier — contenente almeno uno dei seguenti identificatori:

   > - SP pubblici — spid-publicsector-SP (oid 1.3.76.16.4.2.1);
   > - SP privati — spid-privatesector-SP (oid 1.3.76.16.4.3.1).

Trattandosi di certificati di sigillo elettronico e non di certificati di firma elettronica, gli attributi name (oid 2.5.4.41), surname (oid 2.5.4.4), givenName (oid 2.5.4.42), initials (oid 2.5.4.43) e pseudonym (oid 2.5.4.65) non devono essere utilizzati. Altre estensioni, come ad esempio emailAddress (oid 1.2.840.113549.1.9.1), se presenti, non sono valorizzate con dati personali afferenti a persone fisiche.

Gli SP pubblici possono creare autonomamente i certificati elettronici necessari. I certificati possono anche essere di tipo self-signed. Qualora il SP pubblico utilizzi un certificato dedicato all’apposizione del sigillo elettronico sul proprio metadata e un altro certificato dedicato all’apposizione di sigilli elettronici sulle proprie request, il presente Avviso si applica ad entrambi.

A seguito dell’accreditamento presso AgID, i SP privati ricevono un certificato di federazione emesso dall’infrastruttura a chiave pubblica (pki) che AgID ha istituito appositamente per la gestione dell’intera federazione SPID. Al fine di ottenere detto certificato si deve far riferimento all’Avviso SPID n23/2016 e s.m.i. e compilare il previsto modulo di richiesta. La chiave privata cui tale certificato afferisce è utilizzata dal SP privato per apporre sigilli elettronici avanzati sia sul proprio metadata che sulle proprie request.

Ulteriori estensioni stabilite dagli standard e dalle normative sono liberamente utilizzabili.

##### Algoritmi crittografici, di hash e tipologia delle chiavi

Per la generazione delle chiavi crittografiche i SP utilizzano l’algoritmo rsa (Rivest-Shamir-Adleman) con lunghezza delle chiavi non inferiore a 2048 bit. L’algoritmo impiegato per le impronte crittografiche è il dedicated hash-function 4 definito nella norma ISO/IEC 10118-3, corrispondente alla funzione sha-256. È consentito l’uso della funzione sha-512.

#### Identity Provider

Le caratteristiche dell’Identity provider sono definite attraverso metadata conformi allo standard SAML v2.0 (SAML-Metadata) e rispettano le condizioni di seguito indicate:

SI DEVE

- Nell’elemento `<EntityDescriptor>` deve essere presente il seguente attributo:

  > - `entityID` indicante l’identificativo (URI) dell’entità univoco in ambito SPID

- L’elemento `<IDPSSODescriptor>` contraddistingue l’entità di tipo Identity Provider e deve riportare i seguenti attributi:

  > - `protocolSupportEnumeration`: che enumera gli URI indicanti i protocolli supportati dall’entità (poiché si tratta di un’entità SAML 2.0, deve indicare almeno il valore del relativo protocollo: `urn:oasis:names:tc:SAML:2.0:protocol`)
  > - `WantAuthnRequestsSigned`: attributo con valore booleano che impone ai Service Provider che fanno uso di questo Identity provider l’obbligo della firma delle richieste di autenticazione;

  > all’interno di `<IDPSSODescriptor>` devono essere presenti:

  > > - l’elemento `<KeyDescriptor>` che contiene l’elenco dei certificati e delle corrispondenti chiavi pubbliche dell’entità, utili per la verifica della firma dei messaggi prodotti da tale entità nelle sue interazioni con le altre (SAMLMetadata, par. 2.4.1.1)

  > > - l’elemento `<NameIDFormat>` riportante l’attributo:

  > >   > - `format`, indicante il formato `urn:oasis:names:tc:SAML:2.0:nameidformat:transient` come quello supportato per l’elemento di `<NameID>` utilizzato nelle richieste e risposte SAML per identificare l’identificativo del soggetto (subject id) cui si riferisce un’asserzione

  > > - uno o più elementi `<SingleSignOnService>` che specificano l’indirizzo del Single Sign-On Service riportanti i seguenti attributi:

  > >   > - `Location` URL endpoint del servizio per la ricezione delle richieste

  > >   > - `Binding` che può assumere uno dei valori

  > >   >   > - `urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect`
  > >   >   > - `urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST`

  > > - uno o più elementi `<SingleLogoutService>` che specificano l’indirizzo del Single Logout Service riportanti i seguenti attributi:

  > >   > - `Location` URL endpoint del servizio per la ricezione delle richieste di Single Logout;

  > >   > - `Binding` che può assumere uno dei valori

  > >   >   > - `urn:oasis:names:tc:SAML:2.0:bindings:SOAP`
  > >   >   > - `urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect`
  > >   >   > - `urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST`

  > >   >   > Nota

  > >   >   > Ad oggi, nessun Identity Provider espone un SingleLogoutService basato su SOAP.

  > >   > - `ResponseLocation` (opzionale): URL endpoint del servizio per la ricezione delle risposte alle richieste di Single Logout.

  > opzionalmente possono essere presenti:

  > > - uno o più elementi `<Attribute>` ad indicare nome e formato degli attributi SPID certificabili dell’Identity Provider (cfr. Tabella attributi SPID), riportanti gli attributi:

  > >   > - `Name`: nome dell’attributo SPID (colonna identificatore della Tabella attributi SPID)
  > >   > - `xsi:type`: tipo dell’attributo (colonna tipo della Tabella attributi SPID)

- Deve essere presente l’elemento `<Signature>` riportante la firma sui metadata. La firma deve essere prodotta secondo il profilo specificato per SAML (SAML-Metadata, cap. 3) utilizzando chiavi RSA almeno a 2048 bit e algoritmo di digest SHA-256 o superiore. Gli SP pubblici possono creare autonomamente i certificati elettronici necessari e questi possono essere anche di tipo self-signed. I Fornitori Privati dovranno fare invece richiesta presso AgID.

SI PUÒ

- È consigliata la presenza di un elemento `<Organization>` a indicare l’organizzazione a cui afferisce l’entità specificata, riportante gli elementi:

  > - `<OrganizationName>` indicante un identificatore language-qualified dell’organizzazione a cui l’entità afferisce
  > - `<OrganizationURL>` riportante in modalità language-qualified la URL istituzionale dell’organizzazione.

##### Esempio: metadata IdP

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    <md:EntityDescriptor xmlns:md = "urn:oasis:names:tc:SAML:2.0:metadata"
        xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
        xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance"
        xmlns:fpa="https://spid.gov.it/invoicing-extensions"
        xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
        entityID="http://spid.identityprovider.it"
        ID="_2ini49248n98dn984n...">
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            [...]
        </ds:Signature>
        <md:IDPSSODescriptor
            protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"
            WantAuthnRequestsSigned="true">
            <md:KeyDescriptor use="signing">...</md:KeyDescriptor>
            <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
                Location="https://spid.identityprovider.it/Post-Post-saml2slo"
                ResponseLocation="https://spid.identityprovider.it/Post-Post-saml2slo"/>
            <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
                Location="https://spid.identityprovider.it/redirect-Post-saml2slo"
                ResponseLocation="https://spid.identityprovider.it/redirect-Post-saml2slo"/>
            <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat>
            <md:SingleSignOnService
                Location="https://spid.identityprovider.it/redirect-Post-saml2sso"
                Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/>
            <md:SingleSignOnService
                Location="https://spid.identityprovider.it/Post-Post-saml2sso"
                Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
            <saml:Attribute xsi:type="xsi:string" Name="familyName"/>
            <saml:Attribute xsi:type="xsi:string" Name="name"/>
            <saml:Attribute xsi:type="xsi:string" Name="spidCode"/>
            <saml:Attribute xsi:type="xsi:string" Name="fiscalNumber"/>
            <saml:Attribute xsi:type="xsi:string" Name="gender"/>
            <saml:Attribute xsi:type="xsi:string" Name="dateOfBirth"/>
            <saml:Attribute xsi:type="xsi:string" Name="placeOfBirth"/>
            <saml:Attribute xsi:type="xsi:string" Name="companyName"/>
            <saml:Attribute xsi:type="xsi:string" Name="registeredOffice"/>
            <saml:Attribute xsi:type="xsi:string" Name="ivaCode"/>
            <saml:Attribute xsi:type="xsi:string" Name="idCard"/>
            <saml:Attribute xsi:type="xsi:string" Name="mobilePhone"/>
            <saml:Attribute xsi:type="xsi:string" Name="email"/>
            <saml:Attribute xsi:type="xsi:string" Name="address"/>
            <saml:Attribute xsi:type="xsi:string" Name="digitalAddress"/>
        </md:IDPSSODescriptor>
        <md:Organization>
            <md:OrganizationName xml:lang="it">SPID Identity Provider</md:OrganizationName>
            <md:OrganizationDisplayName xml:lang="it">SPID Identity Provider</md:OrganizationDisplayName>
            <md:OrganizationURL xml:lang="it">https://spid.identityprovider.it</md:OrganizationURL>
        </md:Organization>
        <md:ContactPerson contactType="billing">
            <md:Extensions>
                <fpa:CessionarioCommittente>
                <fpa:DatiAnagrafici>
                <fpa:IdFiscaleIVA>
                    <fpa:IdPaese>IT</fpa:IdPaese>
                    <fpa:IdCodice>983745349857</fpa:IdCodice>
                </fpa:IdFiscaleIVA>
                <fpa:Anagrafica>
                    <fpa:Denominazione>Destinatario Fatturazione</fpa:Denominazione>
                </fpa:Anagrafica>
                </fpa:DatiAnagrafici>
                <fpa:Sede>
                    <fpa:Indirizzo>via tante cose</fpa:Indirizzo>
                    <fpa:NumeroCivico>12</fpa:NumeroCivico>
                    <fpa:CAP>87100</fpa:CAP>
                    <fpa:Comune>Cosenza</fpa:Comune>
                    <fpa:Provincia>CS</fpa:Provincia>
                    <fpa:Nazione>IT</fpa:Nazione>
                </fpa:Sede>
                </fpa:CessionarioCommittente>
            </md:Extensions>
            <md:Company>example s.p.a.</md:Company>
            <md:EmailAddress>info@example.org</md:EmailAddress>
            <md:TelephoneNumber>+39 84756344785</md:TelephoneNumber>
        </md:ContactPerson>
    </md:EntityDescriptor>

#### Service Provider

Le caratteristiche del Service Provider devono essere definite attraverso metadata conformi allo standard SAML v2.0 (SAML-Metadata) e rispettare le condizioni di seguito indicate:

- Nell’elemento `<EntityDescriptor>` deve essere presente il seguente attributo:

  > - entityID (1 occorrenza) - Attributo valorizzato con l’EntityID, così come riportato nell’estensione uri del certificato elettronico del SP. In caso il SP svolga più attività - come ad esempio quella di SP pubblico e di SP privato - si dota di metadata saml differenti, ciascuno con un diverso EntityID.

- Deve essere presente l’elemento `<KeyDescriptor>` contenenete il certificato della corrispondente chiave pubblica dell’entità, utile per la verifica della firma dei messaggi prodotti da tale entità nelle sue interazioni con le altre (SAML-Metadata, par. 2.4.1.1);

- Deve essere presente l’elemento `<Signature>` riportante la firma sui metadata. La firma deve essere prodotta secondo il profilo specificato per SAML (SAML-Metadata, cap. 3) utilizzando chiavi RSA almeno a 2048 bit e algoritmo di digest SHA-256 o superiore;

- Deve essere presente un solo elemento `<SPSSODescriptor>` riportante i seguenti attributi:

  > - `protocolSupportEnumeration`: che enumera, separati da uno spazio, gli URI associati ai protocolli supportati dall’entità (poiché si tratta di un’entità SAML 2.0, deve indicare almeno il valore del relativo protocollo: `urn:oasis:names:tc:SAML:2.0:protocol`);
  > - `AuthnRequestSigned`: valorizzato `true` attributo con valore booleano che esprime il requisito che le richieste di autenticazione inviate dal Service Provider siano firmate;

- Deve essere presente almeno un elemento `<AssertionConsumerService>` indicante il servizio (in termini di URL e relativo binding HTTP-POST) a cui contattare il Service Provider per l’invio di risposte SAML, riportante i seguenti attributi:

  > - `index` che può assumere valori unsigned;
  > - `Binding` posto al valore `urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST`;
  > - `Location` URL endpoint del servizio per la ricezione delle risposte;

  > In particolare il primo di questi elementi (o l’unico elemento riportato) deve obbligatoriamente riportare:

  > - l’attributo `index` posto al valore `0`;
  > - l’attributo `isDefault` posto al valore `true`;

- Deve essere presente almeno un elemento `<SingleLogoutService>` indicante l’indirizzo del SingleLogoutService e riportante i seguenti attributi:

  > - `Location` URL endpoint del servizio per la ricezione delle richieste di Single Logout;

  > - `Binding` che può assumere uno dei valori

  >   > - `urn:oasis:names:tc:SAML:2.0:bindings:SOAP`
  >   > - `urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect`
  >   > - `urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST`

  > ed opzionalmente l’attributo:

  > > - `ResponseLocation`, URL endpoint del servizio per la ricezione delle risposte alle richieste di Single Logout.

- Organization (1 occorrenza) — Contiene vari tag, ciascuno dei quali ripetuto almeno una volta valorizzato in lingua italiana, più occorrenze facoltative localizzanti il medesimo nome in ulteriori lingue (identificate mediante l’attributo xml:lang, obbligatoriamente presente in tutti i tag figli):

  - OrganizationName (1 o più occorrenze) — Denominazione – completa e per esteso e con il corretto uso di minuscole, maiuscole, lettere accentate e altri segni diacritici – del SP, così come riportata nell’estensione organizationName del certificato elettronico del SP (esempio: “Agenzia per l’Italia Digitale”).
  - OrganizationDisplayName (1 o più occorrenze) — Denominazione del SP, eventualmente in forma abbreviata (senza esplicitare gli eventuali acronimi) con il corretto utilizzo delle minuscole e maiuscole (esempio: “AgID”). Durante la fase di autenticazione, gli IdP avvisano l’utente dell’invio degli attributi al SP, visualizzando il valore di questo tag per indicare il soggetto richiedente.
  - OrganizationURL (1 o più occorrenze) — Contiene l’ url di una pagina del sito web del SP relativa al servizio di autenticazione o ai servizi accessibili tramite essa, i cui contenuti sono localizzati nella lingua specificata dal proprio attributo xml:lang.

- ContactPerson (1 o 2 occorrenze) — Tag utilizzato per veicolare le informazioni per contattare il soggetto cui il metadata afferisce. Ogni occorrenza è dotata dei seguenti attributi:

  - contactType — L’occorrenza obbligatoria di ContactPerson è valorizzata con other; l’ulteriore occorrenza, obbligatoria per i soli SP privati, è valorizzata con billing.

> L’occorrenza di ContactPerson con l’attributo contactType valorizzato come other contiene i seguenti tag (namespace md):

- Extensions (1 occorrenza obbligatoria) — Contenente almeno uno dei seguenti tag (tutti con namespace spid):

  1. IPACode — Presente solo per il SP pubblico, è valorizzato con il codice ipa dell’Ente.
  2. VATNumber — Obbligatorio per il SP privato dotato di partita iva (altrimenti facoltativo), è valorizzato comprensivo del codice ISO 3166-1 α-2 del Paese (senza spazi).
  3. FiscalCode — Obbligatorio per il SP privato non dotato di partita iva (altrimenti facoltativo), è valorizzato con il codice fiscale del SP.
  4. Public — Tag vuoto, obbligatorio per il SP pubblico o,

  in alternativa,

- Private — Tag vuoto, obbligatorio per il SP privato.

- Company (0 o 1 occorrenze) — Se presente, è valorizzato come il tag OrganizationName contenuto nel tag Organization.
- EmailAddress (1 occorrenza, obbligatorio) — Contiene l’indirizzo di posta elettronica per contattare il SP. Non deve trattarsi di un indirizzo riferibile direttamente ad una persona fisica.
- TelephoneNumber (0 o 1 occorrenze) — Contiene il numero di telefono, per contattare il SP; senza spazi e comprensivo del prefisso internazionale (esempio: “+39” per l’Italia).

##### Informazioni obbligatorie per la fatturazione

> > L’occorrenza di ContactPerson con l’attributo contactType valorizzato come billing è obbligatoria in caso sia presente l’estensione Private nel tag Extensions (dell’occorrenza di ContactPerson con l’attributo contactType valorizzato come other). Contiene le informazioni fiscali minime per l’individuazione del soggetto che sarà il destinatario di fatturazione elettronica, in qualità di committente, da parte degli IdP. Al suo interno sono presenti i seguenti tag:

> - Extensions (1 occorrenza obbligatorio) — Tramite estensione con opportuno namespace https://spid.gov.it/invoicing-extensions, ispirato dallo standard FatturaPA dell’Agenzia delle Entrate, contiene i tag minimi necessari alla suddetta individuazione fiscale. Sono dunque presenti il tag figlio CessionarioCommittente e, qualora necessario, il tag figlio TerzoIntermediarioSoggettoEmittente, valorizzati come previsto dallo standard:
>   - CessionarioCommittente (1 occorrenza) — con figli:
>     - DatiAnagrafici (1 occorrenza) — con figli: IdFiscaleIVA (figli:
>         IdPaese e IdCodice) e/o CodiceFiscale; Anagrafica (figli: Denominazione, ovvero Nome e Cognome; opzionalmente Titolo; opzionalmente CodiceEORI);
>     - Sede (1 occorrenza) — con figli: Indirizzo, NumeroCivico (opzionale), CAP, Comune, Provincia (opzionale), Nazione.
>   - TerzoIntermediarioSoggettoEmittente (0 o 1 occorrenze) — valorizzato, se necessario e solo relativamente al committente.
> - Company (0 o 1 occorrenze) — Obbligatoriamente presente qualora il soggetto per l’emissione delle fatture sia distinto dal SP stesso (e in ogni caso riportante il nome completo e per esteso di una persona giuridica, con il corretto uso di minuscole, maiuscole e segni diacritici).
> - EmailAddress (1 occorrenza, obbligatorio) — Contiene l’indirizzo di posta elettronica, aziendale o istituzionale, per contattare il soggetto per questioni di fatturazione elettronica. Può trattarsi di un indirizzo di posta elettronica certificata (pec) aziendale, ma non deve trattarsi di una casella e-mail personale.

##### Esempio: Contatti metadata SP per Fatturazione

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    <md:EntityDescriptor
           entityID="https://entityID.unico/dell/SP"
           ID="_uniqueID"
           xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
           xmlns:spid="https://spid.gov.it/saml-extensions">
        <md:Organization>
            <md:OrganizationName xml:lang="it">
                Denominazione Completa dell'Organizzazione s.r.l.
            </md:OrganizationName>
            <md:OrganizationDisplayName xml:lang="it">
                Organizzazione
            </md:OrganizationDisplayName>
            <md:OrganizationURL xml:lang="it">
                https://organizzazione.com/it
            </md:OrganizationURL>
        </md:Organization>
        <md:ContactPerson contactType="other">
            <md:Extensions>
                <spid:VATNumber>IT12345678901</spid:VATNumber>
                <spid:FiscalCode>XYZABCAAMGGJ000W</spid:FiscalCode>
                <spid:Private/>
            </md:Extensions>
            <md:EmailAddress>spid@organizzazione.com</md:EmailAddress>
            <md:TelephoneNumber>+390123456789</md:TelephoneNumber>
        </md:ContactPerson>
        <md:ContactPerson contactType="billing">
            <md:Extensions
                   xmlns:fpa="https://spid.gov.it/invoicing-extensions">
                <fpa:CessionarioCommittente>
                    <fpa:DatiAnagrafici>
                        <fpa:IdFiscaleIVA>
                            <fpa:IdPaese>IT</fpa:IdPaese>
                            <fpa:IdCodice>02468135791</fpa:IdCodice>
                        </fpa:IdFiscaleIVA>
                        <fpa:Anagrafica>
    			           <fpa:Denominazione>
                                Destinatario_Fatturazione
    			           </fpa:Denominazione>
                        </fpa:Anagrafica>
                    </fpa:DatiAnagrafici>
                    <fpa:Sede>
    		             <fpa:Indirizzo>via [...]</fpa:Indirizzo>
    		             <fpa:NumeroCivico>99</fpa:NumeroCivico>
    		             <fpa:CAP>12345</ fpa:CAP>
    		             <fpa:Comune>nome_citta</fpa:Comune>
    		             <fpa:Provincia>XY</fpa:Provincia>
                        <fpa:Nazione>IT</fpa:Nazione>
                    </fpa:Sede>
                </fpa:CessionarioCommittente>
            </md:Extensions>
            <md:Company>Destinatario_Fatturazione</md:Company>
            <md:EmailAddress>email@fatturazione.it</md:EmailAddress>
            <md:TelephoneNumber>telefono_fatture</md:TelephoneNumber>
        </md:ContactPerson>
     </md:EntityDescriptor>

##### Esempio: metadata SP

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    <md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
        xmlns:spid="https://spid.gov.it/saml-extensions"
        xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
        entityID="https://spid.serviceprovider.it"
        ID="_0j40cj0848d8e3jncjdjss...">
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            [...]
        </ds:Signature>
        <md:SPSSODescriptor
            protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"
            AuthnRequestsSigned="true"
            WantAssertionsSigned="true">
            <md:KeyDescriptor use="signing">
                [...]
            </md:KeyDescriptor>
            <SingleLogoutService
                Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
                Location="https://spid.serviceprovider.it/slo-location"
                ResponseLocation="https://spid.serviceprovider.it/slo-location"/>
            <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>
            <md:AssertionConsumerService
                index="0" isDefault="true"
                Location="https://spid.serviceprovider.it/sso-location"
                Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
            <md:AssertionConsumerService
                index="1"
                Location="https://spidSP.serviceProvider.it/sso-location"
                Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
            <md:AttributeConsumingService index="0">
                <md:ServiceName xml:lang="it">Set 0</md:ServiceName>
                <md:RequestedAttribute Name="name"/>
                <md:RequestedAttribute Name="familyName"/>
                <md:RequestedAttribute Name="fiscalNumber"/>
                <md:RequestedAttribute Name="email"/>
            </md:AttributeConsumingService>
                <md:AttributeConsumingService index="1">
                <md:ServiceName xml:lang="it">Set 1</md:ServiceName>
                <md:RequestedAttribute Name="spidCode"/>
                <md:RequestedAttribute Name="fiscalNumber"/>
            </md:AttributeConsumingService>
        </md:SPSSODescriptor>
        <md:Organization>
            <OrganizationName xml:lang="it">Service provider</OrganizationName>
            <OrganizationDisplayName xml:lang="it">Nome service provider</OrganizationDisplayName>
            <OrganizationURL xml:lang="it">http://spid.serviceprovider.it</OrganizationURL>
        </md:Organization>
        <md:ContactPerson contactType="other">
            <md:Extensions>
                <spid:VATNumber>IT12345678901</spid:VATNumber>
                <spid:FiscalCode>XYZABCAAMGGJ000W</spid:FiscalCode>
                <spid:Private/>
            </md:Extensions>
            <md:EmailAddress>tech-info@example.org</md:EmailAddress>
            <md:TelephoneNumber>+39 8472345634785</md:TelephoneNumber>
        </md:ContactPerson>
    </md:EntityDescriptor>

### Trasmissione dei messaggi (binding)

La trasmissione dei messaggi tra le entità della federazione SPID può avvenire secondo le due modalità previste da SAML:

- HTTP-Redirect
- HTTP-POST

#### Binding HTTP-Redirect

Nel caso del binding HTTP-Redirect la richiesta viene veicolata con le seguenti modalità:

1. L’entità mittente invia allo User Agent un messaggio HTTP di redirezione, cioè avente uno status code con valore 302 («Found») o 303 («See Other»).
2. Il Location Header del messaggio HTTP contiene l’URI di destinazione del servizio esposto dall’entità destinataria.
3. Il browser dell’utente elabora quindi tale messaggio HTTP-Redirect indirizzando una richiesta HTTP con metodo GET al servizio dell’entità destinataria sotto forma di URL con tutti i sopraindicati parametri contenuti nella query string.

Il messaggio HTTP trasporta i seguenti parametri (tutti URL-encoded):

`SAMLRequest`
  Un costrutto SAML codificato in formato Base64 e compresso con algoritmo DEFLATE. Come da specifica, il messaggio SAML non contiene la firma in formato XML Digital Signature esteso (come avviene in generale nel caso di binding HTTP-POST). Ciò a causa delle dimensioni eccessive che esso raggiungerebbe per essere veicolato in una query string. La specifica indica come modalità alternativa quella di specificare con parametri aggiuntivi l’algoritmo utilizzato per firmare (`SigAlg`) e la stringa con la codifica Base64 URL-encoded dei byte del messaggio SAML (`Signature`).
`RelayState`
  Identifica la risorsa (servizio) originariamente richiesta dall’utente e a cui trasferire il controllo alla fine del processo di autenticazione. Il Service Provider a tutela della privacy dell’utente nell’utilizzare questo parametro deve mettere in atto accorgimenti tali da rendere minima l’evidenza possibile sulla natura o tipologia della risorsa (servizio) richiesta
`SigAlg`
  Identifica l’algoritmo usato per la firma prodotta secondo il profilo specificato per SAML (SAML-Core, cap. 5) utilizzando chiavi RSA almeno a 2048 bit e algoritmo di digest SHA-256 o superiore; il valore esteso di questo parametro è contestualizzato da un namespace appartenente allo standard XML Digital Signature. Come indicato al punto 1, tuttavia, la firma prodotta non fa uso della struttura XML definita in tale standard
`Signature`
  Contiene la firma digitale della query string, così come prodotta prima di aggiungere questo parametro, utilizzando l’algoritmo indicato al parametro precedente;

Un esempio di tale URL è il seguente, nel quale sono evidenziati in grassetto i parametri citati (i valori di alcuni parametri sono stati ridotti per brevità, inoltre il valore del parametro `RelayState` è stato reso non immediatamente intellegibile, come suggerito dalla specifica, sostituendo la stringa in chiaro con l’ID della richiesta: l’entità mittente tiene traccia della corrispondenza)

    SAMLRequest=nVPLbtswELz3KwTeZb0M2SYsBa6NoAbSRrGUHnqjqFVDQCJVLuU4f19KlhEDb
    VygR5K7O7Mzw%2FXdqW2cI2gUSiYkmPnEAclVJeTPhDwX%2B6S3KWf1sjapqOb3rzIA%2FzqAY2zQQRtbNtWSe
    [...]
    ZwPAU88aUQvQ%2F8oe8S68piBDNabB5s3AyThb1XZMCxxEhhPj5qLZddW2sZIcoP4fBW%2BWccqH0fZ6iNir0tU
    QGeCWZaGZxE5pM4n8Nz7p%2Be2D3S6L51x1NljO%2BCO2qh8zO%2Bji%2FfnN098%3D&RelayState=s29f6c7d
    6bbf9e62968d27309e2e4beb6133663a2e&SigAlg=http%3A%2F%2Fwww.w3.org%2F2000%2F09%2Fxmldsig
    %23rsa-sha1&Signature=LtNj%2BbMc8j%2FhglWzHPMmo0ESQzBaWlmQbZxas%2B%2FIfNO4F%2F7WNoMKDZ4
    VVYeBtCEQKWp12pU7vPB5WVVMRMrGB8ZRAdHmmPp0hJ9opO3NdafRc04Z%2BbfnkSuQCN9NcGV%2BajT
    [...]
    ra169jhaGRReRQ9KkgSB3aTpQGaffAYUPVo2XZiWy6f9Z7zsmV%2FFoT8dg%3D%3D

#### Binding HTTP-POST

Nel caso del binding HTTP-POST, l’entità mittente invia allo User Agent (il browser dell’utente) un messaggio HTTP con status code avente valore 200 («OK»):

1. Il messaggio HTTP contiene una form HTML all’interno della quale è trasportato un costrutto SAML codificato come valore di un hidden form control di nome `SAMLRequest` oppure `SAMLResponse`. Rispetto al binding HTTP-Redirect, l’utilizzo di una form HTML permette di superare i limiti di dimensione della query string. Pertanto, l’intero messaggio SAML in formato XML può essere firmato in accordo alla specifica XML Digital Signature. Il risultato a valle della firma è quindi codificato in formato Base64
   - Il parametro deve essere denominato `SAMLRequest` nel trasporto dei messaggi `<AuthnRequest>` e `LogoutRequest`, mentre deve essere denominato `SAMLResponse` nel trasporto dei messaggi `<Response>` e `<LogoutResponse>`.
2. La form HTML contiene un secondo hidden form control di nome `RelayState` che contiene il corrispondente valore del Relay State, cioè della risorsa originariamente richiesta dall’utente e alla quale dovrà essere trasferito il controllo al termine della fase di autenticazione
3. La form HTML è corredata da uno script che la rende auto-postante all’indirizzo indicato nell’attributo `action` corrispondente alla Location del SingleSignOnService.
4. Il browser dell’utente elabora quindi la risposta HTTP e invia una richiesta HTTP POST verso il servizio dell’entità destinataria.

Un esempio di form HTML per trasferire in HTTP-POST la richiesta di autenticazione è descritto nell’esempio successivo. Osservando attentamente il codice riportato in figura si può notare il valore del parametro `SAMLRequest` (ridotto per brevità); il valore del parametro `RelayState` reso non immediatamente intellegibile (cfr. sez. precedente); l’elemento `<input type="submit" value="Invia"/>`, che ha lo scopo di visualizzare all’interno del web browser il pulsante di invio della form utilizzabile dall’utente, non strettamente necessario in quanto la form è resa autopostante.

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    <html>
        <head>
            [...]
        </head>
        <body onload="javascript:document.forms[0].submit()">
            <form method="post" action="https://spid.identityprovider.it/SSOServiceProxy">
                <input type="hidden" name="SAMLRequest"
                    value="PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZVRGLTgiPz4KPHNhbWxwOkF1dGhuUmVxdWVzdCBB
                    c3NlcnRpb25Db25zdW1lclNlcnZpY2VVUkw9Imh0dHA6Ly9zcC5pY2FyLml0OjgwODAvaWNhc
                    [...]
                    N0ZWRUcmFuc3BvcnQ8L3NhbWw6QXV0aG5Db250ZXh0Q2xhc3NSZWY+PC9zYW1scDpSZXF1ZXN0ZWRBdXRobkNvb
                    nRleHQ+PHNhbWxwOlNjb3BpbmcgUHJveHlDb3VudD0iMiIgeG1sbnM6c2FtbHA9InVybjpvYXNpczpuYW1lczp0
                    YzpTQU1MOjIuMDpwcm90b2NvbCIvPjwvc2FtbG5SZXF1ZXN0Pg==">
                <input type="hidden" name="RelayState" value="s2645f48777bd62ec83eddc62...">
                <input type="submit" value="Invia"/>
            </form>
        </body>
    </html>

Un esempio di form HTML per trasferire in HTTP-POST la risposta ad una richiesta di autenticazione è descritto nell’esempio successivo.

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    <html>
        <head>
            [...]
        </head>
        <body onload="javascript:document.forms[0].submit()">
            <form method="post" action="https://spid.serviceprovider.it/AssertionConsumerService">
                <input type="hidden" name="SAMLResponse"
                    value="PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHNhbWxwOlJlc3BvbnNlIERlc3Rp
                    bmF0aW9uPSJodHRwOi8vc3AuaWNhci5pdDo4MDgwL2ljYXItc3AvQXNzZXJ0aW9uQ29uc3VtZXJTZXJ2aWNlIiB
                    JRD0iczJhNTdmN2RhYTUyMTc2NWZmOTQ2ODM0ZmY2NjIzNTA3ZTcwNGI1MDQ3IiBJblJlc3BvbnNlVG89InMyOG
                    Q5MWEyNmJkNGQ2MGY0N2E0OTkxMzMwMGZhZjc2MzFiZjMxNDBlOSIgSXNzdWVJbnN0YW50PSIyMDA4LTAzLTA0V
                    DIyOjEzOjQ4LjUwMFoiIFZlcnNpb249IjIuMCIgeG1sbnM6c2Ftb
                    [...]
                    2lzOm5hbWVzOnRjOlNBTUw6Mi4wOmFjOmNsYXNzZXM6UGFzc3dvcmRQcm90ZWN0ZWRUcmFuc3BvcnQ8L3NhbWw6
                    QXV0aG5Db250ZXh0Q2xhc3NSZWY+PC9zYW1sOkF1dGhuQ29udGV4dD48L3NhbWw6QXV0aG5TdGF0ZW1lbnQ+PC9
                    zYW1sOkFzc2VydGlvbj48L3NhbWxwOlJlc3BvbnNlPg==">
                <input type="hidden" name="RelayState" value="s28d91a26bd4d60f47a49913300f...">
                <input type="submit" value="Invia"/>
            </form>
        </body>
    </html>

#### Sicurezza

Il profilo SAML SSO raccomanda l’uso di TLS 1.2 nei colloqui tra Asserting party (Identity Provider e Attribute Authority), le Relaying Party (Service Provider) e lo user agent. In ambito SPID si rende obbligatorio l’impiego di TLS 1.2. In casi particolari e temporanei, può essere adottata la versione 1.1, fermo restando che la versione 1.2 deve essere adottata lato server. Conseguentemente, le versioni più obsolete dei browser, che non supportano le versioni del protocollo indicate, non devono essere utilizzate e, i livelli minimi accettati per l’accesso ai servizi SPID, devono essere documentati nei confronti degli utenti.

### Single Sign-On

Il meccanismo di autenticazione è innescato dalla selezione, da parte dell’utente, del Gestore delle Identità con cui intende effettuare l’accesso; tale selezione avviene all’interno del sito del Fornitore di Servizi mediante un bottone ufficiale «Entra con SPID» da integrarsi nel servizio. Il Fornitore di Servizi prepara di conseguenza una `<AuthnRequest>` da inoltrarsi al Gestore delle Identità, dove l’utente viene reindirizzato per effettuare l’autenticazione. Eseguita l’autenticazione, l’utente torna presso il sito del Fornitore di Servizi con un’asserzione firmata dal Gestore delle Identity contenente gli attributi richiesti (ad es. nome, cognome, codice fiscale) che il Fornitore di Servizi può usare per autorizzare l’utente in base alle proprie policy ed erogare il servizio richiesto.

| Descrizione | SAML | Binding
--- | --- | --- | ---
A | L’utente richiede l’accesso ad un servizio |  |
B1 | Il Service Provider (SP) invia allo User Agent (UA) una richiesta di autenticazione da far pervenire all’Identity Provider (IdP) | `AuthnRequest` | HTTP POST/REDIRECT
B2 | Lo User Agent inoltra la richiesta di autenticazione contattando L’Identity Provider | `AuthnRequest` | HTTP POST/REDIRECT
C1 | L’Identity Provider esamina la richiesta ricevuta e, se necessario, esegue una challenge di autenticazione con l’utente |  |
C2 | L’Identity Provider, portata a buon fine l’autenticazione, effettua lo user login e prepara l’asserzione contenente lo statement di autenticazione dell’utente destinato al Service Provider (più eventuali statement di attributo emessi dall’Identity Provider stesso) |  |
D | L’Identity Provider restituisce allo User Agent la `<Response>` SAML contenente l’asserzione preparata al punto precedente | `Response` | HTTP POST
E | Lo User Agent inoltra al Service Provider (SP) la `<Response>` SAML emessa dall’Identity Provider | `Response` | HTTP POST

#### AuthnRequest

Il messaggio `AuthnRequest` è inviato dal Service Provider, per tramite dello User Agent, al SingleSignOnService dell’Identity Provider ed ha la funzione di avviare il flusso di autenticazione. Può essere inoltrato da un Service Provider all’Identity Provider usando il binding HTTP-Redirect o il binding HTTP-POST. Il messaggio deve essere conforme allo standard SAML v2.0 (cfr. [SAML-Core]) e rispettare le condizioni di seguito indicate.

SI DEVE

- nell’elemento `<AuthnRequest>` devono essere presenti i seguenti attributi:

  > - l’attributo `ID` univoco, per esempio basato su un Universally Unique Identifier (UUID) o su una combinazione origine + timestamp (quest’ultimo generato con una precisione di almeno un millesimo di secondo per garantire l’univocità)

  > - l’attributo `Version`, che deve valere sempre `2.0`, coerentemente con la versione della specifica SAML adottata;

  > - l’attributo `IssueInstant` a indicare l’istante di emissione della richiesta, in formato UTC (esempio: `2017-03-05T18:03:10.531Z`)

  > - l’attributo `Destination`, valore dell’attributo Location esposto dal SingleSignOnService dell’IdP al quale è inviata la richiesta.

  >   > Avvertimento

  >   > Il valore richiesto per l’attributo Destination in SPID può corrispondere all’entityID dell’Identity Provider a cui è inviata la richiesta. Tuttavia l”Avviso 11 SPID consente ai Service Provider di implementare questo parametro come da standard Saml2.

  > - l’attributo `ForceAuthn` nel caso in cui si richieda livelli di autenticazione superiori a SpidL1 (SpidL2 o SpidL3)

  > - l’attributo `AssertionConsumerServiceIndex`, riportante un indice posizionale facente riferimento ad uno degli elementi `<AssertionConsumerService>` presenti nei metadata del Service Provider, atto ad indicare, mediante l’attributo `Location`, l’URL a cui inviare il messaggio di risposta alla richiesta di autenticazione, e mediante l’attributo `Binding`, il binding da utilizzare, quest’ultimo valorizzato obbligatoriamente con `urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST`. In alternativa all’attributo `AssertionConsumerServiceIndex` (scelta sconsigliata) possono essere presenti:

  >   > - l’attributo `AssertionConsumerServiceURL` ad indicare l’URL a cui inviare il messaggio di risposta alla richiesta di autenticazione (l’indirizzo deve coincidere con quello del servizio riportato dall’elemento `<AssertionConsumingService>` presente nei metadata del Service Provider);
  >   > - l’attributo `ProtocolBinding`, identificante il binding da utilizzare per inoltrare il messaggio di risposta, valorizzato con `urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST`;

- nell’elemento `<AuthnRequest>` non deve essere presente l’attributo `IsPassive` (ad indicare `false` come valore di default)

- deve essere presente l’elemento `<Issuer>` attualizzato come l’attributo `entityID` riportato nel corrispondente SP metadata, a indicare l’identificatore univoco del Service Provider emittente. L’elemento deve riportare gli attributi:

  > - `Format` fissato al valore `urn:oasis:names:tc:SAML:2.0:nameid-format:entity`
  > - `NameQualifier` che qualifica il dominio a cui afferisce tale valore (URI riconducibile al Service Provider stesso)

- deve essere presente l’elemento `<NameIDPolicy>` avente l’attributo:

  > - `Format` valorizzato come `urn:oasis:names:tc:SAML:2.0:nameid-format:transient`

- deve essere presente l’elemento `<RequestedAuthnContext>` (SAMLCore, sez. 3.3.2.2.1) ad indicare il contesto di autenticazione atteso, ossia la «robustezza» delle credenziali richieste. Allo scopo sono definite le seguenti «authentication context class» estese (SAMLAuthContext, sez. 3) in riferimento SPID:

  > > - `https://www.spid.gov.it/SpidL1`
  > > - `https://www.spid.gov.it/SpidL2`
  > > - `https://www.spid.gov.it/SpidL3`

  > referenziate dagli elementi `<AuthnContextClassRef>`

  > Ciascuna di queste classi indica in ordine di preferenza il contesto di autenticazione (atteso o effettivo) secondo alcune dimensioni di riferimento, quali per esempio i meccanismi di autenticazione con cui l’Identity Provider può identificare l’utente. L’elemento `<RequestedAuthnContext>` prevede un attributo `Comparison` con il quale indicare il metodo per stabilire il rispetto del vincolo sul contesto di abilitazione: i valori ammessi per questo attributo sono:

  > > - `exact`
  > > - `minimum`
  > > - `better`
  > > - `maximum`

  > Nel caso dell’elemento `<RequestedAuthnContext>`, questa informazione si riflette sulle tipologie di meccanismi utilizzabili dall’Identity Provider ai fini dell’autenticazione dell’utente. L’esempio seguente di `<RequestedAuthnContext>` fa riferimento a una «authentication context class» di tipo SpidL2 o superiore.

  >     1
  >     2
  >     3
  >     4
  >     5
  >     <samlp:RequestedAuthnContext Comparison="minimum">
  >         <saml:AuthnContextClassRef>
  >             https://www.spid.gov.it/SpidL2
  >         </saml:AuthnContextClassRef>
  >     </samlp:RequestedAuthnContext>

  > N.B. L’Identity Provider ha facoltà di utilizzare per l’autenticazione un livello SPID più alto rispetto a quelli risultanti dall’indicazione del richiedente mediante l’attributo Comparison. Tale scelta non deve comportare un esito negativo della richiesta.

- nel caso del binding HTTP POST deve essere presente l’elemento `<Signature>` contenente la firma sulla richiesta apposta dal Service Provider. La firma deve essere prodotta secondo il profilo specificato per SAML (SAML-Core, cap. 5) utilizzando chiavi RSA almeno a 2048 bit e algoritmo di digest SHA-256 o superiore.

SI PUÒ

- può essere presente l’elemento `<Subject>` a indicare il soggetto per cui si chiede l’autenticazione in cui deve comparire:

  > - l’elemento `<NameID>` atto a qualificare il soggetto in cui sono presenti i seguenti attributi:

  >   > - `Format` che deve assumere il valore `urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified` (cfr. SAMLCore, sez. 8.3)
  >   > - `NameQualifier` che qualifica il dominio a cui afferisce tale valore (URI)

  >   > Avvertimento

  >   > L’obbligatorietà dell’attributo `NameQualifier` differisce da quanto previsto dalle specifiche SAML.

- l’elemento `<Conditions>`, se presente, deve indicare i limiti di validità attesi dell’asserzione ricevuta in risposta, per esempio specificando gli attributi `NotBefore` e `NotOnOrAfter` opportunamente valorizzati in formato UTC.

  > N.B. L’Identity Provider non è obbligato a tener conto dell’indicazione nel caso che questa non sia confacente con i criteri di sicurezza da esso adottati.

- se presente l’elemento `<Scoping>` il relativo attributo `ProxyCount` deve assumere valore `0` per indicare che l’Identity Provider invocato non può delegare il processo di autenticazione ad altra Asserting Party.

- eventuali elementi `<RequesterID>` contenuti devono indicare l’URL del servizio di reperimento metadati di ciascuna delle entità che hanno emesso originariamente la richiesta di autenticazione e di quelle che in seguito la hanno propagata, mantenendo l’ordine che indichi la sequenza di propagazione (il primo elemento `<RequesterID>` dell’elemento `<Scoping>` è relativo all’ultima entità che ha propagato la richiesta).

  > Gli elementi `<Scoping>` `<RequesterID>` sono previsti per futuri usi ed al momento non devono essere utilizzati. Nel caso di presenza di tali parametri nella richiesta questi dovranno essere al momento ignorati all’atto dell’elaborazione della risposta da parte dell’Identity Provider.

##### Autenticazione con identità digitale uso professionale o per la persona giuridica

Per i casi in cui il fornitore di servizi richieda una Autenticazione per i seguenti profili:

- Identità digitale della persona giuridica
- Identità digitale ad uso professionale della persona fisica
- Identità digitale ad uso professionale per la persona giuridica

si applicano le seguenti specifiche tecniche:

- Avviso AgID numero 15
- Avviso AgID numero 18
- Avviso AgID numero 18 v2

##### Esempio di AuthnRequest

     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    <samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
        xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
        ID="_4d38c302617b5bf98951e65b4cf304711e2166df20"
        Version="2.0"
        IssueInstant="2015-01-29T10:00:31Z"
        Destination="https://spid.identityprovider.it/redirect-Post-saml2sso"
        AssertionConsumerServiceURL="http://spid.serviceprovider.it"
        ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
        AttributeConsumingServiceIndex="1">
        <saml:Issuer
            NameQualifier="http://spid.serviceprovider.it"
            Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            http://spid.serviceprovider.it
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            [...]
        </ds:Signature>
        <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" />
        <samlp:RequestedAuthnContext Comparison="exact">
            <saml:AuthnContextClassRef>
                https://www.spid.gov.it/SpidL2
            </saml:AuthnContextClassRef>
        </samlp:RequestedAuthnContext>
    </samlp:AuthnRequest>

#### Response

La risposta inviata dall’Identity Provider al Service Provider può essere trasmessa solo tramite il binding HTTP-POST e deve avere le seguenti caratteristiche:

SI DEVE

- Nell’elemento `<Response>` devono essere presenti i seguenti attributi:

  > - l’attributo `ID` univoco basato, per esempio, su un Universally Unique Identifier (UUID) (cfr. UUID) o su una combinazione origine + timestamp (quest’ultimo generato con una precisione di almeno un millesimo di secondo per garantire l’univocità);
  > - deve essere presente l’attributo `Version`, che deve valere sempre `2.0`, coerentemente con la versione della specifica SAML adottata;
  > - deve essere presente l’attributo `IssueInstant` a indicare l’istante di emissione della risposta, in formato UTC;
  > - deve essere presente l’attributo `InResponseTo`, il cui valore deve fare riferimento all’ID della richiesta a cui si risponde;
  > - deve essere presente l’attributo `Destination`, a indicare l’indirizzo (`URI` reference) del Service Provider a cui è inviata la risposta;

- Deve essere presente l’elemento `<Status>` a indicare l’esito della AuthnRequest secondo quanto definito nelle specifiche SAML (SAML-Core, par. 3.2.2.1 e successivi) comprendente il sotto-elemento

  > > - `<StatusCode>`

  > ed opzionalmente i sotto-elementi

  > > - `<StatusMessage>`
  > > - `<StatusDetail>`

  > (Messaggi di errore SPID)

- Deve essere presente l’elemento `<Issuer>` a indicare l’entityID dell’entità emittente, cioè l’Identity Provider stesso. L’attributo `Format` deve essere omesso o fissato al valore `urn:oasis:names:tc:SAML:2.0:nameid-format:entity`.

- Deve essere presente un elemento `<Assertion>` ad attestare l’avvenuta autenticazione, contenente almeno un elemento `<AuthnStatement>`; nel caso l’Identity Provider abbia riscontrato un errore nella gestione della richiesta di autenticazione l’elemento `<Assertion>` non deve essere presente.

SI PUÒ

- Può essere presente l’elemento `<Signature>` contenente la firma sulla risposta apposta dall’Identity Provider. La firma deve essere prodotta secondo il profilo specificato per SAML (SAML-Core, cap. 5) utilizzando chiavi RSA almeno a 1024 bit e algoritmo di digest SHA-256 o superiore.

##### Assertion

SI DEVE

- Nell’elemento `<Assertion>` devono essere presenti i seguenti attributi:

  > - l’attributo `ID` univoco, per esempio basato su un Universally Unique Identifier (UUID) o su una combinazione origine + timestamp (quest’ultimo generato con una precisione di almeno un millesimo di secondo per garantire l’univocità);
  > - l’attributo `Version`, che deve valere sempre `2.0`, coerentemente con la versione della specifica SAML adottata;
  > - l’attributo `IssueInstant` a indicare l’istante di emissione della richiesta, in formato UTC (esempio: `2017-03-01T15:05:10.531Z`);

- Deve essere presente l’elemento `<Subject>` a referenziare il soggetto che si è autenticato in cui devono comparire gli elementi:

  > - `<NameID>` atto a qualificare il soggetto dell’asserzione, in cui sono presenti i seguenti attributi:

  > - `Format` che deve assumere il valore `urn:oasis:names:tc:SAML:2.0:nameidformat:transient` (SAML Core, par8.3)

  > - `NameQualifier` che qualifica il dominio a cui afferisce tale valore (URI riconducibile all’Identity Provider stesso)

  > - `<SubjectConfirmation>` contenente l’attributo

  >   > - `Method` riportante il valore `urn:oasis:names:tc:SAML:2.0:cm:bearer`

  > - `<SubjectConfirmationData>` riportante gli attributi:

  >   > - `Recipient` riportante l”`AssertionConsumerServiceURL` relativa al servizio per cui è stata emessa l’asserzione e l’attributo
  >   > - `NotOnOrAfter` che limita la finestra di tempo durante la quale l’asserzione può essere propagata.
  >   > - `InResponseTo`, il cui valore deve fare riferimento all’ID della richiesta.

- Deve essere presente l’elemento `<Issuer>` a indicare l’entityID dell’Identity Provider emittente (attualizzato come l’attributo `entityID` presente nei corrispondenti IdP metadata) con l’attributo `Format` riportante il valore `urn:oasis:names:tc:SAML:2.0:nameidformat:entity`;

- Deve essere presente l’elemento `<Conditions>` in cui devono essere presenti:

  > - gli attributi `NotBefore` `NotOnOrAfter`;
  > - l’elemento `<AudienceRestriction>` riportante a sua volta l’elemento `<Audience>` attualizzato con l’entityID del Service Provider per il quale l’asserzione è emessa.

- Deve essere presente l’elemento `<AuthStatement>` a sua volta contenente l’elemento:

  > - `<AuthnContext>` riportante nel sotto elemento `<AuthnContextClassRef>` la classe relativa all’effettivo contesto di autenticazione (es. `https://www.spid.gov.it/SpidL2`);

  > Nel caso di asserzioni emesse a seguito di richieste di autenticazione per il livello SPID 1 l’elemento `<AuthStatement>` deve avere l’attributo `SessionIndex` specificante l’indice della sessione di autenticazione instaurata per l’utente presso il gestore dell’identità; tale elemento non dovrà essere presente nel caso di asserzioni emesse a seguito di richieste di autenticazione per i livelli SPID 2 e SPID 3.

- Deve essere presente l’elemento `<Signature>` riportante la firma che l’entità emittente (SP) appone sull’envelope XML da inoltrare. La firma deve essere prodotta secondo il profilo specificato per SAML (cfr [SAML-Core] cap5) utilizzando chiavi RSA almeno a 2048 bit e algoritmo di digest SHA-256 o superiore.

SI PUÒ

- Può essere presente l’elemento `<AttributeStatement>` riportante gli attributi identificativi certificati dall’Identity Provider. Tale elemento se presente dovrà comprendere:

  > - uno o più elementi di tipo `<Attribute>` relativi ad attributi che l’Identity Provider può rilasciare (cfr. Tabella attributi SPID) su richiesta del Service Provider espressa attraverso l’attributo `AttributeConsumingServiceIndex` nella AuthnRequest;
  > - per gli elementi `<AttributeValue>` si raccomanda l’uso dell’attributo `xsi:type` attualizzato come specificato nella Tabella attributi SPID;

- Può essere presente un elemento `<Advice>`, contenente a sua volta altri elementi `<Assertion>`. La possibile presenza dell’elemento, prevista per futuri usi, consente, nei casi in cui gli statement emessi dall’Identity Provider si basino su altre asserzioni SAML ottenute da altre authority, di fornire evidenza delle stesse in forma originale unitamente alla risposta alla richiesta di autenticazione.

L’elemento `<Advice>` è previsto per futuri usi ed al momento non deve essere utilizzato.

##### Esempio di Response con Assertion

      1
      2
      3
      4
      5
      6
      7
      8
      9
     10
     11
     12
     13
     14
     15
     16
     17
     18
     19
     20
     21
     22
     23
     24
     25
     26
     27
     28
     29
     30
     31
     32
     33
     34
     35
     36
     37
     38
     39
     40
     41
     42
     43
     44
     45
     46
     47
     48
     49
     50
     51
     52
     53
     54
     55
     56
     57
     58
     59
     60
     61
     62
     63
     64
     65
     66
     67
     68
     69
     70
     71
     72
     73
     74
     75
     76
     77
     78
     79
     80
     81
     82
     83
     84
     85
     86
     87
     88
     89
     90
     91
     92
     93
     94
     95
     96
     97
     98
     99
    100
    101
    102
    103
    104
    105
    106
    107
    108
    109
    110
    111
    112
    113
    114
    115
    116
    117
    118
    119
    120
    121
    122
    123
    124
    125
    126
    127
    128
    129
    130
    131
    132
    133
    134
    135
    136
    137
    138
    139
    140
    141
    142
    143
    144
    145
    146
    147
    148
    149
    150
    151
    152
    153
    154
    155
    156
    157
    158
    159
    160
    161
    162
    163
    164
    165
    166
    167
    168
    169
    170
    171
    172
    173
    174
    175
    176
    177
    178
    179
    180
    181
    182
    183
    <samlp:Response Destination="https://that.spid.example.org/saml2/acs/post" ID="_5e728601-9ad4-4686-b269-81d107a8194a" InResponseTo="id-wr6bt7ZpfqiYVrqTd" IssueInstant="2021-02-04T15:41:59Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            http://localhost:8080
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#_5e728601-9ad4-4686-b269-81d107a8194a">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                        <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        ...
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                ...
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        ...
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>

        <samlp:Status>
            <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
        </samlp:Status>

        <saml:Assertion ID="_bebbed6a-2f6c-43d9-b151-f214d0c61de0" IssueInstant="2021-02-04T15:41:59Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

            <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
                https://that.spid.idp.example.org/metadata
            </saml:Issuer>
            <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                <ds:SignedInfo>
                    <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                    <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                    <ds:Reference URI="#_bebbed6a-2f6c-43d9-b151-f214d0c61de0">
                        <ds:Transforms>
                            <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                            <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                        </ds:Transforms>
                        <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                        <ds:DigestValue>
                            6V8qWljmWULO0C0OQit0DaylE+neFN9K8SXR2izWXpw=
                        </ds:DigestValue>
                    </ds:Reference>
                </ds:SignedInfo>
                <ds:SignatureValue>
                    ...
                </ds:SignatureValue>
                <ds:KeyInfo>
                    <ds:X509Data>
                        <ds:X509Certificate>
                            ...
                        </ds:X509Certificate>
                    </ds:X509Data>
                </ds:KeyInfo>
            </ds:Signature>

            <saml:Subject>
                <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" NameQualifier="https://validator.spid.gov.it">
                        _655df4bc-b372-475e-906d-e71e4d7e98de
                </saml:NameID>
                <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
                    <saml:SubjectConfirmationData InResponseTo="id-wr6bt7ZpfqiYVrqTd" NotOnOrAfter="2021-02-04T15:46:51Z" Recipient="https://that.spid.example.org/saml2/acs/post"/>
                </saml:SubjectConfirmation>
            </saml:Subject>

            <saml:Conditions NotBefore="2021-02-04T15:41:59Z" NotOnOrAfter="2021-02-04T15:46:51Z">
                <saml:AudienceRestriction>
                    <saml:Audience>
                        http://that.spid.example.org/saml2/metadata
                    </saml:Audience>
                </saml:AudienceRestriction>
            </saml:Conditions>

            <saml:AuthnStatement AuthnInstant="2021-02-04T15:41:59Z" SessionIndex="_ec9c5b35-12dc-414d-ad09-5b4610934db8">
                <saml:AuthnContext>
                    <saml:AuthnContextClassRef>
                        https://www.spid.gov.it/SpidL1
                    </saml:AuthnContextClassRef>
                </saml:AuthnContext>
            </saml:AuthnStatement>

            <saml:AttributeStatement>

                <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                    <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                        AGID-001
                    </saml:AttributeValue>
                </saml:Attribute>
                <saml:Attribute Name="name" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                    <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                        SpidValidator
                    </saml:AttributeValue>
                </saml:Attribute>
                <saml:Attribute Name="familyName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                    <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                        AgID
                    </saml:AttributeValue>
                </saml:Attribute>
                <saml:Attribute Name="placeOfBirth" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                    <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                        Roma
                    </saml:AttributeValue>
                </saml:Attribute>
                <saml:Attribute Name="countyOfBirth" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                    <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                        RM
                    </saml:AttributeValue>
                </saml:Attribute>
                <saml:Attribute Name="dateOfBirth" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                    <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:date">
                        2000-01-01
                    </saml:AttributeValue>
                </saml:Attribute>
                <saml:Attribute Name="gender" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                    <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                        M
                    </saml:AttributeValue>
                </saml:Attribute>
                <saml:Attribute Name="companyName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                    <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                        Agenzia per l'Italia Digitale
                    </saml:AttributeValue>
                </saml:Attribute>
                <saml:Attribute Name="registeredOffice" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                    <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                        Via Listz 21 00144 Roma
                    </saml:AttributeValue>
                </saml:Attribute>
                <saml:Attribute Name="fiscalNumber" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                    <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                        TINIT-GDASDV00A01H501J
                    </saml:AttributeValue>
                </saml:Attribute>
                <saml:Attribute Name="ivaCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                    <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                        VATIT-97735020584
                    </saml:AttributeValue>
                </saml:Attribute>
                <saml:Attribute Name="idCard" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                    <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                        CartaIdentità AA00000000 ComuneRoma 2018-01-01 2028-01-01
                    </saml:AttributeValue>
                </saml:Attribute>
                <saml:Attribute Name="expirationDate" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                    <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:date">
                        2028-01-01
                    </saml:AttributeValue>
                </saml:Attribute>
                <saml:Attribute Name="mobilePhone" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                    <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                        +393331234567
                    </saml:AttributeValue>
                </saml:Attribute>
                <saml:Attribute Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                    <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                        spid.tech@agid.gov.it
                    </saml:AttributeValue>
                </saml:Attribute>
                <saml:Attribute Name="address" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                    <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                        Via Listz 21 00144 Roma
                    </saml:AttributeValue>
                </saml:Attribute>
                <saml:Attribute Name="digitalAddress" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                    <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                        pec@pecagid.gov.it
                    </saml:AttributeValue>
                </saml:Attribute>
            </saml:AttributeStatement>
        </saml:Assertion>

    </samlp:Response>

##### Processamento della Response

Alla ricezione della `<Response>` qualunque sia il binding utilizzato il Service Provider prima di utilizzare l’asserzione deve operare almeno le seguenti verifiche:

- controllo delle firme presenti nella `<Assertion>` e nella `<Response>`;

- nell’elemento `<SubjectConfirmationData>` verificare che:

  > - l’attributo `Recipient` coincida con la AssertionConsumerServiceURL a cui la `<Response>` è pervenuta
  > - l’attributo `NotOnOrAfter` non sia scaduto;
  > - l’attributo `InResponseTo` si riferisca correttamente all’ID della `<AuthnRequest>` di richiesta

Il fornitore di servizi deve garantire che le asserzioni non vengano ripresentate, mantenendo il set di identificatori di richiesta (`ID`) usati come per le `<AuthnRequest>` per tutta la durata di tempo per cui l’asserzione risulta essere valida, secondo l’attributo `NotOnOrAfter` dell’elemento `<SubjectConfirmationData>` presente nell’asserzione stessa. Più semplicemente un SP deve esclusivamente accettare Response riconducibili a Richieste di Autenticazione già inoltrate e non scadute, Response non sollecitate da precedenti AuthnRequest devono essere pertanto scartate.

### Single Logout

#### Gestione delle sessioni

Ai sensi dell’art 28 del regolamento Modalità attuative per la realizzazione dello SPID un gestore delle identità a completamento con esito positivo dell’autenticazione relativa al livello SPID 1 di un utente stabilisce per lo stesso utente una sessione finalizzata al processo di autenticazione. Nel corso di validità della sessione instaurata, il gestore delle identità può rilasciare ai fornitori di servizi, che fanno richiesta di autenticazione di livello SPID 1 per l’utente con il quale è stata stabilita la sessione, asserzioni di autenticazione basate sull’evento di autenticazione che ha dato origine alla sessione stessa. Ancora a i sensi dell’art 28 del regolamento Modalità attuative per la realizzazione dello SPID, per le richieste di autenticazione di livello SPID 2 e 3 non è prevista l’instaurazione di alcuna sessione, pertanto per ogni richiesta di questo tipo deve essere ripetuto l’evento di autenticazione. La sessione stabilita a seguito di un evento di autenticazione relativo al livello SPID 1 è denominata, per chiarezza di esposizione, sessione di autenticazione per distinguerla dalla sessione che un fornitore di servizi può instaurare con l’utente al fine dell’erogazione di un particolare servizio richiesto, denominata a sua volta sessione individuale.

La relazione esistente tra la sessione di autenticazione, mantenuta dal gestore dell’identità per un dato utente, e le sessioni individuali gestite per lo stesso utente dai fornitori di servizi stabilite sullo stesso evento di autenticazione che ha dato origine alla sessione di autenticazione, costituisce, in senso logico, una sessione distribuita che denominiamo sessione globale. Il diagramma di stato riportato in figura 1 specifica il comportamento che deve assumere il gestore delle identità per la gestione della sessione di autenticazione relativa ad un dato utente a fronte delle diverse richieste che possono essere presentate dai fornitori di servizi relativamente allo stesso utente.

L’evoluzione dello stato associato alla sessione di autenticazione deve rispettare le seguenti regole:

1. l’instaurazione di una sessione di autenticazione per un determinato utente avviene al completamento con esito positivo di una richiesta di autenticazione di livello SPID 1 da parte di un fornitore di servizi - evento di autenticazione andato a buon fine con contestuale assenso al trasferimento delle informazioni richieste -. Il fornitore di servizi che ha effettuato la richiesta entra a far parte della sessione globale;

2. le richieste di autenticazione per i livelli SPID 2 e SPID3 per un dato utente, non devono influenzare il regime di sessione per esso vigente. In particolare, se le richieste dovessero pervenire in presenza di una sessione di autenticazione relativa all’utente questa non deve essere in nessun caso chiusa; viceversa, se le richieste dovessero giungere in assenza di una sessione di autenticazione relativa all’utente questa non deve essere in nessun caso creata. Il fornitore di servizi che ha effettuato la richiesta non entra a far parte della sessione globale relativa all’utente qualora questa esistesse;

3. le richieste di autenticazione di livello SPID1 per un dato utente successive all’instaurazione di una sessione di autenticazione per lo stesso utente, qualunque sia il loro esito, non devono incidere sul perdurare della sessione stessa. Il mancato assenso da parte dell’utente al trasferimento delle informazioni richieste dal fornitore di servizi determina il fallimento della richiesta ma non deve produrre conseguenze sulla vigente sessione di autenticazione né sulla sessione globale; ovvero, in merito a quest’ultima, il mancato assenso non deve comportare:

   > - l’esclusione dalla sessione globale del fornitore di servizi che opera la richiesta se questo fosse già coinvolto nella stessa sessione globale per una precedente richiesta andata a buon fine;
   > - l’inclusione nella sessione globale del fornitore di servizi nel caso questo non fosse ancora coinvolto nella stessa sessione globale per una precedente richiesta andata a buon fine.

   > L’assenso da parte dell’utente al trasferimento delle informazioni determina il successo della richiesta ed il coinvolgimento del fornitore di servizi nella sessione globale relativa all’utente, se lo stesso fornitore di servizi non ne facesse già parte per via di una precedente richiesta da esso effettuata ed andata a buon fine.

4. L’evento di Single Logout consiste nella chiusura della sessione di autenticazione e di tutte le sessioni individuali messe tra loro in relazione dalla sessione globale. Tale chiusura avviene su espressa richiesta dell’utente presso il gestore dell’identità o presso uno dei fornitori di servizi. La modalità prevista in SPID per il processo di Single Logout è quella definita dal SAML Single Logout Profile (cfr.[SAML-profiles] sez. 4.4). L’insieme dei fornitori di servizi che entrano a far parte della sessione globale, necessario alla corretta gestione del Single Logout Profile è popolato dinamicamente dal gestore delle identità, applicando i criteri espressi nei precedenti punti a), b, c). Il processo di Single Logout necessita per andare a buon fine del corretto comportamento di tutti i fornitori di servizio coinvolti nella sessione globale secondo quanto previsto dal suddetto Single Logout Profile. Se qualcuno di questi fornitori di servizi non rispetta il comportamento previsto dal Single Logout Profile, il processo non potrà essere concluso con successo e il Single Logout sarà perciò degradato a partial logout. Il partial logout, pur non dando garanzia che tutte le sessioni individuali vigenti presso i fornitori di servizio coinvolti nella sessione globale siano effettivamente chiuse, deve comunque assicurare la chiusura della sessione di autenticazione e, qualora la richiesta di Single Logout venga fatta presso un fornitore dei servizi, della sessione individuale mantenuta dallo stesso fornitore dei servizi presso cui viene operata la richiesta.

5. La sessione di autenticazione può essere chiusa ad opera del gestore dell’identità allo scadere del timeout associato alla sessione stessa o su richiesta operata dall’utente presso lo stesso gestore dell’identità. Con la chiusura della sessione di autenticazione viene meno la relazione che lega la sessione di autenticazione stessa con le sessioni individuali stabilite sulla base di quest’ultima e di conseguenza la sessione globale decade. Una eventuale richiesta di Single Logout relativa ad una sessione globale in precedenza venuta meno a seguito di una chiusura della sessione di autenticazione si risolve in una immediata notifica di partial logout, presentata dal gestore dell’identità al fornitore di servizi presso cui ne è stata fatta richiesta.

I gestori delle identità dovranno mettere a disposizioni dell’utente funzionalità per la richiesta di Single Logout o per la chiusura della sessione di autenticazione.

##### Sessioni individuali

E’ lasciata ai fornitori di servizi la scelta delle modalità da adottare per la gestione del ciclo di vita delle sessioni individuali. In particolare le sessioni individuali possono:

1. non essere affatto instaurate (il fornitore di servizi eroga il servizio richiesto dall’utente senza, per quanto possibile, stabilire con esso alcuna sessione);
2. essere chiuse anche nel corso di validità della sessione di autenticazione che le ha originate (ovvero prima di una eventuale richiesta di Single Logout o della scadenza del timeout associato alla sessione di autenticazione).

In entrambi i casi i fornitori di servizio devono essere comunque in condizione di supportare il processo di Single Logout notificando, a fronte della prevista richiesta da parte del gestore delle identità, l’avvenuta chiusura delle sessioni mai instaurate o già in precedenza chiuse. I fornitori di servizio che instaurano sessioni individuali dovranno mettere a disposizioni dell’utente funzionalità per la richiesta della chiusura della sessione individuale o della sessione globale.

##### Meccanismi di Single Logout

Per la realizzazione del processo di Single Logout secondo quanto previsto dal SAML Single Logout Profile le entità coinvolte (gestore dell’identità e fornitori di servizi) dovranno mettere a disposizione una apposita interfaccia per la notifica dei messaggi:

- SingleLogoutService: ricezione di richieste e notifiche per il Single Logout SAML.

Le tabelle seguenti specificano i passi previsti ed il flusso di messaggi che intercorrono tra il gestore delle identità, l’utente ed i fornitori di servizi nel corso del processo di Single Logout, nei due casi distinti in cui l’inizio avviene presso il gestore dell’identità oppure presso uno dei fornitori di servizi.

Single Logout iniziato presso un Fornitore di Servizi
| Descrizione | SAML | Binding
--- | --- | --- | ---
1 | L’utente utilizzando il browser (User Agent) richiede il Single Logout presso un fornitore di servizi |  |
2 | Il fornitore di servizi procede con la chiusura della propria sessione individuale ed invia una richiesta | LogoutRequest | HTTP-Redirect, HTTP-POST
3 | Il gestore dell’identità ricevuta la richiesta chiude la sessione di autenticazione associata alla sessione globale. Successivamente per ciascun fornitore di servizi facente parte della sessione globale, a partire da quelli in grado di supportare il bindind SOAP, procede alla chiusura delle sessioni individuali. In particolare: |  |
3.1 | invia una richiesta di logout all’i- esimo fornitore di servizi riportando l’identificatore associato alla sessione globale che si vuole chiudere | LogoutRequest | SOAP, HTTP-Redirect, HTTP-POST
3.2 | l’i-esimo fornitore di serviziricevuta la richiesta chiude la sessione identificata ( se la stessa non fosse stata già chiusa in precedenza o mai instaurata) ed invia una notifica di avvenuta chiusura al gestore dell’identità | LogoutResponse | SOAP, HTTP-Redirect, HTTP-POST
3.3 | Se l’i-esimo fornitore di servizi non è raggiungibile il processo degrada a partial logout |  |
4 | Il gestore dell’identità completata la notifica a ciascun fornitore di servizi facente parte della sessione globale trasmette l’esito (success/partial logout) del global logout al fornitore di servizi che aveva dato inizio al processo. | LogoutResponse | SOAP, HTTP-Redirect, HTTP-POST

Single Logout avente origine presso il gestore dell’identità
| Descrizione | SAML | Binding
--- | --- | --- | ---
1 | L’utente utilizzando il browser (User Agent) richiede il Single Logout presso il gestore dell’identità |  |
2 | Il gestore dell’identità ricevuta la richiesta chiude la sessione di autenticazione associata alla sessione globale. Successivamente per ciascun fornitore di servizi facente parte della sessione globale, a partire da quelli in grado di supportare il bindind SOAP, procede alla chiusura delle sessioni individuali. In particolare: |  |
2.1 | invia una richiesta di logout all’i-esimo fornitore di servizi riportando l’identificatore associato alla sessione globale che si vuole chiudere | LogoutRequest | SOAP, HTTP-Redirect
2.2 | L’iesimo fornitore di servizi ricevuta la richiesta chiude la sessione identificata ( se la stessa non fosse stata già chiusa in precedenza o mai instaurata) ed invia una notifica di avvenuta chiusura al gestore dell’identità | LogoutResponse | SOAP, HTTP-Redirect, HTTP-POST
2.3 | Se l’i-esimo fornitore di servizi non è raggiungibile il processo degrada a partial logout |  |

Il risultato della sequenza di scambio è la chiusura della sessione globale.

In condizioni di anomalia derivate da una mancata, intempestiva o non corretta risposta da parte di uno o più fornitori di servizi coinvolti nella sessione, il processo di Single Logout degrada ad un partial logout. In questo caso alla fine del processo risulteranno chiuse la sessione di autenticazione e la sessione individuale presso il fornitore dei servizi presso cui viene operata la richiesta di Single Logout ma non si potrà avere garanzia sulla effettiva chiusura delle altre sessioni individuali facenti parte della sessione globale. Nel caso di richiesta di Single Logout operata presso un fornitore di servizi (Tabella 1) il gestore dell’identità nel caso di operazione conclusa con successo dovrà notificare tale situazione al fornitore di servizi richiedente, riportando nella response il seguente status code:

- StatusCode: `urn:oasis:names:tc:SAML:2.0:status:Success`

Viceversa nel caso in cui si verificasse una condizione di partial logout il gestore dell’identità, se in condizione di poterlo fare, dovrà notificare tale esito al fornitore di servizi richiedente, riportando nella response i seguenti status code:

- StatusCode: `urn:oasis:names:tc:SAML:2.0:status:Requester`
- sub-StatusCode: `urn:oasis:names:tc:SAML:2.0:status:PartialLogout`

Quest’ultimo comportamento deve essere assunto dal gestore dell’identità anche nel caso di una richiesta di Single Logout operata presso un fornitore di servizi e presentata dopo la scadenza della sessione globale, a seguito del timeout della relativa sessione di autenticazione o della esplicita chiusura della stessa da parte dell’utente.

#### LogoutRequest

Nota

Come sopra descritto, il messaggio di LogoutRequest può essere inviato dal Service Provider all’Identity Provider o viceversa, a seconda dell’entità presso la quale l’utente ha richiesto il Single Logout.

Il messaggio di LogoutRequest deve seguire le specifiche SAML (cfr.[SAML-Core] sez. 3.7) e avere le seguenti caratteristiche:

SI DEVE

- Nell’elemento `<LogoutRequest>` devono essere presenti i seguenti attributi:

  > - l’attributo `ID` univoco, per esempio basato su un Universally Unique Identifier (UUID) o su una combinazione origine + timestamp (quest’ultimo generato con una precisione di almeno un millesimo di secondo per garantire l’univocità);
  > - l’attributo `Version`, che deve valere sempre `2.0`, coerentemente con la versione della specifica SAML adottata;
  > - l’attributo `IssueInstant` a indicare l’istante di emissione della richiesta, in formato UTC (esempio: `2008-03-13T18:04:15.531Z`);
  > - l’attributo `Destination`, a indicare l’indirizzo (URI reference) dell’entità (gestore delle identità o fornitori di servizi) a cui è inviata la richiesta.

- Nell’elemento `<LogoutRequest>` devono essere presenti i seguenti elementi:

  > - l’elemento `<Issuer>` attualizzato come l’attributo `entityID` riportato nel corrispondente metadata, a indicare l’identificatore univoco dell’entità (gestore delle identità o fornitori di servizi) emittente. L’elemento deve riportare gli attributi:

  >   > - `Format` fissato al valore `urn:oasis:names:tc:SAML:2.0:nameid-format:entity`;
  >   > - `NameQualifier` che qualifica il dominio a cui afferisce tale valore (URI riconducibile alla stessa entità emittente);

  > - l’elemento `<NameID>` atto a qualificare il soggetto a cui si riferisce l’evento di autenticazione che ha dato origine alla sessione, in cui sono presenti i seguenti attributi:

  >   > - `Format` che deve assumere il valore `urn:oasis:names:tc:SAML:2.0:nameid- format:transient` (cfr. SAMLCore, sez. 8.3);
  >   > - `NameQualifier` che qualifica il dominio a cui afferisce tale valore (URI riconducibile al gestore dell’identità che ha emesso l’asserzione);

  > - l’elemento `<SessionIndex>` atto ad identificare la sessione a cui la richiesta di chiusura si riferisce;

- Deve essere presente l’elemento `<Signature>` contenente la firma sulla richiesta apposta dal Service Provider. La firma deve essere prodotta secondo il profilo specificato per SAML (cfr [SAML-Core] cap5) utilizzando chiavi RSA almeno a 2048 bit e algoritmo di digest SHA-256 o superiore.

#### LogoutResponse

Nota

Come sopra descritto, il messaggio di LogoutResponse può essere inviato dal Service Provider all’Identity Provider o viceversa, a seconda dell’entità presso la quale l’utente ha richiesto il Single Logout.

Il messaggio di LogoutResponse deve seguire le specifiche SAML (cfr.[SAML-Core] sez. 3.7) e avere le seguenti caratteristiche:

SI DEVE

- Nell’elemento `<LogoutResponse>` devono essere presenti i seguenti elementi:

  > - l’attributo `ID` univoco, per esempio basato su un Universally Unique Identifier (UUID) (cfr. UUID) o su una combinazione origine + timestamp (quest’ultimo generato con una precisione di almeno un millesimo di secondo per garantire l’univocità);
  > - deve essere presente l’attributo `Version`, che deve valere sempre `2.0`, coerentemente con la versione della specifica SAML adottata;
  > - deve essere presente l’attributo `IssueInstant` a indicare l’istante di emissione della risposta, in formato UTC;
  > - deve essere presente l’attributo `InResponseTo`, il cui valore deve fare riferimento all’ID della richiesta a cui si risponde;
  > - deve essere presente l’attributo `Destination`, a indicare l’indirizzo (URI reference) dell’entità (gestore delle identità o fornitori di servizi) a cui è inviata la risposta;

- Nell’elemento `<LogoutResponse>` devono essere presenti i seguenti elementi:

  > - deve essere presente l’elemento `<Issuer>` a indicare l’`entityID` dell’entità emittente; l’elemento deve riportare gli attributi:

  >   > - `Format` fissato al valore `urn:oasis:names:tc:SAML:2.0:nameid-format:entity`;
  >   > - `NameQualifier` che qualifica il dominio a cui afferisce tale valore (URI riconducibile alla stessa entità emittente);

  > - deve essere presente l’elemento `<Status>` a indicare l’esito della LogoutRequest secondo quanto definito nelle specifiche SAML (cfr. [SAML-Core] par. 3.2.2.1 e ss.) comprendente il sotto-elemento `<StatusCode>` ed opzionalmente i sotto-elementi `<StatusMessage>` e `<StatusDetail>` (cfr [SPID-TabErr]);

#### Binding

Per il trasporto dei messaggi di LogoutRequest e del relativo LogoutResponse. possono essere utilizzati binding di tipo sincrono (SOAP) o di tipo asincrono (http-redirect o http-POST). Nel caso di uso di binding http-redirect o http-POST, si faccia riferimento a quanto già specificato nel documento SPID Regole tecniche rispettivamente ai paragrafi al paragrafo 1.2.2.1 e 1.2.2.2 per le richieste di autenticazione (SSO Profile), tenendo presente che i messaggi di LogoutRequest e LogoutResponse devono essere veicolati rispettivamente nei previsti parametri/hidden form control denominati SAMLRequest e SAMLResponse. Per il binding SOAP si faccia riferimento a quanto già specificato sempre nel documento SPID Regole tecniche al paragrafo 2.2.3. Gli scambi dovranno avvenire su canale sicuro realizzato mediante l’impiego di TLS nella versione più recente disponibile.

##### Impiego del binding SOAP

Nel caso in cui i fornitori di servizi dispongano del binding SOAP i gestori dell’identità potranno utilizzarlo, preferendolo questo agli altri Binding. La richiesta di Single Logout, quando operata dall’utente presso un fornitore di servizi, sarà iniziata utilizzando uno dei binding asincroni resi disponibili dai gestori dell’identità, per dar modo ai gestori dell’identità di completare il processo anche presso i fornitori di servizi sprovvisti di interfacce SOAP.

### Gestori di attributi qualificati (Attribute Authority)

Avvertimento

Questa sezione non è stata ancora trascritta nel presente documento consolidato. Si rimanda al documento originale delle Regole Tecniche SPID.

Nota

È in corso, presso l’Agenzia per l’Italia Digitale, un Gruppo di Lavoro per la ridefinizione delle regole tecniche per i gestori di attributi qualificati. È possibile che le regole ad oggi vigenti subiscano modifiche.

### Soggetti Aggregatori

I Soggetti Aggregatori sono pubbliche amministrazioni o privati che offrono a terzi (soggetti aggregati) la possibilità di rendere accessibili tramite lo SPID i rispettivi servizi. Tali soggetti si distinguono in aggregatori di servizi pubblici e aggregatori di servizi privati.

Per le specifiche per Soggetti Aggregatori si rimanda ai seguenti avvisi:

- Avviso AgID numero 19 v4
- Avviso AgID numero 22 v3
- Avviso AgID numero 23 v2

### Registro

Il Registro SPID è il repository di tutte le informazioni relative alla entità aderenti a SPID e costituisce l’evidenza del cosiddetto circle of trust in esso stabilito. La relazione di fiducia su cui si basa la federazione stabilita in SPID si realizza per il tramite dell’intermediazione dell’Agenzia, terza parte garante, attraverso il processo di accreditamento dei gestori dell’identità digitale, dei gestori degli attributi qualificati e dei fornitori di servizi. L’adesione a SPID costituisce l’instaurazione di una relazione di fiducia con tutti i soggetti già aderenti, accreditati dall’Agenzia, sulla base della condivisione dei livelli standard di sicurezza dichiarati e garantiti da SPID. L’adesione al patto di fiducia tra le entità aderenti (gestori dell’identità digitale, gestori degli attributi qualificati e fornitori di servizi) si evidenzia nella presenza di tali entità nel Registro SPID gestito dall’Agenzia.

#### Contenuti del Registro

Il federation registry contiene la lista delle entità che hanno superato il processo di accreditamento e quindi facenti parte della federazione SPID. Le informazioni contenute nel registro per ciascuna delle suddette entità sono le seguenti:

- `AuthorityInfo`: entry del Registro relativa ad una entità, a sua volta costituita da:

  > - `EntityId`: identificatore SAML dell’entità;
  > - `Soggetto`: denominazione del soggetto a cui afferisce l’entità della federazione;
  > - `EntityType`: tipo di entità (Identity Provider, Attribute Authority, Service Provider);
  > - `MetadataProviderURL`: l’URL del servizio di reperimento metadati;
  > - `AttributeList`: elenco di attributi qualificati certificabili da una entità di tipo Attribute Authority.

Il federation registry viene popolato dall’Agenzia per l’Italia Digitale a seguito del processo di stipula delle convenzioni e aggiornata dalla stessa Agenzia nel corso delle attività legate alla gestione delle convenzioni e della vigilanza sui soggetti del circuito SPID. Il contenuto informativo della federation registry è in fruizione a tutte le entità appartenenti al circuito SPID ai fini della verifica della sussistenza di relazioni di trust nei confronti di entità terze (IdP, AA, SP) e del reperimento delle informazioni associate alla alle stesse. Il Discovery Service può anch’esso accedere al federation registry per utilizzarne i contenuti ai fini dell’attività di discovering.

Nota

Non è al momento attivo un Discovery Service.

#### Accesso al Registro

Avvertimento

Questa sezione non è stata ancora trascritta nel presente documento consolidato. Si rimanda al documento originale delle Regole Tecniche SPID.

Nota

Il Registro è disponibile alla URL https://registry.spid.gov.it/

#### Accesso al Registro in modalità LDAP

Avvertimento

Questa sezione non è stata ancora trascritta nel presente documento consolidato. Si rimanda al documento originale delle Regole Tecniche SPID.

Nota

L’accesso via LDAP non è al momento attivo.

### Log

#### Identity Provider

Ai fini della tracciatura l’Identity Provider dovrà mantenere un Registro delle transazioni contenente i tracciati delle richieste di autenticazione servite negli ultimi 24 mesi. L’unità di memorizzazione di tale registro dovrà rendere persistente per ogni transazione la tripla composta dell’identificativo dell’identità digitale (`spidCode`) interessata dalla transazione, dalla `<AuthnRequest>` e della relativa `<Response>`.

Al fine di consentire una facile ricerca e consultazione dei dati di tracciature potrebbe essere opportuno memorizzare in ogni record informazioni direttamente estratte dai suddetti messaggi in formato SAML. A titolo esemplificativo e non esaustivo le informazioni presenti in un record del registro potrebbero essere le seguenti:

- `SpidCode`
- `<AuthnRequest>`
- `<Response>`
- `AuthnReq_ID`
- `AuthnReq_ IssueInstant`
- `AuthnReq_` Issuer
- `Resp_ID`
- `Resp_IssueInstant`
- `Resp_Issuer`
- `Assertion_ID`
- `Assertion_subject`
- `Assertion_subject_NameQualifier`

#### Service Provider

Il comma 2 dell’articolo 13 del DPCM obbliga i fornitori di servizi (Service Provider) alla conservazione per ventiquattro mesi delle informazioni necessarie a imputare alle singole identità digitali le operazioni effettuate sui propri sistemi.

A tal fine un Service provider dovrà mantenere un Registro delle transazioni contenente i tracciati delle richieste di autenticazione servite negli ultimi 24 mesi. L’unità di memorizzazione di tale registro dovrà rendere persistente per ogni transazione la coppia dalla `<AuthnRequest>` e della relativa `<Response>`.

Al fine di consentire una facile ricerca e consultazione dei dati di tracciature potrebbe essere opportuno memorizzare in ogni record informazioni direttamente estratte dai suddetti messaggi in formato SAML. A titolo esemplificativo e non esaustivo le informazioni presenti in un record del registro potrebbero essere le seguenti:

- `<AuthnRequest>`
- `<Response>`
- `AuthnReq_ID`
- `AuthnReq_IssueInstant`
- `Resp_ID`
- `Resp_IssueInstant`
- `Resp_Issuer`
- `Assertion_ID`
- `Assertion_subject`
- `Assertion_subject_NameQualifier`

### Tabella attributi

L’identificatore sotto indicato è il valore dell’attributo `Name` dell’elemento `<saml:Attribute>`. Il valore dell’attributo `NameFormat` dello stesso elemento è, come da specifica SAML-core, `urn:oasis:names:tc:SAML:2.0:attrname-format:basic`.

Il tipo sotto indicato è il valore dell’attributo `xsi:type` dell’elemento `<saml:AttributeValue>`.

Tabella attributi identificativi
Attributo | Identificatore | Tipo | Note
--- | --- | --- | ---
Codice identificativo | `spidCode` | xs:string | Il codice identificativo è assegnato dal gestore dell’identità digitale, deve essere univoco in ambito SPID. Il formato è il seguente: `<cod_IdP><nr. univoco>` dove: `<cod_IdP>` è un codice composto da 4 lettere univocamente assegnato al gestore delle identità; `<nr.univoco>` è una stringa alfanumerica composta da 10 caratteri che il gestore delle identità genera in maniera univoca nell’ambito del proprio dominio. (Es. `ABCD123456789A`)
Nome | `name` | xs:string | Stringa composta da una sequenza di una o più sottostringhe non vuote con carattere iniziale in maiuscolo intervallate da uno (solo) spazio (Es. `Francesca` , `Giovanni Mario`)
Cognome | `familyName` | xs:string | Stringa composta da una sequenza di una o più sottostringhe non vuote con carattere iniziale in maiuscolo intervallate da uno (solo) spazio (Es. `Rossi`, `Bianchi Verdi`)
Luogo di nascita | `placeOfBirth` | xs:string | Stringa corrispondente al codice catastale (Codice Belfiore) del Comune o della nazione estera di nascita. (Es. `F205` per la città di Milano)
Provincia di nascita | `countyOfBirth` | xs:string | Stringa corrispondente alla sigla della provincia di nascita. (Es. `MI` per provincia di Milano)
Data di nascita | `dateOfBirth` | xs:date | Secondo specifica xs:date nel formato YYYY-MM-DD dove: YYYY indica l’anno utilizzando 4 cifre; MM indica il mese in (due) cifre; DD indica il giorno in (due) cifre; (Es. `2002-09-24`)
Sesso | `gender` | xs:string | Valori ammessi: F per sesso femminile; M per sesso maschile.
Ragione o denominazione sociale | `companyName` | xs:string | Stringa composta da una sequenza di sottostringhe non vuote intervallate da uno (solo) spazio. In maiuscolo le sottostringhe corrispondenti a nomi. (Es. `Agenzia per l’ Italia Digitale`)
Sede legale | `registeredOffice` | xs:string | Stringa composta da una sequenza di sottostringhe non vuote intervallate da uno (solo) spazio rappresentanti: Tipologia(via, viale, piazza…); Indirizzo; Nr. civico; CAP; Luogo; Provincia; (Es. `via Listz 21 00144 Roma`)
Codice fiscale | `fiscalNumber` | xs:string | Per il formato si faccia riferimento alla codifica dell’attributo CF per i certificati, proposta nell’ambito del Draft ETSI EN 319 412-1, che nel caso specifico prevede la seguente composizione: `TINIT-<CodiceFiscale>`
Partita IVA | `ivaCode` | xs:string | Per il formato si faccia riferimento alla codifica dell’attributo Partita IVA per i certificati, proposta nell’ambito del Draft ETSI EN 319 412-1, che nel caso specifico prevede la seguente composizione: `VATIT-<PartitaIVA>`
Documento d’identità | `idCard` | xs:string | Stringa composta dalla sequenza di sottostringhe (non vuote) concatenate nell’ordine sotto riportato e intervallate da uno (solo) spazio: * <tipo di documento> xs:string; valori ammessi: cartaIdentita, passaporto, patenteGuida; patenteNautica; librettoPensione, patentinoImpTermici, portoArmi, tesseraRiconoscimento; * <numero di documento> xs:string; Numero del documento; * <ente emettitore> xs:string; stringa ottenuta dalla concatenazione dei termini costituenti la denominazione dell’ente a meno di congiunzioni, articoli e preposizioni. Es. `regioneLazio` (Regione Lazio); `provinciaCatania` (Provincia di Catania); `prefetturaRoma` (Prefettura di Roma); `MinisteroEconomiaFinanze` (Ministero dell’Economia e delle Finanze); <data emissione> xs:date; data di rilascio del documento; <data scadenza> xs:date; data di scadenza del documento; (Es. `CartaIdentità AS09452389 ComuneRoma 2013- 01-02 2013-01-31`)

Tabella attributi secondari
Attributo | Identificatore | Tipo | Note
--- | --- | --- | ---
Numero di telefono mobile | `mobilePhone` | xs:string | Stringa numerica senza spazi intermedi (Es. `34912345678`)
Indirizzo di posta elettronica | `email` | xs:string | Formato standard indirizzo di posta elettronica
Domicilio | `domicileStreetAddress` | xs:string | via, viale, piazza
Codice Postale | `domicilePostalCode` | xs:string | CAP
Comune | `domicileMunicipality` | xs:string | Comune
Provincia | `domicileProvince` | xs:string |
Domicilio fisico | `address` | xs:string | Stringa composta da una sequenza di sottostringhe non vuote intervallate da uno (solo) spazio rappresentanti: Tipologia (via, viale, piazza…); Indirizzo; Nr. civico; CAP; Luogo; Provincia.
Nazione | `domicileNation` | xs_string |
Data di scadenza identità | `expirationDate` | xs:date | Secondo specifica xs:date
Domicilio digitale | `digitalAddress` | xs:string | Indirizzo casella PEC

Avvertimento

L’attributo address è stato sostituito dall Avviso AgID n25

### Messaggi di errore

#### Autenticazione corretta

Error code: | 1 (Autenticazione corretta)
--- | ---
Binding: | HTTP-POST, HTTP-Redirect
HTTP status code: | 200
SAML StatusCode: | `urn:oasis:names:tc:SAML:2.0:status:Success`
Destinatario notifica: | Fornitore del servizio (SP)

#### Anomalie del sistema

Error code: | 2 (Indisponibilità sistema)
--- | ---
Binding: | HTTP-POST
Destinatario notifica: | Utente
Schermata IdP: | Messaggio di errore generico
Troubleshooting utente: | Ripetere l’accesso al servizio più tardi

Error code: | 3 (Errore di sistema)
--- | ---
Binding: | HTTP-Redirect
HTTP status code: | 500
Destinatario notifica: | Utente
Schermata IdP: | Pagina di cortesia con messaggio “Sistema di autenticazione non disponibile - Riprovare più tardi”
Troubleshooting utente: | Ripetere l’accesso al servizio più tardi
Note: | Tutti i casi di errore di sistema in cui è possibile mostrare un messaggio informativo all’utente

#### Anomalie delle richieste

Error code: | 4 (Formato binding non corretto)
--- | ---
Binding: | HTTP-Redirect, HTTP-POST
HTTP status code: | 403
Destinatario notifica: | Utente
Schermata IdP: | Pagina di cortesia con messaggio “Formato richiesta non corretto - Contatare il gestore del servzio”
Troubleshooting utente: | Contattare il gestore del servizio
Troubleshooting SP: | Verificare la conformità con le regole tecniche SPID del formato del messaggio di richiesta
Parametri obbligatori: | `SAMLRequest` `SigAlg` (solo per HTTP-Redirect) `Signature` (solo per HTTP-Redirect)
Parametri non obbligatori: | `RelayState`

Error code: | 5 (Verifica della firma fallita)
--- | ---
Binding: | HTTP-Redirect
HTTP status code: | 403
Destinatario notifica: | Utente
Schermata IdP: | Pagina di cortesia con messaggio “Impossibile stabilire l’autenticità della richiesta di autenticazione - Contattare il gestore del servizio”
Troubleshooting utente: | Contattare il gestore del servizio
Troubleshooting SP: | Verificare certificato o modalità di apposizione firma
Note: | Firma sulla richiesta non presente, corrotta, non conforme in uno dei parametri, con certificato scaduto o con certificato non associato al corretto EntityID nei metadati registrati

Error code: | 6 (Binding su metodo HTTP errato)
--- | ---
Binding: | HTTP-Redirect, HTTP-POST
HTTP status code: | 403
Destinatario notifica: | Utente
Schermata IdP: | Pagina di cortesia con messaggio “Formato richiesta non ricevibile - Contattare il gestore del servizio”
Troubleshooting utente: | Contattare il gestore del servizio
Troubleshooting SP: | Verificare metadata Gestore dell’identita (IdP)
Note: | Invio richiesta in HTTP-Redirect su entrypoint HTTP-POST dell’identity, oppure invio richiesta in HTTP-POST su entrypoint HTTP-Redirect dell’identity

Error code: | 7 (Errore sulla verifica della firma della richiesta)
--- | ---
Binding: | HTTP-POST
HTTP status code: | 403
Destinatario notifica: | Utente
Schermata IdP: | Pagina di cortesia con messaggio “Formato richiesta non corretto - Contattare il gestore del servizio”
Troubleshooting utente: | Contattare il gestore del servizio
Troubleshooting SP: | Verificare certificato o modalità di apposizione firma
Note: | Firma sulla richiesta non presente, corrotta, non conforme in uno dei parametri, con certificato scaduto o con certificato non associato al corretto EntityID nei metadati registrati

Error code: | 8 (Formato della richiesta non conforme alle specifiche SAML)
--- | ---
Binding: | HTTP-Redirect, HTTP-POST
SAML StatusCode: | `urn:oasis:names:tc:SAML:2.0:status:Requester`
SAML StatusMessage: | ErrorCode nr08
Destinatario notifica: | Fornitore del servizio (SP)
Troubleshooting SP: | Formulare la richiesta secondo le regole tecniche SPID - Fornire pagina di cortesia all’utente
Note: | Non conforme alle specifiche SAML - Il controllo deve essere operato successivamente alla verifica positiva della firma

Error code: | 9 (Parametro version non presente, malformato o diverso da `2.0`)
--- | ---
Binding: | HTTP-Redirect, HTTP-POST
SAML StatusCode: | `urn:oasis:names:tc:SAML:2.0:status:VersionMismatch`
SAML StatusMessage: | ErrorCode nr09
Destinatario notifica: | Fornitore del servizio (SP)
Troubleshooting SP: | Formulare la richiesta secondo le regole tecniche SPID - Fornire pagina di cortesia all’utente

Error code: | 10 (Issuer non presente, malformato o non corrispondete all’entità che sottoscrive la richiesta)
--- | ---
Binding: | HTTP-Redirect, HTTP-POST
HTTP status code: | 403
Destinatario notifica: | Utente
Schermata IdP: | Pagina di cortesia con messaggio “Formato richiesta non corretto - Contattare il gestore del servizio”
Troubleshooting utente: | Contattare il gestore del servizio
Troubleshooting SP: | Verificare formato delle richieste prodotte

Error code: | 11 (ID non presente, malformato o non conforme)
--- | ---
Binding: | HTTP-Redirect, HTTP-POST
SAML StatusCode: | `urn:oasis:names:tc:SAML:2.0:status:Requester`
SAML StatusMessage: | ErrorCode nr11
Destinatario notifica: | Fornitore del servizio (SP)
Troubleshooting SP: | Formulare correttamente la richiesta - Fornire pagina di cortesia all’utente
Note: | Identificatore necessario per la correlazione con la risposta. L’eventuale presenza dell’anomalia va verificata e segnalata solo a seguito di una positiva verifica della firma.

Error code: | 12 (`RequestAuthnContext` non presente, malformato o non previsto da SPID)
--- | ---
Binding: | HTTP-Redirect, HTTP-POST
SAML StatusCode: | `urn:oasis:names:tc:SAML:2.0:status:Requester`
SAML sub-StatusCode: | `urn:oasis:names:tc:SAML:2.0:statuss:NoAuthnContext`
SAML StatusMessage: | ErrorCode nr12
Destinatario notifica: | Fornitore del servizio (SP)
Schermata IdP: | Pagina temporanea con messaggio di errore: “Autenticazione SPID non conforme o non specificata”
Troubleshooting SP: | Informare l’utente
Note: | Identificatore necessario per la correlazione con la risposta. L’eventuale presenza dell’anomalia va verificata e segnalata solo a seguito di una positiva verifica della firma.

Error code: | 13 (`IssueInstant` non presente, malformato o non coerente con l’orario di arrivo della richiesta)
--- | ---
Binding: | HTTP-Redirect, HTTP-POST
SAML StatusCode: | `urn:oasis:names:tc:SAML:2.0:status:Requester`
SAML sub-StatusCode: | `urn:oasis:names:tc:SAML:2.0:statuss:RequestDenied`
SAML StatusMessage: | ErrorCode nr13
Destinatario notifica: | Fornitore del servizio (SP)
Troubleshooting SP: | Formulare correttamente la richiesta - Fornire pagina di cortesia all’utente

Error code: | 14 (`Destination` non presente, malformata o non coincidente con il Gestore delle identità ricevente la richiesta)
--- | ---
Binding: | HTTP-Redirect, HTTP-POST
SAML StatusCode: | `urn:oasis:names:tc:SAML:2.0:status:Requester`
SAML sub-StatusCode: | `urn:oasis:names:tc:SAML:2.0:statuss:RequestUnsupported`
SAML StatusMessage: | ErrorCode nr14
Destinatario notifica: | Fornitore del servizio (SP)
Troubleshooting SP: | Formulare correttamente la richiesta - Fornire pagina di cortesia all’utente

Error code: | 15 (Attributo `IsPassive` presente e attualizzato al valore true)
--- | ---
Binding: | HTTP-Redirect, HTTP-POST
SAML StatusCode: | `urn:oasis:names:tc:SAML:2.0:status:Requester`
SAML sub-StatusCode: | `urn:oasis:names:tc:SAML:2.0:statuss:NoPassive`
SAML StatusMessage: | ErrorCode nr15
Destinatario notifica: | Fornitore del servizio (SP)
Troubleshooting SP: | Formulare correttamente la richiesta - Fornire pagina di cortesia all’utente

Error code: | 16 (`AssertionConsumerService` non correttamente valorizzato)
--- | ---
Binding: | HTTP-Redirect, HTTP-POST
SAML StatusCode: | `urn:oasis:names:tc:SAML:2.0:status:Requester`
SAML sub-StatusCode: | `urn:oasis:names:tc:SAML:2.0:statuss:RequestUnsupported`
SAML StatusMessage: | ErrorCode nr16
Destinatario notifica: | Fornitore del servizio (SP)
Troubleshooting SP: | Formulare correttamente la richiesta - Fornire pagina di cortesia all’utente
Note: | `AssertionConsumerServiceIndex` presente e attualizzato con valore non riportato nei metadata `AssertionConsumerServiceIndex` riportato in presenza di uno od entrambi gli attributi `AssertionConsumerServiceURL` e `ProtocolBinding` `AssertionConsumerServiceIndex` non presente in assenza di almeno uno attributi `AssertionConsumerServiceURL` e `ProtocolBinding` La response deve essere inoltrata presso `AssertionConsumerService` di default riportato nei metadata

Error code: | 17 (Attributo `Format` dell’elemento `NameIDPolicy` assente o non valorizzato secondo specifica)
--- | ---
Binding: | HTTP-Redirect, HTTP-POST
SAML StatusCode: | `urn:oasis:names:tc:SAML:2.0:status:Requester`
SAML sub-StatusCode: | `urn:oasis:names:tc:SAML:2.0:statuss:RequestUnsupported`
SAML StatusMessage: | ErrorCode nr17
Destinatario notifica: | Fornitore del servizio (SP)
Troubleshooting SP: | Formulare correttamente la richiesta - Fornire pagina di cortesia all’utente
Note: | Nel caso di valori diversi dalla specifica del parametro opzionale `AllowCreate` si procede con l’autenticazione senza riportare errori

Error code: | 18 (`AttributeConsumerServiceIndex` malformato o che riferisce a un valore non registrato nei metadati di SP)
--- | ---
Binding: | HTTP-Redirect, HTTP-POST
SAML StatusCode: | `urn:oasis:names:tc:SAML:2.0:status:Requester`
SAML sub-StatusCode: | `urn:oasis:names:tc:SAML:2.0:statuss:RequestUnsupported`
SAML StatusMessage: | ErrorCode nr18
Destinatario notifica: | Fornitore del servizio (SP)
Troubleshooting SP: | Riformulare la richiesta con un valore dell’indice presente nei metadati

#### Anomalie derivanti dall’utente

Error code: | 19 (Autenticazione fallita per ripetuta sottomissione di credenziali errate - superato numero tentativi secondo le policy adottate)
--- | ---
Binding: | HTTP-Redirect, HTTP-POST
SAML StatusCode: | `urn:oasis:names:tc:SAML:2.0:status:Responder`
SAML sub-StatusCode: | `urn:oasis:names:tc:SAML:2.0:statuss:AuthnFailed`
SAML StatusMessage: | ErrorCode nr19
Destinatario notifica: | HTTP POST/HTTP Redirect
Schermata IdP: | Messaggio di errore specifico ad ogni interazione prevista
Troubleshooting utente: | Inserire credenziali corrette
Troubleshooting SP: | Fornire una pagina di cortesia notificando all’utente le ragioni che hanno determinato il mancato accesso al servizio richiesto
Note: | Si danno indicazioni specifiche e puntuali all’utente per risolvere l’anomalia, rimanendo nelle pagine dello IdP. Solo al verificarsi di determinate condizioni legate alle policy di sicurezza aziendali, ad esempio dopo 3 tentativi falliti, si risponde al SP.

Error code: | 20 (Utente privo di credenziali compatibili con il livello HTTP richiesto dal fornitore del servizio)
--- | ---
Binding: | HTTP-Redirect, HTTP-POST
SAML StatusCode: | `urn:oasis:names:tc:SAML:2.0:status:Responder`
SAML sub-StatusCode: | `urn:oasis:names:tc:SAML:2.0:statuss:AuthnFailed`
SAML StatusMessage: | ErrorCode nr20
Destinatario notifica: | Fornitore del servizio (SP)
Troubleshooting utente: | Acquisire credenziali di livello idoneo all’accesso al servizio richiesto
Troubleshooting SP: | Fornire una pagina di cortesia notificando all’utente le ragioni che hanno determinato il mancato accesso al servizio richiesto

Error code: | 21 (Timeout durante l’autenticazione utente)
--- | ---
Binding: | HTTP-Redirect, HTTP-POST
SAML StatusCode: | `urn:oasis:names:tc:SAML:2.0:status:Responder`
SAML sub-StatusCode: | `urn:oasis:names:tc:SAML:2.0:statuss:AuthnFailed`
SAML StatusMessage: | ErrorCode nr21
Destinatario notifica: | Fornitore del servizio (SP)
Troubleshooting utente: | Si ricorda che l’operazione di autenticazione deve essere completata entro un determinato periodo di tempo
Troubleshooting SP: | Fornire una pagina di cortesia notificando all’utente le ragioni che hanno determinato il mancato accesso al servizio richiesto

Error code: | 22 (Utente nega il consenso all’invio di dati al SP in caso di sessione vigente)
--- | ---
Binding: | HTTP-Redirect, HTTP-POST
SAML StatusCode: | `urn:oasis:names:tc:SAML:2.0:status:Responder`
SAML sub-StatusCode: | `urn:oasis:names:tc:SAML:2.0:statuss:AuthnFailed`
SAML StatusMessage: | ErrorCode nr22
Destinatario notifica: | Fornitore del servizio (SP)
Troubleshooting utente: | Dare consenso
Troubleshooting SP: | Fornire una pagina di cortesia notificando all’utente le ragioni che hanno determinato il mancato accesso al servizio richiesto
Note: | Sia per autenticazione da fare, sia per sessione attiva di classe SpidL1.

Error code: | 23 (Utente con identità sospesa/revocata o con credenziali bloccate)
--- | ---
Binding: | HTTP-Redirect, HTTP-POST
SAML StatusCode: | `urn:oasis:names:tc:SAML:2.0:status:Responder`
SAML sub-StatusCode: | `urn:oasis:names:tc:SAML:2.0:statuss:AuthnFailed`
SAML StatusMessage: | ErrorCode nr23
Destinatario notifica: | Fornitore del servizio (SP)
Schermata IdP: | Pagina temporanea con messaggio di errore: “Credenziali sospese o revocate”
Troubleshooting SP: | Fornire una pagina di cortesia notificando all’utente le ragioni che hanno determinato il mancato accesso al servizio richiesto

Error code: | 24 (Riservato)
--- | ---

Error code: | 25 (Processo di autenticazione annullato dall’utente)
--- | ---
Binding: | HTTP-Redirect, HTTP-POST
SAML StatusCode: | `urn:oasis:names:tc:SAML:2.0:status:Responder`
SAML sub-StatusCode: | `urn:oasis:names:tc:SAML:2.0:statuss:AuthnFailed`
SAML StatusMessage: | ErrorCode nr25
Destinatario notifica: | Fornitore del servizio (SP)
Troubleshooting SP: | Fornire una pagina di cortesia notificando all’utente le ragioni che hanno determinato il mancato accesso al servizio richiesto

Error code: | 30 (tentativo dell’utente di utilizzare una tipologia di identità digitale diversa da quanto richiesto dal SP)
--- | ---
Binding: | HTTP-Redirect, HTTP-POST
SAML StatusCode: | `urn:oasis:names:tc:SAML:2.0:status:Responder`
SAML sub-StatusCode: | `urn:oasis:names:tc:SAML:2.0:statuss:AuthnFailed`
SAML StatusMessage: | ErrorCode nr30
Destinatario notifica: | Fornitore del servizio (SP)
Troubleshooting SP: | Fornire una pagina di cortesia notificando all’utente le ragioni che hanno determinato il mancato accesso al servizio richiesto. Per maggiori dettagli consultare Avviso 18 <https://www.agid.gov.it/sites/default/files/repository_files/spid-avviso-n18_v.2-_autenticazione_persona_giuridica_o_uso_professionale_per_la_persona_giuridica.pdf>_

#### Regole tecniche

SPID, il Sistema Pubblico di Identità Digitale, è la soluzione che ti permette di accedere a tutti i servizi online della Pubblica Amministrazione con un’unica Identità Digitale (username e password) utilizzabile da computer, tablet e smartphone.

Progetto: Sistema Pubblico di Identità Digitale

Amministrazione: italia

Tag:
spid
Scarica
Sorgente