Risultati
87 risultati
-
italia
Metadata Attribute Authority
Una AA DEVE pubblicare, all'interno del suo EC, un Metadata federation_entity e un Metadata oauth_resource e, se le risorse sono protette, DEVE anche pubblicare un Metadata oauth_authorization_server. Il Metadata di tipo "federation_entity" DEVE contenere almeno i seguenti parametri obbligatori:. Descrizione. Supportato da. organization_name. Vedi Sezione 4.8 di OIDC-FED. homepage_uri. Vedi Sezione 4.8 di OIDC-FED. policy_uri. Vedi Sezione 4.8 di OIDC-FED. logo_uri. URL del logo dell'entità; DEVE essere in formato SVG. Vedi Sezione 4.8 di OIDC-FED. contacts. PEC istituzionale dell'ente. Vedi Sezione 4.8 di OIDC-FED. federation_trust_mark_status_endpoint. Vedi Sezione Endpoint di Federazione e OIDC-FED Section 4.8. federation_resolve_endpoint. Vedi Sezione Endpoint di Federazione e OIDC-FED Section 4.8. Il Metadata di tipo "oauth_authorization_server" DEVE contenere almeno i seguenti parametri obbligatori:. Descrizione. Supportato da. issuer. Vedi RFC 8414#page-4. DEVE essere valorizzato con un HTTPS URL che identifica univocamente l'AA. authorization_endpoint. Solo per Attribute Authority private flow. Vedi LG-AA and RFC 8414#page-4. token_endpoint. Vedi RFC 8414#page-4. jwks. Vedi JWK. scopes_supported. Vedi RFC 8414#page-4. response_types_supported. Vedi RFC 8414#page-4,. grant_types_supported. Vedi RFC 8414#page-4 e RFC 8623. token_endpoint_auth_methods_supported. Vedi RFC 8414#page-4. Il valore supportato è private_key_jwt. token_endpoint_auth_signing_alg_values_supported. Vedi RFC 8414#page-4. Vedi signature Algoritmi crittografici. op_policy_uri. Vedi RFC 8414#page-4. op_tos_uri. Vedi RFC 8414#page-6. dpop_signing_alg_values_supported. Vedi OAuth-DPoP. Vedi signature Algoritmi crittografici. Il Metadata di tipo "oauth_resource" DEVE contenere almeno i seguenti parametri obbligatori:. Descrizione. Supportato da. resource. Vedi OAuth-RS. Una o più HTTPS URL che identificano gli endpoint delle risorse protette ...
-
italia
Esempi
The following example shows a Metadata policy in the Entity Statement provided by a TA and related to an RP. "metadata_policy": { "openid_relying_party": { "jwks": { "value": { "keys": [ { "kty": "RSA", "e": "AQAB", "use": "sig", "kid": "....", "n": "....." }, { "kty": "RSA", "e": "AQAB", "use": "enc", "kid": "....", "n": "....." } ] }, "grant_types": { "subset_of": [ "authorization_code", "refresh_token" ], "superset_of": [ "authorization_code" ] }, "id_token_signed_response_alg": { "one_of": [ "RS256", "RS512", "ES256", "ES512", "PS256", "PS512" ], "essential": true }, "id_token_encrypted_response_alg": { "one_of": [ "RSA-OAEP", "RSA-OAEP-256", "ECDH-ES", "ECDH-ES+A128KW", "ECDH-ES+A256KW" ], "essential": false }, "id_token_encrypted_response_enc": { "one_of": [ "A128CBC-HS256", "A256CBC-HS512" ], "essential": false }, "userinfo_signed_response_alg": { "one_of": [ "RS256", "RS512", "ES256", "ES512", "PS256", "PS512" ], "essential": true }, "userinfo_encrypted_response_alg": { "one_of": [ "RSA-OAEP", "RSA-OAEP-256", "ECDH-ES", "ECDH-ES+A128KW", "ECDH-ES+A256KW" ], "essential": true }, "userinfo_encrypted_response_enc": { "one_of": [ "A128CBC-HS256", "A256CBC-HS512" ], "essential": true }, "token_endpoint_auth_method": { "one_of": [ "private_key_jwt" ], "essential": true }, "client_registration_types": { "subset_of": [ "automatic" ], "essential": true }, "redirect_uris": { "essential": true }, "client_id": { "essential": true }, "response_types": { "value": [ "code" ] } } }. The following example shows a Metadata policy in the Entity Statement provided by a TA and related to an SA. "metadata_policy": { "openid_relying_party": { "grant_types": { "subset_of": [ "authorization_code", "refresh_token" ], "superset_of": [ "authorization_code" ] }, "id_token_signed_response_alg": { "one_of": [ "RS256", "RS512", "ES256", "ES512", "PS256", "PS512" ], "essential": true }, "id_token_encrypted_response_alg": { "one_of": [ "RSA-OAEP", "RSA-OAEP-256", "ECDH-ES", "ECDH-ES+A128KW", "ECDH-ES+A256KW" ], "essential": false }, "id_token_encrypted_response_enc": { "one_of": [ "A128CBC-HS256", "A256CBC-HS512" ], "essential": false }, "userinfo_signed_response_alg": { "one_of": [ "RS256", "RS512", "ES256", "ES512", "PS256", "PS512" ], "essential": true }, "userinfo_encrypted_response_alg": { "one_of": [ "RSA-OAEP", "RSA-OAEP-256", "ECDH-ES", "ECDH-ES+A128KW", "ECDH-ES+A256KW" ], "essential": true }, "userinfo_encrypted_response_enc": { "one_of": [ "A128CBC-HS256", "A256CBC-HS512" ], "essential": true }, "token_endpoint_auth_method": { "one_of": [ "private_key_jwt" ], "essential": true }, "client_registration_types": { "subset_of": [ "automatic" ], "essential": true }, "redirect_uris": { "essential": true }, "client_id": { "essential": true }, "response_types": { "value": [ "code" ] } } }. The following example shows a Metadata policy in the Entity Statement provided by a SA and related to an RP. "metadata_policy": { "openid_relying_party": { "jwks": { "value": { "keys": [ { "kty": "RSA", "e": "AQAB", "use": "sig", "kid": "....", "n": "....." }, { "kty": "RSA", "e": "AQAB", "use": "enc", "kid": "....", "n": "....." } ] }, } }. The following example shows a Metadata policy in the Entity Statement provided by a TA and related to an OP. "metadata_policy": { "openid_relying_party": { "jwks": { "value": { "keys": [ { "kty": "RSA", "e": "AQAB", "use": "sig", "kid": "....", "n": "....." }, { "kty": "RSA", "e": "AQAB", "use": "enc", "kid": "....", "n": "....." } ] }, "revocation_endpoint_auth_methods_supported": { "subset_of": [ "private_key_jwt" ], "essential": true }, "code_challenge_methods_supported": { "subset_of": [ "S256" ], "essential": true }, "scopes_supported": { "subset_of": [ "openid", "offline_access", "profile", "email" ], "superset_of": [ "openid", "offline_access" ] }, "response_types_supported": { "subset_of": [ "code" ], "essential": true }, "response_modes_supported": { "subset_of": [ "form_post", "query" ], "superset_of": [ "form_post", "query" ], "essential": true }, "grant_types_supported": { "subset_of": [ "authorization_code", "refresh_token" ], "superset_of": [ "authorization_code", "refresh_token" ], "essential": true }, "acr_values_supported": { "subset_of": [ "https://www.spid.gov.it/SpidL1", "https://www.spid.gov.it/SpidL2", "https://www.spid.gov.it/SpidL3" ], "superset_of": [ "https://www.spid.gov.it/SpidL1", "https://www.spid.gov.it/SpidL2", "https://www.spid.gov.it/SpidL3" ], "essential": true }, "subject_types_supported": { "subset_of": [ "pairwise" ], "essential": true }, "id_token_signing_alg_values_supported": { "subset_of": [ "RS256", "RS512", "ES256", "ES512", "PS256", "PS512" ], "superset_of": [ "RS256", "RS512", "ES256", "ES512", "PS256", "PS512" ], "essential": true }, "id_token_encryption_alg_values_supported": { "subset_of": [ "RSA-OAEP", "RSA-OAEP-256", "ECDH-ES", "ECDH-ES+A128KW", "ECDH-ES+A256KW" ], "superset_of": [ "RSA-OAEP", "RSA-OAEP-256", "ECDH-ES", "ECDH-ES+A128KW", "ECDH-ES+A256KW" ], "essential": true }, "id_token_encryption_enc_values_supported": { "subset_of": [ "A128CBC-HS256", "A256CBC-HS512" ], "superset_of": [ "A128CBC-HS256", "A256CBC-HS512" ], "essential": true }, "userinfo_signing_alg_values_supported": { "subset_of": [ "RS256", "RS512", "ES256", "ES512", "PS256", "PS512" ], "superset_of": [ "RS256", "RS512", "ES256", "ES512", "PS256", "PS512" ], "essential": true }, "userinfo_encryption_alg_values_supported": { "subset_of": [ "RSA-OAEP", "RSA-OAEP-256", "ECDH-ES", "ECDH-ES+A128KW", "ECDH-ES+A256KW" ], "superset_of": [ "RSA-OAEP", "RSA-OAEP-256", "ECDH-ES", "ECDH-ES+A128KW", "ECDH-ES+A256KW" ], "essential": true }, "userinfo_encryption_enc_values_supported": { "subset_of": [ "A128CBC-HS256", "A256CBC-HS512" ], "superset_of": [ "A128CBC-HS256", "A256CBC-HS512" ], "essential": true }, "token_endpoint_auth_methods_supported": { "subset_of": [ "private_key_jwt" ], "essential": true }, "token_endpoint_auth_signing_alg_values_supported": { "subset_of": [ "RS256", "RS512", "ES256", "ES512", "PS256", "PS512" ], "superset_of": [ "RS256", "RS512", "ES256", "ES512", "PS256", "PS512" ], "essential": true }, "claims_parameter_supported": { "value": true }, "request_parameter_supported": { "value": true }, "authorization_response_iss_parameter_supported": { "value": true }, "client_registration_types_supported": { "subset_of": [ "automatic" ], "essential": true }, "request_authentication_methods_supported": { "value": { "authorization_endpoint": [ "request_object" ] } }, "request_authentication_signing_alg_values_supported": { "subset_of": [ "RS256", "RS512", "ES256", "ES512", "PS256", "PS512" ], "superset_of": [ "RS256", "RS512", "ES256", "ES512", "PS256", "PS512" ], "essential": true }, "request_object_signing_alg_values_supported": { "subset_of": [ "RS256", "RS512", "ES256", "ES512", "PS256", "PS512" ], "superset_of": [ "RS256", "RS512", "ES256", "ES512", "PS256", "PS512" ], "essential": true }, "issuer": { "essential": true }, "authorization_endpoint": { "essential": true }, "token_endpoint": { "essential": true }, "userinfo_endpoint": { "essential": true }, "introspection_endpoint": { "essential": true }, "revocation_endpoint": { "essential": true } } } ...
-
italia
Diventa fornitore di servizi
Qui di seguito riportiamo gli indirizzi di riferimento per le procedure di "onboarding" di SPID e CIE, cioè per diventare fornitori di servizi. Come diventare fornitori di servizi CIE ...
-
italia
Riferimenti
DM-CIE. DM 23 December 2015 n.210: "Modalità tecniche di emissione della Carta d'identità elettronica." (15A09809) (GU Serie Generale n.302 30-12-2015) ...
-
italia
Le Federazioni eID Italiane
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 ...
-
italia
Algoritmi crittografici
Tutti i partecipanti devono pubblicare gli algoritmi supportati di criptazione e firma all'interno dei propri metadata. Tali agoritmi sono utilizzati per tutte le operazioni di cifratura e firma previsti da OIDC core e di Federation. La lunghezza delle chiavi RSA deve essere pari o superiore a 2048 bit. Si raccomanda una lunghezza di 4096 bit. In SPID e CIE id i seguenti algoritmi DEVONO essere supportati:. Operazioni. Riferimento. Supportato da. RS256. Signature. OpenID.Core and RFC7518. RS512. Signature. RFC7518. RSA-OAEP. Key Encryption. RFC7518. RSA-OAEP-256. Key Encryption. RFC7516. A128CBC-HS256. Content Encryption. RFC7516. A256CBC-HS512. Content Encryption. RFC7516. In SPID e CIE id è RACCOMANDATO il supporto per i seguenti algoritmi:. Operazioni. Riferimento. Applicabile a. ES256. Signature. OpenID.Core and RFC7518. ES512. Signature. RFC7518. PS256. Signature. RFC7518. PS512. Signature. RFC7518. ECDH-ES. Key Encryption. RFC7518. ECDH-ES+A128KW. Key Encryption. RFC7518. ECDH-ES+A256KW. Key Encryption. RFC7518. In SPID e CIE id i seguenti algoritmi NON DEVONO essere supportati:. Operazioni. Riferimenti. Applicabile a. none. Signature. RFC7518. RSA_1_5. Key Encryption. RFC7516. HS256. Signature. RFC7518. HS384. Signature. RFC7518. HS512. Signature. RFC7518 ...
-
italia
Acquisire i Metadata
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 ...
-
italia
Differenze con OIDC iGov
CIE OpenID Connect e SPID OpenID Connect sono basati su iGov.OIDC con le seguenti differenze:. L'Authentication Response nel flusso di autenticazione di CIE impone l'uso del claim iss per evitare l'attacco mix-up I-D.ietf-OAuth-Security-BCP. L'uso di questo claim è OPZIONALE in SPID. La sezione 2.4 di iGov stabilisce "Gli RP POSSONO opzionalmente mandare richieste all'Authorization Endpoint usando il parametro request." Sia in SPID che in CIE id, l'uso del parametro request è RICHIESTO. La sezione 3.1 di iGov stabilisce che "in caso di utilizzo di vtr nella richiesta di autenticazione, l'ID Token DEVE contenere i seguenti claim RICHIESTI, cioè: vot e vtm ". Considerando che vtr non è usato in SPID e CIE id, i claim appena citati non vengono inclusi all'interno dell'ID Token. La sezione 3.1 di iGov stabilisce che "il claim auth-time nell'ID Token è RACCOMANDATO". SPID e CIE id non adottano questo claim nell'ID Token. L'ID Token, sia in SPID che in CIE id, DEVE avere il claim acr RICHIESTO, mentre questo è opzionale nell'iGov draft iGov. L'ID Token, sia in SPID che in CIE id, ha il requisito del claim at_hash RICHIESTO. Questo è OPZIONALE in OIDC-CORE è assente in iGOV. Sia in SPID che in CIE id, l'identificatore del soggetto DEVE essere pairwised. La UserInfo Response, sia in SPID che in CIE id, DEVE essere un Nested JWT, firmato con la chiave privata dell'emettitore e cifrato con la chiave pubblica del RP. Il JWT firmato della UserInfo Response DEVE avere i claim iss, sub, aud, iat e exp. La sezione 3.4 di iGov stabilisce "Gli OpenID Provider POSSONO accettare oggetti request by reference usando il parametro request_uri". Questo parametro è intercambiabile con il parametro request. SPID e CIE id adottano solamente il parametro request. Sezione 3.8. La registrazione dinamica di iGOV specifica che la registrazione dinamica del client è obbligatoria. Sia in CIE id che in SPID, la registrazione automatica OIDC del client è OBBLIGATORIA, mentre la registrazione dinamica OIDC del client NON DOVREBBE essere supportata. Nella sezione 4.2 di iGOV gli scope openid, offline_access, profile e email vengono usati in CIE id OpenID Connect proposal e non considerano gli altri scope raccomandati nel profilo iGov, cioè: doc. Nella sezione 4.2 di iGOV gli scope openid, offline_access vengono usati in SPID OpenID Connect proposal e non considerano gli altri scope raccomandati nel profilo iGov, cioè: doc. La sezione 4.3 di iGov definisce la politica relativa all'oggetto userinfo del claim request. In CIE id, definiamo la politica per entrambi gli oggetti userinfo e ID Token. Nelle sezioni 3.7 e 2.5 di iGOV, i Metadata sia di SPID che di CIE id vengono distribuiti secondo le modalità definite nella sezione "3. Metadata". L'Access Token è un JWT firmato in conformità a RFC 9068 ...
-
italia
Metadata di Trust Anchor (TA) e Intermediari (SA)
Un TA e un SA DEVONO pubblicare all'interno del loro EC un Metadata da federation_entity come riportato nel seguente esempio:. L'EC di un TA e di SA DEVE configurare un metadata di tipo "federation_entity" e contenere almeno i seguenti parametri obbligatori:. Descrizione. Supportato da. organization_name. Vedi Sezione 4.8 di OIDC-FED. homepage_uri. Vedi Sezione 4.8 di OIDC-FED. policy_uri. Vedi Sezione 4.8 di OIDC-FED. logo_uri. URL del logo dell'entità; DEVE essere in formato SVG. Vedi Sezione 4.8 di OIDC-FED. contacts. PEC istituzionale dell'ente. Vedi Sezione 4.8 di OIDC-FED. federation_fetch_endpoint. Vedi Sezione Endpoint di Federazione e OIDC-FED Section 4.8. federation_list_endpoint. Vedi Sezione Endpoint di Federazione e OIDC-FED Section 4.8. federation_trust_mark_status_endpoint. Vedi Sezione Endpoint di Federazione e OIDC-FED Section 4.8. federation_resolve_endpoint. Vedi Sezione Endpoint di Federazione e OIDC-FED Section 4.8. Esempio di EC di un OP e di un SA SA ...
-
italia
Soggetti Aggregatori
Un SA può registrare RP preesistenti e già conformi allo standard OIDC-FED, afferenti a domini esterni al proprio oppure mascherare dietro di sé i propri discendenti. Nel primo caso il SA è di tipo Trasparente (Aggregatore Light) mentre nel secondo caso è di tipo Proxy (Aggregatore Full). I SA Light registrano RP preesistenti e conformi a OIDC-FED e pubblicano gli ES a questi riferiti. I SA Full provvedono a costruire una interfaccia di autenticazione e federazione per conto dei propri aggregati, mediante risorse web solitamente esposte all'interno del proprio dominio. Questa tipologia di Aggregatore espone le seguenti risorse per ogni suo aggregato:. Authorization callback endpoint per l'acquisizione dell'auth code da parte del OP (redirect_uri). Il SA di tipo Full DEVE aggiungere almeno uno dei codici identificativi presenti nell'id_code (così come definito nella Sezione Composizione dei Trust Mark), all'interno del web path che compone il client_id, questo identifica univocamente all'interno della federazione l'aggregato
/ /. Se sono disponibili più di un codice identificativo, il SA PUÒ riportarli nel web path come nel seguente esempio: /ipa_code/aoo_code/. Nella seguente tabella sono presenti alcuni esempi non normativi per evidenziare le differenze tra gli aggregati Light e Full:. Modalità Full. client_id. https://www.rp.it/. https://www.sa.it/ /. redirect_uri. https://www.rp.it/callback/. https://www.sa.it/ /callback/. authorization endpoint. https://www.rp.it/authorization/. https://www.sa.it/ /authorization/. Entity Configuration. https://www.rp.it/.well-known/openid-federation. https://www.sa.it/ /.well-known/openid-federation ... -
italia
OpenID Connect Relying Party Metadata (RP)
Un RP DEVE pubblicare all'interno del suo EC un Metadata di tipo federation_entity e uno di tipo openid_relying_party come riportato nel seguente esempio:. Il Metadata di tipo "federation_entity" DEVE contenere almeno i seguenti parametri obbligatori:. Descrizione. Supportato da. organization_name. Vedi Sezione 4.8 di OIDC-FED. homepage_uri. Vedi Sezione 4.8 di OIDC-FED. policy_uri. Vedi Sezione 4.8 di OIDC-FED. logo_uri. (RACCOMANDATO) URL del logo dell'entità; DEVE essere in formato SVG. Vedi Sezione 4.8 di OIDC-FED. contacts. PEC istituzionale dell'ente. Vedi Sezione 4.8 di OIDC-FED. federation_resolve_endpoint. Vedi Sezione Endpoint di Federazione e OIDC-FED Section 4.6. Il Metadata di tipo "openid_relying_party" DEVE contenere almeno i seguenti parametri obbligatori:. Descrizione. Supportato da. redirect_uris. Vedi OpenID.Registration#ClientMetadata. È obbligatorio l'uso dello schema HTTPS nel caso di client web-based. grant_types. Vedi OpenID.Registration#ClientMetadata. I valori ammissibili authorization_code e refresh_token. jwks. Vedi OpenID.Registration#ClientMetadata e JWK. signed_jwks_uri. Vedi OIDC-FED. id_token_signed_response_alg. Vedi OpenID.Registration#ClientMetadata. Vedi signature Algoritmi crittografici. id_token_encrypted_response_alg. OPZIONALE. Se presente, l'OP DEVE restituire l'ID Token firmato e cifrato. Vedi OpenID.Registration#ClientMetadata. Vedi key encryption Algoritmi crittografici. id_token_encrypted_response_enc. Vedi OpenID.Registration#ClientMetadata. Obbligatorio solo nel caso sia presente anche il parametro id_token_encrypted_response_alg. Vedi content encryption Algoritmi crittografici. userinfo_signed_response_alg. Vedi OpenID.Registration#ClientMetadata. Vedi signature Algoritmi crittografici. userinfo_encrypted_response_alg. Vedi OpenID.Registration#ClientMetadata. Vedi key encryption Algoritmi crittografici. userinfo_encrypted_response_enc. Vedi OpenID.Registration#ClientMetadata. Vedi content encryption Algoritmi crittografici. token_endpoint_auth_method. Vedi OpenID.Registration#ClientMetadata. Il valore richiesto è private_key_jwt. client_id. Vedi OpenID.Registration. DEVE essere valorizzato con un HTTPS URL che identifica univocamente il RP. client_registration_types. Vedi OIDC-FED Section 4.1. Il valore richiesto è automatic. response_types. Array dei valori di response_type previsti da OAuth 2.0 che il RP userà nelle richieste di autenticazione. Deve contenere il valore code. Gli URI presenti nel parametro redirect_uris POSSONO anche usare eventuali schemi custom (ad es. myapp://) al fine di supportare applicazioni mobili. Il Metadata "openid_relying_party" DEVE adottare il parametro jwks. Il Metadata "openid_relying_party" DEVE adottare il parametro jwks o signed_jwks_uri ...
-
italia
Retention Policy
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. Avvertimento. Le chiavi che non sono sono più attive da più di 24 mesi POSSONO essere rimosse dal registro a discrezione del TA ...