OAuth 2.0 Dynamic Client Registration Protocol

Internet Engineering Task Force (IETF)                    J. Richer, Ed.
Request for Comments: 7591
Category: Standards Track                                       M. Jones
ISSN: 2070-1721                                                Microsoft
                                                              J. Bradley
                                                           Ping Identity
                                                             M. Machulak
                                                    Newcastle University
                                                                 P. Hunt
                                                      Oracle Corporation
                                                               July 2015

Abstract

この仕様は、authorization server に対して OAuth 2.0 client を動的に登録するための仕組みを定義する。登録要求では、望ましい client のメタデータ値一式を authorization server に送信する。登録応答では、authorization server で使用するための client identifier と、その client に登録された client メタデータ値を返す。client は、その登録情報を使って、OAuth 2.0 プロトコルにより authorization server と通信できるようになる。さらに本仕様は、登録時に client が使用する共通の client メタデータ・フィールドと値の集合も定義する。

Status of This Memo

本書は Internet Standards Track 文書である。

本書は Internet Engineering Task Force (IETF) の成果物である。IETF コミュニティの合意を示している。公開レビューを受け、Internet Engineering Steering Group (IESG) によって刊行が承認された。Internet Standards に関する追加情報は RFC 5741 の Section 2 にある。

本書の現在のステータス、正誤表（errata）、およびフィードバックの提供方法に関する情報は、以下から入手できる。 http://www.rfc-editor.org/info/rfc7591

Copyright Notice

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

本書は、刊行日に有効な BCP 78 および IETF Trust の「IETF Documents に関する法的規定」 (http://trustee.ietf.org/license-info) の対象となる。これらの文書を注意深く確認してほしい。これらは、本書に関する権利および制約を説明している。本書から抽出される Code Components は、Trust Legal Provisions の Section 4.e で述べられている Simplified BSD License の文言を含めなければならず、また Simplified BSD License で述べられているとおり、無保証で提供される。

Table of Contents

• OAuth 2.0 Dynamic Client Registration Protocol
  • Abstract
  • Status of This Memo
  • Copyright Notice
  • Table of Contents
  • 1. Introduction
  • 1.1. Notational Conventions
  • 1.2. Terminology
  • 1.3. Protocol Flow
  • 2. Client Metadata
  • 2.1. Relationship between Grant Types and Response Types
  • 2.2. Human-Readable Client Metadata
  • 2.3. Software Statement
  • 3. Client Registration Endpoint
  • 3.1. Client Registration Request
  • 3.1.1. Client Registration Request Using a Software Statement
  • 3.2. Responses
  • 3.2.1. Client Information Response
  • 3.2.2. Client Registration Error Response
  • 4. IANA Considerations
  • 4.1. OAuth Dynamic Client Registration Metadata Registry
  • 4.1.1. Registration Template
  • 4.1.2. Initial Registry Contents
  • 4.2. OAuth Token Endpoint Authentication Methods Registry
  • 4.2.1. Registration Template
  • 4.2.2. Initial Registry Contents
  • 5. Security Considerations
  • 6. Privacy Considerations
  • 7. References
  • 7.1. Normative References
  • 7.2. Informative References
  • Appendix A. Use Cases
  • A.1. Open versus Protected Dynamic Client Registration
  • A.1.1. Open Dynamic Client Registration
  • A.1.2. Protected Dynamic Client Registration
  • A.2. Registration without or with Software Statements
  • A.2.1. Registration without a Software Statement
  • A.2.2. Registration with a Software Statement
  • A.3. Registration by the Client or Developer
  • A.3.1. Registration by the Client
  • A.3.2. Registration by the Developer
  • A.4. Client ID per Client Instance or per Client Software
  • A.4.1. Client ID per Client Software Instance
  • A.4.2. Client ID Shared among All Instances of Client Software
  • A.5. Stateful or Stateless Registration
  • A.5.1. Stateful Client Registration
  • A.5.2. Stateless Client Registration
  • Acknowledgments
  • Authors' Addresses

1. Introduction

OAuth 2.0 [RFC6749] client が OAuth 2.0 authorization server を利用するためには、その server とやり取りするための特定の情報が必要である。これには、その server で使用する OAuth 2.0 client identifier も含まれる。本仕様は、この情報を得るために、OAuth 2.0 client が authorization server に動的に登録できる方法を述べる。

登録プロセスの一部として、本仕様は、client が authorization server に対して、有効な redirection URI 群などのメタデータ一式を提示する仕組みも定義する。このメタデータは、自己申告（self-asserted）として伝達することもできるし、software statement と呼ばれるメタデータ一式として伝達することもできる。software statement は、デジタル署名されるか、Message Authentication Code (MAC) により保護される。software statement の場合、issuer が client に関するデータの妥当性を保証していることになる。

従来、authorization server に client を登録する作業は手動で行われてきた。本仕様で定義する仕組みは、client が自分自身を authorization server に動的登録する用途にも、client developer が authorization server に対してプログラムで client を登録する用途にも使用できる。OAuth 2.0 を使う複数のアプリケーションは、これまで同様の登録を行うための仕組みを個別に実装してきた。本仕様は、それらのうち「OpenID Connect Dynamic Client Registration 1.0」[OpenID.Registration] で定義され「User Managed Access (UMA) Profile of OAuth 2.0」[UMA-Core] で使用されている登録メカニズムを一般化し、両者と互換でありつつ、より広い OAuth 2.0 のユースケースに適用できる形にする。

1.1. Notational Conventions

本書におけるキーワード 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', 'OPTIONAL' は、[RFC2119] に記載されているとおりに解釈される。

特に断りがない限り、すべてのプロトコル・パラメータ名および値は大文字小文字を区別する。

1.2. Terminology

本仕様は、OAuth 2.0 [RFC6749] で定義されている "access token", "authorization code", "authorization endpoint", "authorization grant", "authorization server", "client", "client identifier", "client secret", "grant type", "protected resource", "redirection URI", "refresh token", "resource owner", "resource server", "response type", "token endpoint" を用いる。また、JSON Web Token (JWT) [RFC7519] で定義されている "Claim" という用語を用いる。

本仕様は以下の用語を定義する。

Client Software
OAuth 2.0 client を実装するソフトウェア。

Client Instance
ある client software の、配備されたインスタンス。

Client Developer
client software パッケージを作成し、配布に向けて準備する個人または組織。client がビルドされる時点では、配備するサービスプロバイダ組織が誰になるかを developer が把握していないことが多い。client developer は、コンパイル時点では配備 URL などソフトウェアの側面を予測できない場合に dynamic registration を使う必要がある。たとえば、ソフトウェア API の publisher と配備する組織が同一ではない場合に起こり得る。

Client Registration Endpoint
client を authorization server に登録できる OAuth 2.0 endpoint。本 endpoint の URL をどのように取得するかは、本仕様のスコープ外である。

Initial Access Token
developer または client に対して authorization server が（任意で）発行する OAuth 2.0 access token。client registration endpoint への呼び出しを認可するために用いられる。この token の種別および形式はサービス固有である可能性が高く、本仕様のスコープ外である。authorization server がこの token を発行する方法、および registration endpoint がこの token を検証する方法も、本仕様のスコープ外である。authorization server が client を登録できる主体を制限する場合、initial access token の使用が必要となる。

Deployment Organization
ソフトウェア API（サービス）が配備され、OAuth 2.0 フレームワークにより保護される、管理上のセキュリティドメイン。OAuth のシナリオによっては、deployment organization とソフトウェア API publisher が同一である場合がある。その場合、配備組織は client software developer と密接な関係を持つことが多い。多くの他のケースでは、サービスの定義者は独立した第三者 publisher や標準化団体であることがある。公開仕様に基づく API に取り組む場合、client software developer は、そのソフトウェア API（サービス）を配備する可能性がある多数の deployment organization と、事前の関係を持てない。

Software API Deployment
特定の deployment organization ドメインにおいて、OAuth 2.0（protected resource）により保護されているソフトウェア API の配備インスタンス。あるソフトウェア API について、配備は 1 つ以上存在し得る。software API deployment は通常、対応する OAuth 2.0 authorization server と client registration endpoint を持つ。endpoint をどのように取得するかは、本仕様のスコープ外である。

Software API Publisher
特定の web からアクセス可能な API を定義し、それを 1 つ以上の配備環境に配備できるようにする組織。publisher は、標準化団体、営利、公共、私的、オープンソースのいずれの組織でもよく、OAuth 2.0 を介して保護され得るソフトウェアおよび API 仕様の公開・配布に責任を持つ。場合によっては software API publisher と client developer が同一組織であることもある。web からアクセス可能な API を公開する時点では、software publisher は配備組織と事前の関係を持たないことが多い。

Software Statement
client software に関するメタデータ値を主張する、デジタル署名または MAC 済みの JSON Web Token (JWT) [RFC7519]。場合によっては software statement は client developer により直接発行される。他の場合には、client developer が使用できるよう第三者組織によって発行される。いずれの場合も、authorization server が software statement の issuer と持つ信頼関係は、登録要求を受け入れるかどうかを評価する際の入力として使われる意図がある。software statement は client registration request の一部として authorization server に提示できる。

1.3. Protocol Flow

      +--------(A)- Initial Access Token (OPTIONAL)
      |
      |   +----(B)- Software Statement (OPTIONAL)
      |   |
      v   v
  +-----------+                                      +---------------+
  |           |--(C)- Client Registration Request -->|    Client     |
  | Client or |                                      | Registration  |
  | Developer |<-(D)- Client Information Response ---|   Endpoint    |
  |           |        or Client Error Response      +---------------+
  +-----------+

 Figure 1: Abstract Dynamic Client Registration Flow

Figure 1 に示す抽象的な OAuth 2.0 client の dynamic registration フローは、client または developer と、本仕様で定義される endpoint の間のやり取りを説明している。この図はエラー条件を示していない。このフローは以下のステップを含む。

(A) 任意で、client または developer に対し、client registration endpoint へのアクセス権を与える initial access token が発行される。initial access token が client または developer に発行される方法は、本仕様のスコープ外である。

(B) 任意で、client または developer に対し、client registration endpoint で使用する software statement が発行される。software statement が client または developer に発行される方法は、本仕様のスコープ外である。

(C) client または developer は、client registration endpoint を呼び出し、client が望む登録メタデータを送信する。authorization server により (A) の initial access token が要求される場合は、任意でそれを含める。

(D) authorization server は client を登録し、以下を返す。

• client の登録済みメタデータ
• server 内で一意な client identifier
• 当該 client に適用可能であれば、client secret などの client credentials 一式

異なる構成や利用方法の例は Appendix A に含まれている。

2. Client Metadata

登録された client には、authorization server における client identifier に紐づくメタデータ値一式がある。たとえば、有効な redirection URI 群の一覧や表示名などである。

これらの client メタデータ値は 2 つの形で使われる。

• 登録要求の入力値として
• 登録応答の出力値として

以下の client メタデータ・フィールドを本仕様は定義する。特に明記されない限り、すべての client メタデータ・フィールドの実装および使用は OPTIONAL である。すべてのデータメンバ型（文字列、配列、数値）は、JSON [RFC7159] の表現に基づいて定義される。

redirect_uris
redirect ベースのフロー（authorization code および implicit フローなど）で使用する redirection URI 文字列の配列。OAuth 2.0 [RFC6749] の Section 2 が要求するとおり、redirection を使うフローを用いる client は、その redirection URI 値を登録しなければならない（MUST）。redirect ベースのフローに対して dynamic registration をサポートする authorization server は、このメタデータ値のサポートを実装しなければならない（MUST）。

token_endpoint_auth_method
token endpoint に対する、要求される認証方式を示す文字列。 本仕様で定義される値は以下である。

• "none": OAuth 2.0 の Section 2.1 で定義される Public client であり、client secret を持たない。
• "client_secret_post": OAuth 2.0 の Section 2.3.1 で定義される HTTP POST パラメータを使用する。
• "client_secret_basic": OAuth 2.0 の Section 2.3.1 で定義される HTTP Basic を使用する。

追加の値は、Section 4.2 で確立される IANA の "OAuth Token Endpoint Authentication Methods" レジストリにより定義できる。登録せずに Absolute URI をこのパラメータの値として用いることもできる。指定されない、または省略される場合のデフォルトは "client_secret_basic" であり、OAuth 2.0 の Section 2.3.1 で規定される HTTP Basic 認証方式を指す。

grant_types
client が token endpoint で利用できる OAuth 2.0 grant type 文字列の配列。これらの grant type は以下のとおり定義される。

• "authorization_code": OAuth 2.0 の Section 4.1 で定義される authorization code grant type。
• "implicit": OAuth 2.0 の Section 4.2 で定義される implicit grant type。
• "password": OAuth 2.0 の Section 4.3 で定義される resource owner password credentials grant type。
• "client_credentials": OAuth 2.0 の Section 4.4 で定義される client credentials grant type。
• "refresh_token": OAuth 2.0 の Section 6 で定義される refresh token grant type。
• "urn:ietf:params:oauth:grant-type:jwt-bearer": OAuth JWT Bearer Token Profiles [RFC7523] で定義される JWT Bearer Token Grant Type。
• "urn:ietf:params:oauth:grant-type:saml2-bearer": OAuth SAML 2 Bearer Token Profiles [RFC7522] で定義される SAML 2.0 Bearer Assertion Grant。

token endpoint が当該 grant type で使用される場合、このパラメータの値は、その grant type 定義において token endpoint に渡される "grant_type" パラメータの値と同一でなければならない（MUST）。authorization server は、OAuth 2.0 の Section 4.5 で述べられる grant type 拡張プロセスにより定義される他の値を許可してよい（MAY）。省略された場合のデフォルト動作は、client が "authorization_code" Grant Type のみを使用する、というものである。

response_types
client が authorization endpoint で利用できる OAuth 2.0 response type 文字列の配列。これらの response type は以下のとおり定義される。

• "code": OAuth 2.0 の Section 4.1 で定義される authorization code response type。
• "token": OAuth 2.0 の Section 4.2 で定義される implicit response type。

authorization endpoint が当該 grant type で使用される場合、このパラメータの値は、その grant type 定義において authorization endpoint に渡される "response_type" パラメータの値と同一でなければならない（MUST）。authorization server は、OAuth 2.0 の Section 4.5 で述べられる grant type 拡張プロセスにより定義される他の値を許可してよい（MAY）。省略された場合のデフォルトは、client が "code" response type のみを使用する、というものである。

client_name
authorization の際に end-user に提示される、人が読める client 名の文字列。省略された場合、authorization server は代わりに raw な "client_id" 値を end-user に表示してよい（MAY）。client は常にこのフィールドを送ることが RECOMMENDED である。このフィールドの値は、Section 2.2 に記載のとおり国際化してよい（MAY）。

client_uri
client に関する情報を提供する web ページの URL 文字列。存在する場合、server はこの URL を end-user に対してクリック可能な形で表示すべきである（SHOULD）。client は常にこのフィールドを送ることが RECOMMENDED である。このフィールドの値は有効な web ページを指さなければならない（MUST）。このフィールドの値は、Section 2.2 に記載のとおり国際化してよい（MAY）。

logo_uri
client のロゴを参照する URL 文字列。存在する場合、server は承認時にこの画像を end-user に表示すべきである（SHOULD）。このフィールドの値は有効な画像ファイルを指さなければならない（MUST）。このフィールドの値は、Section 2.2 に記載のとおり国際化してよい（MAY）。

scope
client が Access Token の要求時に使用できる scope 値の、空白区切りリストを含む文字列（OAuth 2.0 [RFC6749] の Section 3.3 で述べられる）。このリスト中の値の意味はサービス固有である。省略された場合、authorization server はデフォルトの scope 一式で client を登録してよい（MAY）。

contacts
この client の責任者に連絡する方法（典型的には email address）を表す文字列の配列。authorization server は、client に対するサポート要求のために、これらの連絡先を end-user に提示してよい（MAY）。Privacy Considerations に関する情報は Section 6 を参照。

tos_uri
end-user が client を認可する際に同意する、end-user と client の契約関係を記述した、読める形の terms of service 文書を指す URL 文字列。提供されている場合、authorization server はこの URL を end-user に表示すべきである（SHOULD）。このフィールドの値は有効な web ページを指さなければならない（MUST）。このフィールドの値は、Section 2.2 に記載のとおり国際化してよい（MAY）。

policy_uri
deployment organization が個人データをどのように収集・使用・保持・開示するかを記述した、読める形の privacy policy 文書を指す URL 文字列。提供されている場合、authorization server はこの URL を end-user に表示すべきである（SHOULD）。このフィールドの値は有効な web ページを指さなければならない（MUST）。このフィールドの値は、Section 2.2 に記載のとおり国際化してよい（MAY）。

jwks_uri
client の公開鍵を含む JSON Web Key (JWK) Set [RFC7517] 文書を参照する URL 文字列。このフィールドの値は、有効な JWK Set 文書を指さなければならない（MUST）。これらの鍵は、署名や暗号化を用いる上位プロトコルで使用できる。たとえば、JWT を用いた client 認証 [RFC7523] を使う場合に、token endpoint への署名付き要求を検証するために使用され得る。このパラメータは "jwks" パラメータよりも推奨される。鍵のローテーションを容易にできるためである。"jwks_uri" と "jwks" は同一の request または response に同時に存在してはならない（MUST NOT）。

jwks
client の JSON Web Key Set [RFC7517] 文書値であり、client の公開鍵を含む。このフィールドの値は、有効な JWK Set を含む JSON object でなければならない（MUST）。これらの鍵は、署名や暗号化を用いる上位プロトコルで使用できる。このパラメータは、"jwks_uri" パラメータを使えない client（たとえば公開 URL をホストできない native client）で使用する意図がある。"jwks_uri" と "jwks" は同一の request または response に同時に存在してはならない（MUST NOT）。

software_id
登録 endpoint が、動的登録される client software を識別するために、client developer または software publisher によって割り当てられる一意な識別子文字列（例: Universally Unique Identifier (UUID)）。authorization server によって発行され、インスタンス間で変わるべき（SHOULD） "client_id" と異なり、"software_id" は client software のすべてのインスタンスで同一であるべきである（SHOULD）。"software_id" は、同一ソフトウェアの複数回の更新やバージョン間でも同一であるべきである（SHOULD）。このフィールドの値は人が読む用途を想定しておらず、通常は client と authorization server から見ると不透明である。

software_version
"software_id" で識別される client software のバージョン識別子文字列。"software_version" の値は、同じ "software_id" で識別される client software が更新されるたびに変わるべきである（SHOULD）。このフィールドの値は文字列の等価比較で比較される意図があり、それ以外の比較の意味論は本仕様では定義しない。このフィールドの値の内容は本仕様のスコープ外であるが、人が読む用途を想定しておらず、通常は client と authorization server から見ると不透明である。どのような更新がこの値の変更を引き起こすかの定義は、ソフトウェア固有であり本仕様のスコープ外である。

本仕様の拡張やプロファイルは、本書の Section 4 の IANA Considerations に従って登録されたメタデータ名と説明により、この一覧を拡張できる。authorization server は、client が送信した client メタデータのうち理解できないものを無視しなければならない（MUST）（たとえば処理中に未知のメタデータを黙って削除する）。authorization server は、要求された client メタデータ値を、Section 3.2.1 に記載の適切なデフォルト値に置き換えることで拒否してよい（MAY）。または、Section 3.2.2 に記載の error response を返して拒否してよい（MAY）。

client メタデータ値は、Section 3.1 に記載のとおり登録要求の本文で直接伝達することもできるし、Section 2.3 に記載のとおり software statement 内の claims として含めることもできる。両方を混在させることも可能である。同一の client メタデータ名が両方に存在し、かつ software statement が authorization server に信頼されている場合、software statement 内の claim の値が優先されなければならない（MUST）。

2.1. Relationship between Grant Types and Response Types

上記の "grant_types" と "response_types" の値は、OAuth プロトコルにおいて異なる endpoint に渡される引数を指すため、部分的には独立である。しかし、client が利用可能な "grant_types" は client が使用を許可される "response_types" に影響し、またその逆も成り立つという意味で、両者は関係している。たとえば、"grant_types" に "authorization_code" が含まれることは、"response_types" に "code" が含まれることを意味する。どちらも OAuth 2.0 の authorization code grant の一部として定義されているためである。このため、これらのフィールドをサポートする server は、client が矛盾した状態で登録されないようにするための手段を講じるべきである（SHOULD）。たとえば、矛盾した登録要求に対し "invalid_client_metadata" error response を返す、などである。

両フィールドの対応関係は以下の表に示す。

+-----------------------------------------------+-------------------+
| grant_types value includes:                   | response_types    |
|                                               | value includes:   |
+-----------------------------------------------+-------------------+
| authorization_code                            | code              |
| implicit                                      | token             |
| password                                      | (none)            |
| client_credentials                            | (none)            |
| refresh_token                                 | (none)            |
| urn:ietf:params:oauth:grant-type:jwt-bearer   | (none)            |
| urn:ietf:params:oauth:grant-type:saml2-bearer | (none)            |
+-----------------------------------------------+-------------------+

本書の拡張やプロファイルで、"grant_types" または "response_types" のいずれかに新しい値を導入するものは、これら 2 種のパラメータ型の間のすべての対応関係を文書化しなければならない（MUST）。

2.2. Human-Readable Client Metadata

人が読める client メタデータ値、および人が読める値を参照する client メタデータ値は、複数の言語や文字体系で表現してよい（MAY）。たとえば、"client_name", "tos_uri", "policy_uri", "logo_uri", "client_uri" といったフィールドの値は、異なる場所での利用を容易にするために、ある登録内で複数の locale 固有の値を持ち得る。

言語と文字体系を指定するため、BCP 47 [RFC5646] の language tag を client メタデータのメンバ名に付与し、"#" 文字で区切る。JSON [RFC7159] のメンバ名は大文字小文字を区別するため、Claim Name に用いる language tag 値は、"IANA Language Subtag" レジストリ [IANA.Language] に登録されている文字大小で綴ることが RECOMMENDED である。特に、通常、言語名は小文字、地域名は大文字、言語は混在ケースで綴られる。ただし、BCP 47 の language tag 値は大文字小文字を区別しないため、実装は、提供された language tag 値を大文字小文字非依存に解釈するべきである（SHOULD）。BCP 47 の推奨に従い、メタデータのメンバ名に用いる language tag 値は必要な範囲でのみ具体的であるべきである。たとえば多くの文脈では "fr-CA" や "fr-FR" よりも "fr" で十分であり得る。

たとえば client は、英語の名称を "client_name#en": "My Client" として表現し、日本語の名称を "client_name#ja-Jpan-JP": "u30AFu30E9u30A4u30A2u30F3u30C8u540D" として、同一の登録要求内に含めることができる。authorization server は、authorization のステップにおいて、resource owner に対して、これらの名称の任意のもの、またはすべてを表示してよい（MAY）。どの名称を表示するかは、システム設定、ユーザの好み、その他の要因に基づいて選択できる。

人が読めるフィールドが language tag なしで送られた場合、それを使用する当事者は、文字列値の言語、文字集合、文字体系について何らの前提も置いてはならず（MUST NOT）、ユーザインタフェースに提示する場所では文字列値をそのまま使用しなければならない（MUST）。相互運用性を促進するため、client と server は、language 固有フィールドに加えて、language tag を持たない人が読めるフィールドも使用することが RECOMMENDED である。また、language tag なしで送られる人が読めるフィールドは、幅広いシステムで表示するのに適した値を含むことが RECOMMENDED である。

実装者への注記: 多くの JSON ライブラリは、JSON object のメンバを、ライブラリのネイティブなプログラミング環境のオブジェクト構成のメンバとして参照できる。しかし、"#" 文字は JSON object のメンバ名としては有効である一方、多くのプログラミング環境ではオブジェクト・メンバ名として使えない。したがって実装は、これらの claims に対して代替のアクセス形式を使う必要がある。たとえば JavaScript では、"var j = JSON.parse(json);" のように JSON をパースした場合、回避策として "client_name#en-us" というメンバは JavaScript の構文 "j["client_name#en-us"]" でアクセスできる。

2.3. Software Statement

software statement は、client software についてのメタデータ値を束ねて主張する JSON Web Token (JWT) [RFC7519] である。software statement で使用できる claims の集合は Section 2 で定義される。client registration request の一部として authorization server に提示される場合、software statement は JSON Web Signature (JWS) [RFC7515] によりデジタル署名されるか MAC 済みで保護されなければならず（MUST）、software statement 内の claims に対して証明する主体を示す "iss"（issuer）claim を含まなければならない（MUST）。software statement は、"RS256" 署名アルゴリズムを使ってデジタル署名されることが RECOMMENDED であるが、特定のアプリケーションは別のアルゴリズムの使用を指定してよい（MAY）。authorization server が同一 software statement を用いる異なる software のインスタンスを相関できるよう、software statement に "software_id" claim を含めることが RECOMMENDED である。

たとえば software statement は以下の claims を含み得る。

{
  "software_id": "4NRB1-0XZABZI9E6-5SM3R",
  "client_name": "Example Statement-based Client",
  "client_uri": "https://client.example.net/"
}

以下は、これらの claims を含み "RS256" を用いて非対称署名された、非規範（non-normative）な JWT の例である（表示目的のみに改行を入れている）。

eyJhbGciOiJSUzI1NiJ9.
eyJzb2Z0d2FyZV9pZCI6IjROUkIxLTBYWkFCWkk5RTYtNVNNM1IiLCJjbGll
bnRfbmFtZSI6IkV4YW1wbGUgU3RhdGVtZW50LWJhc2VkIENsaWVudCIsImNs
aWVudF91cmkiOiJodHRwczovL2NsaWVudC5leGFtcGxlLm5ldC8ifQ.
GHfL4QNIrQwL18BSRdE595T9jbzqa06R9BT8w409x9oIcKaZo_mt15riEXHa
zdISUvDIZhtiyNrSHQ8K4TvqWxH6uJgcmoodZdPwmWRIEYbQDLqPNxREtYn0
5X3AR7ia4FRjQ2ojZjk5fJqJdQ-JcfxyhK-P8BAWBd6I2LLA77IG32xtbhxY
fHX7VhuU5ProJO8uvu3Ayv4XRhLZJY4yKfmyjiiKiPNe-Ia4SMy_d_QSWxsk
U5XIQl5Sa2YRPMbDRXttm2TfnZM1xx70DoYi8g6czz-CPGRi4SW_S2RKHIJf
IjoI3zTJ0Y2oe0_EJAiXbL6OyF9S5tKxDXV8JIndSA

software statement は通常、client application のすべてのインスタンスとともに配布される。client または developer が software statement を取得する手段は、本仕様のスコープ外である。一般的な方法としては、client developer が software API publisher に登録して、ある種の client 向けの software statement を得たうえで、client 固有の JWT を生成する、などがあり得る。

authorization server が software statement の情報を信頼して利用するかどうかを判断する基準は、本仕様のスコープ外である。

場合によっては、authorization server は、事前に dynamic client registration を行わなくても、authorization request において software statement 値を client identifier として直接受け入れることを選択してよい（MAY）。authorization server がそのようにする状況、およびその場合に要求される software statement の具体的な特性は、本仕様のスコープ外である。

3. Client Registration Endpoint

client registration endpoint は、本書で定義される OAuth 2.0 endpoint であり、client を authorization server に登録できるよう設計されている。client registration endpoint は、request parameters が entity body に "application/json" 形式でエンコードされた HTTP POST メッセージを受け入れなければならない（MUST）。client registration endpoint は、Section 5 で述べるとおり、トランスポート層のセキュリティ機構で保護されなければならない（MUST）。

client registration endpoint は OAuth 2.0 [RFC6749] の protected resource であってよい（MAY）。また、登録を事前に認可された主体のみに制限するために、OAuth 2.0 access token という形の initial access token を受け入れてよい（MAY）。initial access token を client または developer がどのように取得するかは、通常、帯域外（out of band）であり本仕様のスコープ外である。initial access token を client registration endpoint がどのように検証・妥当性確認するかも、本仕様のスコープ外である。

オープン登録をサポートし、より広い相互運用性を促進するため、client registration endpoint は、認可なし（すなわち request に initial access token がない）での登録要求を許可するべきである（SHOULD）。これらの要求は、client registration endpoint へのサービス不能攻撃を防ぐために、レート制限や他の制限を課してよい（MAY）。

3.1. Client Registration Request

この操作は、authorization server に client を登録する。authorization server は、この client に一意な client identifier を割り当て、任意で client secret を割り当て、要求で提供されたメタデータを発行された client identifier に関連付ける。要求には、登録時点で client に指定される client メタデータ・パラメータが含まれる。authorization server は、client メタデータで省略された項目に対してデフォルト値を用意してよい（MAY）。

登録のために、client または developer は、content type を "application/json" として client registration endpoint へ HTTP POST を送る。HTTP Entity Payload は、JSON [RFC7159] 文書であり、JSON object と、要求された client メタデータ値をその JSON object のトップレベル・メンバとして含む。

たとえば server がオープン登録（initial access token なし）をサポートしている場合、client は以下の登録要求を client registration endpoint に送ることができる。

以下は initial access token を使用しない、非規範（non-normative）な要求例である。

POST /register HTTP/1.1
Content-Type: application/json
Accept: application/json
Host: server.example.com

{
 "redirect_uris": [
   "https://client.example.org/callback",
   "https://client.example.org/callback2"],
 "client_name": "My Example Client",
 "client_name#ja-Jpan-JP":
    "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
 "token_endpoint_auth_method": "client_secret_basic",
 "logo_uri": "https://client.example.org/logo.png",
 "jwks_uri": "https://client.example.org/my_public_keys.jwks",
 "example_extension_parameter": "example_value"
}

また、server が認可付き登録をサポートしている場合、developer または client には initial access token が用意される。（initial access token をどのように取得するかは本仕様のスコープ外である。）developer または client は以下の認可付き登録要求を client registration endpoint に送る。なお、この例では initial access token は OAuth 2.0 Bearer Token [RFC6750] として送られているが、authorization server は任意の OAuth 2.0 token type を使用してよい（MAY）。

以下は initial access token を使用し、JWK Set を値として登録する、非規範（non-normative）な要求例である（表示目的のみに、値の中に改行がある）。

POST /register HTTP/1.1
Content-Type: application/json
Accept: application/json
Authorization: Bearer ey23f2.adfj230.af32-developer321
Host: server.example.com

{
 "redirect_uris": ["https://client.example.org/callback",
    "https://client.example.org/callback2"],
 "client_name": "My Example Client",
 "client_name#ja-Jpan-JP":
    "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
 "token_endpoint_auth_method": "client_secret_basic",
 "policy_uri": "https://client.example.org/policy.html",
 "jwks": {"keys": [{
    "e": "AQAB",
    "n": "nj3YJwsLUFl9BmpAbkOswCNVx17Eh9wMO-_AReZwBqfaWFcfG
HrZXsIV2VMCNVNU8Tpb4obUaSXcRcQ-VMsfQPJm9IzgtRdAY8NN8Xb7PEcYyk
lBjvTtuPbpzIaqyiUepzUXNDFuAOOkrIol3WmflPUUgMKULBN0EUd1fpOD70p
RM0rlp_gg_WNUKoW1V-3keYUJoXH9NztEDm_D2MQXj9eGOJJ8yPgGL8PAZMLe
2R7jb9TxOCPDED7tY_TU4nFPlxptw59A42mldEmViXsKQt60s1SLboazxFKve
qXC_jpLUt22OC6GUG63p-REw-ZOr3r845z50wMuzifQrMI9bQ",
    "kty": "RSA"
 }]},
 "example_extension_parameter": "example_value"
}

3.1.1. Client Registration Request Using a Software Statement

JSON 要素に加えて、client メタデータ値は、Section 2.3 で述べたとおり software statement で提供してよい（MAY）。authorization server は、この機能をサポートしない場合、software statement を無視してよい（MAY）。server が software statement をサポートする場合、software statement により伝達される client メタデータ値は、平文の JSON 要素により伝達されるものより優先されなければならない（MUST）。

software statement は、要求の JSON object に以下の OPTIONAL メンバとして含める。

software_statement
client software に関する client メタデータ値を claims として含む software statement。署名済み JWT 全体を含む文字列値である。

以下の例では、Section 2.3 の例の software statement の claims として登録パラメータの一部を伝達しつつ、client instance 固有の値の一部は通常のパラメータとして伝達している（表示目的のみに、値の中に改行がある）。

POST /register HTTP/1.1
Content-Type: application/json
Accept: application/json
Host: server.example.com

{
  "redirect_uris": [
    "https://client.example.org/callback",
    "https://client.example.org/callback2"
  ],
  "software_statement": "eyJhbGciOiJSUzI1NiJ9.
eyJzb2Z0d2FyZV9pZCI6IjROUkIxLTBYWkFCWkk5RTYtNVNNM1IiLCJjbGll
bnRfbmFtZSI6IkV4YW1wbGUgU3RhdGVtZW50LWJhc2VkIENsaWVudCIsImNs
aWVudF91cmkiOiJodHRwczovL2NsaWVudC5leGFtcGxlLm5ldC8ifQ.
GHfL4QNIrQwL18BSRdE595T9jbzqa06R9BT8w409x9oIcKaZo_mt15riEXHa
zdISUvDIZhtiyNrSHQ8K4TvqWxH6uJgcmoodZdPwmWRIEYbQDLqPNxREtYn0
5X3AR7ia4FRjQ2ojZjk5fJqJdQ-JcfxyhK-P8BAWBd6I2LLA77IG32xtbhxY
fHX7VhuU5ProJO8uvu3Ayv4XRhLZJY4yKfmyjiiKiPNe-Ia4SMy_d_QSWxsk
U5XIQl5Sa2YRPMbDRXttm2TfnZM1xx70DoYi8g6czz-CPGRi4SW_S2RKHIJf
IjoI3zTJ0Y2oe0_EJAiXbL6OyF9S5tKxDXV8JIndSA",
  "scope": "read write",
  "example_extension_parameter": "example_value"
}

3.2. Responses

登録要求が成功した場合、authorization server は client の client identifier を返す。server は HTTP 201 Created ステータスコードと、Section 3.2.1 で述べる内容を含む "application/json" 型の body を返す。

登録要求が失敗した場合、authorization server は Section 3.2.2 に述べる error を返す。

3.2.1. Client Information Response

response は client identifier と、client が Confidential client である場合は client secret も含む。response は本仕様の拡張が指定する追加フィールドを含んでよい（MAY）。

client_id
REQUIRED。OAuth 2.0 client identifier 文字列。現在、他の登録済み client に対して有効なものではないべきである（SHOULD NOT）が、authorization server は裁量により、同じ client identifier を登録済み client の複数インスタンスに発行してよい（MAY）。

client_secret
OPTIONAL。OAuth 2.0 client secret 文字列。発行される場合、各 "client_id" ごとに一意でなければならず（MUST）、同じ "client_id" を使う client の複数インスタンス間でも一意であるべきである（SHOULD）。この値は、OAuth 2.0 [RFC6749] の Section 2.3.1 に述べるとおり、Confidential client が token endpoint に認証するために使用する。

client_id_issued_at
OPTIONAL。client identifier が発行された時刻。UTC で計測した 1970-01-01T00:00:00Z から発行日時までの秒数として表現する。

client_secret_expires_at
"client_secret" が発行される場合は REQUIRED。client secret が失効する時刻。失効しない場合は 0。UTC で計測した 1970-01-01T00:00:00Z から失効日時までの秒数として表現する。

さらに authorization server は、この client に関する登録済みメタデータすべて（authorization server 自身が用意したフィールドを含む）を返さなければならない（MUST）。authorization server は、登録中に client が提出した要求メタデータ値の一部を拒否または置換し、適切な値に差し替えてよい（MAY）。client または developer は response 内の値を確認することで、登録内容が利用に十分かどうか（例: 登録された "token_endpoint_auth_method" が client software によりサポートされているか）を判断でき、client software にとって適切な対応方針を決められる。このような状況への対応は本仕様のスコープ外であるが、アプリケーション developer または authorization server provider への報告、別のメタデータ値での再登録の試行、その他様々な方法があり得る。たとえば server が [RFC7592] で定義されるような registration management 機構もサポートしている場合、client または developer は別のメタデータ値で登録の更新を試みることができる。このプロセスは、[OpenID.Discovery] のように server の機能を列挙できる service discovery プロトコルによっても助けられ得る。client はそれにより、より情報に基づいた登録要求を作れる。このような管理または discovery システムの使用は optional であり、本仕様のスコープ外である。

成功した登録 response は、HTTP 201 Created ステータスコードと、"application/json" 型の body を使用し、単一の JSON object [RFC7159] に全パラメータをトップレベル・メンバとして含める。

登録の一部として software statement が使われた場合、その値は "software_statement" メンバ名を用いて、他のメタデータとともに、変更せずに response へ返さなければならない（MUST）。software statement から用いられた client メタデータ要素は、登録 response でもトップレベルの client メタデータ値として直接返さなければならない（MUST）（値は異なる可能性がある。要求値と実際に使われた値が異なり得るためである）。

以下は成功した登録の、非規範（non-normative）な response 例である。

HTTP/1.1 201 Created
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
 "client_id": "s6BhdRkqt3",
 "client_secret": "cf136dc3c1fc93f31185e5885805d",
 "client_id_issued_at": 2893256800,
 "client_secret_expires_at": 2893276800,
 "redirect_uris": [
   "https://client.example.org/callback",
   "https://client.example.org/callback2"],
 "grant_types": ["authorization_code", "refresh_token"],
 "client_name": "My Example Client",
 "client_name#ja-Jpan-JP":
    "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
 "token_endpoint_auth_method": "client_secret_basic",
 "logo_uri": "https://client.example.org/logo.png",
 "jwks_uri": "https://client.example.org/my_public_keys.jwks",
 "example_extension_parameter": "example_value"
}

3.2.2. Client Registration Error Response

client が無効な initial access token を提示するなど、OAuth 2.0 の error condition が発生した場合、authorization server は OAuth 2.0 の token type に応じた適切な error response を返す。

登録に関する error condition が発生した場合、authorization server は（特に指定がない限り）HTTP 400 ステータスコードと、"application/json" content type を返す。body は、error を記述する JSON object [RFC7159] である。

JSON object に含める 2 つのメンバを定義する。

error
REQUIRED。単一の ASCII error code 文字列。

error_description
OPTIONAL。デバッグのための、人が読める ASCII テキストによる error の説明。

他のメンバも含めてよい（MAY）。理解できないメンバは無視されなければならない（MUST）。

本仕様は以下の error code を定義する。

invalid_redirect_uri
1 つ以上の redirection URI の値が無効である。

invalid_client_metadata
client メタデータ・フィールドのいずれかの値が無効であり、server がこの要求を拒否した。なお authorization server は、client のメタデータで要求された任意のパラメータについて、有効な値に差し替えることを選択してよい（MAY）。

invalid_software_statement
提示された software statement が無効である。

unapproved_software_statement
提示された software statement は、この authorization server において使用が承認されていない。

以下は、authorization server がブラックリストに登録した redirection URI により発生した error response の、非規範（non-normative）な例である（表示目的のみに、値の中に改行がある）。

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
 "error": "invalid_redirect_uri",
 "error_description": "The redirection URI
   http://sketchy.example.com is not allowed by this server."
}

以下は、"response_types" と "grant_types" の値の組み合わせが矛盾していることにより発生した error response の、非規範（non-normative）な例である（表示目的のみに、値の中に改行がある）。

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
 "error": "invalid_client_metadata",
 "error_description": "The grant type 'authorization_code' must be
   registered along with the response type 'code' but found only
  'implicit' instead."
}

4. IANA Considerations

4.1. OAuth Dynamic Client Registration Metadata Registry

本仕様は "OAuth Dynamic Client Registration Metadata" レジストリを確立する。

OAuth 登録の client メタデータ名と説明は、oauth-ext-review@ietf.org メーリングリストにおける 2 週間のレビュー期間を経たうえで、Specification Required（[RFC5226]）により登録される。登録は 1 名以上の Designated Experts の助言に基づいて行われる。ただし、刊行前に名前の割り当てを可能にするため、Designated Experts は、[RFC7120] に従い、その仕様が刊行されると確信できる状態に満足した時点で登録を承認してよい（MAY）。

レビューのためにメーリングリストへ送る登録要求は、適切な件名（例: "Request to register OAuth Dynamic Client Registration Metadata name: example"）を使うべきである（SHOULD）。

レビュー期間内に、Designated Experts は登録要求を承認または拒否し、その決定をレビュー用リストおよび IANA に伝える。拒否には説明を含め、該当する場合は要求を成功させるための提案も含めるべきである（SHOULD）。

IANA は、Designated Experts からのレジストリ更新のみを受け入れなければならず（MUST）、登録要求はすべてレビュー用メーリングリストへ回すべきである（SHOULD）。

4.1.1. Registration Template

Client Metadata Name:
要求される名前（例: "example"）。この名前は大文字小文字を区別する。大文字小文字非依存に見て他の登録済み名と一致する名前は、受け入れられるべきではない（SHOULD NOT）。

Client Metadata Description:
メタデータ値の簡潔な説明（例: "Example description"）。

Change Controller:
Standards Track RFC の場合は "IESG" を記載する。それ以外の場合は責任主体の名称を記載する。他の詳細（例: 郵送先住所、email address、home page URI）も含めてよい（MAY）。

Specification Document(s):
client メタデータ定義を規定する文書への参照。望ましくは、その文書のコピーを取得できる URI を含む。関連する section を示してもよいが（MAY）、必須ではない。

4.1.2. Initial Registry Contents

"OAuth Dynamic Client Registration Metadata" レジストリの初期内容は以下のとおりである。

• Client Metadata Name: "redirect_uris"
• Client Metadata Description: redirect-based flows で使用する redirection URI の配列
• Change Controller: IESG
• Specification Document(s): RFC 7591

• Client Metadata Name: "token_endpoint_auth_method"
• Client Metadata Description: token endpoint に対する要求認証方式
• Change Controller: IESG
• Specification Document(s): RFC 7591

• Client Metadata Name: "grant_types"
• Client Metadata Description: client が使用できる OAuth 2.0 grant type の配列
• Change Controller: IESG
• Specification Document(s): RFC 7591

• Client Metadata Name: "response_types"
• Client Metadata Description: client が使用できる OAuth 2.0 response type の配列
• Change Controller: IESG
• Specification Document(s): RFC 7591

• Client Metadata Name: "client_name"
• Client Metadata Description: user に提示される、人が読める client 名
• Change Controller: IESG
• Specification Document(s): RFC 7591

• Client Metadata Name: "client_uri"
• Client Metadata Description: client に関する情報を提供する web ページの URL
• Change Controller: IESG
• Specification Document(s): RFC 7591

• Client Metadata Name: "logo_uri"
• Client Metadata Description: client のロゴを参照する URL
• Change Controller: IESG
• Specification Document(s): RFC 7591

• Client Metadata Name: "scope"
• Client Metadata Description: OAuth 2.0 scope 値の空白区切りリスト
• Change Controller: IESG
• Specification Document(s): RFC 7591

• Client Metadata Name: "contacts"
• Client Metadata Description: この client の責任者への連絡手段（典型的には email address）を表す文字列配列
• Change Controller: IESG
• Specification Document(s): RFC 7591

• Client Metadata Name: "tos_uri"
• Client Metadata Description: 読める形の terms of service 文書を指す URL
• Change Controller: IESG
• Specification Document(s): RFC 7591

• Client Metadata Name: "policy_uri"
• Client Metadata Description: 読める形の policy 文書を指す URL
• Change Controller: IESG
• Specification Document(s): RFC 7591

• Client Metadata Name: "jwks_uri"
• Client Metadata Description: client の公開鍵を表す JSON Web Key (JWK) Set [RFC7517] 文書への参照 URL
• Change Controller: IESG
• Specification Document(s): RFC 7591

• Client Metadata Name: "jwks"
• Client Metadata Description: client の公開鍵を表す JSON Web Key Set [RFC7517] 文書値
• Change Controller: IESG
• Specification Document(s): RFC 7591

• Client Metadata Name: "software_id"
• Client Metadata Description: client を構成するソフトウェアの識別子
• Change Controller: IESG
• Specification Document(s): RFC 7591

• Client Metadata Name: "software_version"
• Client Metadata Description: client を構成するソフトウェアのバージョン識別子
• Change Controller: IESG
• Specification Document(s): RFC 7591

• Client Metadata Name: "client_id"
• Client Metadata Description: client identifier
• Change Controller: IESG
• Specification Document(s): RFC 7591

• Client Metadata Name: "client_secret"
• Client Metadata Description: client secret
• Change Controller: IESG
• Specification Document(s): RFC 7591

• Client Metadata Name: "client_id_issued_at"
• Client Metadata Description: client identifier が発行された時刻
• Change Controller: IESG
• Specification Document(s): RFC 7591

• Client Metadata Name: "client_secret_expires_at"
• Client Metadata Description: client secret が失効する時刻
• Change Controller: IESG
• Specification Document(s): RFC 7591

4.2. OAuth Token Endpoint Authentication Methods Registry

本仕様は "OAuth Token Endpoint Authentication Methods" レジストリを確立する。

"token_endpoint_auth_method" の値として使用する追加の値は、oauth-ext-review@ietf.org メーリングリストにおける 2 週間のレビュー期間を経たうえで、Specification Required（[RFC5226]）により登録される。登録は 1 名以上の Designated Experts の助言に基づいて行われる。ただし、刊行前に値の割り当てを可能にするため、Designated Experts は、[RFC7120] に従い、その仕様が刊行されると確信できる状態に満足した時点で登録を承認してよい（MAY）。

登録要求は、レビューとコメントのために oauth-ext-review@ietf.org メーリングリストへ送られなければならない（MUST）。適切な件名（例: "Request to register token_endpoint_auth_method value: example"）を使うべきである（SHOULD）。

レビュー期間内に、Designated Experts は登録要求を承認または拒否し、その決定をレビュー用リストおよび IANA に伝える。拒否には説明を含め、該当する場合は要求を成功させるための提案も含めるべきである（SHOULD）。

IANA は、Designated Experts からのレジストリ更新のみを受け入れなければならず（MUST）、登録要求はすべてレビュー用メーリングリストへ回すべきである（SHOULD）。

4.2.1. Registration Template

Token Endpoint Authentication Method Name:
要求される名前（例: "example"）。この名前は大文字小文字を区別する。大文字小文字非依存に見て他の登録済み名と一致する名前は、受け入れられるべきではない（SHOULD NOT）。

Change Controller:
Standards Track RFC の場合は "IESG" を記載する。それ以外の場合は責任主体の名称を記載する。他の詳細（例: 郵送先住所、email address、home page URI）も含めてよい（MAY）。

Specification Document(s):
token endpoint 認証方式を規定する文書への参照。望ましくは、その文書のコピーを取得できる URI を含む。関連する section を示してもよいが（MAY）、必須ではない。

4.2.2. Initial Registry Contents

"OAuth Token Endpoint Authentication Methods" レジストリの初期内容は以下のとおりである。

• Token Endpoint Authentication Method Name: "none"
• Change Controller: IESG
• Specification Document(s): RFC 7591

• Token Endpoint Authentication Method Name: "client_secret_post"
• Change Controller: IESG
• Specification Document(s): RFC 7591

• Token Endpoint Authentication Method Name: "client_secret_basic"
• Change Controller: IESG
• Specification Document(s): RFC 7591

5. Security Considerations

client registration endpoint への要求は（HTTP request と response において）平文の credentials の送信を伴うため、authorization server は、registration endpoint へ要求を送る際に、トランスポート層のセキュリティ機構の使用を要求しなければならない（MUST）。server は TLS 1.2 [RFC5246] をサポートしなければならず（MUST）、セキュリティ要件を満たす追加のトランスポート層セキュリティ機構をサポートしてよい（MAY）。TLS を用いる場合、client は RFC 6125 [RFC6125] に従って TLS/SSL server certificate の検証を行わなければならない（MUST）。実装上のセキュリティ考慮点は「Recommendations for Secure Use of TLS and DTLS」[BCP195] にある。

"authorization_code" や "implicit" のような redirect-based の grant type を用いる client に対して、authorization server は client に redirection URI 値の登録を要求しなければならない（MUST）。これは、悪意ある主体が不正な redirection URI や open redirector を通じて、有効に登録された client を注入・なりすましし、その authorization code や token を横取りする攻撃の緩和に役立つ。加えて、redirection の戻り値の乗っ取りを防ぐため、登録される redirection URI 値は以下のいずれかでなければならない（MUST）。

• TLS により保護されたリモート web site
  （例: https://client.example.com/oauth_redirect）
• ローカルマシン上でホストされた web site（HTTP URI を使用）
  （例: http://localhost:8080/oauth_redirect）
• client application のみが利用できる、非 HTTP の application 固有 URL
  （例: exampleapp://oauth_redirect）

authorization server のポリシーが許す場合、Public client はこのプロトコルを用いて authorization server に登録してよい（MAY）。Public client は "token_endpoint_auth_method" メタデータ・フィールドに "none" 値を用い、一般に "implicit" grant type とともに使われる。これらの client はしばしば、in-browser の短命なアプリケーションであり、ユーザの resources へのアクセスを要求し、そのアクセスは authorization server 上のユーザのアクティブなセッションに結びついている。このような client は長期保存領域を持たないことが多いため、ブラウザ・アプリケーションがロードされるたびに再登録が必要になる可能性がある。その結果として死んだ client identifier が大量に増えるのを避けるため、authorization server は、一定の条件を満たす既存 client の登録を、一定期間の経過後に失効させることを選択してよい（MAY）。あるいは、そのような client を、in-browser アプリケーションのコードを配信している server 側で登録し、client の構成をコードとともにブラウザへ配布することもできる。

OAuth 2.0 の grant type によりセキュリティおよび使用特性が異なるため、authorization server は、複数の grant type をサポートするために、あるソフトウェアに対して別々の登録を要求してよい（MAY）。たとえば authorization server は、"authorization_code" grant type を使うすべての client に対して "token_endpoint_auth_method" に client secret を使うことを要求しつつ、"implicit" grant type を使う client には token endpoint での認証を一切使わないことを要求するかもしれない。この場合 server は、client が "authorization_code" と "implicit" の両方の grant type を同時に登録することを許可しないことがあり得る（MAY）。同様に、"authorization_code" grant type は end-user に代わってのアクセスを表し、"client_credentials" grant type は client 自身に代わってのアクセスを表す。セキュリティ上の理由から、authorization server はこれら異なる用途に対して異なる scope を要求するかもしれず、その結果として、これら 2 つの grant type が同一 client によって一緒に登録されることを許可しないことがあり得る（MAY）。これらすべての場合、authorization server は "invalid_client_metadata" error response を返すことになる。

software statement 内の claim として使用される場合を除き、authorization server はすべての client メタデータを自己申告として扱わなければならない（MUST）。たとえば悪意ある client が、なりすまし対象である正当な client の名前やロゴを使用するかもしれない。また悪意ある client が、正当な client の software identifier や software version を使って、自分自身を authorization server 上で正当な client のインスタンスに紐づけようとするかもしれない。これに対抗するため、authorization server は、登録要求全体と client の構成を見て、このリスクを緩和する適切な手段を取らなければならない（MUST）。たとえば、ロゴの domain/site が redirection URI の domain/site と一致しない場合に警告を出すことができる。また、既知の software identifier からの登録要求が、異なる redirection URI や異なる client URI を要求している場合、registration request を拒否することもできる。authorization server はまた、動的登録された client について、特に最近登録されたものや、authorization server においてこれまでにいずれのユーザにも信頼されていないものについて、end-user に警告メッセージを提示することもできる。

authorization server がオープンな client 登録をサポートしている状況では、user に表示されるあらゆる URL（例: "logo_uri", "tos_uri", "client_uri", "policy_uri"）について極めて慎重でなければならない。たとえば悪意ある client が "policy_uri" にドライブバイ・ダウンロードへの参照を指定し、authorization 中に user がそれをクリックするよう誘導するかもしれない。authorization server は、"logo_uri", "tos_uri", "client_uri", "policy_uri" が、"redirect_uris" 配列で定義されたものと同じ host と scheme を持ち、かつそれらの URI が有効な web ページへ解決するかどうかを確認すべきである（SHOULD）。これらの URI 値は authorization ページで user に表示される意図があるため、authorization server は可能な範囲で、それらの URL 上の悪意あるコンテンツから user を保護すべきである（SHOULD）。たとえば authorization server は、authorization ページで URL を user に提示する前に、URL のコンテンツをダウンロードし、マルウェアスキャナやブラックリストフィルタで検査し、URL に安全・非安全な混在コンテンツがあるかを判定するなど、他の server 側緩和策を行うことができる。これらの URL のコンテンツはいつでも変わり得るため、authorization server は URL の安全性について完全な確信を提供できないが、これらの実践は助けになり得る。この種の脅威をさらに緩和するため、authorization server は、URL リンクが第三者によって提供されたこと、注意して扱うべきであること、authorization server 自身によってホストされているわけではないことを user に警告できる。たとえば HTML anchor で直接リンクを提供する代わりに、authorization server は interstitial の警告ページへ user を誘導してから、目的の URL へ進ませることができる。

client は、直接の JSON object と JWT でエンコードされた software statement の両方を用いて、登録要求の一部として authorization server に client メタデータを提示してよい（MAY）。software statement は暗号学的に保護され、statement の issuer による claims を表す一方、JSON object は client または developer が直接自己申告する claims を表す。software statement が有効であり、受け入れ可能な権威（例: software API publisher）によって署名されている場合、software statement 内の client メタデータ値が、平文の JSON object で提示されたメタデータ値より優先されなければならない（MUST）。後者は途中で傍受・改変された可能性があるためである。

他のメタデータ値と同様に、software statement も、client によって自己申告される項目である。software statement の issuer によってデジタル署名や MAC が付与されていても同じである。そのため、多くの場合、software statement の提示だけでは client software を完全に識別するのに十分ではない。対照的に initial access token は、必ずしも特定の client software に関する情報を含むわけではなく、registration endpoint を使用するための認可を表す。authorization server は、software statement、initial access token、JSON の client メタデータ値を含む登録要求全体を考慮し、所与の登録要求を認めるかどうかを判断しなければならない（MUST）。

authorization server が、同時に複数のインスタンスが登録される意図のない client に対する登録要求を受け取り、既存 client との登録の重複を推測できる場合（例: 別の既存 client と同じ "software_id" と "software_version" を使用している場合）、server は新しい登録を疑わしいものとして扱い、登録を拒否すべきである（SHOULD）。新しい client が既存 client になりすまして user をだまし認可させようとしている可能性や、元の登録がもはや有効でない可能性がある。この状況をどのように管理するかの詳細は、authorization server の配備固有であり、本仕様のスコープ外である。

client identifier は、authorization endpoint において client をなりすますために使用され得る公開値であるため、同じ client identifier を登録済み client の複数インスタンスに発行すると決めた authorization server は、それが起こる状況について非常に慎重である必要がある。たとえば authorization server は、ある client identifier を、同じ redirect-based フローおよび同じ redirection URI を使用する client に限定できる。authorization server は、同じ client identifier が発行される場合であっても、登録済み client の複数インスタンスに同一の client secret を発行するべきではない（SHOULD NOT）。さもないと client secret が漏洩し、悪意あるなりすましが Confidential client を装えるようになる。

6. Privacy Considerations

本仕様で述べるプロトコルは、ほぼ専らソフトウェアに関する情報を扱い、人に関する情報は扱わないため、プライバシー上の懸念は非常に少ない。注目すべき例外は Section 2 で定義される "contacts" フィールドであり、これは client software の developer やその他の責任主体の連絡先情報を含む。これらの値は end-user に表示される意図があり、authorization server の管理者にも見える。そのため developer は、個人用または職務用のアドレスを使うのではなく、client をサポートする目的のために明示的に用意した email address やその他の連絡先情報を提供したいと考えるかもしれない。あるいは developer は、developer が移動して別の誰かが責任を引き継いだ後も client software への連絡とサポートを継続できるよう、client 用の代表メールアドレスを提供したいと考えるかもしれない。

一般に、client 名や software identifier といった client のメタデータは、client software のすべてのインスタンスに共通であるため、end-user のプライバシー問題は生じない。一方、client identifier は特定の client インスタンスに固有であることが多い。多数の user が利用する web site のような client では、client identifier に関するプライバシー懸念は大きくないかもしれないが、単一の end-user のデバイスにインストールされる native application のような client では、client identifier が OAuth 2.0 トランザクション中に一意に追跡され、その使用が当該 end-user に結び付けられる可能性がある。ただし、client software は、resource owner により OAuth 2.0 authorization grant を通じて認可される必要があるため、client identifier が一意かどうかにかかわらず、認証済み resource owner と要求した client identifier を相関させることで、この種の追跡は起こり得る。

本仕様は、client が自分自身の client identifier を作成することを禁じている点に注意すること。もし client がそれを作成できるなら、個々の client インスタンスが、共謀する複数の authorization server にまたがって追跡され得て、プライバシーおよびセキュリティ上の問題が生じる。加えて client identifier は、同じソフトウェアの同じインスタンスに対してであっても、一般に登録要求ごとに一意に発行される。このように、アプリケーションは複数回登録し、完全に別のアプリケーションであるかのように見せることで、わずかにプライバシーを改善できる。しかしこの手法は、resource owner ごとに複数回の認可を要求するという大きなユーザビリティ・コストを伴うため、実務で使われる可能性は低い。

7. References

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

[IANA.Language] IANA, "Language Subtag Registry".

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels",
BCP 14, RFC 2119, March 1997.

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 5226, May 2008.

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2",
RFC 5246, August 2008.

[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages",
BCP 47, RFC 5646, September 2009.

[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, March 2011.

[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, October 2012.

[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage",
RFC 6750, October 2012.

[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code Points",
BCP 100, RFC 7120, January 2014.

[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format",
RFC 7159, March 2014.

[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)",
RFC 7515, May 2015.

[RFC7517] Jones, M., "JSON Web Key (JWK)",
RFC 7517, May 2015.

[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)",
RFC 7519, May 2015.

[RFC7522] Campbell, B., Mortimore, C., and M. Jones, "Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants",
RFC 7522, May 2015.

[RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants",
RFC 7523, May 2015.

7.2. Informative References

[OpenID.Discovery] Sakimura, N., Bradley, J., Jones, M., and E. Jay,
"OpenID Connect Discovery 1.0", November 2014.

[OpenID.Registration] Sakimura, N., Bradley, J., and M. Jones,
"OpenID Connect Dynamic Client Registration 1.0", November 2014.

[RFC7592] Richer, J., Jones, M., Bradley, J., and M. Machulak,
"OAuth 2.0 Dynamic Client Registration Management Protocol",
RFC 7592, July 2015.

[UMA-Core] Hardjono, T., Maler, E., Machulak, M., and D. Catalano,
"User-Managed Access (UMA) Profile of OAuth 2.0", Work in Progress, draft-hardjono-oauth-umacore-13, April 2015.

Appendix A. Use Cases

この appendix は、本仕様を利用するさまざまな方法を説明する。ここでは、意思決定が必要になり得る選択肢もいくつか述べる。選択肢の中には、独立で組み合わせ可能なものもあれば、相互に関連するものもある。

A.1. Open versus Protected Dynamic Client Registration

A.1.1. Open Dynamic Client Registration

オープン登録をサポートする authorization server は、initial access token なしで登録を行える。これにより、すべての client software が authorization server に登録できる。

A.1.2. Protected Dynamic Client Registration

保護された登録をサポートする authorization server は、登録要求を行う際に initial access token の使用を要求する。client または developer が initial access token を受け取る方法、および authorization server が initial access token を検証する方法は本仕様のスコープ外であるが、一般的なアプローチとして、developer が authorization server の手動の事前登録ポータルを使い、developer に initial access token が発行される、というものがある。

A.2. Registration without or with Software Statements

A.2.1. Registration without a Software Statement

登録要求で software statement を使用しない場合、authorization server は、client メタデータ値が、いかなる権威によっても（デジタル署名または MAC により）署名・保護され、証明されていない状態であっても、それらを使用する意思がなければならない。（この選択は Open と Protected の選択とは独立であり、initial access token は別の形の証明でもある点に注意。）

A.2.2. Registration with a Software Statement

software statement は、ある権威による client メタデータ値一式の証明を提供するために、登録要求で使用できる。これは、authorization server が、一定の権威によって証明された client software に登録を制限したい場合や、複数の登録要求が同じ client software を指していることを知りたい場合に有用である。

A.3. Registration by the Client or Developer

A.3.1. Registration by the Client

いくつかのユースケースでは、client software は authorization server とやり取りするために必要な client identifier およびその他の情報を得るために、authorization server に対して自分自身を動的に登録する。この場合、authorization server 向けの client identifier は client software に同梱されていない。

A.3.2. Registration by the Developer

いくつかのケースでは、developer（または developer が使用する開発用ソフトウェア）が、authorization server または複数の authorization server に対して client software を事前登録する。この場合、authorization server（群）向けの client identifier 値（群）を client software に同梱できる。

A.4. Client ID per Client Instance or per Client Software

A.4.1. Client ID per Client Software Instance

いくつかのケースでは、client software の配備された各インスタンスが動的に登録し、それぞれ別々の client identifier 値を取得する。これは、たとえば code フローが使用されている場合に有利であり、各 client instance が自身の client secret を持つことも可能になる。これは、software に同梱された client secret 値の秘匿性を保てない native client にとって有用であり得る。一方で native client は、インスタンスごとの client secret の秘匿性は保てる場合がある。

A.4.2. Client ID Shared among All Instances of Client Software

いくつかのケースでは、client software の配備された各インスタンスが、共通の client identifier 値を共有する。たとえば、in-browser client が implicit フローを使用し、client secret が関与しない場合にしばしば見られる。特定の authorization server は、software statement 値と client identifier 値の対応関係を維持し、特定のソフトウェアに対するすべての登録要求に同じ client identifier 値を返すことを選択するかもしれない。authorization server がそのようにする状況、およびこの場合に要求される software statement の具体的な特性は、本仕様のスコープ外である。

A.5. Stateful or Stateless Registration

A.5.1. Stateful Client Registration

いくつかのケースでは、authorization server は登録済み client に関する状態を維持し、典型的には client identifier 値でこの状態に索引を付ける。この状態には通常、client 登録に関連する client メタデータ値が含まれ、さらに authorization server の実装に固有の他の状態も含まれ得る。stateful な登録が使われる場合、この状態を取得および／または更新する操作がサポートされ得る。stateful 登録に対する操作の 1 つの集合は [RFC7592] に述べられている。

A.5.2. Stateless Client Registration

いくつかのケースでは、authorization server は登録済み client についてのローカル状態を一切維持しない形で実装される。これを行う 1 つの手段は、返される client identifier 値の中に登録状態をすべてエンコードし、必要に応じて authorization server に対して状態を暗号化して、状態の機密性と完全性を保つことである。

Acknowledgments

著者らは、本書に対する入力を提供した OAuth Working Group、User-Managed Access Working Group、および OpenID Connect Working Group の参加者に感謝する。特に、以下の個人は、本書の各ドラフト版に対するレビューおよび貢献において重要な役割を果たした。Amanda Anganes, Derek Atkins, Tim Bray, Domenico Catalano, Donald Coffin, Vladimir Dzhuvinov, George Fletcher, Thomas Hardjono, William Kim, Torsten Lodderstedt, Eve Maler, Josh Mandel, Nov Matake, Tony Nadalin, Nat Sakimura, Christian Scholz, and Hannes Tschofenig.

Authors' Addresses

Justin Richer (editor)

Email: ietf@justin.richer.org

Michael B. Jones
Microsoft

Email: mbj@microsoft.com
URI: http://self-issued.info/

John Bradley
Ping Identity

Email: ve7jtb@ve7jtb.com

Maciej Machulak
Newcastle University

Email: maciej.machulak@gmail.com

Phil Hunt
Oracle Corporation

Email: phil.hunt@yahoo.com