1. Introduction (Einführung)
Diese Spezifikation verallgemeinert das von "OpenID Connect Discovery 1.0" [OpenID.Discovery] definierte Metadatenformat (Metadata) so, dass es mit OpenID Connect Discovery kompatibel ist und gleichzeitig auf eine breitere Palette von OAuth 2.0-Anwendungsfällen anwendbar ist. Dies steht bewusst im Einklang mit der Art und Weise, wie "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591] den von "OpenID Connect Dynamic Client Registration 1.0" [OpenID.Registration] definierten dynamischen Client-Registrierungsmechanismus verallgemeinert, um mit letzterem kompatibel zu sein.
Die Metadaten des Autorisierungsservers (Authorization Server) werden von einem bekannten (well-known) Ort als JSON [RFC8259]-Dokument abgerufen, das die Positionen seiner Endpunkte (Endpoint) und die Fähigkeiten des Autorisierungsservers deklariert. Dieser Prozess wird in Abschnitt 3 beschrieben.
Diese Metadaten können auf selbstbehauptende (self-asserted) Weise vom Serverursprung (server origin) über HTTPS übermittelt werden oder als Satz signierter Metadatenwerte, die als Ansprüche (claim) in einem JSON Web Token (JWT) [JWT] dargestellt werden. Im Fall von JWT bürgt der Aussteller (issuer) für die Gültigkeit der Daten über den Autorisierungsserver. Dies ist ähnlich der Rolle, die Software Statements in der dynamischen OAuth-Client-Registrierung [RFC7591] spielen.
Wie ein Client (Client) einen Autorisierungsserver auswählt, liegt außerhalb des Umfangs dieser Spezifikation. In einigen Fällen kann sein Aussteller-Identifikator (issuer identifier) manuell im Client konfiguriert werden. In anderen Fällen kann er dynamisch entdeckt werden, beispielsweise unter Verwendung von WebFinger [RFC7033], wie in Abschnitt 2 von "OpenID Connect Discovery 1.0" [OpenID.Discovery] beschrieben.
1.1. Requirements Notation and Conventions (Anforderungsnotation und Konventionen)
Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind wie in BCP 14 [RFC2119] [RFC8174] beschrieben zu interpretieren, wenn und nur wenn sie in Großbuchstaben erscheinen, wie hier gezeigt.
Alle Verwendungen von JSON Web Signature (JWS) [JWS] und JSON Web Encryption (JWE) [JWE] Datenstrukturen in dieser Spezifikation verwenden die JWS Compact Serialization oder die JWE Compact Serialization. Die JWS JSON Serialization und JWE JSON Serialization werden nicht verwendet.
1.2. Terminology (Terminologie)
Diese Spezifikation verwendet die folgenden von OAuth 2.0 [RFC6749] definierten Begriffe: "Access Token (Zugriffstoken)", "Authorization Code (Autorisierungscode)", "Authorization Endpoint (Autorisierungsendpunkt)", "Authorization Grant (Autorisierungsberechtigung)", "Authorization Server (Autorisierungsserver)", "Client", "Client Authentication (Client-Authentifizierung)", "Client Identifier (Client-Identifikator)", "Client Secret (Client-Geheimnis)", "Grant Type (Berechtigungstyp)", "Protected Resource (geschützte Ressource)", "Redirection URI (Umleitungs-URI)", "Refresh Token (Aktualisierungstoken)", "Resource Owner (Ressourcenbesitzer)", "Resource Server (Ressourcenserver)", "Response Type (Antworttyp)" und "Token Endpoint (Token-Endpunkt)". Die von JSON Web Token (JWT) [JWT] definierten Begriffe: "Claim Name (Anspruchsname)", "Claim Value (Anspruchswert)" und "JSON Web Token (JWT)". Den von "OAuth 2.0 Multiple Response Type Encoding Practices" [OAuth.Responses] definierten Begriff: "Response Mode (Antwortmodus)".