[要約] RFC 8414は、OAuth 2.0認可サーバーメタデータの標準化を目的としています。このRFCは、認可サーバーの機能、エンドポイント、サポートされる機能などの情報を提供し、クライアントが認可サーバーとのインタラクションを容易にすることを目指しています。
Internet Engineering Task Force (IETF) M. Jones
Request for Comments: 8414 Microsoft
Category: Standards Track N. Sakimura
ISSN: 2070-1721 NRI
J. Bradley
Yubico
June 2018
OAuth 2.0 Authorization Server Metadata
OAuth 2.0 Authorization Serverメタデータ
Abstract
概要
This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities.
この仕様は、OAuth 2.0クライアントがOAuth 2.0承認サーバーとのやり取りに必要な情報（エンドポイントの場所や承認サーバーの機能など）を取得するために使用できるメタデータ形式を定義しています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8414.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8414で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Requirements Notation and Conventions ......................3
1.2. Terminology ................................................3
2. Authorization Server Metadata ...................................4
2.1. Signed Authorization Server Metadata .......................8
3. Obtaining Authorization Server Metadata .........................8
3.1. Authorization Server Metadata Request ......................9
3.2. Authorization Server Metadata Response ....................10
3.3. Authorization Server Metadata Validation ..................11
4. String Operations ..............................................11
5. Compatibility Notes ............................................11
6. Security Considerations ........................................12
6.1. TLS Requirements ..........................................12
6.2. Impersonation Attacks .....................................12
6.3. Publishing Metadata in a Standard Format ..................13
6.4. Protected Resources .......................................13
7. IANA Considerations ............................................14
7.1. OAuth Authorization Server Metadata Registry ..............14
7.1.1. Registration Template ..............................15
7.1.2. Initial Registry Contents ..........................16
7.2. Updated Registration Instructions .........................19
7.3. Well-Known URI Registry ...................................19
7.3.1. Registry Contents ..................................19
8. References .....................................................20
8.1. Normative References ......................................20
8.2. Informative References ....................................22
Acknowledgements ..................................................23
Authors' Addresses ................................................23
This specification generalizes the metadata format defined by "OpenID Connect Discovery 1.0" [OpenID.Discovery] in a way that is compatible with OpenID Connect Discovery while being applicable to a wider set of OAuth 2.0 use cases. This is intentionally parallel to the way that "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591] generalized the dynamic client registration mechanisms defined by "OpenID Connect Dynamic Client Registration 1.0" [OpenID.Registration] in a way that is compatible with it.
この仕様は、「OpenID Connect Discovery 1.0」[OpenID.Discovery]によって定義されたメタデータ形式を、OpenID Connect Discoveryと互換性のある方法で一般化し、OAuth 2.0の幅広いユースケースに適用できます。これは、「OAuth 2.0動的クライアント登録プロトコル」[RFC7591]が「OpenID Connect動的クライアント登録1.0」[OpenID.Registration]で定義された動的クライアント登録メカニズムを互換性のある方法で一般化した方法と意図的に並行しています。
The metadata for an authorization server is retrieved from a well-known location as a JSON [RFC8259] document, which declares its endpoint locations and authorization server capabilities. This process is described in Section 3.
承認サーバーのメタデータは、よく知られている場所から、エンドポイントの場所と承認サーバーの機能を宣言するJSON [RFC8259]ドキュメントとして取得されます。このプロセスについては、セクション3で説明します。
This metadata can be communicated either in a self-asserted fashion by the server origin via HTTPS or as a set of signed metadata values represented as claims in a JSON Web Token (JWT) [JWT]. In the JWT case, the issuer is vouching for the validity of the data about the authorization server. This is analogous to the role that the Software Statement plays in OAuth Dynamic Client Registration [RFC7591].
このメタデータは、HTTPSを介してサーバーオリジンによって自己表明された方法で、またはJSON Web Token（JWT）[JWT]のクレームとして表された署名済みメタデータ値のセットとして通信できます。 JWTの場合、発行者は認証サーバーに関するデータの有効性を保証しています。これは、OAuth動的クライアント登録[RFC7591]でソフトウェアステートメントが果たす役割に似ています。
The means by which the client chooses an authorization server is out of scope. In some cases, its issuer identifier may be manually configured into the client. In other cases, it may be dynamically discovered, for instance, through the use of WebFinger [RFC7033], as described in Section 2 of "OpenID Connect Discovery 1.0" [OpenID.Discovery].
クライアントが許可サーバーを選択する方法は範囲外です。場合によっては、その発行者IDを手動でクライアントに構成できます。他の場合では、「OpenID Connect Discovery 1.0」[OpenID.Discovery]のセクション2で説明されているように、たとえばWebFinger [RFC7033]を使用して動的に検出される場合があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
All uses of JSON Web Signature (JWS) [JWS] and JSON Web Encryption (JWE) [JWE] data structures in this specification utilize the JWS Compact Serialization or the JWE Compact Serialization; the JWS JSON Serialization and the JWE JSON Serialization are not used.
この仕様におけるJSON Web Signature（JWS）[JWS]およびJSON Web Encryption（JWE）[JWE]データ構造のすべての使用は、JWS Compact SerializationまたはJWE Compact Serializationを利用します。 JWS JSONシリアライゼーションとJWE JSONシリアライゼーションは使用されません。
This specification uses the terms "Access Token", "Authorization Code", "Authorization Endpoint", "Authorization Grant", "Authorization Server", "Client", "Client Authentication", "Client Identifier", "Client Secret", "Grant Type", "Protected Resource", "Redirection URI", "Refresh Token", "Resource Owner", "Resource Server", "Response Type", and "Token Endpoint" defined by OAuth 2.0 [RFC6749]; the terms "Claim Name", "Claim Value", and "JSON Web Token (JWT)" defined by JSON Web Token (JWT) [JWT]; and the term "Response Mode" defined by "OAuth 2.0 Multiple Response Type Encoding Practices" [OAuth.Responses].
この仕様では、「アクセストークン」、「認証コード」、「認証エンドポイント」、「認証付与」、「認証サーバー」、「クライアント」、「クライアント認証」、「クライアント識別子」、「クライアントシークレット」、「 OAuth 2.0 [RFC6749]で定義されている「付与タイプ」、「保護されたリソース」、「リダイレクトURI」、「トークンの更新」、「リソース所有者」、「リソースサーバー」、「応答タイプ」、および「トークンエンドポイント」。 JSON Web Token（JWT）[JWT]で定義されている「Claim Name」、「Claim Value」、および「JSON Web Token（JWT）」という用語。また、「OAuth 2.0多重応答タイプエンコーディングプラクティス」[OAuth.Responses]で定義されている「応答モード」という用語。
Authorization servers can have metadata describing their configuration. The following authorization server metadata values are used by this specification and are registered in the IANA "OAuth Authorization Server Metadata" registry established in Section 7.1:
承認サーバーは、構成を説明するメタデータを持つことができます。次の承認サーバーメタデータ値はこの仕様で使用され、セクション7.1で確立されたIANA「OAuth承認サーバーメタデータ」レジストリに登録されます。
issuer REQUIRED. The authorization server's issuer identifier, which is a URL that uses the "https" scheme and has no query or fragment components. Authorization server metadata is published at a location that is ".well-known" according to RFC 5785 [RFC5785] derived from this issuer identifier, as described in Section 3. The issuer identifier is used to prevent authorization server mix-up attacks, as described in "OAuth 2.0 Mix-Up Mitigation" [MIX-UP].
発行者が必要です。承認サーバーの発行者識別子。これは、「https」スキームを使用し、クエリやフラグメントコンポーネントを持たないURLです。承認サーバーのメタデータは、セクション3で説明されているように、この発行者識別子から派生したRFC 5785 [RFC5785]に従って「.well-known」である場所に発行されます。発行者識別子は、次のように、承認サーバーの混合攻撃を防ぐために使用されます。 「OAuth 2.0の混合の軽減」[MIX-UP]で説明されています。
authorization_endpoint URL of the authorization server's authorization endpoint [RFC6749]. This is REQUIRED unless no grant types are supported that use the authorization endpoint.
authorization_endpoint許可サーバーの許可エンドポイントのURL [RFC6749]。承認エンドポイントを使用する許可タイプがサポートされていない場合を除き、これは必須です。
token_endpoint URL of the authorization server's token endpoint [RFC6749]. This is REQUIRED unless only the implicit grant type is supported.
token_endpoint承認サーバーのトークンエンドポイントのURL [RFC6749]。暗黙の付与タイプのみがサポートされていない限り、これは必須です。
jwks_uri OPTIONAL. URL of the authorization server's JWK Set [JWK] document. The referenced document contains the signing key(s) the client uses to validate signatures from the authorization server. This URL MUST use the "https" scheme. The JWK Set MAY also contain the server's encryption key or keys, which are used by clients to encrypt requests to the server. When both signing and encryption keys are made available, a "use" (public key use) parameter value is REQUIRED for all keys in the referenced JWK Set to indicate each key's intended usage.
jwks_uriオプション。許可サーバーのJWKセット[JWK]ドキュメントのURL。参照されるドキュメントには、クライアントが承認サーバーからの署名を検証するために使用する署名キーが含まれています。このURLは「https」スキームを使用する必要があります。 JWKセットには、クライアントがサーバーへのリクエストを暗号化するために使用するサーバーの暗号化キーも含まれる場合があります。署名キーと暗号化キーの両方を使用できるようにすると、参照されるJWKセット内のすべてのキーに「使用」（公開キーの使用）パラメータ値が必要になり、各キーの使用目的を示します。
registration_endpoint OPTIONAL. URL of the authorization server's OAuth 2.0 Dynamic Client Registration endpoint [RFC7591].
registration_endpointオプション。承認サーバーのOAuth 2.0動的クライアント登録エンドポイントのURL [RFC7591]。
scopes_supported RECOMMENDED. JSON array containing a list of the OAuth 2.0 [RFC6749] "scope" values that this authorization server supports. Servers MAY choose not to advertise some supported scope values even when this parameter is used.
scopes_supported推奨。この認証サーバーがサポートするOAuth 2.0 [RFC6749]の「スコープ」値のリストを含むJSON配列。サーバーは、このパラメーターが使用されている場合でも、サポートされている一部のスコープ値を通知しないことを選択できます。
response_types_supported REQUIRED. JSON array containing a list of the OAuth 2.0 "response_type" values that this authorization server supports. The array values used are the same as those used with the "response_types" parameter defined by "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591].
response_types_supported必須です。この認証サーバーがサポートするOAuth 2.0の "response_type"値のリストを含むJSON配列。使用される配列値は、「OAuth 2.0 Dynamic Client Registration Protocol」[RFC7591]で定義されている「response_types」パラメーターで使用されるものと同じです。
response_modes_supported OPTIONAL. JSON array containing a list of the OAuth 2.0 "response_mode" values that this authorization server supports, as specified in "OAuth 2.0 Multiple Response Type Encoding Practices" [OAuth.Responses]. If omitted, the default is "["query", "fragment"]". The response mode value "form_post" is also defined in "OAuth 2.0 Form Post Response Mode" [OAuth.Post].
response_modes_supportedオプション。この認証サーバーがサポートするOAuth 2.0の "response_mode"値のリストを含むJSON配列。「OAuth 2.0多重応答タイプエンコーディングプラクティス」[OAuth.Responses]で指定されています。省略した場合、デフォルトは "[" query "、" fragment "]"です。応答モードの値「form_post」は、「OAuth 2.0フォームポスト応答モード」[OAuth.Post]でも定義されています。
grant_types_supported OPTIONAL. JSON array containing a list of the OAuth 2.0 grant type values that this authorization server supports. The array values used are the same as those used with the "grant_types" parameter defined by "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591]. If omitted, the default value is "["authorization_code", "implicit"]".
grant_types_supportedオプション。この許可サーバーがサポートするOAuth 2.0付与タイプ値のリストを含むJSON配列。使用される配列値は、「OAuth 2.0 Dynamic Client Registration Protocol」[RFC7591]で定義されている「grant_types」パラメーターで使用されるものと同じです。省略した場合、デフォルト値は "[" authorization_code "、" implicit "]"です。
token_endpoint_auth_methods_supported OPTIONAL. JSON array containing a list of client authentication methods supported by this token endpoint. Client authentication method values are used in the "token_endpoint_auth_method" parameter defined in Section 2 of [RFC7591]. If omitted, the default is "client_secret_basic" -- the HTTP Basic Authentication Scheme specified in Section 2.3.1 of OAuth 2.0 [RFC6749].
token_endpoint_auth_methods_supportedオプション。このトークンエンドポイントでサポートされるクライアント認証方法のリストを含むJSON配列。クライアント認証方法の値は、[RFC7591]のセクション2で定義されている「token_endpoint_auth_method」パラメータで使用されます。省略した場合、デフォルトは "client_secret_basic"-OAuth 2.0 [RFC6749]のセクション2.3.1で指定されたHTTP基本認証スキームです。
token_endpoint_auth_signing_alg_values_supported OPTIONAL. JSON array containing a list of the JWS signing algorithms ("alg" values) supported by the token endpoint for the signature on the JWT [JWT] used to authenticate the client at the token endpoint for the "private_key_jwt" and "client_secret_jwt" authentication methods. This metadata entry MUST be present if either of these authentication methods are specified in the "token_endpoint_auth_methods_supported" entry. No default algorithms are implied if this entry is omitted. Servers SHOULD support "RS256". The value "none" MUST NOT be used.
token_endpoint_auth_signing_alg_values_supportedオプション。 「private_key_jwt」および「client_secret_jwt」認証方式のトークンエンドポイントでクライアントを認証するために使用されるJWT [JWT]の署名のトークンエンドポイントでサポートされるJWS署名アルゴリズム（「alg」値）のリストを含むJSON配列。これらの認証方法のいずれかが「token_endpoint_auth_methods_supported」エントリで指定されている場合、このメタデータエントリが存在する必要があります。このエントリを省略した場合、デフォルトのアルゴリズムは含まれません。サーバーは「RS256」をサポートする必要があります（SHOULD）。値「none」は使用してはなりません（MUST NOT）。
service_documentation OPTIONAL. URL of a page containing human-readable information that developers might want or need to know when using the authorization server. In particular, if the authorization server does not support Dynamic Client Registration, then information on how to register clients needs to be provided in this documentation.
service_documentationオプション。承認サーバーを使用する際に開発者が知りたい、または知っておく必要がある人間が読める情報を含むページのURL。特に、許可サーバーが動的クライアント登録をサポートしていない場合は、クライアントの登録方法に関する情報をこのドキュメントで提供する必要があります。
ui_locales_supported OPTIONAL. Languages and scripts supported for the user interface, represented as a JSON array of language tag values from BCP 47 [RFC5646]. If omitted, the set of supported languages and scripts is unspecified.
ui_locales_supportedオプション。ユーザーインターフェースでサポートされる言語とスクリプト。BCP47 [RFC5646]の言語タグ値のJSON配列として表されます。省略した場合、サポートされる言語とスクリプトのセットは指定されません。
op_policy_uri OPTIONAL. URL that the authorization server provides to the person registering the client to read about the authorization server's requirements on how the client can use the data provided by the authorization server. The registration process SHOULD display this URL to the person registering the client if it is given. As described in Section 5, despite the identifier "op_policy_uri" appearing to be OpenID-specific, its usage in this specification is actually referring to a general OAuth 2.0 feature that is not specific to OpenID Connect.
op_policy_uriオプション。承認サーバーがクライアントを登録する人に提供するURL。クライアントが承認サーバーによって提供されるデータをどのように使用できるかに関する承認サーバーの要件について読むために使用します。登録プロセスは、クライアントが登録されている場合は、このURLを提示する必要があります（SHOULD）。セクション5で説明したように、識別子「op_policy_uri」はOpenID固有であるように見えますが、この仕様での使用は、実際にはOpenID Connectに固有ではない一般的なOAuth 2.0機能を指します。
op_tos_uri OPTIONAL. URL that the authorization server provides to the person registering the client to read about the authorization server's terms of service. The registration process SHOULD display this URL to the person registering the client if it is given. As described in Section 5, despite the identifier "op_tos_uri", appearing to be OpenID-specific, its usage in this specification is actually referring to a general OAuth 2.0 feature that is not specific to OpenID Connect.
op_tos_uriオプション。承認サーバーがクライアントを登録するユーザーに提供するURLで、承認サーバーの利用規約について読むために使用します。登録プロセスは、クライアントが登録されている場合は、このURLを提示する必要があります（SHOULD）。セクション5で説明したように、識別子「op_tos_uri」はOpenID固有であるように見えますが、この仕様での使用は、実際にはOpenID Connectに固有ではない一般的なOAuth 2.0機能を指します。
revocation_endpoint OPTIONAL. URL of the authorization server's OAuth 2.0 revocation endpoint [RFC7009].
revocation_endpoint OPTIONAL。承認サーバーのOAuth 2.0失効エンドポイントのURL [RFC7009]。
revocation_endpoint_auth_methods_supported OPTIONAL. JSON array containing a list of client authentication methods supported by this revocation endpoint. The valid client authentication method values are those registered in the IANA "OAuth Token Endpoint Authentication Methods" registry [IANA.OAuth.Parameters]. If omitted, the default is "client_secret_basic" -- the HTTP Basic Authentication Scheme specified in Section 2.3.1 of OAuth 2.0 [RFC6749].
revocation_endpoint_auth_methods_supportedオプション。この失効エンドポイントでサポートされているクライアント認証方法のリストを含むJSON配列。有効なクライアント認証方式の値は、IANA「OAuthトークンエンドポイント認証方式」レジストリ[IANA.OAuth.Parameters]に登録されている値です。省略した場合、デフォルトは "client_secret_basic"-OAuth 2.0 [RFC6749]のセクション2.3.1で指定されたHTTP基本認証スキームです。
revocation_endpoint_auth_signing_alg_values_supported OPTIONAL. JSON array containing a list of the JWS signing algorithms ("alg" values) supported by the revocation endpoint for the signature on the JWT [JWT] used to authenticate the client at
revocation_endpoint_auth_signing_alg_values_supportedオプション。でクライアントを認証するために使用されるJWT [JWT]の署名の失効エンドポイントによってサポートされるJWS署名アルゴリズム（「alg」値）のリストを含むJSON配列
the revocation endpoint for the "private_key_jwt" and "client_secret_jwt" authentication methods. This metadata entry MUST be present if either of these authentication methods are specified in the "revocation_endpoint_auth_methods_supported" entry. No default algorithms are implied if this entry is omitted. The value "none" MUST NOT be used.
「private_key_jwt」および「client_secret_jwt」認証方式の失効エンドポイント。これらの認証方法のいずれかが「revocation_endpoint_auth_methods_supported」エントリで指定されている場合、このメタデータエントリが存在する必要があります。このエントリを省略した場合、デフォルトのアルゴリズムは含まれません。値「none」は使用してはなりません（MUST NOT）。
introspection_endpoint OPTIONAL. URL of the authorization server's OAuth 2.0 introspection endpoint [RFC7662].
introspection_endpoint OPTIONAL。許可サーバーのOAuth 2.0イントロスペクションエンドポイントのURL [RFC7662]。
introspection_endpoint_auth_methods_supported OPTIONAL. JSON array containing a list of client authentication methods supported by this introspection endpoint. The valid client authentication method values are those registered in the IANA "OAuth Token Endpoint Authentication Methods" registry [IANA.OAuth.Parameters] or those registered in the IANA "OAuth Access Token Types" registry [IANA.OAuth.Parameters]. (These values are and will remain distinct, due to Section 7.2.) If omitted, the set of supported authentication methods MUST be determined by other means.
introspection_endpoint_auth_methods_supported OPTIONAL。このイントロスペクションエンドポイントでサポートされるクライアント認証方法のリストを含むJSON配列。有効なクライアント認証方式の値は、IANA「OAuthトークンエンドポイント認証方式」レジストリ[IANA.OAuth.Parameters]に登録されている値、またはIANA「OAuthアクセストークンタイプ」レジストリ[IANA.OAuth.Parameters]に登録されている値です。 （これらの値は、セクション7.2のために、今後も区別されます。）省略した場合、サポートされている認証方法のセットは、他の方法で決定する必要があります。
introspection_endpoint_auth_signing_alg_values_supported OPTIONAL. JSON array containing a list of the JWS signing algorithms ("alg" values) supported by the introspection endpoint for the signature on the JWT [JWT] used to authenticate the client at the introspection endpoint for the "private_key_jwt" and "client_secret_jwt" authentication methods. This metadata entry MUST be present if either of these authentication methods are specified in the "introspection_endpoint_auth_methods_supported" entry. No default algorithms are implied if this entry is omitted. The value "none" MUST NOT be used.
introspection_endpoint_auth_signing_alg_values_supported OPTIONAL。 「private_key_jwt」および「client_secret_jwt」認証メソッドのイントロスペクションエンドポイントでクライアントを認証するために使用されるJWT [JWT]の署名のイントロスペクションエンドポイントによってサポートされるJWS署名アルゴリズム（「alg」値）のリストを含むJSON配列。これらの認証方法のいずれかが「introspection_endpoint_auth_methods_supported」エントリで指定されている場合、このメタデータエントリが存在する必要があります。このエントリを省略した場合、デフォルトのアルゴリズムは含まれません。値「none」は使用してはなりません（MUST NOT）。
code_challenge_methods_supported OPTIONAL. JSON array containing a list of Proof Key for Code Exchange (PKCE) [RFC7636] code challenge methods supported by this authorization server. Code challenge method values are used in the "code_challenge_method" parameter defined in Section 4.3 of [RFC7636]. The valid code challenge method values are those registered in the IANA "PKCE Code Challenge Methods" registry [IANA.OAuth.Parameters]. If omitted, the authorization server does not support PKCE.
code_challenge_methods_supportedオプション。この認証サーバーでサポートされているコード交換（PKCE）[RFC7636]コードチャレンジメソッドのプルーフキーのリストを含むJSON配列。コードチャレンジメソッドの値は、[RFC7636]のセクション4.3で定義されている「code_challenge_method」パラメータで使用されます。有効なコードチャレンジメソッドの値は、IANAの「PKCEコードチャレンジメソッド」レジストリ[IANA.OAuth.Parameters]に登録されている値です。省略した場合、許可サーバーはPKCEをサポートしません。
Additional authorization server metadata parameters MAY also be used. Some are defined by other specifications, such as OpenID Connect Discovery 1.0 [OpenID.Discovery].
追加の承認サーバーメタデータパラメーターも使用される場合があります。 OpenID Connect Discovery 1.0 [OpenID.Discovery]など、他の仕様で定義されているものもあります。
In addition to JSON elements, metadata values MAY also be provided as a "signed_metadata" value, which is a JSON Web Token (JWT) [JWT] that asserts metadata values about the authorization server as a bundle. A set of claims that can be used in signed metadata is defined in Section 2. The signed metadata MUST be digitally signed or MACed using JSON Web Signature (JWS) [JWS] and MUST contain an "iss" (issuer) claim denoting the party attesting to the claims in the signed metadata. Consumers of the metadata MAY ignore the signed metadata if they do not support this feature. If the consumer of the metadata supports signed metadata, metadata values conveyed in the signed metadata MUST take precedence over the corresponding values conveyed using plain JSON elements.
JSON要素に加えて、メタデータ値は "signed_metadata"値として提供される場合があります。これは、承認サーバーに関するメタデータ値をバンドルとしてアサートするJSON Web Token（JWT）[JWT]です。署名付きメタデータで使用できる一連のクレームは、セクション2で定義されています。署名付きメタデータは、JSON Web Signature（JWS）[JWS]を使用してデジタル署名またはMAC化し、パーティーを示す「iss」（発行者）クレームを含める必要があります署名されたメタデータの主張を証明します。メタデータの利用者は、この機能をサポートしていない場合、署名されたメタデータを無視してもよい（MAY）。メタデータのコンシューマーが署名付きメタデータをサポートする場合、署名付きメタデータで伝達されるメタデータ値は、プレーンなJSON要素を使用して伝達される対応する値よりも優先される必要があります。
Signed metadata is included in the authorization server metadata JSON object using this OPTIONAL member:
署名されたメタデータは、次のオプションのメンバーを使用して、承認サーバーのメタデータJSONオブジェクトに含まれています。
signed_metadata A JWT containing metadata values about the authorization server as claims. This is a string value consisting of the entire signed JWT. A "signed_metadata" metadata value SHOULD NOT appear as a claim in the JWT.
signed_metadata承認サーバーに関するメタデータ値をクレームとして含むJWT。これは、署名されたJWT全体で構成される文字列値です。 「signed_metadata」メタデータ値は、JWTでクレームとして表示されるべきではありません（SHOULD NOT）。
Authorization servers supporting metadata MUST make a JSON document containing metadata as specified in Section 2 available at a path formed by inserting a well-known URI string into the authorization server's issuer identifier between the host component and the path component, if any. By default, the well-known URI string used is "/.well-known/oauth-authorization-server". This path MUST use the "https" scheme. The syntax and semantics of ".well-known" are defined in RFC 5785 [RFC5785]. The well-known URI suffix used MUST be registered in the IANA "Well-Known URIs" registry [IANA.well-known].
メタデータをサポートする承認サーバーは、セクション2で指定されたメタデータを含むJSONドキュメントを、ホストコンポーネントとパスコンポーネントの間の承認サーバーの発行者識別子に、よく知られているURI文字列を挿入して形成されたパスで利用できるようにする必要があります（存在する場合）。デフォルトでは、使用される既知のURI文字列は「/.well-known/oauth-authorization-server」です。このパスは「https」スキームを使用する必要があります。 「.well-known」の構文とセマンティクスは、RFC 5785 [RFC5785]で定義されています。使用される既知のURIサフィックスは、IANAの「既知のURI」レジストリ[IANA.well-known]に登録する必要があります。
Different applications utilizing OAuth authorization servers in application-specific ways may define and register different well-known URI suffixes used to publish authorization server metadata as used by those applications. For instance, if the example application uses an OAuth authorization server in an example-specific way, and there are example-specific metadata values that it needs to publish, then it might register and use the "example-configuration" URI suffix and publish the metadata document at the path formed by inserting "/.well-known/example-configuration" between the host and path components of the authorization server's issuer identifier. Alternatively, many such applications will use the default well-known URI string "/.well-known/oauth-authorization-server", which is the right choice for general-purpose OAuth authorization servers, and not register an application-specific one.
アプリケーション固有の方法でOAuth承認サーバーを利用するさまざまなアプリケーションは、それらのアプリケーションで使用される承認サーバーメタデータの公開に使用されるさまざまな既知のURIサフィックスを定義および登録できます。たとえば、サンプルアプリケーションがサンプル固有の方法でOAuth承認サーバーを使用し、公開する必要のあるサンプル固有のメタデータ値がある場合、「example-configuration」URIサフィックスを登録して使用し、承認サーバーの発行者識別子のホストコンポーネントとパスコンポーネントの間に「/.well-known/example-configuration」を挿入して形成されたパスにあるメタデータドキュメント。または、そのようなアプリケーションの多くは、汎用のOAuth承認サーバーに適したデフォルトの既知のURI文字列「/.well-known/oauth-authorization-server」を使用し、アプリケーション固有のものを登録しません。
An OAuth 2.0 application using this specification MUST specify what well-known URI suffix it will use for this purpose. The same authorization server MAY choose to publish its metadata at multiple well-known locations derived from its issuer identifier, for example, publishing metadata at both "/.well-known/example-configuration" and "/.well-known/oauth-authorization-server".
この仕様を使用するOAuth 2.0アプリケーションは、この目的で使用する既知のURIサフィックスを指定する必要があります。同じ認証サーバーが、発行者識別子から派生した複数の既知の場所でメタデータを公開することを選択する場合があります。たとえば、「/。well-known / example-configuration」と「/.well-known/oauth-」の両方でメタデータを公開します。認可サーバー」。
Some OAuth applications will choose to use the well-known URI suffix "openid-configuration". As described in Section 5, despite the identifier "/.well-known/openid-configuration", appearing to be OpenID specific, its usage in this specification is actually referring to a general OAuth 2.0 feature that is not specific to OpenID Connect.
一部のOAuthアプリケーションは、既知のURIサフィックス「openid-configuration」の使用を選択します。セクション5で説明されているように、OpenID固有であるように見える識別子「/.well-known/openid-configuration」にもかかわらず、この仕様でのその使用法は、OpenID Connectに固有ではない一般的なOAuth 2.0機能を実際に参照しています。
An authorization server metadata document MUST be queried using an HTTP "GET" request at the previously specified path.
承認サーバーのメタデータドキュメントは、以前に指定されたパスでHTTP "GET"要求を使用して照会する必要があります。
The client would make the following request when the issuer identifier is "https://example.com" and the well-known URI suffix is "oauth-authorization-server" to obtain the metadata, since the issuer identifier contains no path component:
発行者識別子にはパスコンポーネントが含まれていないため、発行者識別子が「https://example.com」で、既知のURIサフィックスが「oauth-authorization-server」の場合、クライアントは次のリクエストを行ってメタデータを取得します。
GET /.well-known/oauth-authorization-server HTTP/1.1
Host: example.com
If the issuer identifier value contains a path component, any terminating "/" MUST be removed before inserting "/.well-known/" and the well-known URI suffix between the host component and the path component. The client would make the following request when the issuer identifier is "https://example.com/issuer1" and the well-known URI suffix is "oauth-authorization-server" to obtain the metadata, since the issuer identifier contains a path component:
発行者識別子の値にパスコンポーネントが含まれている場合は、ホストコンポーネントとパスコンポーネントの間に「/.well-known/」とウェルノウンURIサフィックスを挿入する前に、末尾の「/」を削除する必要があります。発行者識別子にパスが含まれているため、発行者識別子が「https://example.com/issuer1」であり、既知のURIサフィックスが「oauth-authorization-server」である場合、クライアントは次の要求を行ってメタデータを取得します。成分：
GET /.well-known/oauth-authorization-server/issuer1 HTTP/1.1
Host: example.com
Using path components enables supporting multiple issuers per host. This is required in some multi-tenant hosting configurations. This use of ".well-known" is for supporting multiple issuers per host; unlike its use in RFC 5785 [RFC5785], it does not provide general information about the host.
パスコンポーネントを使用すると、ホストごとに複数の発行者をサポートできます。これは、一部のマルチテナントホスティング構成で必要です。この「.well-known」の使用は、ホストごとに複数の発行者をサポートするためのものです。 RFC 5785 [RFC5785]での使用とは異なり、ホストに関する一般的な情報は提供しません。
The response is a set of claims about the authorization server's configuration, including all necessary endpoints and public key location information. A successful response MUST use the 200 OK HTTP status code and return a JSON object using the "application/json" content type that contains a set of claims as its members that are a subset of the metadata values defined in Section 2. Other claims MAY also be returned.
応答は、必要なすべてのエンドポイントと公開鍵の場所情報を含む、承認サーバーの構成に関する一連のクレームです。成功した応答は、200 OK HTTPステータスコードを使用し、セクション2で定義されているメタデータ値のサブセットである一連のクレームをメンバーとして含む「application / json」コンテンツタイプを使用してJSONオブジェクトを返す必要があります。も返されます。
Claims that return multiple values are represented as JSON arrays. Claims with zero elements MUST be omitted from the response.
複数の値を返すクレームは、JSON配列として表されます。要素がゼロのクレームは、応答から除外する必要があります。
An error response uses the applicable HTTP status code value.
エラー応答は、適切なHTTPステータスコード値を使用します。
The following is a non-normative example response:
以下は、非規範的な応答例です。
HTTP/1.1 200 OK
Content-Type: application/json
{
"issuer":
"https://server.example.com",
"authorization_endpoint":
"https://server.example.com/authorize",
"token_endpoint":
"https://server.example.com/token",
"token_endpoint_auth_methods_supported":
["client_secret_basic", "private_key_jwt"],
"token_endpoint_auth_signing_alg_values_supported":
["RS256", "ES256"],
"userinfo_endpoint":
"https://server.example.com/userinfo",
"jwks_uri":
"https://server.example.com/jwks.json",
"registration_endpoint":
"https://server.example.com/register",
"scopes_supported":
["openid", "profile", "email", "address",
"phone", "offline_access"],
"response_types_supported":
["code", "code token"],
"service_documentation":
"http://server.example.com/service_documentation.html",
"ui_locales_supported":
["en-US", "en-GB", "en-CA", "fr-FR", "fr-CA"]
}
The "issuer" value returned MUST be identical to the authorization server's issuer identifier value into which the well-known URI string was inserted to create the URL used to retrieve the metadata. If these values are not identical, the data contained in the response MUST NOT be used.
返される「発行者」の値は、メタデータの取得に使用されるURLを作成するために、既知のURI文字列が挿入された承認サーバーの発行者識別子の値と同一である必要があります。これらの値が同一でない場合、応答に含まれるデータを使用してはなりません（MUST NOT）。
Processing some OAuth 2.0 messages requires comparing values in the messages to known values. For example, the member names in the metadata response might be compared to specific member names such as "issuer". Comparing Unicode [UNICODE] strings, however, has significant security implications.
一部のOAuth 2.0メッセージを処理するには、メッセージ内の値を既知の値と比較する必要があります。たとえば、メタデータ応答のメンバー名は、「発行者」などの特定のメンバー名と比較される場合があります。ただし、Unicode [UNICODE]文字列を比較すると、セキュリティに大きな影響があります。
Therefore, comparisons between JSON strings and other Unicode strings MUST be performed as specified below:
したがって、JSON文字列と他のUnicode文字列との比較は、以下の指定に従って実行する必要があります。
1. Remove any JSON-applied escaping to produce an array of Unicode code points.
1. JSONに適用されたエスケープを削除して、Unicodeコードポイントの配列を生成します。
2. Unicode Normalization [USA15] MUST NOT be applied at any point to either the JSON string or the string it is to be compared against.
2. Unicode正規化[USA15]は、JSON文字列または比較対象の文字列のいずれにも適用しないでください。
3. Comparisons between the two strings MUST be performed as a Unicode code-point-to-code-point equality comparison.
3. 2つの文字列間の比較は、Unicodeのコードポイントとコードポイントの等価比較として実行する必要があります。
Note that this is the same equality comparison procedure described in Section 8.3 of [RFC8259].
これは、[RFC8259]のセクション8.3で説明されている同等比較手順と同じです。
The identifiers "/.well-known/openid-configuration", "op_policy_uri", and "op_tos_uri" contain strings referring to the OpenID Connect [OpenID.Core] family of specifications that were originally defined by "OpenID Connect Discovery 1.0" [OpenID.Discovery]. Despite the reuse of these identifiers that appear to be OpenID specific, their usage in this specification is actually referring to general OAuth 2.0 features that are not specific to OpenID Connect.
識別子「/.well-known/openid-configuration」、「op_policy_uri」、および「op_tos_uri」には、「OpenID Connect Discovery 1.0」[OpenID 。発見]。 OpenID固有のように見えるこれらの識別子の再利用にもかかわらず、この仕様でのそれらの使用法は、実際にはOpenID Connectに固有ではない一般的なOAuth 2.0機能を参照しています。
The algorithm for transforming the issuer identifier to an authorization server metadata location defined in Section 3 is equivalent to the corresponding transformation defined in Section 4 of "OpenID Connect Discovery 1.0" [OpenID.Discovery], provided that the issuer identifier contains no path component. However, they are different when there is a path component, because OpenID Connect Discovery 1.0 specifies that the well-known URI string is appended to the issuer identifier (e.g., "https://example.com/issuer1/.well-known/openid-configuration"), whereas this specification specifies that the well-known URI string is inserted before the path component of the issuer identifier (e.g., "https://example.com/.well-known/openid-configuration/issuer1").
発行者識別子をセクション3で定義された承認サーバーメタデータの場所に変換するアルゴリズムは、「OpenID Connect Discovery 1.0」[OpenID.Discovery]のセクション4で定義された対応する変換と同等です。ただし、発行者識別子にパスコンポーネントが含まれていない場合に限ります。ただし、パスコンポーネントがある場合は異なります。OpenIDConnect Discovery 1.0は、既知のURI文字列が発行者識別子に追加されることを指定しているためです（たとえば、「https://example.com/issuer1/.well-known/一方、この仕様では、既知のURI文字列が発行者識別子のパスコンポーネントの前に挿入されることを指定しています（たとえば、「https://example.com/.well-known/openid-configuration/issuer1」。 ）。
Going forward, OAuth authorization server metadata locations should use the transformation defined in this specification. However, when deployed in legacy environments in which the OpenID Connect Discovery 1.0 transformation is already used, it may be necessary during a transition period to publish metadata for issuer identifiers containing a path component at both locations. During this transition period, applications should first apply the transformation defined in this specification and attempt to retrieve the authorization server metadata from the resulting location; only if the retrieval from that location fails should they fall back to attempting to retrieve it from the alternate location obtained using the transformation defined by OpenID Connect Discovery 1.0. This backwards-compatible behavior should only be necessary when the well-known URI suffix employed by the application is "openid-configuration".
今後、OAuth承認サーバーのメタデータの場所では、この仕様で定義されている変換を使用する必要があります。ただし、OpenID Connect Discovery 1.0トランスフォーメーションがすでに使用されているレガシー環境にデプロイする場合、移行期間中に両方の場所でパスコンポーネントを含む発行者識別子のメタデータを公開する必要がある場合があります。この移行期間中、アプリケーションは最初にこの仕様で定義されている変換を適用し、結果の場所から承認サーバーのメタデータを取得する必要があります。その場所からの取得が失敗した場合にのみ、OpenID Connect Discovery 1.0で定義された変換を使用して取得した代替の場所から取得を試みます。この下位互換性のある動作は、アプリケーションが使用する既知のURIサフィックスが「openid-configuration」である場合にのみ必要です。
Implementations MUST support TLS. Which version(s) ought to be implemented will vary over time and depend on the widespread deployment and known security vulnerabilities at the time of implementation. The authorization server MUST support TLS version 1.2 [RFC5246] and MAY support additional TLS mechanisms meeting its security requirements. When using TLS, the client MUST perform a TLS/SSL server certificate check, per RFC 6125 [RFC6125]. Implementation security considerations can be found in "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)" [BCP195].
実装はTLSをサポートする必要があります。どのバージョンを実装する必要があるかは、時間の経過とともに変化し、広範囲にわたる展開と、実装時の既知のセキュリティの脆弱性によって異なります。認可サーバーはTLSバージョン1.2 [RFC5246]をサポートしなければならず（MUST）、そのセキュリティ要件を満たす追加のTLSメカニズムをサポートしてもよい（MAY）。 TLSを使用する場合、クライアントはRFC 6125 [RFC6125]に従ってTLS / SSLサーバー証明書チェックを実行する必要があります。実装のセキュリティに関する考慮事項は、「トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（DTLS）の安全な使用に関する推奨事項」[BCP195]にあります。
To protect against information disclosure and tampering, confidentiality protection MUST be applied using TLS with a ciphersuite that provides confidentiality and integrity protection.
情報の漏えいや改ざんから保護するには、機密性と完全性を保護する暗号スイートを備えたTLSを使用して、機密性保護を適用する必要があります。
TLS certificate checking MUST be performed by the client, as described in Section 6.1, when making an authorization server metadata request. Checking that the server certificate is valid for the issuer identifier URL prevents man-in-middle and DNS-based attacks. These attacks could cause a client to be tricked into using an attacker's keys and endpoints, which would enable impersonation of the legitimate authorization server. If an attacker can accomplish this, they can access the resources that the affected client has access to using the authorization server that they are impersonating.
TLS証明書チェックは、セクション6.1で説明されているように、承認サーバーのメタデータ要求を行うときにクライアントで実行する必要があります。サーバー証明書が発行者識別子のURLに対して有効であることを確認することで、中間者攻撃やDNSベースの攻撃を防ぐことができます。これらの攻撃により、クライアントが攻撃者のキーとエンドポイントをだまされ、正規の認証サーバーの偽装を可能にする可能性があります。攻撃者がこれを達成できる場合、影響を受けるクライアントが、偽装している認証サーバーを使用してアクセスできるリソースにアクセスできます。
An attacker may also attempt to impersonate an authorization server by publishing a metadata document that contains an "issuer" claim using the issuer identifier URL of the authorization server being impersonated, but with its own endpoints and signing keys. This would enable it to impersonate that authorization server, if accepted by the client. To prevent this, the client MUST ensure that the issuer identifier URL it is using as the prefix for the metadata request exactly matches the value of the "issuer" metadata value in the authorization server metadata document received by the client.
攻撃者はまた、なりすまされている認証サーバーの発行者ID URLを使用して、独自のエンドポイントと署名キーを使用して、「発行者」クレームを含むメタデータドキュメントを公開することにより、認証サーバーを偽装しようと試みる可能性があります。これにより、クライアントが受け入れた場合に、その承認サーバーを偽装できるようになります。これを防ぐために、クライアントは、メタデータ要求のプレフィックスとして使用している発行者識別子URLが、クライアントが受信した認証サーバーメタデータドキュメントの「発行者」メタデータ値の値と正確に一致することを確認する必要があります。
Publishing information about the authorization server in a standard format makes it easier for both legitimate clients and attackers to use the authorization server. Whether an authorization server publishes its metadata in an ad hoc manner or in the standard format defined by this specification, the same defenses against attacks that might be mounted that use this information should be applied.
許可サーバーに関する情報を標準形式で公開すると、正当なクライアントと攻撃者の両方が許可サーバーを使用しやすくなります。承認サーバーがそのメタデータをアドホックな方法で公開する場合でも、この仕様で定義されている標準形式で公開する場合でも、この情報を使用する、実装される可能性のある攻撃に対する同じ防御策を適用する必要があります。
Secure determination of appropriate protected resources to use with an authorization server for all use cases is out of scope of this specification. This specification assumes that the client has a means of determining appropriate protected resources to use with an authorization server and that the client is using the correct metadata for each authorization server. Implementers need to be aware that if an inappropriate protected resource is used by the client, that an attacker may be able to act as a man-in-the-middle proxy to a valid protected resource without it being detected by the authorization server or the client.
すべてのユースケースで許可サーバーとともに使用する適切な保護リソースを安全に決定することは、この仕様の範囲外です。この仕様では、クライアントに、認証サーバーで使用する適切な保護リソースを決定する手段があり、クライアントが各認証サーバーの正しいメタデータを使用していると想定しています。実装者は、不適切な保護リソースがクライアントによって使用されている場合、攻撃者が承認サーバーまたは認証サーバーによって検出されずに、有効な保護リソースに対する中間者プロキシとして機能できることに注意する必要があります。クライアント。
The ways to determine the appropriate protected resources to use with an authorization server are, in general, application dependent. For instance, some authorization servers are used with a fixed protected resource or set of protected resources, the locations of which may be well known or could be published as metadata values by the authorization server. In other cases, the set of resources that can be used with an authorization server can be dynamically changed by administrative actions. Many other means of determining appropriate associations between authorization servers and protected resources are also possible.
許可サーバーで使用する適切な保護リソースを決定する方法は、一般にアプリケーションに依存します。たとえば、一部の承認サーバーは、固定された保護リソースまたは保護リソースのセットで使用されます。その場所はよく知られているか、承認サーバーによってメタデータ値として公開されます。他の場合では、許可サーバーで使用できるリソースのセットは、管理アクションによって動的に変更できます。承認サーバーと保護されたリソース間の適切な関連付けを決定する他の多くの方法も可能です。
The following registration procedure is used for the registry established by this specification.
本仕様書で定めるレジストリは、以下の登録手順に従います。
Values are registered on a Specification Required [RFC8126] basis after a two-week review period on the oauth-ext-review@ietf.org mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of values prior to publication, the Designated Experts may approve registration once they are satisfied that such a specification will be published.
値は、1名以上のDesignated Expertsの助言により、oauth-ext-review @ ietf.orgメーリングリストの2週間のレビュー期間の後に、Specification Required [RFC8126]ベースで登録されます。ただし、公開前に値を割り当てることを可能にするために、指定された専門家は、そのような仕様が公開されることを納得したら、登録を承認することができます。
Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register OAuth Authorization Server Metadata: example").
確認のためにメーリングリストに送信される登録リクエストでは、適切な件名を使用する必要があります（「OAuth Authorization Serverメタデータの登録リクエスト：例」など）。
Within the review period, the Designated Experts will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the iesg@ietf.org mailing list) for resolution.
レビュー期間内に、Designated Expertsは登録リクエストを承認または拒否し、この決定をレビューリストとIANAに通知します。拒否には、要求を成功させる方法についての説明と、該当する場合は提案を含める必要があります。 21日よりも長い期間未確定の登録要求は、解決のために（iesg@ietf.orgメーリングリストを使用して）IESGに通知することができます。
Criteria that should be applied by the Designated Experts include determining whether the proposed registration duplicates existing functionality, determining whether it is likely to be of general applicability or whether it is useful only for a single application, and whether the registration makes sense.
Designated Expertsが適用する必要のある基準には、提案された登録が既存の機能と重複しているかどうかの判断、一般的な適用性があるかどうか、単一のアプリケーションにのみ有用かどうかの判断、および登録に意味があるかどうかの判断が含まれます。
IANA must only accept registry updates from the Designated Experts and should direct all requests for registration to the review mailing list.
IANAは、Designated Expertsからのレジストリの更新のみを受け入れ、登録のすべてのリクエストをレビューメーリングリストに転送する必要があります。
It is suggested that multiple Designated Experts be appointed who are able to represent the perspectives of different applications using this specification, in order to enable broadly-informed review of registration decisions. In cases where a registration decision could be perceived as creating a conflict of interest for a particular Designated Expert, that Designated Expert should defer to the judgment of the other Designated Experts.
広範囲にわたる情報に基づいた登録決定のレビューを可能にするために、この仕様を使用してさまざまなアプリケーションの視点を表すことができる複数の指定専門家を任命することをお勧めします。登録の決定が特定の指定されたエキスパートの利益相反を生み出すものとして認識される可能性がある場合、その指定されたエキスパートは、他の指定されたエキスパートの判断に委ねるべきです。
This specification establishes the IANA "OAuth Authorization Server Metadata" registry for OAuth 2.0 authorization server metadata names. The registry records the authorization server metadata member and a reference to the specification that defines it.
この仕様は、OAuth 2.0承認サーバーメタデータ名のIANA "OAuth承認サーバーメタデータ"レジストリを確立します。レジストリは、承認サーバーのメタデータメンバーとそれを定義する仕様への参照を記録します。
The Designated Experts must either:
指定専門家は次のいずれかを行う必要があります。
(a) require that metadata names and values being registered use only
printable ASCII characters excluding double quote ('"') and backslash
('\') (the Unicode characters with code points U+0021, U+0023 through
U+005B, and U+005D through U+007E), or
(b) if new metadata members or values are defined that use other code points, require that their definitions specify the exact sequences of Unicode code points used to represent them. Furthermore, proposed registrations that use Unicode code points that can only be represented in JSON strings as escaped characters must not be accepted.
（b）他のコードポイントを使用する新しいメタデータメンバーまたは値が定義されている場合、それらの定義は、それらを表すために使用されるUnicodeコードポイントの正確なシーケンスを指定する必要があります。さらに、エスケープ文字としてJSON文字列でのみ表現できるUnicodeコードポイントを使用する登録案は受け入れられません。
Metadata Name: The name requested (e.g., "issuer"). This name is case-sensitive. Names may not match other registered names in a case-insensitive manner (one that would cause a match if the Unicode toLowerCase() operation were applied to both strings) unless the Designated Experts state that there is a compelling reason to allow an exception.
メタデータ名：要求された名前（「発行者」など）。この名前は大文字と小文字が区別されます。指定された専門家が例外を許可する説得力のある理由があると述べていない限り、名前は大文字と小文字を区別しない方法で他の登録名と一致しない場合があります（Unicode toLowerCase()操作が両方の文字列に適用された場合に一致するもの）。
Metadata Description: Brief description of the metadata (e.g., "Issuer identifier URL").
メタデータの説明：メタデータの簡単な説明（「発行者IDのURL」など）。
Change Controller: For Standards Track RFCs, list the "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.
変更管理者：Standards Track RFCsについては、「IESG」をリストします。その他の場合は、責任者の名前を入力してください。その他の詳細（たとえば、住所、電子メールアドレス、ホームページURI）も含まれる場合があります。
Specification Document(s): Reference to the document or documents that specify the parameter, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required.
仕様ドキュメント：パラメータを指定する1つまたは複数のドキュメントへの参照。できれば、ドキュメントのコピーを取得するために使用できるURIを含む。関連セクションの表示も含まれる場合がありますが、必須ではありません。
o Metadata Name: issuer o Metadata Description: Authorization server's issuer identifier URL o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o メタデータ名：発行者oメタデータの説明：承認サーバーの発行者ID URL o変更管理者：IESG o仕様書：RFC 8414のセクション2
o Metadata Name: authorization_endpoint o Metadata Description: URL of the authorization server's authorization endpoint o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o メタデータ名：authorization_endpoint oメタデータの説明：承認サーバーの承認エンドポイントのURL o変更管理者：IESG o仕様書：RFC 8414のセクション2
o Metadata Name: token_endpoint o Metadata Description: URL of the authorization server's token endpoint o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o メタデータ名：token_endpoint oメタデータの説明：承認サーバーのトークンエンドポイントのURL o変更管理者：IESG o仕様書：RFC 8414のセクション2
o Metadata Name: jwks_uri o Metadata Description: URL of the authorization server's JWK Set document o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o メタデータ名：jwks_uri oメタデータの説明：承認サーバーのJWKセットドキュメントのURL o変更管理者：IESG o仕様ドキュメント：RFC 8414のセクション2
o Metadata Name: registration_endpoint o Metadata Description: URL of the authorization server's OAuth 2.0 Dynamic Client Registration Endpoint o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o メタデータ名：registration_endpoint oメタデータの説明：承認サーバーのOAuth 2.0動的クライアント登録エンドポイントのURL o変更コントローラー：IESG o仕様書：RFC 8414のセクション2
o Metadata Name: scopes_supported o Metadata Description: JSON array containing a list of the OAuth 2.0 "scope" values that this authorization server supports o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o メタデータ名：scopes_supported oメタデータの説明：この認証サーバーがサポートするOAuth 2.0の「スコープ」値のリストを含むJSON配列o変更コントローラー：IESG o仕様書：RFC 8414のセクション2
o Metadata Name: response_types_supported o Metadata Description: JSON array containing a list of the OAuth 2.0 "response_type" values that this authorization server supports o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o メタデータ名：response_types_supported oメタデータの説明：この認証サーバーがサポートするOAuth 2.0の "response_type"値のリストを含むJSON配列oコントローラーの変更：IESG o仕様書：RFC 8414のセクション2
o Metadata Name: response_modes_supported
o Metadata Description: JSON array containing a list of the OAuth
2.0 "response_mode" values that this authorization server supports
o Change Controller: IESG
o Specification Document(s): Section 2 of RFC 8414
o Metadata Name: grant_types_supported
o Metadata Description: JSON array containing a list of the OAuth
2.0 grant type values that this authorization server supports
o Change Controller: IESG
o Specification Document(s): Section 2 of RFC 8414
o Metadata Name: token_endpoint_auth_methods_supported o Metadata Description: JSON array containing a list of client authentication methods supported by this token endpoint o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o メタデータ名：token_endpoint_auth_methods_supported oメタデータの説明：このトークンエンドポイントでサポートされているクライアント認証方法のリストを含むJSON配列o変更コントローラー：IESG o仕様書：RFC 8414のセクション2
o Metadata Name: token_endpoint_auth_signing_alg_values_supported o Metadata Description: JSON array containing a list of the JWS signing algorithms supported by the token endpoint for the signature on the JWT used to authenticate the client at the token endpoint o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o メタデータ名：token_endpoint_auth_signing_alg_values_supported oメタデータの説明：トークンエンドポイントでクライアントを認証するために使用されるJWTの署名のトークンエンドポイントによってサポートされるJWS署名アルゴリズムのリストを含むJSON配列o変更コントローラー：IESG o仕様ドキュメント： RFC 8414のセクション2
o Metadata Name: service_documentation o Metadata Description: URL of a page containing human-readable information that developers might want or need to know when using the authorization server o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o メタデータ名：service_documentation oメタデータの説明：承認サーバーを使用するときに開発者が知りたい、または知っておく必要がある人間が読める情報を含むページのURL o変更管理者：IESG o仕様書：RFC 8414のセクション2
o Metadata Name: ui_locales_supported o Metadata Description: Languages and scripts supported for the user interface, represented as a JSON array of language tag values from BCP 47 o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o メタデータ名：ui_locales_supported oメタデータの説明：ユーザーインターフェイスでサポートされる言語とスクリプト。BCP47からの言語タグ値のJSON配列として表されます。oコントローラーの変更：IESG o仕様書：RFC 8414のセクション2
o Metadata Name: op_policy_uri o Metadata Description: URL that the authorization server provides to the person registering the client to read about the authorization server's requirements on how the client can use the data provided by the authorization server o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o メタデータ名：op_policy_uri oメタデータの説明：承認サーバーがクライアントを登録する人に提供するURLで、承認サーバーが提供するデータをクライアントがどのように使用できるかに関する承認サーバーの要件について読むoコントローラーの変更：IESG o仕様書）：RFC 8414のセクション2
o Metadata Name: op_tos_uri
o Metadata Description: URL that the authorization server provides
to the person registering the client to read about the
authorization server's terms of service
o Change Controller: IESG
o Specification Document(s): Section 2 of RFC 8414
o Metadata Name: revocation_endpoint
o Metadata Description: URL of the authorization server's OAuth 2.0
revocation endpoint
o Change Controller: IESG
o Specification Document(s): Section 2 of RFC 8414
o Metadata Name: revocation_endpoint_auth_methods_supported o Metadata Description: JSON array containing a list of client authentication methods supported by this revocation endpoint o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o メタデータ名：revocation_endpoint_auth_methods_supported oメタデータの説明：この失効エンドポイントでサポートされているクライアント認証方法のリストを含むJSON配列o変更コントローラー：IESG o仕様書：RFC 8414のセクション2
o Metadata Name: revocation_endpoint_auth_signing_alg_values_supported o Metadata Description: JSON array containing a list of the JWS signing algorithms supported by the revocation endpoint for the signature on the JWT used to authenticate the client at the revocation endpoint o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o メタデータ名：revocation_endpoint_auth_signing_alg_values_supported oメタデータの説明：失効エンドポイントでクライアントを認証するために使用されるJWTの署名の失効エンドポイントによってサポートされるJWS署名アルゴリズムのリストを含むJSON配列o変更コントローラー：IESG o仕様ドキュメント： RFC 8414のセクション2
o Metadata Name: introspection_endpoint o Metadata Description: URL of the authorization server's OAuth 2.0 introspection endpoint o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o メタデータ名：introspection_endpoint oメタデータの説明：承認サーバーのOAuth 2.0イントロスペクションエンドポイントのURL o変更コントローラー：IESG o仕様書：RFC 8414のセクション2
o Metadata Name: introspection_endpoint_auth_methods_supported o Metadata Description: JSON array containing a list of client authentication methods supported by this introspection endpoint o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o メタデータ名：introspection_endpoint_auth_methods_supported oメタデータの説明：このイントロスペクションエンドポイントでサポートされるクライアント認証方法のリストを含むJSON配列o変更コントローラー：IESG o仕様書：RFC 8414のセクション2
o Metadata Name: introspection_endpoint_auth_signing_alg_values_supported o Metadata Description: JSON array containing a list of the JWS signing algorithms supported by the introspection endpoint for the signature on the JWT used to authenticate the client at the introspection endpoint o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8414
o メタデータ名：introspection_endpoint_auth_signing_alg_values_supported oメタデータの説明：イントロスペクションエンドポイントでクライアントを認証するために使用されるJWTの署名のイントロスペクションエンドポイントでサポートされるJWS署名アルゴリズムのリストを含むJSON配列oコントローラーの変更：IESG o仕様ドキュメント： RFC 8414のセクション2
o Metadata Name: code_challenge_methods_supported
o Metadata Description: PKCE code challenge methods supported by
this authorization server
o Change Controller: IESG
o Specification Document(s): Section 2 of RFC 8414
o Metadata Name: signed_metadata
o Metadata Description: Signed JWT containing metadata values about
the authorization server as claims
o Change Controller: IESG
o Specification Document(s): Section 2.1 of RFC 8414
This specification adds to the instructions for the Designated Experts of the following IANA registries, both of which are in the "OAuth Parameters" registry [IANA.OAuth.Parameters]:
この仕様は、次のIANAレジストリのDesignated Expertsの指示に追加されます。どちらも「OAuth Parameters」レジストリ[IANA.OAuth.Parameters]にあります。
o OAuth Access Token Types o OAuth Token Endpoint Authentication Methods
o OAuthアクセストークンのタイプo OAuthトークンエンドポイント認証方式
IANA has added a link to this specification in the Reference sections of these registries.
IANAは、これらのレジストリのリファレンスセクションにこの仕様へのリンクを追加しました。
For these registries, the Designated Experts must reject registration requests in one registry for values already occurring in the other registry. This is necessary because the "introspection_endpoint_auth_methods_supported" parameter allows for the use of values from either registry. That way, because the values in the two registries will continue to be mutually exclusive, no ambiguities will arise.
これらのレジストリの場合、指定エキスパートは、他のレジストリですでに発生している値について、1つのレジストリでの登録要求を拒否する必要があります。 「introspection_endpoint_auth_methods_supported」パラメーターは、いずれかのレジストリーからの値の使用を許可するため、これが必要です。このように、2つのレジストリーの値は相互に排他的であり続けるので、あいまいさは生じません。
This specification registers the well-known URI defined in Section 3 in the IANA "Well-Known URIs" registry [IANA.well-known] established by RFC 5785 [RFC5785].
この仕様は、RFC 5785 [RFC5785]によって確立されたIANA "Well-Known URIs"レジストリ[IANA.well-known]のセクション3で定義された既知のURIを登録します。
o URI suffix: oauth-authorization-server o Change controller: IESG o Specification document: Section 3 of RFC 8414 o Related information: (none)
o URIサフィックス：oauth-authorization-server o変更コントローラー：IESG o仕様書：RFC 8414のセクション3 o関連情報：（なし）
[BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, May 2015, <http://www.rfc-editor.org/info/bcp195>.
[BCP195] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、2015年5月、<http://www.rfc-editor.org/info/bcp195>。
[IANA.OAuth.Parameters] IANA, "OAuth Parameters", <https://www.iana.org/assignments/oauth-parameters>.
[IANA.OAuth.Parameters] IANA、「OAuthパラメータ」、<https://www.iana.org/assignments/oauth-parameters>。
[JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, <https://www.rfc-editor.org/info/rfc7516>.
[JWE]ジョーンズ、M.、J。ヒルデブランド、「JSON Web Encryption（JWE）」、RFC 7516、DOI 10.17487 / RFC7516、2015年5月、<https://www.rfc-editor.org/info/rfc7516>。
[JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, <https://www.rfc-editor.org/info/rfc7517>.
[JWK]ジョーンズ、M。、「JSON Web Key（JWK）」、RFC 7517、DOI 10.17487 / RFC7517、2015年5月、<https://www.rfc-editor.org/info/rfc7517>。
[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/info/rfc7515>.
[JWS]ジョーンズ、M。、ブラッドリー、J.、N。崎村、「JSON Web Signature（JWS）」、RFC 7515、DOI 10.17487 / RFC7515、2015年5月、<https://www.rfc-editor.org / info / rfc7515>。
[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/info/rfc7519>.
[JWT]ジョーンズ、M。、ブラッドリー、J.、N。崎村、「JSON Web Token（JWT）」、RFC 7519、DOI 10.17487 / RFC7519、2015年5月、<https://www.rfc-editor.org / info / rfc7519>。
[OAuth.Post] Jones, M. and B. Campbell, "OAuth 2.0 Form Post Response Mode", April 2015, <http://openid.net/specs/ oauth-v2-form-post-response-mode-1_0.html>.
[OAuth.Post]ジョーンズ、M.、B。キャンベル、「OAuth 2.0フォームポストレスポンスモード」、2015年4月、<http://openid.net/specs/ oauth-v2-form-post-response-mode-1_0 .html>。
[OAuth.Responses] de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. Jones, "OAuth 2.0 Multiple Response Type Encoding Practices", February 2014, <http://openid.net/specs/ oauth-v2-multiple-response-types-1_0.html>.
[OAuth.Responses] de Medeiros、B.、Ed。、Scurtescu、M.、Tarjan、P.、and M. Jones、 "OAuth 2.0 Multiple Response Type Encoding Practices"、February 2014、<http://openid.net / specs / oauth-v2-multiple-response-types-1_0.html>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<https://www.rfc-editor.org/info / rfc5246>。
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC5646]フィリップス、A。、エド。 M.デイビス編、「言語を識別するためのタグ」、BCP 47、RFC 5646、DOI 10.17487 / RFC5646、2009年9月、<https://www.rfc-editor.org/info/rfc5646>。
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, April 2010, <https://www.rfc-editor.org/info/rfc5785>.
[RFC5785]ノッティンガム、M。およびE. Hammer-Lahav、「Defining Well-Known Uniform Resource Identifiers（URIs）」、RFC 5785、DOI 10.17487 / RFC5785、2010年4月、<https://www.rfc-editor.org / info / rfc5785>。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6125] Saint-Andre、P。およびJ. Hodges、「トランスポート層セキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用したインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、 RFC 6125、DOI 10.17487 / RFC6125、2011年3月、<https://www.rfc-editor.org/info/rfc6125>。
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/info/rfc6749>.
[RFC6749] Hardt、D。、編、「The OAuth 2.0 Authorization Framework」、RFC 6749、DOI 10.17487 / RFC6749、2012年10月、<https://www.rfc-editor.org/info/rfc6749>。
[RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, August 2013, <https://www.rfc-editor.org/info/rfc7009>.
[RFC7009] Lodderstedt、T.、Ed。、Dronia、S。、およびM. Scurtescu、「OAuth 2.0トークンの取り消し」、RFC 7009、DOI 10.17487 / RFC7009、2013年8月、<https：//www.rfc-editor。 org / info / rfc7009>。
[RFC7033] Jones, P., Salgueiro, G., Jones, M., and J. Smarr, "WebFinger", RFC 7033, DOI 10.17487/RFC7033, September 2013, <https://www.rfc-editor.org/info/rfc7033>.
[RFC7033]ジョーンズ、P。、サルゲイロ、G。、ジョーンズ、M。、およびJ.スマール、「WebFinger」、RFC 7033、DOI 10.17487 / RFC7033、2013年9月、<https://www.rfc-editor.org / info / rfc7033>。
[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, July 2015, <https://www.rfc-editor.org/info/rfc7591>.
[RFC7591] Richer、J.、Ed。、Jones、M.、Bradley、J.、Machulak、M。、およびP. Hunt、「OAuth 2.0 Dynamic Client Registration Protocol」、RFC 7591、DOI 10.17487 / RFC7591、2015年7月、<https://www.rfc-editor.org/info/rfc7591>。
[RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key for Code Exchange by OAuth Public Clients", RFC 7636, DOI 10.17487/RFC7636, September 2015, <https://www.rfc-editor.org/info/rfc7636>.
[RFC7636] Sakimura、N.、Ed。、Bradley、J.、and N. Agarwal、 "Proof Key for Code Exchange by OAuth Public Clients"、RFC 7636、DOI 10.17487 / RFC7636、September 2015、<https：// www .rfc-editor.org / info / rfc7636>。
[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, <https://www.rfc-editor.org/info/rfc7662>.
[RFC7662] Richer、J。、編、「OAuth 2.0トークンイントロスペクション」、RFC 7662、DOI 10.17487 / RFC7662、2015年10月、<https://www.rfc-editor.org/info/rfc7662>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259]ブレイ、T。、編、「JavaScript Object Notation（JSON）データ交換フォーマット」、STD 90、RFC 8259、DOI 10.17487 / RFC8259、2017年12月、<https://www.rfc-editor.org / info / rfc8259>。
[UNICODE] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.
[UNICODE] Unicodeコンソーシアム、「The Unicode Standard」、<http://www.unicode.org/versions/latest/>。
[USA15] Davis, M., Ed. and K. Whistler, Ed., "Unicode Normalization Forms", Unicode Standard Annex #15, May 2018, <http://www.unicode.org/reports/tr15/>.
[USA15]デービス、M。、エド。 K.ウィスラー編、「Unicode Normalization Forms」、Unicode Standard Annex＃15、2018年5月、<http://www.unicode.org/reports/tr15/>。
[IANA.well-known] IANA, "Well-Known URIs", <https://www.iana.org/assignments/well-known-uris>.
[IANA.well-known] IANA、「既知のURI」、<https://www.iana.org/assignments/well-known-uris>。
[MIX-UP] Jones, M., Bradley, J., and N. Sakimura, "OAuth 2.0 Mix-Up Mitigation", Work in Progress, draft-ietf-oauth-mix-up-mitigation-01, July 2016.
[MIX-UP]ジョーンズ、M。、ブラッドリー、J.、N。崎村、「OAuth 2.0ミックスアップ緩和」、作業中、draft-ietf-oauth-mix-up-mitigation-01、2016年7月。
[OpenID.Core] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0", November 2014, <http://openid.net/specs/openid-connect-core-1_0.html>.
[OpenID.Core] Sakimura N.、Bradley、J.、Jones、M.、de Medeiros、B。、およびC. Mortimore、「OpenID Connect Core 1.0」、2014年11月、<http://openid.net/ specs / openid-connect-core-1_0.html>。
[OpenID.Discovery] Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID Connect Discovery 1.0", November 2014, <http://openid.net/specs/ openid-connect-discovery-1_0.html>.
[OpenID.Discovery] Sakimura N.、Bradley、J.、Jones、M。、およびE. Jay、「OpenID Connect Discovery 1.0」、2014年11月、<http://openid.net/specs/ openid-connect- discovery-1_0.html>。
[OpenID.Registration] Sakimura, N., Bradley, J., and M. Jones, "OpenID Connect Dynamic Client Registration 1.0", November 2014, <http://openid.net/specs/ openid-connect-registration-1_0.html>.
[OpenID.Registration] Sakimura N.、Bradley、J。、およびM. Jones、「OpenID Connect Dynamic Client Registration 1.0」、2014年11月、<http://openid.net/specs/ openid-connect-registration-1_0 .html>。
Acknowledgements
謝辞
This specification is based on the OpenID Connect Discovery 1.0 specification, which was produced by the OpenID Connect working group of the OpenID Foundation. This specification standardizes the de facto usage of the metadata format defined by OpenID Connect Discovery to publish OAuth authorization server metadata.
この仕様は、OpenID FoundationのOpenID Connectワーキンググループによって作成されたOpenID Connect Discovery 1.0仕様に基づいています。この仕様は、OpenID Connect Discoveryによって定義されたメタデータ形式の事実上の使用を標準化して、OAuth承認サーバーのメタデータを公開します。
The authors would like to thank the following people for their reviews of this specification: Shwetha Bhandari, Ben Campbell, Brian Campbell, Brian Carpenter, William Denniss, Vladimir Dzhuvinov, Donald Eastlake, Samuel Erdtman, George Fletcher, Dick Hardt, Phil Hunt, Alexey Melnikov, Tony Nadalin, Mark Nottingham, Eric Rescorla, Justin Richer, Adam Roach, Hannes Tschofenig, and Hans Zandbelt.
著者は、この仕様のレビューに対して以下の人々に感謝します：シュエタバンダリ、ベンキャンベル、ブライアンキャンベル、ブライアンカーペンター、ウィリアムデニス、ウラジミールズビノフ、ドナルドイーストレイク、サミュエルエルドマン、ジョージフレッチャー、ディックハード、フィルハント、アレクセイMelnikov、Tony Nadalin、Mark Nottingham、Eric Rescorla、Justin Richer、Adam Roach、Hannes Tschofenig、Hans Zandbelt。
Authors' Addresses
著者のアドレス
Michael B. Jones Microsoft
マイケルB.ジョーンズマイクロソフト
Email: mbj@microsoft.com
URI: http://self-issued.info/
Nat Sakimura Nomura Research Institute, Ltd.
崎村ナット野村総合研究所
Email: n-sakimura@nri.co.jp
URI: http://nat.sakimura.org/
John Bradley Yubico
ジョンブラッドリーユビコ
Email: RFC8414@ve7jtb.com
URI: http://www.thread-safe.com/