• Internet Engineering Task Force (IETF): M. Jones (Microsoft)
• Request for Comments: 8414
• Category: Standards Track
• ISSN: 2070-1721
• N. Sakimura (NRI), J. Bradley (Yubico)
• June 2018

OAuth 2.0 Authorization Server Metadata

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.

Status of This Memo

This is an Internet Standards Track document.

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.

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

Copyright Notice

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

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.

---

Table of Contents

• OAuth 2.0 Authorization Server Metadata
• Abstract
• Status of This Memo
• Copyright Notice
• Table of Contents
• 1. Introduction
• 1.1. Requirements Notation and Conventions
• 1.2. Terminology
• 2. Authorization Server Metadata
• 2.1. Signed Authorization Server Metadata
• 3. Obtaining Authorization Server Metadata
  • 3.1. Authorization Server Metadata Request
  • 3.2. Authorization Server Metadata Response
  • 3.3. Authorization Server Metadata Validation
• 4. String Operations
• 5. Compatibility Notes
• 6. Security Considerations
  • 6.1. TLS Requirements
  • 6.2. Impersonation Attacks
  • 6.3. Publishing Metadata in a Standard Format
  • 6.4. Protected Resources
• 7. IANA Considerations
  • 7.1. OAuth Authorization Server Metadata Registry
  • 7.1.1. Registration Template
  • 7.1.2. Initial Registry Contents
  • 7.2. Updated Registration Instructions
  • 7.3. Well-Known URI Registry
  • 7.3.1. Registry Contents
• 8. References
  • 8.1. Normative References
  • 8.2. Informative References
• Acknowledgements
• Authors' Addresses

---

1. Introduction

本仕様は、「OpenID Connect Discovery 1.0」[OpenID.Discovery] で定義された metadata 形式を、OpenID Connect Discovery と互換性を保ちつつ、より広い OAuth 2.0 のユースケースに適用できるよう一般化する。これは、「OAuth 2.0 Dynamic Client Registration Protocol」[RFC7591] が、「OpenID Connect Dynamic Client Registration 1.0」[OpenID.Registration] で定義された dynamic client registration の仕組みを、それと互換性を保ったまま一般化した方法と意図的に並行している。

Authorization Server の metadata は、well-known location から JSON [RFC8259] document として取得され、そこには endpoint の場所および Authorization Server の capabilities が宣言される。この手順は Section 3 に記述される。

この metadata は、サーバ origin から HTTPS 経由で自己主張（self-asserted）として伝達することも、JSON Web Token (JWT) [JWT] の claims として表現された署名付き metadata values の集合として伝達することもできる。JWT の場合、issuer は Authorization Server に関するデータの正当性を保証する。これは OAuth Dynamic Client Registration [RFC7591] における Software Statement の役割に類似する。

client が Authorization Server を選択する方法はスコープ外である。いくつかのケースでは、その issuer identifier が手動で client に設定されることがある。別のケースでは、たとえば WebFinger [RFC7033] の利用により動的に discovered され得る。これは「OpenID Connect Discovery 1.0」[OpenID.Discovery] の Section 2 で説明されている。

1.1. Requirements Notation and Conventions

本文書中のキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY"、"OPTIONAL" は、ここに示すようにすべて大文字で現れる場合に限り、BCP 14 [RFC2119] [RFC8174] に記述されるとおりに解釈される。

本仕様における JSON Web Signature (JWS) [JWS] および JSON Web Encryption (JWE) [JWE] data structures の利用は、JWS Compact Serialization または JWE Compact Serialization を用いる。JWS JSON Serialization および JWE JSON Serialization は用いない。

1.2. Terminology

本仕様は OAuth 2.0 [RFC6749] で定義された "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"、および "Token Endpoint" の各用語、JSON Web Token (JWT) [JWT] で定義された "Claim Name"、"Claim Value"、および "JSON Web Token (JWT)" の各用語、そして「OAuth 2.0 Multiple Response Type Encoding Practices」[OAuth.Responses] で定義された "Response Mode" という用語を用いる。

---

2. Authorization Server Metadata

Authorization Server は、その configuration を記述する metadata を持ち得る。本仕様で用いられる以下の Authorization Server metadata values は、Section 7.1 で設立される IANA "OAuth Authorization Server Metadata" registry に登録される。

issuer : REQUIRED。Authorization Server の issuer identifier。これは "https" scheme を使用し、query または fragment components を持たない URL である。Authorization Server metadata は、この issuer identifier から導出され、Section 3 に記述するとおり、RFC 5785 [RFC5785] に従い ".well-known" となる location に公開される。issuer identifier は、「OAuth 2.0 Mix-Up Mitigation」[MIX-UP] で説明される authorization server mix-up attacks を防止するために使用される。

authorization_endpoint : Authorization Server の authorization endpoint [RFC6749] の URL。authorization endpoint を使用する grant types が一つもサポートされない場合を除き、これは REQUIRED である。

token_endpoint : Authorization Server の token endpoint [RFC6749] の URL。implicit grant type のみがサポートされる場合を除き、これは REQUIRED である。

jwks_uri : OPTIONAL。Authorization Server の JWK Set [JWK] document の URL。参照先 document には、client が Authorization Server からの signatures を検証するために使用する signing key(s) が含まれる。この URL は "https" scheme を使用しなければならない (MUST)。JWK Set は、server の encryption key（1つまたは複数）を含み得る。これらは client が server への requests を暗号化するために使用する。signing と encryption の両方の keys が利用可能にされる場合、参照される JWK Set 内のすべての keys には、それぞれの key の intended usage を示すために "use" (public key use) parameter value が REQUIRED である。

registration_endpoint : OPTIONAL。Authorization Server の OAuth 2.0 Dynamic Client Registration endpoint [RFC7591] の URL。

scopes_supported : RECOMMENDED。OAuth 2.0 [RFC6749] の "scope" values のうち、本 Authorization Server がサポートするものの一覧を含む JSON array。サーバは、この parameter が使用される場合であっても、サポートする scope values の一部を広告しないことを選択してよい (MAY)。

response_types_supported : REQUIRED。本 Authorization Server がサポートする OAuth 2.0 "response_type" values の一覧を含む JSON array。ここで使用される array values は、「OAuth 2.0 Dynamic Client Registration Protocol」[RFC7591] で定義された "response_types" parameter とともに使用されるものと同一である。

response_modes_supported : OPTIONAL。本 Authorization Server がサポートする OAuth 2.0 "response_mode" values の一覧を含む JSON array（[OAuth.Responses] で規定）。省略された場合、default は ["query", "fragment"]。response mode value "form_post" は「OAuth 2.0 Form Post Response Mode」[OAuth.Post] でも定義される。

grant_types_supported : OPTIONAL。本 Authorization Server がサポートする OAuth 2.0 grant type values の一覧を含む JSON array。ここで使用される array values は、「OAuth 2.0 Dynamic Client Registration Protocol」[RFC7591] で定義された "grant_types" parameter とともに使用されるものと同一である。省略された場合、default value は ["authorization_code", "implicit"]。

token_endpoint_auth_methods_supported : OPTIONAL。この token endpoint がサポートする client authentication methods の一覧を含む JSON array。client authentication method values は [RFC7591] の Section 2 で定義される "token_endpoint_auth_method" parameter で用いられる。省略された場合、default は "client_secret_basic"（OAuth 2.0 [RFC6749] の Section 2.3.1 で規定される HTTP Basic Authentication Scheme）である。

token_endpoint_auth_signing_alg_values_supported : OPTIONAL。"private_key_jwt" および "client_secret_jwt" authentication methods において、token endpoint で client を認証するために使用される JWT [JWT] の signature のために、token endpoint がサポートする JWS signing algorithms（"alg" values）の一覧を含む JSON array。これらの authentication methods のいずれかが "token_endpoint_auth_methods_supported" entry に指定されている場合、この metadata entry は存在しなければならない (MUST)。この entry が省略された場合、default algorithms は暗黙に示されない。サーバは "RS256" をサポートすべきである (SHOULD)。value "none" は使用してはならない (MUST NOT)。

service_documentation : OPTIONAL。開発者が Authorization Server を利用する際に知りたい、または知る必要がある、人間が読める情報を含むページの URL。特に、Authorization Server が Dynamic Client Registration をサポートしない場合、client を登録する方法に関する情報はこの documentation で提供される必要がある。

ui_locales_supported : OPTIONAL。ユーザインターフェースでサポートされる languages と scripts。BCP 47 [RFC5646] の language tag values の JSON array として表現される。省略された場合、サポートされる languages と scripts の集合は未指定である。

op_policy_uri : OPTIONAL。client を登録する人が、Authorization Server が提供するデータを client がどのように利用できるかに関する Authorization Server の要件を読むために、Authorization Server が提供する URL。登録プロセスは、この URL が与えられている場合、その人に表示すべきである (SHOULD)。Section 5 で述べるとおり、identifier "op_policy_uri" は OpenID 固有に見えるが、本仕様におけるその利用は、OpenID Connect に特有ではない一般的な OAuth 2.0 feature を指す。

op_tos_uri : OPTIONAL。client を登録する人が、Authorization Server の terms of service を読むために、Authorization Server が提供する URL。登録プロセスは、この URL が与えられている場合、その人に表示すべきである (SHOULD)。Section 5 で述べるとおり、identifier "op_tos_uri" は OpenID 固有に見えるが、本仕様におけるその利用は、OpenID Connect に特有ではない一般的な OAuth 2.0 feature を指す。

revocation_endpoint : OPTIONAL。Authorization Server の OAuth 2.0 revocation endpoint [RFC7009] の URL。

revocation_endpoint_auth_methods_supported : OPTIONAL。この revocation endpoint がサポートする client authentication methods の一覧を含む JSON array。有効な client authentication method values は、IANA "OAuth Token Endpoint Authentication Methods" registry [IANA.OAuth.Parameters] に登録されたもの。省略された場合、default は "client_secret_basic"（OAuth 2.0 [RFC6749] の Section 2.3.1 で規定される HTTP Basic Authentication Scheme）である。

revocation_endpoint_auth_signing_alg_values_supported : OPTIONAL。"private_key_jwt" および "client_secret_jwt" authentication methods において、revocation endpoint で client を認証するために使用される JWT [JWT] の signature のために、revocation endpoint がサポートする JWS signing algorithms（"alg" values）の一覧を含む JSON array。これらの authentication methods のいずれかが "revocation_endpoint_auth_methods_supported" entry に指定されている場合、この metadata entry は存在しなければならない (MUST)。この entry が省略された場合、default algorithms は暗黙に示されない。value "none" は使用してはならない (MUST NOT)。

introspection_endpoint : OPTIONAL。Authorization Server の OAuth 2.0 introspection endpoint [RFC7662] の URL。

introspection_endpoint_auth_methods_supported : OPTIONAL。この introspection endpoint がサポートする client authentication methods の一覧を含む JSON array。有効な client authentication method values は、IANA "OAuth Token Endpoint Authentication Methods" registry [IANA.OAuth.Parameters] に登録されたもの、または IANA "OAuth Access Token Types" registry [IANA.OAuth.Parameters] に登録されたもの。（Section 7.2 により、これらの values は相互に区別され、今後も区別されたままである。）省略された場合、サポートされる authentication methods の集合は他の手段で決定されなければならない (MUST)。

introspection_endpoint_auth_signing_alg_values_supported : OPTIONAL。"private_key_jwt" および "client_secret_jwt" authentication methods において、introspection endpoint で client を認証するために使用される JWT [JWT] の signature のために、introspection endpoint がサポートする JWS signing algorithms（"alg" values）の一覧を含む JSON array。これらの authentication methods のいずれかが "introspection_endpoint_auth_methods_supported" entry に指定されている場合、この metadata entry は存在しなければならない (MUST)。この entry が省略された場合、default algorithms は暗黙に示されない。value "none" は使用してはならない (MUST NOT)。

code_challenge_methods_supported : OPTIONAL。本 Authorization Server がサポートする Proof Key for Code Exchange (PKCE) [RFC7636] code challenge methods の一覧を含む JSON array。Code challenge method values は [RFC7636] の Section 4.3 で定義される "code_challenge_method" parameter で用いられる。有効な code challenge method values は、IANA "PKCE Code Challenge Methods" registry [IANA.OAuth.Parameters] に登録されたもの。省略された場合、Authorization Server は PKCE をサポートしない。

Additional Authorization Server metadata parameters も使用され得る (MAY)。いくつかは OpenID Connect Discovery 1.0 [OpenID.Discovery] など他仕様で定義される。

---

2.1. Signed Authorization Server Metadata

JSON elements に加えて、metadata values は "signed_metadata" value としても提供され得る (MAY)。これは、Authorization Server に関する metadata values を bundle として主張する JSON Web Token (JWT) [JWT] である。署名付き metadata で使用できる claims の集合は Section 2 で定義される。signed metadata は JSON Web Signature (JWS) [JWS] を用いてデジタル署名または MAC されなければならず (MUST)、かつ signed metadata の claims に対して attesting する party を示す "iss" (issuer) claim を含まなければならない (MUST)。metadata の consumers は、この feature をサポートしない場合、signed metadata を無視してよい (MAY)。metadata の consumer が signed metadata をサポートする場合、signed metadata で伝達される metadata values は、plain JSON elements で伝達される対応する values より優先されなければならない (MUST)。

Signed metadata は、Authorization Server metadata の JSON object に、次の OPTIONAL member として含まれる。

signed_metadata : Authorization Server に関する metadata values を claims として含む JWT。これは署名付き JWT 全体からなる string value である。"signed_metadata" という metadata value は、JWT 内の claim として現れるべきではない (SHOULD NOT)。

3. Obtaining Authorization Server Metadata

metadata をサポートする Authorization Server は、Section 2 で規定された metadata を含む JSON document を、（もしあれば）Authorization Server の issuer identifier の host component と path component の間に well-known URI string を挿入して形成される path で利用可能にしなければならない (MUST)。デフォルトでは、使用される well-known URI string は "/.well-known/oauth-authorization-server" である。この path は "https" scheme を使用しなければならない (MUST)。".well-known" の構文と意味は RFC 5785 [RFC5785] で定義される。使用される well-known URI suffix は、IANA "Well-Known URIs" registry [IANA.well-known] に登録されていなければならない (MUST)。

OAuth Authorization Server を application-specific な方法で利用する異なる applications は、それぞれの application で使用される Authorization Server metadata を公開するために、異なる well-known URI suffixes を定義して登録し得る。例えば、example application が OAuth Authorization Server を example-specific な方法で使用し、公開すべき example-specific な metadata values がある場合、その application は "example-configuration" URI suffix を登録して使用し、Authorization Server の issuer identifier の host と path components の間に "/.well-known/example-configuration" を挿入して形成される path に metadata document を公開することができる。代替として、多くの applications は default の well-known URI string "/.well-known/oauth-authorization-server" を使用するだろう。これは一般目的の OAuth Authorization Servers に対する正しい選択であり、application-specific なものを登録しない。

本仕様を利用する OAuth 2.0 application は、この目的のためにどの well-known URI suffix を使用するかを指定しなければならない (MUST)。同一の Authorization Server は、issuer identifier から導出される複数の well-known locations に metadata を公開することを選択してよい (MAY)。例えば、"/.well-known/example-configuration" と "/.well-known/oauth-authorization-server" の両方に公開する、といった具合である。

いくつかの OAuth applications は well-known URI suffix "openid-configuration" を使用することを選択するだろう。Section 5 で述べるとおり、identifier "/.well-known/openid-configuration" は OpenID 固有に見えるが、本仕様におけるその利用は、OpenID Connect に特有ではない一般的な OAuth 2.0 feature を指している。

3.1. Authorization Server Metadata Request

Authorization Server metadata document は、前述の指定された path に対する HTTP "GET" request を用いて照会されなければならない (MUST)。

client は、issuer identifier が "https://example.com" で、well-known URI suffix が "oauth-authorization-server" のとき、issuer identifier に path component が含まれないため、metadata を取得するために次の request を行う。

GET /.well-known/oauth-authorization-server HTTP/1.1
Host: example.com

issuer identifier の値に path component が含まれる場合、host component と path component の間に "/.well-known/" と well-known URI suffix を挿入する前に、末尾の "/" は削除されなければならない (MUST)。client は、issuer identifier が "https://example.com/issuer1" で、well-known URI suffix が "oauth-authorization-server" のとき、issuer identifier に path component が含まれるため、metadata を取得するために次の request を行う。

GET /.well-known/oauth-authorization-server/issuer1 HTTP/1.1
Host: example.com

path components を用いることで、1つの host に対して複数の issuers をサポートできる。これは一部の multi-tenant hosting configurations で必要となる。この ".well-known" の利用は、1 host あたり複数 issuers をサポートするためのものである。RFC 5785 [RFC5785] における利用とは異なり、host に関する一般情報を提供するものではない。

3.2. Authorization Server Metadata Response

response は Authorization Server の configuration に関する claims の集合であり、必要なすべての endpoints と public key location 情報を含む。成功 response は 200 OK HTTP status code を使用しなければならず (MUST)、また "application/json" content type を用いて JSON object を返さなければならない (MUST)。この JSON object は、その members として claims の集合を含み、Section 2 で定義された metadata values の部分集合である。その他の claims も返され得る (MAY)。

複数の値を返す claims は JSON arrays として表現される。要素数がゼロの claims は response から省略されなければならない (MUST)。

error response は、該当する HTTP status code 値を用いる。

以下は非規範的な 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"]
}

3.3. Authorization Server Metadata Validation

返された "issuer" value は、metadata を取得するために用いられた URL を作成する際に well-known URI string が挿入された、Authorization Server の issuer identifier value と同一でなければならない (MUST)。これらの values が同一でない場合、response に含まれるデータは使用してはならない (MUST NOT)。

4. String Operations

一部の OAuth 2.0 messages の処理では、messages 内の values を既知の values と比較する必要がある。例えば、metadata response 内の member names を "issuer" のような特定の member names と比較する、といった具合である。しかし、Unicode [UNICODE] strings の比較には重大なセキュリティ上の含意がある。

したがって、JSON strings とその他の Unicode strings の間の比較は、以下に規定するように実施されなければならない (MUST)。

1. JSON に適用された escaping を除去し、Unicode code points の配列を生成する。
2. Unicode Normalization [USA15] は、JSON string に対しても、比較対象となる string に対しても、いかなる時点でも適用してはならない (MUST NOT)。
3. 2つの strings の比較は、Unicode code point ごとの等価比較として実施されなければならない (MUST)。

これは [RFC8259] の Section 8.3 で記述される等価比較手順と同じである。

5. Compatibility Notes

identifiers "/.well-known/openid-configuration"、"op_policy_uri"、および "op_tos_uri" は、もともと "OpenID Connect Discovery 1.0" [OpenID.Discovery] によって定義された OpenID Connect [OpenID.Core] 仕様群に言及する文字列を含む。これらの identifiers の再利用は OpenID 固有に見えるが、本仕様におけるそれらの利用は、OpenID Connect に特有ではない一般的な OAuth 2.0 features を指している。

Section 3 で定義された、issuer identifier を Authorization Server metadata location に変換する algorithm は、issuer identifier に path component が含まれない限り、"OpenID Connect Discovery 1.0" [OpenID.Discovery] の Section 4 で定義された対応する変換と等価である。しかし path component がある場合は異なる。なぜなら OpenID Connect Discovery 1.0 は well-known URI string を issuer identifier に付加する（例: "https://example.com/issuer1/.well-known/openid-configuration"）のに対し、本仕様は well-known URI string を issuer identifier の path component の前に挿入する（例: "https://example.com/.well-known/openid-configuration/issuer1"）と規定するからである。

今後、OAuth Authorization Server metadata locations は本仕様で定義される変換を用いるべきである。しかし、OpenID Connect Discovery 1.0 の変換が既に使用されている legacy environments に展開される場合、移行期間中は、path component を含む issuer identifiers に対して両方の locations に metadata を公開する必要があるかもしれない。移行期間中、applications はまず本仕様で定義される変換を適用し、得られた location から Authorization Server metadata を取得しようと試みるべきである。そこからの取得が失敗した場合に限り、"OpenID Connect Discovery 1.0" によって定義される変換で得られる alternate location からの取得へフォールバックするべきである。この後方互換の挙動が必要となるのは、application により用いられる well-known URI suffix が "openid-configuration" の場合に限られるはずである。

6. Security Considerations

6.1. TLS Requirements

Implementations は TLS をサポートしなければならない (MUST)。どの version(s) を実装すべきかは、実装時点における広範な展開状況および既知のセキュリティ脆弱性に依存して、時間とともに変化し得る。Authorization Server は TLS version 1.2 [RFC5246] をサポートしなければならず (MUST)、その security requirements を満たす追加の TLS mechanisms をサポートしてもよい (MAY)。TLS を用いる場合、client は RFC 6125 [RFC6125] に従い TLS/SSL server certificate check を実行しなければならない (MUST)。Implementation に関するセキュリティの考慮事項は "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)" [BCP195] に記載される。

情報漏えいおよび改ざんから保護するために、confidentiality と integrity protection を提供する ciphersuite を用いた TLS により、confidentiality protection を適用しなければならない (MUST)。

6.2. Impersonation Attacks

Authorization Server metadata request を行う際、client は Section 6.1 で記述されるとおり TLS certificate checking を実施しなければならない (MUST)。server certificate が issuer identifier URL に対して有効であることを確認することで、man-in-middle および DNS-based attacks を防止する。これらの attacks は、client を騙して攻撃者の keys と endpoints を使用させ、正当な Authorization Server のなりすましを可能にし得る。攻撃者がこれを達成できる場合、攻撃者は、なりすましている Authorization Server を用いて、影響を受けた client がアクセスできる resources にアクセスできる。

攻撃者はまた、なりすます対象の Authorization Server の issuer identifier URL を用いた "issuer" claim を含みつつ、endpoints と signing keys は攻撃者自身のものを含む metadata document を公開することで Authorization Server をなりすまそうとするかもしれない。もし client に受け入れられれば、これにより当該 Authorization Server のなりすましが可能となる。これを防ぐために、client は metadata request の prefix として使用している issuer identifier URL が、client が受け取った Authorization Server metadata document に含まれる "issuer" metadata value と正確に一致することを確実にしなければならない (MUST)。

6.3. Publishing Metadata in a Standard Format

Authorization Server に関する情報を標準形式で公開することは、正当な clients と攻撃者の双方にとって Authorization Server を利用しやすくする。Authorization Server が metadata を ad hoc な方法で公開するか、本仕様で定義される標準形式で公開するかに関わらず、この情報を用いて行われ得る attacks に対する同じ防御策を適用すべきである。

6.4. Protected Resources

Authorization Server とともに使用する適切な Protected Resources を安全に決定することは、本仕様のスコープ外である。本仕様は、client が Authorization Server とともに使用する適切な Protected Resources を決定する手段を持ち、かつ client が各 Authorization Server に対して正しい metadata を使用していることを前提とする。実装者は、client により不適切な Protected Resource が使用されると、攻撃者が、それが Authorization Server または client に検出されることなく、有効な Protected Resource への man-in-the-middle proxy として振る舞える可能性があることを認識する必要がある。

Authorization Server とともに使用する適切な Protected Resources を決定する方法は、一般に application dependent である。例えば、いくつかの Authorization Servers は固定の Protected Resource（またはその集合）とともに使用され、その locations は well known であるか、あるいは Authorization Server により metadata values として公開され得る。別のケースでは、Authorization Server とともに使用できる resources の集合が、管理上の actions により動的に変更され得る。Authorization Servers と Protected Resources の適切な関連付けを決定する他の多くの手段も可能である。

7. IANA Considerations

本仕様で設立される registry には、以下の登録手順が用いられる。

values は Specification Required [RFC8126] に基づき、oauth-ext-review@ietf.org mailing list 上での2週間の review period の後、1名以上の Designated Experts の助言のもと登録される。しかし、publication 前の値の割り当てを可能にするため、Designated Experts は、そのような仕様が publication されると満足した時点で登録を承認してよい。

review のために mailing list に送られる registration requests は、適切な subject（例: "Request to register OAuth Authorization Server Metadata: example"）を使用すべきである。

review period 内に、Designated Experts は registration request を approve または deny し、この決定を review list と IANA に伝える。denials には説明を含め、該当する場合は request を成功させるための提案を含めるべきである。21日を超えて undetermined な registration requests は、解決のために IESG の注意を喚起できる（iesg@ietf.org mailing list を用いる）。

Designated Experts が適用すべき criteria には、提案された registration が既存 functionality の重複であるかの判断、general applicability が高い見込みがあるか、あるいは単一 application にのみ有用かの判断、そして registration が妥当であるかの判断が含まれる。

IANA は Designated Experts からの registry updates のみを受け付けなければならず (MUST)、registration の requests はすべて review mailing list に向けるべきである。

登録決定の broadly-informed review を可能にするため、本仕様を利用する異なる applications の perspectives を代表できる複数の Designated Experts を任命することが提案される。registration decision が特定の Designated Expert にとって conflict of interest を生み得ると見なされる場合、その Designated Expert は他の Designated Experts の judgment に委ねるべきである。

7.1. OAuth Authorization Server Metadata Registry

本仕様は、OAuth 2.0 Authorization Server metadata names のための IANA "OAuth Authorization Server Metadata" registry を設立する。この registry は Authorization Server metadata member と、それを定義する specification への reference を記録する。

Designated Experts は次のいずれかを行わなければならない (MUST)。

(a) 登録される metadata names と values が、double quote ('"') と backslash ('\') を除く printable ASCII characters のみ（code points が U+0021、U+0023 から U+005B、U+005D から U+007E の Unicode characters）を使用することを要求する、または

(b) 他の code points を使用する新しい metadata members または values が定義される場合、それらの definitions が、それらを表現するために使用される Unicode code points の exact sequences を指定することを要求する。さらに、escaped characters としてしか JSON strings で表現できない Unicode code points を使用する proposed registrations は受け付けてはならない (MUST NOT)。

7.1.1. Registration Template

Metadata Name: : 要求される name（例: "issuer"）。この name は case-sensitive である。Designated Experts が例外を認めるべき compelling reason があると述べない限り、names は case-insensitive な方法（両方の strings に Unicode の toLowerCase() operation を適用した場合に一致するような方法）で他の registered names と一致してはならない。

Metadata Description: : metadata の brief description（例: "Issuer identifier URL"）。

Change Controller: : Standards Track RFCs については "IESG" を列挙する。その他については responsible party の name を記載する。その他の details（例: postal address、email address、home page URI）を含めてもよい。

Specification Document(s): : parameter を規定する document または documents への reference。望ましくは documents の copies を取得できる URIs を含める。relevant sections の指示を含めてもよいが必須ではない。

7.1.2. Initial Registry Contents

• 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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

7.2. Updated Registration Instructions

本仕様は、いずれも "OAuth Parameters" registry [IANA.OAuth.Parameters] 内にある次の IANA registries の Designated Experts に対する instructions を追加する。

• OAuth Access Token Types
• OAuth Token Endpoint Authentication Methods

IANA は、これら registries の Reference sections に、本仕様への link を追加した。

これら registries について、Designated Experts は、一方の registry における registration requests で、他方の registry に既に存在する values を登録しようとするものを拒否しなければならない (MUST)。これは "introspection_endpoint_auth_methods_supported" parameter が、どちらの registry の values も使用できるためである。そうすることで、2つの registries の values が今後も相互排他的であり続けるため、ambiguities は生じない。

7.3. Well-Known URI Registry

本仕様は、Section 3 で定義された well-known URI を、RFC 5785 [RFC5785] により設立された IANA "Well-Known URIs" registry [IANA.well-known] に登録する。

7.3.1. Registry Contents

• o URI suffix: oauth-authorization-server
• o Change controller: IESG
• o Specification document: Section 3 of RFC 8414
• o Related information: (none)

8. References

8.1. Normative References

[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.

[IANA.OAuth.Parameters] IANA, "OAuth Parameters", 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.

[JWK] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, 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.

[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.

[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.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.

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[UNICODE] The Unicode Consortium, "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/.

8.2. Informative References

[IANA.well-known] IANA, "Well-Known URIs", 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.

[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.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.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.

Acknowledgements

本仕様は OpenID Connect Discovery 1.0 specification に基づいており、これは OpenID Foundation の OpenID Connect working group により作成された。本仕様は、OpenID Connect Discovery により定義された metadata format の de facto usage を標準化し、OAuth Authorization Server metadata を公開する。

著者らは、本仕様の reviews を行った以下の人々に感謝する: 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, Hans Zandbelt.

Authors' Addresses

Michael B. Jones\ Microsoft\ 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/