1. Introduction (Introduzione)
Questa specifica generalizza il formato di metadati (Metadata) definito da "OpenID Connect Discovery 1.0" [OpenID.Discovery] in modo che sia compatibile con OpenID Connect Discovery pur essendo applicabile a una gamma più ampia di casi d'uso OAuth 2.0. Questo è intenzionalmente coerente con il modo in cui "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591] generalizza il meccanismo di registrazione dinamica del client definito da "OpenID Connect Dynamic Client Registration 1.0" [OpenID.Registration] in modo da essere compatibile con quest'ultimo.
I metadati del server di autorizzazione (Authorization Server) vengono recuperati da una posizione nota (well-known) come documento JSON [RFC8259] che dichiara le posizioni dei suoi endpoint (Endpoint) e le capacità del server di autorizzazione. Questo processo è descritto nella sezione 3.
Questi metadati possono essere comunicati in modo auto-affermato (self-asserted) dall'origine del server (server origin) tramite HTTPS, oppure come un insieme di valori di metadati firmati rappresentati come rivendicazioni (claim) in un JSON Web Token (JWT) [JWT]. Nel caso di JWT, l'emittente (issuer) garantisce la validità dei dati relativi al server di autorizzazione. Questo è simile al ruolo che le dichiarazioni software (Software Statement) svolgono nella registrazione dinamica del client OAuth [RFC7591].
Il modo in cui un client (Client) sceglie un server di autorizzazione è al di fuori dell'ambito di questa specifica. In alcuni casi, il suo identificatore dell'emittente (issuer identifier) può essere configurato manualmente nel client. In altri casi, può essere scoperto dinamicamente, ad esempio utilizzando WebFinger [RFC7033], come descritto nella sezione 2 di "OpenID Connect Discovery 1.0" [OpenID.Discovery].
1.1. Requirements Notation and Conventions (Notazione e convenzioni dei requisiti)
Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto in BCP 14 [RFC2119] [RFC8174] quando, e solo quando, appaiono in maiuscolo, come mostrato qui.
Tutti gli usi delle strutture dati JSON Web Signature (JWS) [JWS] e JSON Web Encryption (JWE) [JWE] in questa specifica utilizzano la JWS Compact Serialization o la JWE Compact Serialization. Le JWS JSON Serialization e JWE JSON Serialization non vengono utilizzate.
1.2. Terminology (Terminologia)
Questa specifica utilizza i seguenti termini definiti da OAuth 2.0 [RFC6749]: "Access Token (token di accesso)", "Authorization Code (codice di autorizzazione)", "Authorization Endpoint (endpoint di autorizzazione)", "Authorization Grant (concessione di autorizzazione)", "Authorization Server (server di autorizzazione)", "Client", "Client Authentication (autenticazione del client)", "Client Identifier (identificatore del client)", "Client Secret (segreto del client)", "Grant Type (tipo di concessione)", "Protected Resource (risorsa protetta)", "Redirection URI (URI di reindirizzamento)", "Refresh Token (token di aggiornamento)", "Resource Owner (proprietario della risorsa)", "Resource Server (server di risorse)", "Response Type (tipo di risposta)" e "Token Endpoint (endpoint dei token)". I termini definiti da JSON Web Token (JWT) [JWT]: "Claim Name (nome della rivendicazione)", "Claim Value (valore della rivendicazione)" e "JSON Web Token (JWT)". Il termine definito da "OAuth 2.0 Multiple Response Type Encoding Practices" [OAuth.Responses]: "Response Mode (modalità di risposta)".