OAuth 2.0 Dynamic Client Registration Management Protocol

Internet Engineering Task Force (IETF)                    J. Richer, Ed.
Request for Comments: 7592
Category: Experimental                                          M. Jones
ISSN: 2070-1721                                                Microsoft
                                                              J. Bradley
                                                           Ping Identity
                                                             M. Machulak
                                                    Newcastle University
                                                               July 2015

Abstract

この仕様は、OAuth 2.0 の動的クライアント登録について、登録済みクライアントのプロパティがクライアントの存続期間中に変更される必要があるユースケースに向けて、管理のための手法を定義する。動的クライアント登録をサポートするすべての Authorization Server が、これらの管理手法をサポートするわけではない。

Status of This Memo

本文書は Internet Standards Track の仕様ではない。検討、実験的な実装、評価のために公開される。

本文書は、Internet コミュニティ向けの Experimental Protocol を定義する。本文書は Internet Engineering Task Force (IETF) の成果物である。IETF コミュニティの合意を表している。公開レビューを受け、Internet Engineering Steering Group (IESG) により公開が承認された。IESG により承認されたすべての文書が、いかなるレベルの Internet Standard の候補になるわけではない。RFC 5741 の Section 2 を参照せよ。

本文書の現状、正誤表、ならびにフィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc7592 から取得できる。

Copyright Notice

本文書は、公開日現在で有効な、BCP 78 および IETF Trust の「IETF 文書に関する法的規定」(http://trustee.ietf.org/license-info) の適用を受ける。これらの文書には、本仕様に関する権利と制限が記載されているため、注意深く確認すること。本文書から抽出された Code Components は、Trust Legal Provisions の Section 4.e に記載された Simplified BSD License の文言を含めなければならず、Simplified BSD License に記載のとおり無保証で提供される。

1. Introduction

OAuth 2.0 client が OAuth 2.0 の Authorization Server を利用するためには、そのサーバと相互作用するための特定の情報（そのサーバで用いる OAuth 2.0 の client identifier を含む）が必要である。"OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591] は、OAuth 2.0 client が Authorization Server に対して動的に登録し、この情報を取得する方法、および client に関するメタデータをサーバに登録する方法を記述する。

本仕様は、コアの登録仕様で定義されたものを超えて、動的な OAuth 2.0 client 登録の管理のための手法一式を定義することで、コアの登録仕様を拡張する。状況によっては、client の登録済みメタデータは、Authorization Server 側の修正、または client ソフトウェア自体の変更により、時間の経過とともに変化し得る。本仕様は、client の現在の登録状態を Authorization Server に問い合わせる手法、Authorization Server 上の client 登録を更新する手法、そして Authorization Server から client の登録を解除する手法を提供する。

この Experimental RFC は、相互運用可能なソリューションの開発と展開を促すことを意図しており、この経験から得られるフィードバックが将来の標準に反映されることを期待している。

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" の各用語、および "OAuth 2.0 Client Dynamic Registration Protocol" [RFC7591] で定義される用語を用いる。

本仕様は、次の用語を定義する。

Client Configuration Endpoint
登録済み client の登録情報を管理できる OAuth 2.0 endpoint。この endpoint の URL は、Authorization Server により client information response で返される。

Registration Access Token
client registration endpoint を通じて Authorization Server が発行する OAuth 2.0 Bearer Token。client configuration endpoint で client の登録情報へアクセスする際に、呼び出し元の認証に用いられる。この access token は特定の登録済み client に関連付けられる。

1.3. Protocol Flow

これは "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591] のフローを次のとおり拡張する。

    +--------(A)- Initial Access Token (OPTIONAL)
    |
    |   +----(B)- Software Statement (OPTIONAL)
    |   |
    v   v
+-----------+                                      +---------------+
|           |--(C)- Client Registration Request -->|    Client     |
|           |                                      | Registration  |
|           |<-(D)- Client Information Response ---|   Endpoint    |
|           |                                      +---------------+
|           |
|           |                                      +---------------+
| Client or |--(E)- Read or Update Request ------->|               |
| Developer |                                      |               |
|           |<-(F)- Client Information Response ---|    Client     |
|           |                                      | Configuration |
|           |                                      |   Endpoint    |
|           |                                      |               |
|           |--(G)- Delete Request --------------->|               |
|           |                                      |               |
|           |<-(H)- Delete Confirmation -----------|               |
+-----------+                                      +---------------+

Figure 1: Abstract Extended Dynamic Client Registration Flow

Figure 1 に示す抽象的な OAuth 2.0 client 動的登録フローは、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 を呼び出し、Authorization Server により (A) の initial access token が要求される場合は、それを任意で含める。

(D) Authorization Server は client を登録し、次を返す。

client の登録済みメタデータ
サーバに対して一意な client identifier
該当する場合、client secret などの client credentials 一式
client configuration endpoint を指す URI
client configuration endpoint 呼び出し時に用いる registration access token

(E) client または developer は任意で、(D) で発行された registration access token を用いて、read または update request を client configuration endpoint に対して呼び出す。update request は、client の登録済みメタデータをすべて含む。

(F) Authorization Server は、client の現在の設定を返す。必要に応じて、新しい registration access token および（該当する場合）client secret などの新しい client credentials 一式を含み得る。新しい registration access token が発行された場合、それは以後の client configuration endpoint へのすべての呼び出しにおいて、(D) で発行された token を置き換える。

(G) client または developer は任意で、(D) または (F) で発行された registration access token を用いて、delete request を client configuration endpoint に対して呼び出す。

(H) Authorization Server は client を廃止（deprovision）し、削除が行われたことの確認を返す。

2. Client Configuration Endpoint

client configuration endpoint は、client の登録済み情報の閲覧・更新・削除を容易にするためにサーバが用意する、OAuth 2.0 の保護リソースである。この endpoint の場所は、Section 3 に規定されるとおり、client information response の "registration_client_uri" メンバーを通じて client に伝達される。client は、この endpoint に対するすべての呼び出しにおいて、OAuth 2.0 Bearer Token [RFC6750] として registration access token を用いなければならない。

client configuration endpoint は、Section 5 に記載されるとおり、トランスポート層セキュリティの仕組みによって保護されなければならない。

この endpoint への操作は、異なる HTTP method [RFC7231] の使用によって切り替えられる。Authorization Server が client configuration endpoint 上で特定の method をサポートしない場合、適切なエラーコードで応答しなければならない。

2.1. Client Read Request

Authorization Server 上の client の現在の設定を読み取るために、client は client configuration endpoint に対して HTTP GET request を行い、registration access token により認証する。

次は非規範的なリクエスト例である。

GET /register/s6BhdRkqt3 HTTP/1.1
Accept: application/json
Host: server.example.com
Authorization: Bearer reg-23410913-abewfq.123483

現在アクティブな client の情報を正常に読み取れた場合、Authorization Server は、content type が "application/json" の HTTP 200 OK と、Section 3 に記載のペイロードで応答する。レスポンス中のいくつかの値（"client_secret" と "registration_access_token" を含む）は、初回の登録レスポンスのものと異なり得る。Authorization Server がレスポンスに新しい client secret および／または registration access token を含めた場合、client は直ちに以前の client secret および／または registration access token を破棄しなければならない。"client_id" の値は初回の登録レスポンスから変更されてはならない。

このリクエストに用いられた registration access token が有効でない場合、サーバは OAuth Bearer Token Usage 仕様 [RFC6750] に記載のとおりエラーで応答しなければならない。

このサーバに client が存在しない場合、サーバは HTTP 401 Unauthorized で応答しなければならず、当該リクエストに用いられた registration access token は直ちに失効させるべきである。

client が自分のレコードを読み取る権限を持たない場合、サーバは HTTP 403 Forbidden を返さなければならない。

2.2. Client Update Request

Authorization Server に対して、以前登録した client の登録内容を更新するために、client は content type が "application/json" の HTTP PUT request を client configuration endpoint に対して行う。HTTP エンティティのペイロードは、JSON [RFC7159] 文書であり、JSON オブジェクト 1 つからなり、その JSON オブジェクトのトップレベルメンバーとしてすべてのパラメータを含む。このリクエストは、client に発行された registration access token により認証される。

このリクエストは、以前の登録・読み取り・更新操作で client に返されたすべての client メタデータフィールドを含めなければならない。更新用の client メタデータフィールドには、Section 3 に記載される "registration_access_token", "registration_client_uri", "client_secret_expires_at", "client_id_issued_at" を含めてはならない。

このリクエストにおける client メタデータフィールドの有効値は、これまでこの client に関連付けられていた値を置き換えなければならず、追加（augment）してはならない。省略されたフィールドは、サーバにより null または空値として扱われなければならず、これは client が当該フィールドを client の登録から削除したいという要求を示す。Authorization Server は、ほかの任意の値と同様に、リクエスト中の null または空値を無視してもよい。

client は "client_id" フィールドをリクエストに含めなければならず、かつ、それは現在発行されている client identifier と同一でなければならない。client が "client_secret" フィールドをリクエストに含める場合、その値は当該 client に対して現在発行されている client secret と一致しなければならない。client は、既存の client secret を、自分で選んだ値で上書きできてはならない。

すべてのメタデータフィールドについて、Authorization Server は不正な値を適切なデフォルト値で置き換えてもよく、その場合はレスポンスで当該フィールドを client に返さなければならない。

たとえば client は、上の例の client 登録を新しい情報で更新するために、次のリクエストを client registration endpoint に送ることができる。

次は非規範的なリクエスト例である。

PUT /register/s6BhdRkqt3 HTTP/1.1
Accept: application/json
Host: server.example.com
Authorization: Bearer reg-23410913-abewfq.123483

{
 "client_id": "s6BhdRkqt3",
 "client_secret": "cf136dc3c1fc93f31185e5885805d",
 "redirect_uris": [
   "https://client.example.org/callback",
   "https://client.example.org/alt"],
 "grant_types": ["authorization_code", "refresh_token"],
 "token_endpoint_auth_method": "client_secret_basic",
 "jwks_uri": "https://client.example.org/my_public_keys.jwks",
 "client_name": "My New Example",
 "client_name#fr": "Mon Nouvel Exemple",
 "logo_uri": "https://client.example.org/newlogo.png",
 "logo_uri#fr": "https://client.example.org/fr/newlogo.png"
}

この例は [RFC7591] で定義された client メタデータ値を用いている。

更新が成功した場合、Authorization Server は content type が "application/json" の HTTP 200 OK メッセージと、Section 3 に記載のペイロードで応答する。レスポンス中のいくつかの値（"client_secret" と "registration_access_token" を含む）は、初回の登録レスポンスのものと異なり得る。Authorization Server がレスポンスに新しい client secret および／または registration access token を含めた場合、client は直ちに以前の client secret および／または registration access token を破棄しなければならない。"client_id" の値は初回の登録レスポンスから変更されてはならない。

このリクエストに用いられた registration access token が有効でない場合、サーバは OAuth Bearer Token Usage 仕様 [RFC6750] に記載のとおりエラーで応答しなければならない。

このサーバに client が存在しない場合、サーバは HTTP 401 Unauthorized で応答しなければならず、当該リクエストに用いられた registration access token は直ちに失効させるべきである。

client が自分のレコードを更新することを許可されていない場合、サーバは HTTP 403 Forbidden で応答しなければならない。

client が不正なメタデータフィールドを設定しようとし、かつ Authorization Server がデフォルト値を設定しない場合、Authorization Server は [RFC7591] に記載のとおりエラーで応答する。

2.3. Client Delete Request

Authorization Server 上で自分自身を廃止（deprovision）するために、client は client configuration endpoint に対して HTTP DELETE request を行う。このリクエストは、client に発行された registration access token により認証される。

次は非規範的なリクエスト例である。

DELETE /register/s6BhdRkqt3 HTTP/1.1
Host: server.example.com
Authorization: Bearer reg-23410913-abewfq.123483

削除操作が成功すると、この client の "client_id", "client_secret", "registration_access_token" は無効化される。これにより "client_id" が Authorization Server の authorization endpoint または token endpoint のいずれかで使用されることが防止される。可能であれば、Authorization Server は、既存の authorization grant と現在アクティブな Access Token、すべての Refresh Token、ならびにこの client に関連付けられるその他すべての token を直ちに無効化すべきである。

client の廃止（deprovision）が成功した場合、Authorization Server は HTTP 204 No Content メッセージで応答しなければならない。

サーバが delete method をサポートしない場合、サーバは HTTP 405 Not Supported で応答しなければならない。

このリクエストに用いられた registration access token が有効でない場合、サーバは OAuth Bearer Token Usage 仕様 [RFC6750] に記載のとおりエラーで応答しなければならない。

このサーバに client が存在しない場合、サーバは HTTP 401 Unauthorized で応答しなければならず、可能であれば当該リクエストに用いられた registration access token は直ちに失効させるべきである。

client が自分自身を削除することを許可されていない場合、サーバは HTTP 403 Forbidden で応答しなければならない。

次は非規範的なレスポンス例である。

HTTP/1.1 204 No Content
Cache-Control: no-store
Pragma: no-cache

3. Client Information Response

本仕様は、"OAuth 2.0 Client Dynamic Registration" [RFC7591] で定義される client information response を拡張する。そこでは、レスポンスが client identifier（ならびに client が Confidential client である場合の client secret）を含むと述べられている。本仕様と合わせて用いる場合、client information response は、この特定の client に対する client configuration endpoint（Section 2）の完全修飾 URL を、client または developer が client の登録設定を管理するために使える形で含む。さらに、client または developer が client configuration endpoint で後続の操作を行うために用いる registration access token も含む。

registration_client_uri
REQUIRED。文字列。client configuration endpoint の完全修飾 URL を含む。

registration_access_token
REQUIRED。文字列。client configuration endpoint で、client 登録に対する後続の操作を実行するために用いる access token を含む。

さらに、Authorization Server は、サーバ自身により用意されたフィールドを含め、この client に関するすべての登録済みメタデータを返さなければならない。Authorization Server は、登録または更新リクエストで提出された client の要求メタデータ値の一部を拒否または置換し、適切な値で置き換えてもよい。

レスポンスは、JSON オブジェクト [RFC7159] のトップレベルメンバーとしてすべてのパラメータを含む "application/json" 文書である。

次は非規範的なレスポンス例である。

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
 "registration_access_token": "reg-23410913-abewfq.123483",
 "registration_client_uri":
    "https://server.example.com/register/s6BhdRkqt3",
 "client_id": "s6BhdRkqt3",
 "client_secret": "cf136dc3c1fc93f31185e5885805d",
 "client_id_issued_at": 2893256800,
 "client_secret_expires_at": 2893276800,
 "client_name": "My Example Client",
 "client_name#ja-Jpan-JP":
    "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D",
 "redirect_uris": [
   "https://client.example.org/callback",
   "https://client.example.org/callback2"],
 "grant_types": ["authorization_code", "refresh_token"],
 "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"
}

4. IANA Considerations

本仕様は、[RFC7591] により確立された "OAuth Dynamic Client Registration Metadata" レジストリに、次の client メタデータ名と説明を登録する。

Client Metadata Name: "registration_access_token"
Client Metadata Description: client configuration endpoint へアクセスするために用いる OAuth 2.0 Bearer Token
Change Controller: IESG
Specification Document(s): RFC 7592

Client Metadata Name: "registration_client_uri"
Client Metadata Description: client registration endpoint の完全修飾 URI
Change Controller: IESG
Specification Document(s): RFC 7592

5. Security Considerations

client secret は失効し得るが、client がまだアクティブに登録されている間は registration access token は失効すべきではない。もしこの token が失効すると、developer または client が、client の登録情報を取得・更新・削除する手段を持たない状況に置かれ得る。その場合、新しい登録が必要となり、新しい client identifier が生成される。しかし registration access token の露出面を限定するために、developer または client が client configuration endpoint で read または update 操作を行う際、registration access token をローテーションしてもよい。registration access token は比較的長期の資格情報であり、かつ registration access token は Bearer Token で、client configuration endpoint における唯一の認証として機能するため、OAuth 2.0 Bearer Token Usage 仕様 [RFC6750] に記載のとおり、developer または client によって保護されなければならない。

client configuration endpoint へのリクエストは（HTTP request と response の中で）平文の資格情報の送信を伴うため、Authorization Server は endpoint へのリクエスト送信時にトランスポート層セキュリティ機構の利用を必須としなければならない。サーバは TLS 1.2 [RFC5246] をサポートしなければならず、セキュリティ要件を満たす追加のトランスポート層セキュリティ機構をサポートしてもよい。TLS を利用する場合、client は RFC 6125 [RFC6125] に従って TLS/SSL サーバ証明書の検証を行わなければならない。実装上のセキュリティ考慮事項は Recommendations for Secure Use of TLS and DTLS [BCP195] に示される。

registration access token の所持は、保持者に client の登録（client_secret などの資格情報を含む）を読み取り・修正・削除する権限を与え得るため、registration access token は、この token へのランダム推測攻撃を防ぐのに十分なエントロピーを含まなければならない。これは、[RFC6750] の Section 5.2 および [RFC6819] の Section 5.1.4.2.2 に記載のものと同様である。

client がサーバから廃止（deprovision）された場合、その client に対する未処理（outstanding）の registration access token は同時に無効化されなければならない。そうでないと、認証は成功するが、client がもはや有効ではないためアクションは失敗する、という不整合な状態につながり得る。Authorization Server は、そのようなリクエストを、registration access token が無効である場合と同様に扱い、記載のとおり HTTP 401 Unauthorized エラーを返さなければならない。

6. Privacy Considerations

本仕様は、コアの "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591] に記載されるものを超える追加のプライバシー考慮事項を提示しない。

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

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

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

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

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

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

[RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 Threat Model and Security Considerations", RFC 6819, DOI 10.17487/RFC6819, January 2013.

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

[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014.

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

Appendix A. Registration Tokens and Client Credentials

動的登録プロトコルの過程を通じて、性質と対象がそれぞれ異なる 3 種類の資格情報クラスが関与する。

initial access token は、client または developer により registration endpoint で任意に利用される。これは OAuth 2.0 token であり、初回の client 登録リクエストを認可するために用いられる。この token の内容、構造、生成、検証は本仕様のスコープ外である。Authorization Server は、この token を用いて、提示者が新しい client を動的に登録することを許可されているかを検証できる。この token は、client の複数インスタンス間で共有され、それぞれが別々に登録できるようにしてもよい。これにより Authorization Server は、この token を用いて、登録済み client の複数インスタンス（それぞれ異なる client identifier を持つ）を、initial access token が発行された相手（通常はアプリケーション developer）に結び付けられる。この token は通常、client registration endpoint でのみ利用されることを意図している。

registration access token は、client または developer により client configuration endpoint で利用され、client の登録を管理するための保持者の認可を表す。これは OAuth 2.0 Bearer Token であり、client registration request に対するレスポンスとして client registration endpoint から発行され、client information response に含まれて返される。registration access token は client identifier に一意に紐付けられ、client configuration endpoint へのすべての呼び出しで提示されることが要求される。registration access token は [RFC6750] に記載のとおり保護されるべきであり、client のインスタンス間で共有されるべきではない。もし registration access token が client インスタンス間で共有された場合、ある 1 つのインスタンスが、ほかのすべてのインスタンスの登録値を変更または削除できてしまう。registration access token は、client configuration endpoint における client read または update method の利用を通じてローテーションできる。registration access token は、client configuration endpoint でのみ利用されることを意図している。

client credentials（"client_secret" など）は、client の種類に応じて任意であり、OAuth token を取得するために用いられる。client credentials は多くの場合、client の特定インスタンスに紐付けられ、インスタンス間で共有されるべきではない。すべての種類の client が client credentials を持つわけではないため、client configuration endpoint における client 登録管理には利用できない点に注意せよ。client credentials は、client configuration endpoint の client read または update method の利用を通じてローテーションできる。client credentials は token endpoint でのみ利用されることを意図している。

A.1. Credential Rotation

Authorization Server は、client の存続期間を通じて、新しい registration access token および／または client credentials（"client_secret" など）を発行するように設定され得る。これは、資格情報が露出した場合の影響を最小化する助けになり得る。Authorization Server は、client configuration endpoint への read または update request の client information response において、新しい registration access token と（該当する場合）client credentials を client に伝達する。client の現在の registration access token と client credentials（該当する場合）は、client information response に含まれなければならない。

registration access token は、client configuration endpoint への read または update request に応じてのみローテーションされるべきである。この時点で、新しい registration access token が client に返され、古い registration access token は client によって破棄されなければならず、可能であればサーバによっても破棄されるべきである。もし代わりに、registration access token がそのようなリクエスト以外で失効または無効化された場合、client または developer は client の設定を管理できなくなる可能性がある。

credential rotation の頻度は client ではなく Authorization Server が決定する点に注意せよ。client が credential rotation を要求できる方法は本書のスコープ外である。

Appendix B. Forming the Client Configuration Endpoint URL

Authorization Server は、Section 3 に規定されるとおり、Client Information Response の "registration_client_uri" 要素において、完全修飾 URL を client に提供しなければならない。Authorization Server は、client がこの URL を自ら構築または発見することを期待してはならない。client はサーバから与えられた URL をそのまま利用しなければならず、構成要素からこの URL を組み立ててはならない。

デプロイ特性に応じて、client configuration endpoint の URL はさまざまな形式になり得る。この endpoint URL は、サーバが構築した URL 文字列として形成することが推奨される。具体的には、client registration endpoint の URL と、この client に対して発行された "client_id" を結合し、後者を path parameter または query parameter とする。たとえば、client identifier が "s6BhdRkqt3" の client は、"https://server.example.com/register/s6BhdRkqt3"（path parameter）または "https://server.example.com/register?client_id=s6BhdRkqt3"（query parameter）という client configuration endpoint URL を与えられ得る。どちらの場合も、client は Authorization Server から与えられた URL をそのまま利用する。

これらの一般的なパターンは、サーバがリクエストの対象となる client をより容易に特定する助けとなる。これは、registration access token が発行された client と照合されなければならない。必要に応じて、サーバは client registration endpoint の URL を client configuration endpoint URL としてそのまま返し、registration access token により提供される認証コンテキストに基づいて挙動を変えてもよい。

Acknowledgments

著者らは、この文書に対する input について 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、Phil Hunt、William Kim、Torsten Lodderstedt、Eve Maler、Josh Mandel、Nov Matake、Tony Nadalin、Nat Sakimura、Christian Scholz、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

OAuth 2.0 Dynamic Client Registration Management 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 Configuration Endpoint

2.1. Client Read Request

2.2. Client Update Request

2.3. Client Delete Request

3. Client Information Response

4. IANA Considerations

5. Security Considerations

6. Privacy Considerations

7. Normative References

Appendix A. Registration Tokens and Client Credentials

A.1. Credential Rotation

Appendix B. Forming the Client Configuration Endpoint URL

Acknowledgments

Authors' Addresses