Technical references¶

Riferimenti normativi SPID¶

L'avvio del Sistema SPID, per sua natura e complessità, può richiedere di intervenire su diversi aspetti con specificazioni, chiarimenti, note informative e casi esemplificativi, al fine di dare supporto ad una migliore applicazione e comprensione dei Regolamenti SPID già emanati dall'AgID in conformità con quanto prescritto dall'art.4 del DPCM 24 ottobre 2014.

Al fine di raccogliere organicamente tali interventi e attribuirvi un carattere cogente che ne comporti l'obbligo di applicazione da parte degli attori convolti nel Sistema SPID, siano essi pubblici che privati, è stata creata la presente sezione “Avvisi SPID” con l'obiettivo di assicurare un'uniforme interpretazione delle regole, degli aspetti tecnici e di quant'altro necessario per il corretto funzionamento del Sistema nel suo complesso.

Le presenti regole tecniche implementano i seguenti avvisi SPID:

Riferimenti normativi CIE id¶

Termini¶

Seguono i termini utilizzati da OIDC-FED#Section_1.2 e in questo documento.

Acronimi¶

In questa sezione sono definiti tutti gli acronimi utilizzati all'interno del testo.

Convenzioni e Termini normativi¶

Le parole chiave "DEVE" e "DEVONO", "NON DEVE" e "NON DEVONO", "RICHIEDE" e "RICHIESTO", "NON DEVE", "DOVREBBE", "NON DOVREBBE", "RACCOMANDATO", "PUÒ" e "OPZIONALE" nel presente documento devono essere interpretate come descritte nel BCP 14 RFC 2119 RFC 8174 quando e solo quando appaiono in maiuscolo.

Le notazioni [...] e ... indicano che il testo è stato troncato per esigenze editoriali.

base64url denota la codifica URL-safe base64 senza padding definita in RFC 7515#section-2.

Tutti gli esempi contenuti in questo documento sono da considerarsi come non normativi.

OpenID Connect Federation¶

La Federazione OIDC produce una infrastruttura della fiducia che è:

• Dinamica. La fiducia può essere stabilita dinamicamente durante la prima richiesta di autenticazione. Le Autorità della Federazione espongono un endpoint che fornisce "dichiarazioni" firmate riguardanti le entità discendenti. Queste contengono le chiavi pubbliche dei discendenti e la politica dei Metadata. Le Autorità della Federazione possono disabilitare un'entità nella Federazione in qualsiasi momento, semplicemente smettendo di emettere le dichiarazioni inerenti a questa.
• Scalabile. Riduce significativamente i costi di onboarding, in accordo al principio di delega, con l'istituzione di entità intermediarie (SA).
• Trasparente. Qualsiasi Entità coinvolta nella Federazione può in ogni momento costruire la fiducia autonomamente e in modo sicuro. Inoltre, la composizione della Federazione, in tutte le sue parti, diventa navigabile mediante la sua API, in tempo reale.

Schema ad albero con le Autorità di Federazione SPID e CIE id e, salendo, gli OP che non hanno Intermediari, gli RP e gli Intermediari che a loro volta Aggregano altri RP.

Configurazione della Federazione¶

La configurazione della Federazione è pubblicata dal Trust Anchor all'interno della sua Entity Configuration, disponibile presso un web path ben noto e corrispondente a .well-known/openid-federation.

Tutti i partecipanti DEVONO ottenere, prima della fase di esercizio, la configurazione della Federazione e mantenerla aggiornata su base giornaliera. All'interno della configurazione della Federazione sono pubblicate le chiave pubbliche del Trust Anchor usate per le operazioni di firma, il numero massimo di Intermediari consentiti tra una Foglia e il Trust Anchor (max_path length) e le autorità abilitate all'emissione dei Trust Mark (trust_mark_issuers).

Si veda qui un esempio non normativo di Entity Configuration response Trust Anchor

Si veda la Sezione dedicata alle Entity Configuration per ulteriori dettagli.

Modalità di partecipazione¶

Per aderire alle Federazioni SPID e CIE id un partecipante deve pubblicare la propria configurazione (Entity Configuration) presso il proprio web endpoint .well-known/openid-federation.

Gli incaricati tecnici ed amministrativi della Foglia completano la procedura amministrativa per la registrazione di una nuova Entità o l'aggiornamento di un'Entità preesistente definita dalla Autorità di Federazione o da un suo Intermediario (SA).

L'Autorità di Federazione o il suo Intermediario, dopo aver effettuato tutti i controlli amministrativi e tecnici richiesti, registra le chiavi pubbliche della Foglia e rilascia una prova di adesione alla Federazione sotto forma di Trust Mark (TM).

La Foglia DEVE includere il TM all'interno della propria configurazione di Federazione (Entity Configuration) come prova del buon esito del processo di onboarding.

L'Autorità di Federazione o suo Intermediario DEVE pubblicare la dichiarazione di riconoscimento della Foglia (Entity Statement) contenente le chiavi pubbliche di Federazione della Foglia e i TM a questa rilasciati.

Firma della Entity Configuration¶

Tutte le operazioni di verifica della firma relative agli ES, EC e TM sono eseguite con le chiavi pubbliche di Federazione. Per quanto riguarda gli algoritmi di firma supportati si veda la Sezione Algoritmi Crittografici.

Entity Configuration - claim comuni¶

Claim	Descrizione	Supportato da
iss	String. Identificativo dell'entità che lo emette.
sub	String. Identificativo del soggetto a cui è riferito.
iat	UNIX Timestamp con l'istante di generazione del JWT, codificato come NumericDate come indicato in RFC 7519
exp	UNIX Timestamp con l'istante di scadenza del JWT, codificato come NumericDate come indicato in RFC 7519.
jwks	Un JSON Web Key Set (JWKS) RFC 7517 che rappresenta la parte pubblica delle chiavi di firma dell'entità interessata. Ogni JWK nel set JWK DEVE avere un ID di chiave (claim kid).
metadata	JSON Object. Ogni chiave dell'oggetto JSON rappresenta un identificatore del tipo di Metadata e ogni valore DEVE essere un oggetto JSON che rappresenta i Metadata secondo lo schema di Metadata di quel tipo. Una configurazione di entità PUÒ contenere più dichiarazioni di Metadata, ma solo una per ogni tipo di Metadata (<entity_type>). I tipi consentiti sono i seguenti: openid_relying_party openid_provider federation_entity oauth_authorization_server oauth_resource

Entity Configuration Foglia e intermediari¶

Gli EC delle entità Foglia e intermediari, in aggiunta ai claim precedentemente definiti, contengono anche i seguenti claim:

Claim	Descrizione	Supportato da
authority_hints	Array di URL. Contiene una lista di URL delle entità superiori, quali TA o SA che POSSONO emettere un ES relativo a questo soggetto.
trust_marks	Un array JSON contenente i Trust Mark. Vedere la Sezione Trust Mark. Obbligatorio per tutti i partecipanti fatta esclusione del Trust Anchor.

Entity Configuration Trust Anchor¶

Gli EC di un TA, in aggiunta ai claim comuni a tutti i partecipanti, contengono anche i seguenti:

Claim	Descrizione	Supportato da
constraints	JSON Object che descrive un insieme di vincoli della Trust Chain e che DEVE contenere l'attributo max_path_length. Rappresenta il numero massimo di SA tra una Foglia e il TA. PUÒ anche contenere il claim allowed_leaf_entity_types, che restringe i tipi di Entità riconoscobili come suoi discendenti.
trust_mark_issuers	JSON Array che indica quali autorità sono considerate attendibili nella Federazione per l'emissione di specifici TM, questi assegnati mediante il proprio identificativo univoco.

Firma di Entity Statement¶

Si applicano le medesime considerazioni fatte per gli EC e riportate nella sezione Firma della Entity Configuration.

Entity Statement¶

Gli ES emessi dal TA o da un suo Intermediario per i propri diretti discendenti, DEVONO contenere i seguenti attributi:

Claim	Descrizione	Supportato da
iss	Si rimanda alla specifica OIDC-FED Sezione 3.1 per i dettagli.
sub	Si rimanda alla specifica OIDC-FED Sezione 3.1 per i dettagli.
iat	Si rimanda alla specifica OIDC-FED Sezione 3.1 per i dettagli.
exp	Si rimanda alla specifica OIDC-FED Sezione 3.1 per i dettagli.
jwks	JWKS di Federazione dell'entità sub. Si rimanda alla specifica OIDC-FED Sezione 3.1 per i dettagli.
metadata_policy	JSON Object che descrive un criterio di Metadata. Ogni chiave dell'oggetto JSON rappresenta un identificatore del tipo di Metadata e ogni valore DEVE essere un oggetto JSON che rappresenta la politica dei Metadata in base allo schema di quel tipo di Metadata. Si rimanda alla specifica OIDC-FED Section 5.1 per i dettagli implementativi.
trust_marks	JSON Array contenente i Trust Mark emessi da se stesso per il soggetto discendente.
constraints	PUÒ contenere il claim allowed_leaf_entity_types per restringere i tipi di Entità riconoscobili per il suo discendente (esempio: solo RP).

Metadata Policy¶

Trust Anchors e Intermediari (SA) DEVONO pubblicare una policy relativa ai rispettivi discendenti nell'Entity Statement ad essi riferito. La Metadata Policy si DEVE applicare a cascata su tutti i discendenti.

Metadata Policy di un TA per un RP¶

Di seguito vengono riportati i claim che DEVONO essere considerati nel parametro metadata di tipo openid_realying_party all'interno della policy che il TA stabilisce per un RP suo discendente diretto.

Claim	Operazioni / Valori	Supportato da
jwks	Operazioni: value Valori: DEVE contenere i JWKS del RP relativi alle operazioni di Core essential = true
grant_types	Operazioni: subset_of, super_set Valori: DEVE contenere authorization_code e refresh_token essential = true
id_token_signed_response_alg	Operazioni: one_of Valori: DEVE contenere uno degli algoritmi definiti nella Sezione Algoritmi Crittografici essential = true
id_token_encrypted_response_alg	Operazioni: one_of Valori: DEVE contenere uno degli algoritmi definiti nella Sezione Algoritmi Crittografici essential = false
id_token_encrypted_response_enc	Operazioni: one_of Valori: DEVE contenere uno degli algoritmi definiti nella Sezione Algoritmi Crittografici essential = false
userinfo_signed_response_alg	Operazioni: one_of Valori: DEVE contenere uno degli algoritmi definiti nella Sezione Algoritmi Crittografici essential = true
userinfo_encrypted_response_alg	Operazioni: one_of Valori: DEVE contenere uno degli algoritmi definiti nella Sezione Algoritmi Crittografici essential = true
userinfo_encrypted_response_enc	Operazioni: one_of Valori: DEVE contenere uno degli algoritmi definiti nella Sezione Algoritmi Crittografici essential = true
token_endpoint_auth_method	Operazioni: one_of Valori: DEVE essere private_key_jwt essential = true
client_registration_types	Operazioni: subset_of Valori: DEVE essere automatic essential = true
redirect_uris	Operazioni: essential = true
client_id	Operazioni: essential = true
response_types	Operazioni: value Valori: DEVE essere code essential = true

Metadata Policy di un TA per un SA¶

Di seguito vengono riportati i claim che DEVONO essere considerati nel parametro metadata di tipo openid_relying_party all'interno della policy che il TA stabilisce per un SA. Questa policy DEVE essere applicata a cascata ai metadata dei RP discendenti diretti (aggregati) del SA.

Claim	Operazioni / Valori	Supportato da
grant_types	Operazioni: subset_of, superset_of Valori: DEVE contenere authorization_code e refresh_token essential = true
id_token_signed_response_alg	Operazioni: one_of Valori: DEVE contenere uno degli algoritmi definiti nella Sezione Algoritmi Crittografici essential = true
id_token_encrypted_response_alg	Operazioni: one_of Valori: DEVE contenere gli algoritmi definiti nella Sezione Algoritmi Crittografici essential = false
id_token_encrypted_response_enc	Operazioni: one_of Valori: DEVE contenere uno degli algoritmi definiti nella Sezione Algoritmi Crittografici essential = false
userinfo_signed_response_alg	Operazioni: one_of Valori: DEVE contenere uno degli algoritmi definiti nella Sezione Algoritmi Crittografici essential = true
userinfo_encrypted_response_alg	Operazioni: one_of Valori: DEVE contenere uno degli algoritmi definiti nella Sezione Algoritmi Crittografici essential = true
userinfo_encrypted_response_enc	Operazioni: one_of Valori: DEVE contenere uno degli algoritmi definiti nella Sezione Algoritmi Crittografici essential = true
token_endpoint_auth_method	Operazioni: one_of Valori: DEVE essere private_key_jwt essential = true
client_registration_types	Operazioni: subset_of Valori: DEVE essere automatic essential = true
redirect_uris	Operazioni: essential = true
client_id	Operazioni: essential = true
response_types	Operazioni: value Valori: DEVE essere code essential = true

Metadata Policy di un SA per una RP¶

Di seguito vengono riportati i claim che DEVONO essere considerati nel parametro metadata di tipo openid_relying_party all'interno della policy che il SA stabilisce per un RP suo discendente diretto (Aggregato).

Claim	Operazioni / Valori	Supportato da
jwks	Operazioni: value Valori: DEVE contenere i JWKS del RP relativi alle operazioni di Core essential = true

Metadata Policy di un TA per un OP¶

Di seguito vengono riportati i claim che DEVONO essere considerati nel parametro metadata di tipo openid_provider all'interno della policy che il TA stabilisce per un RP suo discendente diretto.

Claim	Operazioni / Valori	Supportato da
jwks	Operazioni: value Valori: DEVE contenere i JWKS del OP relativi alle operazioni di Core essential = true
revocation_endpoint_auth_methods_supported	Operazioni: subset_of Valori: DEVE essere private_key_jwt essential = true
code_challenge_methods_supported	Operazioni: subset_of Valori: DEVE essere S256 essential = true
scopes_supported	Operazioni: subset_of, superset_of Valori: DEVE contenere openid, offline_access. Per CIE id PUÒ contenere anche profile, email. essential = true
response_types_supported	Operazioni: subset_of Valori: DEVE essere code. essential = true
response_modes_supported	Operazioni: subset_of, superset_of Valori: DEVE contenere form_post, query. essential = true
grant_types_supported	Operazioni: subset_of, superset_of Valori: DEVE contenere refresh_token, authorization_code. essential = true
acr_values_supported	Operazioni: subset_of, superset_of Valori: DEVE contenere https://www.spid.gov.it/SpidL1, https://www.spid.gov.it/SpidL2, https://www.spid.gov.it/SpidL3. essential = true
subject_types_supported	Operazioni: subset_of Valori: DEVE essere pairwise. essential = true
id_token_signing_alg_values_supported	Operazioni: subset_of, superset_of Valori: DEVE contenere gli algoritmi definiti nella Sezione Algoritmi Crittografici essential = true
id_token_encryption_alg_values_supported	Operazioni: subset_of, superset_of Valori: DEVE contenere gli algoritmi definiti nella Sezione Algoritmi Crittografici essential = true
id_token_encryption_enc_values_supported	Operazioni: subset_of, superset_of Valori: DEVE contenere gli algoritmi definiti nella Sezione Algoritmi Crittografici essential = true
userinfo_signing_alg_values_supported	Operazioni: subset_of, superset_of Valori: DEVE contenere gli algoritmi definiti nella Sezione Algoritmi Crittografici essential = true
userinfo_encryption_alg_values_supported	Operazioni: subset_of, superset_of Valori: DEVE contenere gli algoritmi definiti nella Sezione Algoritmi Crittografici essential = true
userinfo_encryption_enc_values_supported	Operazioni: subset_of, superset_of Valori: DEVE contenere gli algoritmi definiti nella Sezione Algoritmi Crittografici essential = true
token_endpoint_auth_methods_supported	Operazioni: subset_of Valori: DEVE essere private_key_jwt essential = true
token_endpoint_auth_signing_alg_values_supported	Operazioni: subset_of, superset_of Valori: DEVE contenere gli algoritmi definiti nella Sezione Algoritmi Crittografici essential = true
claims_parameter_supported	Operazioni: value Valori: DEVE essere true essential = true
request_parameter_supported	Operazioni: value Valori: DEVE essere true essential = true
authorization_response_iss_parameter_supported	Operazioni: value Valori: DEVE essere true essential = true
client_registration_types_supported	Operazioni: subset_of Valori: DEVE essere automatic essential = true
request_authentication_methods_supported	Operazioni: value Valori: DEVE essere request_object essential = true
request_authentication_signing_alg_values_supported	Operazioni: subset_of, superset_of Valori: DEVE contenere gli algoritmi definiti nella Sezione Algoritmi Crittografici essential = true
request_object_signing_alg_values_supported	Operazioni: subset_of, superset_of Valori: DEVE contenere gli algoritmi definiti nella Sezione Algoritmi Crittografici essential = true
issuer	Operazioni: essential = true
authorization_endpoint	Operazioni: essential = true
token_endpoint	Operazioni: essential = true
userinfo_endpoint	Operazioni: essential = true
introspection_endpoint	Operazioni: essential = true
revocation_endpoint	Operazioni: essential = true

Vedi anche

• Esempi non normativi di Metadata Policy

federation_entity Trust Mark¶

In aggiunta ai claim dei profili public e private, il profilo intermediate individua i SA e aggiunge le estensioni full e light all'interno del claim sa_profile, a seconda della modalità con cui operano rispetto ai Soggetti Aggregati

oauth_resource Trust Mark¶

In aggiunta ai claim dei profili public e private, il profilo oauth_resource individua le AA e aggiunge i seguenti claim obbligatori:

Validazione dei Trust Mark¶

Esistono due modi per validare un Trust Mark:

1. Validazione statica. Il Trust Mark viene validato mediante la chiave pubblica dell'autorità che lo ha emesso (attributo iss), sulla base della corrispondenza dell'attributo sub con il medesimo attributo della Entity Configuration in cui è contenuto e sulla base del valore di scadenza (attributo exp).
2. Validazione dinamica. I partecipanti della Federazione possono interrogare l'endpoint trust mark status erogato dal suo emettitore (attributo iss) per la verifica in tempo reale dei TM da lui emessi.

Tutte le entità che rilasciano Trust Mark DEVONO esporre un endpoint di Trust Mark status per consentire la validazione dinamica.

Revoca dei Trust Mark¶

Un Trust Mark può essere revocato in qualsiasi momento solo ed esclusivamente dal soggetto che lo ha emesso. Ad esempio, in caso di esclusione di un Soggetto Aggregato da parte della Autorità di Federazione, questa comunica al Soggetto Aggregatore l'esclusione dell'Aggregato. Di conseguenza il SA DEVE revocare il TM per il suo discendente.

Composizione dei Trust Mark¶

Gli attributi definiti all'interno dei TM aderiscono a quanto definito all'interno dello standard OIDC Federation 1.0 (OIDC-FED). Segue la lista.

Claim	Descrizione	Supportato da
iss	String. URL che identifica univocamente l'Autorità che lo ha emesso.
sub	String. URL che identifica univocamente il soggetto per il quale il Trust Mark è stato emesso.
id	String. Identificativo univoco del Trust Mark. È un URL con la seguente struttura: <TA domain>/<entity_type>/<trustmark_profile>/ es. non normativo: https://registry.interno.gov.it/openid_relying_party/public/
iat	UNIX Timestamp con l'istante di generazione del JWT, codificato come NumericDate come indicato in RFC 7519
logo_uri	String. Un URL che punta al logo rappresentante il Trust Mark.
exp	UNIX Timestamp con l'istante di scadenza del JWT, codificato come NumericDate come indicato in RFC 7519
ref	String. URL che punta a informazioni presenti sul web relative a questo Trust Mark.
organization_type	String. Specifica se l'ente appartiene alla pubblica amministrazione italiana o al settore privato (public o private)
id_code	Oggetto JSON. Contiene uno o più codici di identificazione dell'organizzazione. I claim disponibili sono: - ipa_code: OBBLIGATORIO nel caso di organizzazione pubblica. - aoo_code: OPZIONALE. - uo_code: OPZIONALE. - vat_number: OBBLIGATORIO per organizzazione privata se non presente fiscal_number. - fiscal_number: OBBLIGATORIO per organizzazione privata se non presente vat_number.
email	String. Email istituzionale o PEC dell'organizzazione.
organization_name	String. Il nome completo dell'entità che fornisce i servizi
sa_profile	String. RICHIESTO per SA. Specifica il profilo dell’Aggregatore, full o light.

Relying Party¶

Il RP ottiene la lista degli OP in formato JSON interrogando l'endpoint list disponibile presso il Trust Anchor. Per ogni soggetto contenuto nella risposta dell'endpoint list e corrispondente ad un OP, il RP richiede ed ottiene l'Entity Configuration presso l'OP.

Per ogni EC degli OP, il RP verifica la firma del contenuto adoperando la chiave pubblica ottenuta dall'Entity Statement rilasciato dalla Trust Anchor per gli OP. Verifica la firma dell'Entity Configuration degli OP usando la chiave pubblica ottenuta dall'Entity Statement rilasciato dal TA.

Il RP applica infine le politiche pubblicate dal Trust Anchor sui Metadata dell'OP e salva il Metadata finale associandolo ad una data di scadenza (claim exp). La data di scadenza corrisponde al valore di exp più basso ottenuto da tutti gli elementi che compongono la Trust Chain. Periodicamente il RP aggiorna i Metadata di tutti gli OP rinnovando la Trust Chain relativa a questi.

Ottenuti i Metadata finali di tutti i OpenID Connect Provider, il RP genera lo SPID Button o il CIE id Button e lo pubblica all'interno della pagina di autenticazione destinata agli utenti.

La procedura di Federation Entity Discovery risulta semplificata per i RP, perché all'interno della Federazione non è consentita l'esistenza di Intermediari tra gli OP ed il loro Trust Anchor.

La procedura di Federation Entity Discovery a partire dalla Foglia fino al Trust Anchor. Dall'Entity Statement rilasciato da un superiore si ottiene la chiave pubblica per la validazione dell'Entity Configuration dell'entità discendente.

OpenID Provider¶

Quando un Provider (OP) riceve una richiesta di autorizzazione da parte di un RP non precedentemente riconosciuto, avviene la procedura di automatic client registration. Sono di seguito descritte le operazioni compiute dal OP per registrare un RP dinamicamente.

La registrazione di un RP dalla prospettiva di un OP che per la prima volta riceve una richiesta di autorizzazione dal RP e avvia il processo di Federation Entity Discovery e salvataggio della Trust Chain.

L'OP estrae l'identificativo univoco (client_id) dall'oggetto request contenuto all'interno della Authorization Request ed effettua una richiesta di Entity Configuration presso il RP. Ottiene l'Entity Configuration del RP e convalida la firma dei Trust Mark riconoscibili all'interno della Federazione [1].

Se il RP non espone all'interno della sua configurazione nessun Trust Mark riconoscibile per il profilo di RP (vedi Sezione Trust Mark) il Provider DEVE rifiutare l'autorizzazione con un messaggio di errore come definito nella Sezione Gestione degli errori di Federazione.

Se il Provider convalida con successo almeno un Trust Mark per il profilo RP contenuto all'interno della configurazione del RP richiedente, estrae le entità superiori contenute nel claim authority_hints ed avvia la fase di Federation Entity Discovery. Ne consegue il calcolo della Trust Chain e l'ottenimento del Metadata finale.

Durante il Federation Entity Discovery, il Provider richiede ad una o più entità superiori [2] l'Entity Statement relativo al RP e ottiene la chiave pubblica con la quale valida la configurazione del RP, fino a giungere al Trust Anchor. Infine applica la politica dei Metadata pubblicata dal Trust Anchor e salva il risultante Metadata finale del RP associandolo ad una data di scadenza, oltre la quale rinnoverà il Metadata secondo le modalità di rinnovo della Trust Chain.

Ottenuto il Metadata finale, il Provider valida la richiesta del RP secondo le modalità definite in questo documento.

Nei casi in cui un RP avesse come entità superiore un SA e non direttamente il TA, la procedura di acquisizione e validazione dell'Entity Configuration del RP avviene mediante l'Entity Statement pubblicato dal SA nei confronti del RP e mediante la convalida dell'Entity Configuration del SA con l'Entity Statement emesso dalla TA in relazione al SA. Se la soglia del massimo numero di Intermediari verticali, definita dal valore di max_path_length, viene superata, l'OP blocca il processo di Federation Entity Discovery e rigetta la richiesta del RP.

Ogni partecipante espone la propria configurazione e i propri Trust Mark. Il collegamento tra una Foglia e il Trust Anchor avviene in maniera diretta oppure mediante un Intermediario (Soggetto Aggregatore) come in Figura.

Accesso alla Entity Configuration¶

In questa sezione viene descritto come individuare per un determinato soggetto l'URL RFC 3986 per il download della Entity Configuration.

La risorsa attraverso la quale un partecipante pubblica la sua configurazione (Entity Configuration) corrisponde al webpath .well-known/openid-federation e DEVE essere appesa all'URL che identifica il soggetto.

Esempi:

• con identificativo del soggetto pari a https://rp.example.it il risultante URL di Entity Configuration è
  https://rp.example.it/.well-known/oidc-federation.
• con identificativo del soggetto pari https://rp.servizi-spid.it/oidc/ il risultante URL di Entity Configuration è
  https://rp.servizi-spid.it/oidc/.well-known/oidc-federation.

Se l'URL che identifica il soggetto non presenta il simbolo di slash finale ("/"), è necessario aggiungerlo prima di concatenare il web path della risorsa .well-known.

Una volta che un RP viene riconosciuto come parte della Federazione, ottiene il permesso di effettuare una Richiesta di Autenticazione. L'OP che non ha interagito prima d'ora con un RP che fa la richiesta, è in grado di risolvere la fiducia mediante l'API di federazione (Federation Entity Discovery e produzione della Trust Chain). L'OP inizia richiedendo la Entity Configuration del RP al .well-known endpoint del RP e, seguendo il percorso dato dall'authority_hint, raggiunge la radice del Trust, cioè il TA. In ogni passo della catena l'OP può eseguire tutti i controlli di sicurezza richiedendo le dichiarazioni di entità da ciascuna entità e convalidando i Trust Mark e le firme. La figura che segue dà un esempio rappresentativo di come funziona la catena del Trust.

The Federation Entity Discovery process to build a Trust Chain and obtain the final Metadata.

Codici di errore di Federation¶

Errore	Descrizione	Codice HTTP	Supportato da
temporarily_unavailable	Uno degli endpoint di well-known o di Federation non è raggiungibile.	302 Found or 400 Bad Request
invalid_client	Il Client non è autorizzato perchè la validazione della Trust Chain fallisce.	302 Found
unauthorized_client	L'applicazione del metadata policy produce un metadata non conforme o nessun Trust Mark valido per il profilo richiesto è presente all'interno della configurazione.	302 Found
invalid_request	La richiesta non è completa o non è conforme a quanto definito dalle presenti specifiche tecniche.	400 Bad Request
not_found	La risorsa richiesta non è stata trovata.	404 Not Found

Request¶

Per avviare il processo di autenticazione, il RP reindirizza l'utente all'Authorization Endpoint dell'OP selezionato, inviando una richiesta HTTP contenente il parametro request in formato JWT firmato e contenente l'Authorization Request firmata dal RP.

Per veicolare la richiesta, il RP PUÒ utilizzare i metodi POST e GET. Mediante il metodo POST i parametri DEVONO essere trasmessi utilizzando la Form Serialization. Mediante il metodo GET i parametri DEVONO essere trasmessi utilizzando la Query String Serialization. Per maggiori dettagli vedi OpenID.Core#Serializations.

Di seguito i parametri obbligatori nella richiesta di autenticazione HTTP.

Parametro	Descrizione	Supportato da
scope	Riporta di valori di scope supportati dall'OP e definiti dal parametro scopes_supported nel Metadata OP. DEVE essere presente almeno il valore openid.
code_challenge	Vedi RFC 7636#section-4.2.
code_challenge_method	Come definito dal parametro code_challenge_methods_supported nel Metadata OP.
request	Vedi OpenID.Core#JWTRequests. DEVE essere un JWT firmato.

Di seguito una tabella che riporta la composizione dell'header del JWT.

Jose Header	Descrizione	Supportato da
alg	Vedi RFC 7516#section-4.1.1. Vedi Algoritmi crittografici..
kid	Vedi RFC 7638#section_3.

Il payload del JWT contiene i seguenti parametri obbligatori.

Claim	Descrizione	Supportato da
client_id	Vedi OpenID.Registration. DEVE essere valorizzato con un HTTPS URL che identifica univocamente il RP.
code_challenge	Come definito nella Tabella dei parametri HTTP.
code_challenge_method	Come definito nella Tabella dei parametri HTTP.
nonce	Vedi OpenID.Core#AuthRequest. DEVE essere una stringa casuale di almeno 32 caratteri alfanumerici. Questo valore sarà restituito nell'ID Token fornito dal Token Endpoint, in modo da consentire al client di verificare che sia uguale a quello inviato nella richiesta di autenticazione.
prompt	Vedi OpenID.Core#AuthRequest. I valori consentiti sono: consent: Se non è già attiva una sessione di Single Sign-On, l'OP fa una richiesta di autenticazione all'utente. Quindi chiede il consenso al trasferimento degli attributi. consent login: l'OP forza una richiesta di autenticazione all'utente. Quindi chiede il consenso al trasferimento degli attributi.
redirect_uri	Vedi OpenID.Core#AuthRequest. DEVE essere una URL indicata nel Metadata RP.
response_type	Vedi OpenID.Core#AuthRequest. Come definito dal parametro response_types_supported nel Metadata OP.
scope	Come definito nella Tabella dei parametri HTTP.
acr_values	Vedi OpenID.Core#AuthRequest. Come definito dal parametro acr_values_supported nel Metadata OP. Valori di riferimento della classe di contesto dell'Authentication Request. DEVE essere una stringa separata da uno spazio, che specifica i valori "acr" richiesti in ordine di preferenza. L'OP PUÒ utilizzare un'autenticazione ad un livello più alto di quanto richiesto. Tale scelta non DEVE comportare un esito negativo della richiesta.
claims	Vedi OpenID.Core#ClaimsRequestParameter. Vedi Sezione "Parametri scope e claims".
state	Vedi OpenID.Core#AuthRequest. DEVE essere una stringa casuale di almeno 32 caratteri alfanumerici. Identificativo univoco della sessione lato RP. Questo valore verrà restituito al client nella risposta al termine dell'autenticazione.
exp	UNIX Timestamp con l'istante di scadenza del JWT, codificato come NumericDate come indicato in RFC 7519
iat	UNIX Timestamp con l'istante di generazione del JWT, codificato come NumericDate come indicato in RFC 7519
iss	DEVE corrispondere al client_id.
aud	DEVE corrispondere all'identificativo del OP (parametro issuer presente nel Metadata OP.)
ui_locales	Lingue preferibili per visualizzare le pagine dell’OP. L’OP può ignorare questo parametro se non dispone di nessuna delle lingue indicate. Lista di codici RFC5646 separati da spazi.

import hashlib
import base64
import re
import os
import random
def get_pkce(code_challenge_method: str = "S256", code_challenge_length: int = 64):
    hashers = {"S256": hashlib.sha256}
    code_verifier_length = random.randint(43, 128)
    code_verifier = base64.urlsafe_b64encode(os.urandom(code_verifier_length)).decode("utf-8")
    code_verifier = re.sub("[^a-zA-Z0-9]+", "", code_verifier)

    code_challenge = hashers.get(code_challenge_method)(
        code_verifier.encode("utf-8")
    ).digest()
    code_challenge = base64.urlsafe_b64encode(code_challenge).decode("utf-8")
    code_challenge = code_challenge.replace("=", "")

    return {
        "code_verifier": code_verifier,
        "code_challenge": code_challenge,
        "code_challenge_method": code_challenge_method,
    }

Response¶

Un'Authentication response è un messaggio di risposta di autorizzazione OAuth 2.0 restituito dall'authorization endpoint dell'OpenID Provider (OP) al termine del flusso di autenticazione. L'OP reindirizzerà l'utente all'url contenuto nel parametro redirect_uri specificato nella richiesta di autorizzazione, aggiungendo i parametri della risposta.

Se l'autenticazione è avvenuta con successo, l'OpenID Provider (OP), reindirizza l'utente aggiungendo i seguenti parametri obbligatori come query parameters al redirect_uri (come definito in OpenID.Core#AuthResponse):

Claim	Descrizione	Supportato da
code	Codice univoco di autorizzazione (Authorization Code) che il client può passare al Token Endpoint per ottenere un ID Token e un Access Token. Questo ha il vantaggio di non esporre alcun token allo User Agent o a malware che controllano questo.
state	Valore state incluso nell'Authentication Request. Il client è tenuto a verificarne la corrispondenza. Deve essere lo stesso valore indicato dal client nella Authorization Request.
iss	Identificatore univoco dell'OP che ha creato l'Authentication Response. Il RP DEVE validare questo parametro e NON DEVE permettere a più OP di usare lo stesso identificatore.

Esempio di Authorization Response dell'OP:

Gestione degli errori¶

In caso di errore, l'OP o il RP rappresentano i messaggi di anomalia relativi agli scambi OpenID Connect, come descritti nelle relative tabelle definite dalle Linee Guida UX SPID.

Claim	Descrizione	Supportato da
Errore	Vedi Codici di errori
Descrizione dell'errore	Descrizione più dettagliata dell'errore, finalizzata ad aiutare lo sviluppatore per eventuale debugging. Questo messaggio non è destinato ad essere visualizzato all'utente (a tal fine si faccia riferimento alle Linee Guida UX SPID)
state	Parametro obbligatorio solo nel caso di risposta di errore alla Authentication Request e DEVE essere uguale al valore state incluso nella Authentication Request. Il RP DEVE verificare che corrisponda a quello inviato nella Authentication Request.

Codici di errore¶

Errore	Descrizione	Codice HTTP	Supportato da
access_denied	L’OP ha negato l’accesso a causa di credenziali non valide o non adeguate al livello SPID richiesto (RFC 6749#section-4.1.2.1).	302 Found
unauthorized_client	Il client non è autorizzato a richiedere un authorization code (RFC 6749#section-4.1.2.1).	302 Found
invalid_request	La richiesta non è valida a causa della mancanza o della non correttezza di uno o più parametri (RFC 6749#section-4.1.2.1).	302 Found
invalid_scope	Sono stati richiesti degli scope non validi (RFC 6749#section-4.1.2.1).	302 Found
server_error	L’OP ha riscontrato un problema interno (RFC 6749#section-4.1.2.1).	302 Found
temporarily_unavailable	L’OP ha riscontrato un problema interno temporaneo (RFC 6749#section-4.1.2.1).	302 Found
unsupported_response_type	Il response_type richiesto non è supportato (RFC 6749#section-4.1.2.1).	302 Found
login_required	L'OP richiede l'autenticazione da parte dell'utente (OpenID.Core#AuthError).	302 Found
consent_required	L'OP richiede il consenso esplicito da parte dell'utente (OpenID.Core#AuthError).	302 Found
request_uri_not_supported	L'OP non supporta l'uso del parametro request_uri (OpenID.Core#AuthError).	302 Found
registration_not_supported	L'OP non supporta l'uso del parametro registration (OpenID.Core#AuthError).	302 Found
invalid_request_object	Il parametro request contiene un Request Object non valido (OpenID.Core#AuthError).	302 Found

Avvertimento

In caso di URI di reindirizzamento non valido, non corrispondente o mancante, l'OP restituisce 400 Bad Request come codice HTTP.

Request¶

Di seguito i claim che DEVONO essere inseriti nella Token Request.

Esempio di richiesta con authorization code (caso 1)

Esempio di richiesta con Refresh Token (caso 2):

Claim	Descrizione	Supportato da
client_id	Vedi OpenID.Registration. DEVE essere valorizzato con un HTTPS URL che identifica univocamente il RP.
client_assertion	JWT firmato con la chiave privata del Relying Party contenente i seguenti parametri: iss: DEVE corrispondere al valore client_id sub: DEVE corrispondere al valore iss aud: URL del Token Endpoint dell'OP iat: UNIX Timestamp con l'istante di generazione del JWT, codificato come NumericDate come indicato in RFC 7519. exp: UNIX Timestamp con l'istante di scadenza del JWT, codificato come NumericDate come indicato in RFC 7519 jti: Identificatore univoco per questa richiesta di autenticazione, generato dal client. Ad esempio in formato uuid4.
client_assertion_type	Deve assumere il seguente valore: urn:ietf:params:oauth:client-assertion-type:jwt-bearer
code	Codice di autorizzazione restituito nell'Authentication response. Obbligatorio solo se grant_type è authorization_code
code_verifier	Codice di verifica del code_challenge. Obbligatorio solo se grant_type è authorization_code
grant_type	Tipo di credenziale presentata dal RP per la richiesta corrente. PUÒ assumere uno dei seguenti valori: authorization_code refresh_token
refresh_token	Obbligatorio solo se grant_type è refresh_token

Response¶

L'OpenID Provider (OP) restituisce un ID Token e Access Token e un eventuale Refresh Token, in formato JWT firmato.

L'Access Token deve essere formato secondo le indicazioni dello standard "International Government Assurance Profile (iGov) for OAuth 2.0 - Draft 03", section 3.2.1, "JWT Bearer Tokens".

L'ID Token deve essere formato secondo le indicazioni del paragrafo successivo.

La risposta DEVE contenere i seguenti claim.

Esempio di risposta:

HTTP/1.1 200 OK
Last-Modified: Wed, 22 Jul 2018 19:15:56 GMT
Content-Type: application/json

{
    "access_token":"dC34Pf6kdG...",
    "token_type":"Bearer",
    "refresh_token":"wJ848BcyLP...",
    "expires_in":1800,
    "id_token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY..."
}

Claim	Descrizione	Supportato da
access_token	L'Access Token, in formato JWT firmato, consente l'accesso allo UserInfo endpoint per ottenere gli attributi.
token_type	Tipo di Access Token restituito. DEVE essere valorizzato sempre con Bearer
refresh_token	Disponibile sono nel caso di sessione lunga revocabile. Il Refresh Token, in formato JWT firmato, consente di chiamare nuovamente il Token Endpoint per ottenere un nuovo Access Token e un nuovo ID Token.
expires_in	Scadenza dell'Access Token in secondi.
id_token	ID Token in formato JWT (vedi paragrafo successivo)

Access Token¶

L'Access Token è un JSON Web Token (JWT) firmato che consente l'accesso allo UserInfo endpoint per ottenere gli attributi dell'utente. Di seguito i claim che compongono l'Access Token.

Esempio del contenuto di intestazione di payload di un Access Token:

Claim	Descrizione	Supportato da
iss	DEVE essere valorizzato con un HTTPS URL che identifica univocamente l'OP. Il client DEVE verificare che questo valore corrisponda all'OP chiamato.
sub	Vedi OpenID.Core#SubjectIDTypes. DEVE essere di tipo pairwise.
client_id	DEVE essere valorizzato con un HTTPS URL che identifica univocamente il RP.
aud	DEVE contenere un elenco di Resource Server che consumano l'AT. DEVE contenere almeno lo UserInfo Endpoint.
scope	L'OP DOVREBBE inserire il parametro scope come previsto in RFC 9068 Sezione 2.2.3. DEVE coincidere con il valore presente in fase di richiesta di autenticazione.
iat	UNIX Timestamp con l'istante di generazione del JWT, codificato come NumericDate come indicato in RFC 7519
exp	UNIX Timestamp con l'istante di scadenza del JWT, codificato come NumericDate come indicato in RFC 7519
jti	DEVE essere una Stringa in formato uuid4. Identificatore unico dell'ID Token che il RP PUÒ utilizzare per prevenirne il riuso, rifiutando l'ID Token se già processato.

ID Token¶

L'ID Token è un JSON Web Token (JWT) firmato che contiene informazioni sull'utente che ha eseguito l'autenticazione. I RP DEVONO eseguire la validazione dell'ID Token.

Di seguito i claim disponibili nell'ID Token.

Esempio del contenuto di intestazione e di payload di un ID Token:

Claim	Descrizione	Supportato da
iss	DEVE essere valorizzato con un HTTPS URL che identifica univocamente l'OP. Il client DEVE verificare che questo valore corrisponda all'OP chiamato.
sub	Vedi OpenID.Core#SubjectIDTypes. DEVE essere di tipo pairwise.
aud	DEVE coincidere con il valore client_id. Il RP DEVE verificare che questo valore corrisponda al proprio client ID.
acr	Livello di autenticazione effettivo. DEVE essere uguale o superiore a quello richiesto dal RP nella Authentication Request.
at_hash	Vedi OpenID.Core#CodeIDToken. Il suo valore è la codifica base64url della prima metà dell'hash calcolato sulla rappresentazione ASCII dell'Access Token, usando l'algoritmo di hashing indicato in alg nell'header dell'ID Token. Il client DEVE verificare che questo valore corrisponda applicando la medesima funzione all'Access Token restituito insieme all'ID Token.
iat	UNIX Timestamp con l'istante di generazione del JWT, codificato come NumericDate come indicato in RFC 7519
nbf	UNIX Timestamp. Istante di inizio validità del JWT in formato NumericDate, come indicato in RFC 7519. DEVE corrispondere con il valore di iat.
exp	UNIX Timestamp con l'istante di scadenza del JWT, codificato come NumericDate come indicato in RFC 7519
jti	DEVE essere una Stringa in formato uuid4. Identificatore unico dell'ID Token che il RP PUÒ utilizzare per prevenirne il riuso, rifiutando l'ID Token se già processato.
nonce	Vedi OpenID.Core#AuthRequest. DEVE essere una stringa casuale di almeno 32 caratteri alfanumerici. Questo valore DEVE coincidere con quello inviato dal RP nella richiesta di autenticazione.

Refresh Token¶

Il Refresh Token è un JWT che PUÒ essere rilasciato dall'OP e che PUÒ essere usato per ottenere un nuovo Access Token che abilita il RP ad accedere allo UserInfo endpoint senza interazione diretta dell'utente.

Il Refresh Token DEVE essere rilasciato in formato JWT, firmato, e contenere almeno i seguenti parametri.

Claim	Descrizione	Supportato da
iss	DEVE essere valorizzato con un HTTPS URL che identifica univocamente l'OP. Il RP DEVE verificare che questo valore corrisponda all'OP chiamato.
client_id	DEVE coincidere con il valore client_id. Il RP DEVE verificare che questo valore corrisponda al proprio client ID.
aud	DEVE contenere il Token Endpoint dell'OP.
iat	UNIX Timestamp con l'istante di generazione del JWT, codificato come NumericDate come indicato in RFC 7519
exp	UNIX Timestamp con l'istante di scadenza del JWT, codificato come NumericDate come indicato in RFC 7519
jti	DEVE essere una Stringa in formato uuid4. Identificatore unico del Refresh Token che il RP PUÒ utilizzare per prevenirne il riuso, rifiutando il Refresh Token se già processato.

Codici di errore¶

Claim	Descrizione	Codice HTTP	Supportato da
invalid_client	Problemi durante la client authentication (ad esempio, il client_id è conosciuto, non è fornita l'autenticazione del client o il metodo di autenticazione non è supportato) (RFC 6749#section-5.2).	401 Unauthorized
unsupported_grant_type	Il parametro grant_type contiene un valore non corretto (RFC 6749#section-5.2).	400 Bad Request
invalid_grant	I parametri grant_type, code, code_verifier, access_token non sono validi (RFC 6749#section-5.2).	400 Bad Request
invalid_request	La richiesta non è valida a causa della mancanza o della non correttezza di uno o più parametri (RFC 6749#section-5.2).	400 Bad Request
server_error	L'OP ha riscontrato un problema interno (RFC 6749#section-5.2).	500 Internal Server Error
temporarily_unavailable	L'OP ha riscontrato un problema interno temporaneo (RFC 6749#section-5.2).	503 Service Unavailable

Request¶

Response¶

Il contenuto del corpo della Response DEVE essere un JWT firmato e cifrato..

L'header JOSE DEVE contenere il parametro cty (Content Type) valorizzato con JWT (vedi RFC 7519#section-5.2).

Lo UserInfo Endpoint restituisce gli attributi utente esplicitamente richiesti tramite il parametro claims o tramite l'utilizzo del parametro scope nella Authentication Request.

Esempio:

HTTP/1.1 200 OK
Last-Modified: Wed, 22 Jul 2018 19:15:56 GMT
Content-Type: application/jose

{
  "alg": "RSA-OAEP",
  "enc": "A256CBC-HS512",
  "kid": "HIvo33-Km7n03ZqKDJfWVnlFudsW28YhQZx5eaXtAKA",
  "cty": "JWT"
}
.
{
   "iss": "https://op.fornitore_identita.it",
   "aud": "https://rp.fornitore_servizio.it",
   "iat": 1519032969,
   "nbf": 1519032969,
   "exp": 1519033149,
   "sub": "OP-1234567890",
   "name": "Mario",
   "family_name": "Rossi",
   "https://attributes.spid.gov.it/fiscal_number": "MROXXXXXXXXXXXXX"
}

L'intestazione del JWE DEVE contenere i seguenti parametri:

Claim	Descrizione	Supportato da
alg	String. Vedi Algoritmi crittografici..
kid	Vedi RFC 7638#section_3.
enc	String. Vedi Algoritmi crittografici..
cty	String. DEVE essere valorizzato con "JWT".

Il payload del JWE è un JWS contenente all'interno del suo payload i seguenti parametri:

Claim	Descrizione	Supportato da
sub	String. Identificatore del soggetto, coincidente con quello già rilasciato nell'ID Token. Il RP DEVE verificare che il valore coincida con quello contenuto nell'ID Token.
iat	UNIX Timestamp con l'istante di generazione del JWT, codificato come NumericDate come indicato in RFC 7519.
exp	UNIX Timestamp con l'istante di scadenza del JWT, codificato come NumericDate come indicato in RFC 7519.
aud	String. Identificatore del soggetto destinatario della response (RP). Il RP DEVE verificare che il valore coincida con il proprio client_id.
iss	String. URI che identifica univocamente l'OP.
<attributo>	I claim richiesti al momento dell'autenticazione.

L'intestazione del JWS DEVE contenere i seguenti parametri:

Claim	Descrizione	Supportato da
alg	String. Vedi Algoritmi crittografici..
kid	Vedi RFC 7638#section_3.
cty	String. DEVE essere valorizzato con "JWT".

Codici di errore¶

Come definiti per Token endpoint.

Esempi¶

Si riportano per comodità gli esempi che danno luogo alla composizione di un unico JSON Object da parte di più attributi ed in particolare i claim "place_of_birth", "address", "document_details", $PREFIX/registered_office.

Si riportano a titolo di esempio due indirizzi italiani:

"address": {
    "street_address":"Via Liszt 21",
    "postal_code":"00144",
    "locality":"Roma",
    "region":"RM",
    "country_code":"IT"
}

"address": {
    "street_address":"S.S. Salaria Km 23,800",
    "postal_code":"00015",
    "locality":"Monterotondo",
    "region":"RM",
    "country_code":"IT"
}

Vi sono casi, come per gli Stati Uniti d'America, dove oltre alla nazione (US) esiste uno Stato. In tali casi lo Stato è indicato nel campo Provincia. Si riporta il seguente esempio:

"address":{
    "street_address":"503,Washington Avenue",
    "postal_code":"12401",
    "locality":"Kingston",
    "region":"New york",
    "country_code":"US"
}

Request¶

La richiesta all'Introspection Endpoint consiste nell'invio del token su cui si vogliono ottenere informazioni unitamente a una Client Assertion che consente di autenticare il RP che esegue la richiesta.

Esempio:

POST /introspection HTTP/1.1
Host: https://op.spid.agid.gov.it
Content-Type: application/x-www-form-urlencoded

client_assertion=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiw
ibmFtZSI6IlNQSUQiLCJhZG1pbiI6dHJ1ZX0.LVyRDPVJm0S9q7oiXcYVIIqGWY0wWQlqxvFGYswLF88 … &
client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwtbearer&
client_id=https%3A%2F%2Frp.spid.agid.gov.it&
token=eyJhbGciOiJSUzI1NiJ9.eyJleHAiOjE0MTg3MDI0MTQsImF1ZCI6WyJlNzFmYjcyYS05NzRmLT
QwMDEtYmNiNy1lNjdjMmJjMDAzN2YiXSwiaXNzIjoiaHR0cHM6XC9cL2FzLXZhLmV4YW1wbGUuY29tXC8
iLCJqdGkiOiIyMWIxNTk2ZC04NWQzLTQzN2MtYWQ4My1iM2YyY2UyNDcyNDQiLCJpYXQiOjE0MTg2OTg4
MTR9.FXDtEzDLbTHzFNroW7w27RLk5m0wprFfFH7h4bdFw5fR3pwiqejKmdfAbJvN3_yfAokBv06we5RA
RJUbdjmFFfRRW23cMbpGQCIk7Nq4L012X_1J4IewOQXXMLTyWQQ_BcBMjcW3MtPrY1AoOcfBOJPx1k2jw
RkYtyVTLWlff6S5gKciYf3b0bAdjoQEHd_IvssIPH3xuBJkmtkrTlfWR0Q0pdpeyVePkMSI28XZvDaGnxA4j7QI5loZYeyzGR9
h70xQLVzqwwl1P0-F_0JaDFMJFO1yl4IexfpoZZsB3HhF2vFdL6D_lLeHRyH2g2OzF59eMIsM_Ccs4G47862w…

Claim	Descrizione	Supportato da
client_assertion	JWT firmato con la chiave privata del Relying Party contenente gli stessi parametri documentati per le richieste al Token Endpoint. L'OP deve verificare la validità di tutti i campi presenti nel JWT, nonché la validità della sua firma in relazione al parametro client_id.
client_assertion_type	String. Valori ammessi: urn:ietf:params:oauth:clientassertion-type:jwt-bearer
client_id	URI che identifica univocamente il RP. L'OP deve verificare che il client_id sia noto all'interno della Federazione.
token	Il token su cui il RP vuole ottenere informazioni.

Response¶

L'Introspection Endpoint risponde con un oggetto JSON definito come segue.

Esempio:

{
    "active":true
}

Claim	Descrizione	Supportato da
active	Valore booleano che indica la validità del token. Se il token è scaduto, è revocato o non è mai stato emesso per il client_id chiamante, l'Introspection Endpoint deve restituire false.
scope	Lista degli scope richiesti al momento dell’Authorization Request.
exp	Scadenza del token.
sub	Identificatore del soggetto, coincidente con quello già rilasciato nell’ID Token. Il RP deve verificare che il valore coincida con quello contenuto nell’ID Token.
client_id	URI che identifica univocamente il RP come da Registro SPID. Il RP deve verificare che il valore coincida con il proprio client_id.
iss	Identificatore dell’OP che lo contraddistingue univocamente nella federazione nel formato Uniform Resource Locator (URL). Il client è tenuto a verificare che questo valore corrisponda all’OP chiamato.
aud	Contiene il client ID. Il client è tenuto a verificare che questo valore corrisponda al proprio client ID.

Codici di errore¶

Come definiti per Token endpoint.

Request¶

La richiesta al Revocation Endpoint consiste nell'invio del token che si vuole revocare unitamente a una Client Assertion che consente di identificare il RP che esegue la richiesta.

Esempio:

POST /revoke HTTP/1.1
Host: https://op.spid.agid.gov.it
Content-Type: application/x-www-form-urlencoded

client_assertion=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiw
ibmFtZSI6IlNQSUQiLCJhZG1pbiI6dHJ1ZX0.LVyRDPVJm0S9q7oiXcYVIIqGWY0wWQlqxvFGYswLF88&
client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwtbearer&
client_id=https%3A%2F%2Frp.spid.agid.gov.it&
token=eyJhbGciOiJSUzI1NiJ9.eyJleHAiOjE0MTg3MDI0MTQsImF1ZCI6WyJlNzFmYjcyYS05NzRmLT
QwMDEtYmNiNy1lNjdjMmJjMDAzN2YiXSwiaXNzIjoiaHR0cHM6XC9cL2FzLXZhLmV4YW1wbGUuY29tXC8
iLCJqdGkiOiIyMWIxNTk2ZC04NWQzLTQzN2MtYWQ4My1iM2YyY2UyNDcyNDQiLCJpYXQiOjE0MTg2OTg4
MTR9.FXDtEzDLbTHzFNroW7w27RLk5m0wprFfFH7h4bdFw5fR3pwiqejKmdfAbJvN3_yfAokBv06we5RA
RJUbdjmFFfRRW23cMbpGQCIk7Nq4L012X_1J4IewOQXXMLTyWQQ_BcBMjcW3MtPrY1AoOcfBOJPx1k2jw
RkYtyVTLWlff6S5gKciYf3b0bAdjoQEHd_IvssIPH3xuBJkmtkrTlfWR0Q0pdpeyVePkMSI28XZvDaGnxA4j7QI5loZYeyzGR9
h70xQLVzqwwl1P0-F_0JaDFMJFO1yl4IexfpoZZsB3HhF2vFdL6D_lLeHRyH2g2OzF59eMIsM_Ccs4G47862w

Claim	Descrizione	Supportato da
client_assertion	JWT firmato con la chiave privata OIDC del Relying Party contenente gli stessi parametri inseriti in fase di richiesta al Token Endpoint. L'OP deve verificare la validità di tutti i campi presenti nel JWT, nonché la validità della sua firma in relazione al parametro client_id.
client_assertion_type	String. urn:ietf:params:oauth:clientassertion-type:jwt-bearer
client_id	URL HTTPS che identifica univocamente il RP.
token	Il token che il RP chiede di revocare.

Response¶

Il Revocation Endpoint risponde con un codice HTTP 200, anche nel caso in cui il token indicato non esista o sia già stato revocato (in modo da non rilasciare informazioni).

Codici di errore¶

Come definiti per Token endpoint.

Gestione dei Log di un OP e di un RP¶

Gli OP e gli RP DEVONO mantenere:

1. Un registro delle transazioni contenente i log relativi ai messaggi scambiati. I messaggi memorizzati e mantenuti nel registro DEVONO essere almeno i seguenti:

   • Trust Chain relativa all'Entità con la quale è avvenuta la transazione, composta da:

     1. L'Entity Configuration del Entità con la quale è avvenuta la transazione.
     2. [Solo per OP] L'Entity Statement del SA riferito al RP (se presente).
     3. L'Entity Statement del TA riferito al suo discendente.
     4. L'Entity Configuration del TA.

   • AuthenticationRequest

   • AuthenticationResponse relativa all'AuthenticationRequest

   • TokenRequest relativa all'AuthenticationRequest

   • TokenResponse relativa alla TokenRequest

   • L'eventuale UserInfoRequest relativa alla TokenRequest

   • L'eventuale UserInfoResponse relativa alla UserInfoRequest

   • L'eventuale RevocationRequest relativa alla TokenRequest

   • L'eventuale RevocationResponse relativa alla RevocationRequest

Registro storico delle chiavi pubbliche di Federazione¶

Al fine di consentire la verifica dei messaggi scambiati dalle Entità che partecipano alla federazione e delle relative Trust Chain, il TA DEVE pubblicare lo storico delle proprie chiavi pubbliche (JWKS) di federazione all'interno di un registro reso disponibile a tutti i partecipanti tramite l'endpoint /.well-known/openid-federation-historical-jwks. Per ulteriori dettagli tecnici si rimanda alla Sezione 7.5 di OIDC-FED.

Metadata¶

Nei metadata OP e RP per CIE id sono presenti i parametri che abilitano la cifratura dell'ID Token (vedi le sezioni relative al Metadata OP e al Metadata RP). SPID non consente la cifratura dell'ID Token, dunque tali parametri non sono richiesti.

Inoltre, il metadata OP per CIE id richiede anche il parametro revocation_endpoint_auth_methods_supported, non richiesto da SPID.

Authorization Endpoint¶

SPID, al contrario di CIE id, prevede l'inserimento obbligatorio dei parametri client_id e response_type nella richiesta HTTP. Inoltre, CIE id prevede come obbligatorio il parametro iss nella response per mitigare gli attacchi di tipo mix-up I-D.ietf-OAuth-Security-BCP.

Parametri Scope e Claims¶

CIE id consente di richiedere gli attributi dell'utente sia tramite il parametro claims nella richiesta di autenticazione e sia tramite il parametro scope, abilitando in quest'ultimo i valori profile e email.

SPID non consente l'utilizzo di profile e email nel parametro scope.

Per ulteriori dettagli vedi la sezione Parametri Scope e claims.

ID Token¶

SPID non consente di rilasciare gli attributi dell'utente all'interno dell'ID Token. In CIE id gli attributi dell'utente sono disponibili sia nell'ID Token e sia nella UserInfo response. Inoltre, il CIE id supporta la criptazione dell'ID Token.

Refresh Token¶

SPID prevede l'utilizzo del Refresh Token per abilitare le sessioni lunghe rinnovabili così come definito nelle LL.GG. OpenID Connect in SPID e nell' Avviso n.41 . Consente, infatti, di ottenere, oltre all'Access Token, l'ID Token valido esclusivamente per SPID livello 1.

In CIE id il Refresh Token non consente di ottenere l'ID Token e non è utilizzabile dagli RP per ottenere una nuova autenticazione dell'utente con l'OP o rinnovare una sessione preesistente. In CIE id il Refresh Token è usato per ottenere dallo UserInfo endpoint esclusivamente il medesimo set di attributi dell'utente richiesti in fase di autenticazione iniziale, per il quale l'utente ha espresso il consenso esplicito. Per ulteriori dettagli si veda la sezione Refresh Token.

UserInfo Endpoint¶

CIE id supporta entrambi i metodi HTTP GET e HTTP POST per le richieste allo UserInfo endpoint. SPID consente solo l'utilizzo del metodo HTTP GET.

Introspection Endpoint¶

CIE id prevede il solo parametro active nella risposta dell'Introspection endpoint. SPID aggiunge ulteriori parametri come specificato nella sezione Introspection Endpoint.

Revocation Endpoint e Logout¶

Entrambi SPID e CIE id prevedono che il RP effettui una richiesta di revoca dell'Access Token in fase di logout dell'utente. In SPID la revoca di un Access Token implica anche la revoca dell'eventuale Refresh Token ancora attivo ad esso collegato e la scadenza della sessione di Single Sign-On se ancora attiva.

In CIE id, invece, la revoca di un Access Token non prevede la revoca del relativo Refresh Token, allo stesso tempo la richiesta di revoca di un Refresh Token determina anche la revoca di tutti i relativi token ancora attivi.

Client Registration¶

SPID e CIE supportano esclusivamente automatic_client_registration. La modalità explicit client registration non è supportata.

Trust Mark¶

L'esposizione dei Trust Mark in SPID e CIE è obbligatoria. Per approfondimenti sulla ragione dell'obbligo dei Trust Mark si rimanda alla sezione Considerazioni di Sicurezza.

Claim non supportati negli Entity Statement¶

Poiché SPID e CIE non necessitano di alcun claim aggiuntivo in ambito federativo, non necessitano del claim crit. Inoltre non sono supportati i claim aud, naming_constraints, policy_language_crit e trust_anchor_id. L'eventuale presenza di questi claim non presenta alcuna implicazione, questi verranno semplicemente ignorati fino ad ulteriori avvisi che li normino.

Trust Mark come deterrente contro gli abusi¶

L'implementazione dei Trust Mark e il filtro su questi in fase di Federation Entity Discovery risulta necessario contro gli attacchi destinati al consumo delle risorse. Un OP attaccato con un numero ingente di connessioni presso il suo endpoint di authorization, contenenti client_id e authority_hints fasulli, produrrebbe svariate connessioni verso sistemi di terze parti nel tentativo di trovare un percorso verso la TA e instaurare la fiducia con il richiedente.

L'OP DEVE validare staticamente il TM oppure DEVE escludere a priori la richiesta ove il TM non risultasse presente, in caso di assenza o non validità di un TM la procedura di Federation Entity Discovery NON DEVE essere avviata e NON DEVE creare di conseguenza connessioni verso sistemi di terze parti.

Numero Massimo di authority_hints¶

All'interno di una Federazione il Trust Anchor decide quante intermediazioni consentire tra di lui e le Foglie, mediante la constraint denominata max_path_length. Questo tipo di relazione è di tipo verticale, dalla Foglia alla radice. Questo attributo se valorizzato ad esempio con un valore numerico intero pari a 1 indica che soltanto un SA è consentito tra una Foglia e il TA.

Ogni Foglia DEVE pubblicare i suoi superiori all'interno della lista contenuta nel claim authority_hints. Una Foglia all'interno della Federazione PUÒ avere superiori afferenti a diverse Federazioni. L'analisi dei superiori disponibili introduce un modello di navigazione orizzontale, ad esempio un OP tenta di trovare il percorso più breve verso il Trust Anchor attraverso tutti gli URL contenuti all'interno dell'array authority_hints prima di fare un ulteriore movimento verticale, a salire, verso uno degli Intermediari presenti in questo array.

La soglia max_path_length si applica per la navigazione verticale e superata questa soglia senza aver trovato il TA, la procedura di Federation Entity Discovery DEVE essere interrotta. Si faccia l'esempio di un RP discendente di un SA che a sua volta è discendente di un altro SA, essendo il valore di max_path_length pari a 1 e, superata questa soglia senza aver trovato il Trust Anchor, la procedura DEVE essere interrotta.

Allo stesso tempo la specifica OIDC Federation 1.0 non definisce un limite per il numero di authority_hints, questo perché nessun Trust Anchor può limitare il numero di Federazioni alle quali un partecipante può aderire. Per questa ragione è utile che gli implementatori adottino un limite massimo del numero di elementi consentiti all'interno dell'Array authority_hint. Questo per evitare che un numero esagerato di URL contenuti nella lista di authority_hints, dovuto ad una cattiva configurazione di una Foglia, produca un consumo di risorse eccessivo.

Resolve endpoint¶

Questo endpoint DEVE rilasciare i Metadata, i Trust Mark e la Trust Chain già precedentemente elaborata e NON DEVE innescare una procedura di Federation Entity Discovery ad ogni richiesta pervenuta, a meno che questo endpoint non venga protetto con un meccanismo di autenticazione dei client, come ad esempio private_key_jwt [OIDC-CORE]. In caso di utilizzo di private_key_jwt il valore presente nel parametro sub del private_key_jwt DEVE coincidere con quello presente nella richiesta al Resolve endpoint.

Specializzare le chiavi pubbliche OpenID Core e Federation¶

È buona pratica usare chiavi pubbliche specializzate per i due tipi di operazioni, Core e Federation.

Modalità di aggiornamento dei Metadata OpenID Core¶

L'interoperabilità tra i partecipanti funziona mediante i Metadata ottenuti dal calcolo e dalla conservazione delle Trust Chain. Questo significa che se un OP al tempo T calcola la Trust Chain per un RP e questo al tempo T+n modifica i propri Metadata, l'OP di conseguenza potrebbe incorrere in problematiche di validazione delle richieste di autorizzazione del RP, fino a quando non avrà aggiornato la Trust Chain relativa a questo.

La buona pratica per evitare le interruzioni di servizio relative alle operazioni di OIDC Core è quella di aggiungere le nuove chiavi pubbliche all'interno degli oggetti jwks senza rimuovere i valori preesistenti. Oppure, ad esempio, i nuovi redirect_uri.

In questa maniera dopo il limite massimo di durata delle Trust Chain, definito con il claim exp e pubblicato nella Entity Configuration della TA, si ha la certezza che tutti i partecipanti abbiano rinnovato le loro Trust Chain, e sarà possibile agli amministratori della Foglia rimuovere le vecchie definizioni in cima alla lista.

EN 1. Entity Configuration Request¶

GET /.well-known/openid-federation HTTP/1.1
Host: rp.example.it

EN 1.1. Entity Configuration Response Relying Party¶

HTTP/1.1 200 OK
Last-Modified: Wed, 22 Jul 2018 19:15:56 GMT
Content-Type: application/entity-statement+jwt

{
    "alg": "RS256",
    "kid": "2HnoFS3YnC9tjiCaivhWLVUJ3AxwGGz_98uRFaqMEEs",
    "typ": "entity-statement+jwt"
}
.
{
    "exp": 1649590602,
    "iat": 1649417862,
    "iss": "https://rp.example.it/",
    "sub": "https://rp.example.it/",
    "jwks": {
        "keys": [
            {
                "kty": "RSA",
                "n": "5s4qi …",
                "e": "AQAB",
                "kid": "2HnoFS3YnC9tjiCaivhWLVUJ3AxwGGz_98uRFaqMEEs"
            }
        ]
    },
    "metadata": {
        "openid_relying_party": {
            "application_type": "web",
            "client_id": "https://rp.example.it/",
            "client_registration_types": [
                "automatic"
            ],
            "jwks": {
                "keys": [
                    {
                        "kty": "RSA",
                        "use": "sig",
                        "n": "1Ta-sE …",
                        "e": "AQAB",
                        "kid": "YhNFS3YnC9tjiCaivhWLVUJ3AxwGGz_98uRFaqMEEs"
                    }
                ]
            },
            "client_name": "Name of an example organization",
            "contacts": [
                "ops@rp.example.it"
            ],
            "grant_types": [
                "refresh_token",
                "authorization_code"
            ],
            "redirect_uris": [
                "https://rp.example.it/oidc/rp/callback/"
            ],
            "response_types": [
                "code"
            ],
            "subject_type": "pairwise"
        },
        "federation_entity": {
            "federation_resolve_endpoint": "https://rp.example.it/resolve/",
            "organization_name": "PA OIDC Service Provider",
            "homepage_uri": "https://rp.example.it",
            "policy_uri": "https://rp.example.it/policy",
            "logo_uri": "https://rp.example.it/static/logo.svg",
            "contacts": [
               "tech@example.it"
             ]
        }
    },
    "trust_marks": [
        {
            "id": "https://registry.agid.gov.it/openid_relying_party/public/",
            "trust_mark": "eyJh …"
        }
    ],
    "authority_hints": [
        "https://registry.agid.gov.it/"
    ]
}

EN 1.2. Entity Configuration Response Openid Provider¶

HTTP/1.1 200 OK
Last-Modified: Wed, 22 Jul 2018 19:15:56 GMT
Content-Type: application/entity-statement+jwt

{
    "alg": "RS256",
    "kid": "dB67gL7ck3TFiIAf7N6_7SHvqk0MDYMEQcoGGlkUAAw",
    "typ": "entity-statement+jwt"
}
.
{
    "exp": 1649610249,
    "iat": 1649437449,
    "iss": "https://openid.provider.it/",
    "sub": "https://openid.provider.it/",
    "jwks": {
        "keys": [
            {
                "kty": "RSA",
                "e": "AQAB",
                "n": "01_4a …",
                "kid": "dB67gL7ck3TFiIAf7N6_7SHvqk0MDYMEQcoGGlkUAAw"
            }
        ]
    },
    "metadata": {
        "openid_provider": {
            "authorization_endpoint": "https://openid.provider.it/authorization",
            "revocation_endpoint": "https://openid.provider.it/revocation/",
            "id_token_encryption_alg_values_supported": [
                "RSA-OAEP"
            ],
            "id_token_encryption_enc_values_supported": [
                "A128CBC-HS256"
            ],
            "token_endpoint": "https://openid.provider.it/token/",
            "userinfo_endpoint": "https://openid.provider.it/userinfo/",
            "introspection_endpoint": "https://openid.provider.it/introspection/",
            "claims_parameter_supported":true,
            "contacts": [
                "ops@https://idp.it"
            ],
            "client_registration_types_supported": [
                "automatic"
            ],
            "code_challenge_methods_supported": [
                "S256"
            ],
            "request_authentication_methods_supported": {
                "ar": [
                    "request_object"
                ]
            },
            "acr_values_supported": [
                "https://www.spid.gov.it/SpidL1",
                "https://www.spid.gov.it/SpidL2",
                "https://www.spid.gov.it/SpidL3"
            ],
            "claims_supported": [
                "https://attributes.eid.gov.it/spid_code",
                "given_name",
                "family_name",
                "place_of_birth",
                "birthdate",
                "gender",
                "https://attributes.eid.gov.it/company_name",
                "https://attributes.eid.gov.it/registered_office",
                "https://attributes.eid.gov.it/fiscal_number",
                "https://attributes.eid.gov.it/vat_number",
                "https://attributes.eid.gov.it/document_details",
                "phone_number",
                "email",
                "address",
                "https://attributes.eid.gov.it/eid_exp_date",
                "https://attributes.eid.gov.it/e_delivery_service"
            ],
            "grant_types_supported": [
                "authorization_code",
                "refresh_token"
            ],
            "id_token_signing_alg_values_supported": [
                "RS256",
                "ES256"
            ],
            "issuer": "https://openid.provider.it/",
            "jwks": {
                "keys": [
                    {
                        "kty": "RSA",
                        "use": "sig",
                        "n": "1Ta-sE …",
                        "e": "AQAB",
                        "kid": "FANFS3YnC9tjiCaivhWLVUJ3AxwGGz_98uRFaqMEEs"
                    }
                ]
            },
            "scopes_supported": [
                "openid",
                "offline_access"
            ],
            "logo_uri": "https://openid.provider.it/static/svg/spid-logo-c-lb.svg",
            "organization_name": "SPID OIDC identity provider",
            "op_policy_uri": "https://openid.provider.it/it/website/legal-information/",
            "request_parameter_supported":true,
            "request_uri_parameter_supported":true,
            "require_request_uri_registration":true,
            "response_types_supported": [
                "code"
            ],
            "subject_types_supported": [
                "pairwise",
                "public"
            ],
            "token_endpoint_auth_methods_supported": [
                "private_key_jwt"
            ],
            "token_endpoint_auth_signing_alg_values_supported": [
                "RS256",
                "RS384",
                "RS512",
                "ES256",
                "ES384",
                "ES512"
            ],
            "userinfo_encryption_alg_values_supported": [
                "RSA-OAEP",
                "RSA-OAEP-256"
            ],
            "userinfo_encryption_enc_values_supported": [
                "A128CBC-HS256",
                "A192CBC-HS384",
                "A256CBC-HS512",
                "A128GCM",
                "A192GCM",
                "A256GCM"
            ],
            "userinfo_signing_alg_values_supported": [
                "RS256",
                "RS384",
                "RS512",
                "ES256",
                "ES384",
                "ES512"
            ],
            "request_object_signing_alg_values_supported": [
                "RS256",
                "RS384",
                "RS512",
                "ES256",
                "ES384",
                "ES512"
            ]
        },
        "federation_entity": {
            "federation_resolve_endpoint": "https://openid.provider.it/resolve/",
            "organization_name": "SPID OIDC identity provider",
            "homepage_uri": "https://provider.it",
            "policy_uri": "https://provider.it/policy",
            "logo_uri": "https://provider.it/static/logo.svg",
            "contacts": [
               "tech@provider.it"
             ]
        }
    },
    "authority_hints": [
        "https://registry.agid.gov.it/"
    ]
}

EN 1.3. Entity Configuration Response Intermediary¶

HTTP/1.1 200 OK
Last-Modified: Wed, 22 Jul 2018 19:15:56 GMT
Content-Type: application/entity-statement+jwt

{
    "alg": "RS256",
    "kid": "em3cmnZgHIYFsQ090N6B3Op7LAAqj8rghMhxGmJstqg",
    "typ": "entity-statement+jwt"
}
.
{
    "exp": 1649631824,
    "iat": 1649459024,
    "iss": "https://aggregatore.it/",
    "sub": "https://aggregatore.it/",
    "jwks": {
        "keys": [
            {
                "kty": "RSA",
                "e": "AQAB",
                "n": "14aW …",
                "kid": "em3cmnZgHIYFsQ090N6B3Op7LAAqj8rghMhxGmJstqg"
            }
        ]
    },
    "metadata": {
        "federation_entity": {
            "contacts": [
                "soggetto@aggregatore.it"
            ],
            "federation_fetch_endpoint": "https://aggregatore.it/fetch/",
            "federation_resolve_endpoint": "https://aggregatore.it/resolve/",
            "federation_list_endpoint": "https://aggregatore.it/list/",
            "homepage_uri": "https://soggetto.aggregatore.it",
            "name": "Soggetto Aggregatore di esempio"
        },
        "trust_mark_issuer": {
            "federation_status_endpoint": "https://aggregatore.it/trust_mark_status/",

        }
    },
    "trust_marks": [
        {
            "id": "https://registry.gov.it/intermediate/private/full/",
            "trust_mark": "eyJh …"
        }
    ],
    "authority_hints": [
        "https://registry.agid.gov.it/"
    ]
}

EN 1.4. Entity Configuration Response Trust Anchor¶

HTTP/1.1 200 OK
Last-Modified: Wed, 22 Jul 2018 19:15:56 GMT
Content-Type: application/entity-statement+jwt

{
    "alg": "RS256",
    "kid": "FifYx03bnosD8m6gYQIfNHNP9cM_Sam9Tc5nLloIIrc",
    "typ": "entity-statement+jwt"
}
.
{
    "exp": 1649375259,
    "iat": 1649373279,
    "iss": "https://registry.agid.gov.it/",
    "sub": "https://registry.agid.gov.it/",
    "jwks": {
        "keys": [
            {
                "kty": "RSA",
                "n": "3i5vV-_ …",
                "e": "AQAB",
                "kid": "FifYx03bnosD8m6gYQIfNHNP9cM_Sam9Tc5nLloIIrc"
            }
        ]
    },
    "metadata": {
        "federation_entity": {
            "organization_name": "example TA"
            "contacts":[
                "spid.tech@agid.gov.it"
            ],
            "policy_uri": "https://registry.agid.gov.it/policy",
            "homepage_uri": "https://registry.agid.gov.it/",
            "logo_uri":"https://registry.agid.gov.it/static/svg/logo.svg",
            "federation_fetch_endpoint": "https://registry.agid.gov.it/fetch/",
            "federation_resolve_endpoint": "https://registry.agid.gov.it/resolve/",
            "federation_list_endpoint": "https://registry.agid.gov.it/list/",
            "federation_trust_mark_status_endpoint": "https://registry.agid.gov.it/trust_mark_status/"
        }
    },
    "trust_mark_issuers": {
        "https://registry.agid.gov.it/openid_relying_party/public/": [
            "https://registry.spid.agid.gov.it/",
            "https://public.intermediary.spid.it/"
        ],
        "https://registry.agid.gov.it/openid_relying_party/private/": [
            "https://registry.spid.agid.gov.it/",
            "https://private.other.intermediary.it/"
        ]
    },
    "constraints": {
        "max_path_length": 1
    }
}