1. Introduction
Cette spécification généralise le format de métadonnées (Metadata) défini par "OpenID Connect Discovery 1.0" [OpenID.Discovery] de manière à ce qu'il soit compatible avec OpenID Connect Discovery tout en étant applicable à une gamme plus large de cas d'utilisation OAuth 2.0. Cela est intentionnellement cohérent avec la manière dont "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591] généralise le mécanisme d'enregistrement dynamique de client défini par "OpenID Connect Dynamic Client Registration 1.0" [OpenID.Registration] de manière à être compatible avec ce dernier.
Les métadonnées du serveur d'autorisation (Authorization Server) sont récupérées depuis un emplacement bien connu (well-known) sous forme de document JSON [RFC8259] qui déclare les emplacements de ses points de terminaison (Endpoint) et les capacités du serveur d'autorisation. Ce processus est décrit dans la section 3.
Ces métadonnées peuvent être communiquées de manière auto-affirmée (self-asserted) depuis l'origine du serveur (server origin) via HTTPS, ou comme un ensemble de valeurs de métadonnées signées représentées en tant que revendications (claim) dans un JSON Web Token (JWT) [JWT]. Dans le cas du JWT, l'émetteur (issuer) se porte garant de la validité des données concernant le serveur d'autorisation. Cela est similaire au rôle que jouent les déclarations logicielles (Software Statement) dans l'enregistrement dynamique de client OAuth [RFC7591].
La manière dont un client (Client) choisit un serveur d'autorisation est hors de la portée de cette spécification. Dans certains cas, son identifiant d'émetteur (issuer identifier) peut être configuré manuellement dans le client. Dans d'autres cas, il peut être découvert dynamiquement, par exemple en utilisant WebFinger [RFC7033], comme décrit dans la section 2 de "OpenID Connect Discovery 1.0" [OpenID.Discovery].
1.1. Requirements Notation and Conventions (Notation et conventions des exigences)
Les mots-clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans BCP 14 [RFC2119] [RFC8174] lorsque, et seulement lorsque, ils apparaissent en majuscules, comme indiqué ici.
Toutes les utilisations des structures de données JSON Web Signature (JWS) [JWS] et JSON Web Encryption (JWE) [JWE] dans cette spécification utilisent la JWS Compact Serialization ou la JWE Compact Serialization. Les JWS JSON Serialization et JWE JSON Serialization ne sont pas utilisées.
1.2. Terminology (Terminologie)
Cette spécification utilise les termes suivants définis par OAuth 2.0 [RFC6749] : "Access Token (jeton d'accès)", "Authorization Code (code d'autorisation)", "Authorization Endpoint (point de terminaison d'autorisation)", "Authorization Grant (autorisation)", "Authorization Server (serveur d'autorisation)", "Client", "Client Authentication (authentification du client)", "Client Identifier (identifiant du client)", "Client Secret (secret du client)", "Grant Type (type d'autorisation)", "Protected Resource (ressource protégée)", "Redirection URI (URI de redirection)", "Refresh Token (jeton de rafraîchissement)", "Resource Owner (propriétaire de la ressource)", "Resource Server (serveur de ressources)", "Response Type (type de réponse)" et "Token Endpoint (point de terminaison de jeton)". Les termes définis par JSON Web Token (JWT) [JWT] : "Claim Name (nom de revendication)", "Claim Value (valeur de revendication)" et "JSON Web Token (JWT)". Le terme défini par "OAuth 2.0 Multiple Response Type Encoding Practices" [OAuth.Responses] : "Response Mode (mode de réponse)".