[要約] RFC 7592は、OAuth 2.0の動的クライアント登録管理プロトコルに関する仕様です。この仕様の目的は、クライアントアプリケーションの動的な登録と管理を可能にすることです。
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
OAuth 2.0 Dynamic Client Registration Management Protocol
OAuth 2.0動的クライアント登録管理プロトコル
Abstract
概要
This specification defines methods for management of OAuth 2.0 dynamic client registrations for use cases in which the properties of a registered client may need to be changed during the lifetime of the client. Not all authorization servers supporting dynamic client registration will support these management methods.
この仕様は、クライアントの存続期間中に登録済みクライアントのプロパティを変更する必要があるユースケースのOAuth 2.0動的クライアント登録の管理方法を定義しています。動的クライアント登録をサポートするすべての許可サーバーがこれらの管理方法をサポートするわけではありません。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7592.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7592で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 4
2. Client Configuration Endpoint . . . . . . . . . . . . . . . . 5
2.1. Client Read Request . . . . . . . . . . . . . . . . . . . 6
2.2. Client Update Request . . . . . . . . . . . . . . . . . . 7
2.3. Client Delete Request . . . . . . . . . . . . . . . . . . 9
3. Client Information Response . . . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13
7. Normative References . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Registration Tokens and Client Credentials . . . . . 15
A.1. Credential Rotation . . . . . . . . . . . . . . . . . . . 16
Appendix B. Forming the Client Configuration Endpoint URL . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
In order for an OAuth 2.0 client to utilize an OAuth 2.0 authorization server, the client needs specific information to interact with the server, including an OAuth 2.0 client identifier to use with that server. "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591] describes how an OAuth 2.0 client can be dynamically registered with an authorization server to obtain this information and how metadata about the client can be registered with the server.
OAuth 2.0クライアントがOAuth 2.0承認サーバーを利用するためには、クライアントはサーバーと対話するための特定の情報（そのサーバーで使用するOAuth 2.0クライアント識別子を含む）を必要とします。 「OAuth 2.0動的クライアント登録プロトコル」[RFC7591]では、OAuth 2.0クライアントを認証サーバーに動的に登録してこの情報を取得する方法と、クライアントに関するメタデータをサーバーに登録する方法について説明しています。
This specification extends the core registration specification by defining a set of methods for management of dynamic OAuth 2.0 client registrations beyond those defined in the core registration specification. In some situations, the registered metadata of a client can change over time, either by modification at the authorization server or by a change in the client software itself. This specification provides methods for the current registration state of a client to be queried at the authorization server, methods for the registration of a client to be updated at the authorization server, and methods for the client to be unregistered from the authorization server.
この仕様は、動的なOAuth 2.0クライアント登録を管理するための一連のメソッドをコア登録仕様で定義されたものを超えて定義することにより、コア登録仕様を拡張します。状況によっては、クライアントの登録済みメタデータが、認証サーバーでの変更またはクライアントソフトウェア自体の変更によって、時間の経過とともに変化することがあります。この仕様は、許可サーバーで照会されるクライアントの現在の登録状態のメソッド、許可サーバーで更新されるクライアントの登録のメソッド、および許可サーバーからクライアントの登録を解除するメソッドを提供します。
This Experimental RFC is intended to encourage development and deployment of interoperable solutions with the intent that feedback from this experience will inform a future standard.
この試験的RFCは、この経験からのフィードバックが将来の標準に通知することを意図して、相互運用可能なソリューションの開発と展開を促進することを目的としています。
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Unless otherwise noted, all the protocol parameter names and values are case sensitive.
特に明記しない限り、すべてのプロトコルパラメータの名前と値は大文字と小文字が区別されます。
This specification uses the terms "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", and "token endpoint" defined by OAuth 2.0 [RFC6749] and the terms defined by "OAuth 2.0 Client Dynamic Registration Protocol" [RFC7591].
この仕様では、「アクセストークン」、「承認コード」、「承認エンドポイント」、「承認付与」、「承認サーバー」、「クライアント」、「クライアント識別子」、「クライアントシークレット」、「付与タイプ」、「 OAuth 2.0 [RFC6749]で定義されている「保護されたリソース」、「リダイレクトURI」、「リフレッシュトークン」、「リソースオーナー」、「リソースサーバー」、「応答タイプ」、および「トークンエンドポイント」と「OAuth 2.0クライアントで定義された用語動的登録プロトコル」[RFC7591]。
This specification defines the following terms:
この仕様では、次の用語を定義しています。
Client Configuration Endpoint OAuth 2.0 endpoint through which registration information for a registered client can be managed. This URL for this endpoint is returned by the authorization server in the client information response.
クライアント構成エンドポイント登録済みクライアントの登録情報を管理できるOAuth 2.0エンドポイント。このエンドポイントのこのURLは、承認サーバーによってクライアント情報応答で返されます。
Registration Access Token OAuth 2.0 Bearer Token issued by the authorization server through the client registration endpoint that is used to authenticate the caller when accessing the client's registration information at the client configuration endpoint. This access token is associated with a particular registered client.
登録アクセストークンOAuth 2.0ベアラートークンは、クライアント構成エンドポイントでクライアントの登録情報にアクセスするときに呼び出し元を認証するために使用される、クライアント登録エンドポイントを介して承認サーバーによって発行されます。このアクセストークンは、特定の登録済みクライアントに関連付けられています。
This extends the flow in "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591] as follows:
これにより、「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
図1：抽象拡張動的クライアント登録フロー
The abstract OAuth 2.0 client dynamic registration flow illustrated in Figure 1 describes the interaction between the client or developer and the endpoints defined in this specification and its parent. This figure does not demonstrate error conditions. This flow includes the following steps:
図1に示すOAuth 2.0クライアントの動的登録フローは、クライアントまたは開発者と、この仕様で定義されているエンドポイントとその親との間の相互作用を表しています。この図は、エラー状態を示していません。このフローには次のステップが含まれます。
(A) Optionally, the client or developer is issued an initial access token for use with the client registration endpoint. The method by which the initial access token is issued to the client or developer is out of scope for this specification.
（A）オプションで、クライアントまたは開発者には、クライアント登録エンドポイントで使用する初期アクセストークンが発行されます。初期アクセストークンをクライアントまたは開発者に発行する方法は、この仕様の範囲外です。
(B) Optionally, the client or developer is issued a software statement for use with the client registration endpoint. The method by which the software statement is issued to the client or developer is out of scope for this specification.
（B）オプションで、クライアントまたは開発者は、クライアント登録エンドポイントで使用するソフトウェアステートメントを発行されます。ソフトウェアステートメントがクライアントまたは開発者に発行される方法は、この仕様の範囲外です。
(C) The client or developer calls the client registration endpoint with its desired registration metadata, optionally including the initial access token from (A) if one is required by the authorization server.
（C）クライアントまたは開発者は、必要な登録メタデータを使用してクライアント登録エンドポイントを呼び出します。許可サーバーで必要な場合は、オプションで（A）からの初期アクセストークンを含めます。
(D) The authorization server registers the client and returns:
（D）認可サーバーはクライアントを登録し、次を返します：
* the client's registered metadata,
* クライアントの登録済みメタデータ、
* a client identifier that is unique to the server,
* サーバーに固有のクライアント識別子
* a set of client credentials such as a client secret, if applicable for this client,
* このクライアントに該当する場合、クライアントシークレットなどのクライアント資格情報のセット、
* a URI pointing to the client configuration endpoint, and
* クライアント構成エンドポイントを指すURI、および
* a registration access token to be used when calling the client configuration endpoint.
* クライアント構成エンドポイントを呼び出すときに使用される登録アクセストークン。
(E) The client or developer optionally calls the client configuration endpoint with a read or update request using the registration access token issued in (D). An update request contains all of the client's registered metadata.
（E）クライアントまたは開発者は、（D）で発行された登録アクセストークンを使用して、読み取りまたは更新要求でクライアント構成エンドポイントをオプションで呼び出します。更新リクエストには、クライアントの登録済みメタデータがすべて含まれています。
(F) The authorization server responds with the client's current configuration, potentially including a new registration access token and a new set of client credentials such as a client secret if applicable for this client. If a new registration access token is issued, it replaces the token issued in (D) for all subsequent calls to the client configuration endpoint.
（F）承認サーバーは、クライアントの現在の構成で応答します。このクライアントに該当する場合、新しい登録アクセストークンとクライアントシークレットなどの新しいクライアント資格情報のセットが含まれる可能性があります。新しい登録アクセストークンが発行されると、クライアント構成エンドポイントへの後続のすべての呼び出しで（D）で発行されたトークンが置き換えられます。
(G) The client or developer optionally calls the client configuration endpoint with a delete request using the registration access token issued in (D) or (F).
（G）クライアントまたは開発者は、オプションで、（D）または（F）で発行された登録アクセストークンを使用して、削除要求でクライアント構成エンドポイントを呼び出します。
(H) The authorization server deprovisions the client and responds with a confirmation that the deletion has taken place.
（H）承認サーバーがクライアントのプロビジョニングを解除し、削除が行われたことの確認で応答します。
The client configuration endpoint is an OAuth 2.0 protected resource that is provisioned by the server to facilitate viewing, updating, and deleting a client's registered information. The location of this endpoint is communicated to the client through the "registration_client_uri" member of the client information response, as specified in Section 3. The client MUST use its registration access token in all calls to this endpoint as an OAuth 2.0 Bearer Token [RFC6750].
クライアント構成エンドポイントは、クライアントによって登録された情報の表示、更新、および削除を容易にするためにサーバーによってプロビジョニングされるOAuth 2.0保護リソースです。このエンドポイントの場所は、セクション3で指定されているように、クライアント情報応答の "registration_client_uri"メンバーを介してクライアントに伝達されます。クライアントは、このエンドポイントへのすべての呼び出しでその登録アクセストークンをOAuth 2.0ベアラートークンとして使用する必要があります[RFC6750 ]。
The client configuration endpoint MUST be protected by a transport-layer security mechanism, as described in Section 5.
クライアント構成エンドポイントは、セクション5で説明されているように、トランスポート層セキュリティメカニズムで保護する必要があります。
Operations on this endpoint are switched through the use of different HTTP methods [RFC7231]. If an authorization server does not support a particular method on the client configuration endpoint, it MUST respond with the appropriate error code.
このエンドポイントでの操作は、さまざまなHTTPメソッド[RFC7231]を使用して切り替えられます。承認サーバーがクライアント構成エンドポイントで特定のメソッドをサポートしていない場合は、適切なエラーコードで応答する必要があります。
To read the current configuration of the client on the authorization server, the client makes an HTTP GET request to the client configuration endpoint, authenticating with its registration access token.
許可サーバー上のクライアントの現在の構成を読み取るために、クライアントはクライアント構成エンドポイントにHTTP GET要求を発行し、登録アクセストークンで認証します。
The following is a non-normative example request:
以下は、規範的でないリクエストの例です。
GET /register/s6BhdRkqt3 HTTP/1.1
Accept: application/json
Host: server.example.com
Authorization: Bearer reg-23410913-abewfq.123483
Upon successful read of the information for a currently active client, the authorization server responds with an HTTP 200 OK with content type of "application/json" and a payload as described in Section 3. Some values in the response, including the "client_secret" and "registration_access_token", MAY be different from those in the initial registration response. If the authorization server includes a new client secret and/or registration access token in its response, the client MUST immediately discard its previous client secret and/or registration access token. The value of the "client_id" MUST NOT change from the initial registration response.
現在アクティブなクライアントの情報が正常に読み取られると、認証サーバーは、セクション3で説明されているように、コンテンツタイプ「application / json」とペイロードを含むHTTP 200 OKで応答します。「client_secret」を含む、応答の一部の値「registration_access_token」は、最初の登録応答とは異なる場合があります。承認サーバーの応答に新しいクライアントシークレットや登録アクセストークンが含まれている場合、クライアントは以前のクライアントシークレットや登録アクセストークンを直ちに破棄する必要があります。 「client_id」の値は、最初の登録応答から変更してはなりません。
If the registration access token used to make this request is not valid, the server MUST respond with an error as described in the OAuth Bearer Token Usage specification [RFC6750].
このリクエストを行うために使用された登録アクセストークンが有効でない場合、サーバーはOAuth Bearer Token Usage仕様[RFC6750]で説明されているエラーで応答する必要があります。
If the client does not exist on this server, the server MUST respond with HTTP 401 Unauthorized and the registration access token used to make this request SHOULD be immediately revoked.
クライアントがこのサーバーに存在しない場合、サーバーはHTTP 401 Unauthorizedで応答する必要があり、この要求を行うために使用された登録アクセストークンは直ちに取り消される必要があります。
If the client does not have permission to read its record, the server MUST return an HTTP 403 Forbidden.
クライアントにそのレコードを読み取る権限がない場合、サーバーはHTTP 403 Forbiddenを返さなければなりません（MUST）。
To update a previously registered client's registration with an authorization server, the client makes an HTTP PUT request to the client configuration endpoint with a content type of "application/ json". The HTTP entity payload is a JSON [RFC7159] document consisting of a JSON object and all parameters as top-level members of that JSON object. This request is authenticated by the registration access token issued to the client.
以前に登録されたクライアントの登録を承認サーバーに更新するために、クライアントは、コンテンツタイプが "application / json"のクライアント構成エンドポイントにHTTP PUTリクエストを送信します。 HTTPエンティティのペイロードは、JSONオブジェクトのトップレベルメンバーとしてのJSONオブジェクトとすべてのパラメーターで構成されるJSON [RFC7159]ドキュメントです。この要求は、クライアントに発行された登録アクセストークンによって認証されます。
This request MUST include all client metadata fields as returned to the client from a previous registration, read, or update operation. The updated client metadata fields request MUST NOT include the "registration_access_token", "registration_client_uri", "client_secret_expires_at", or "client_id_issued_at" fields described in Section 3.
このリクエストには、以前の登録、読み取り、または更新操作からクライアントに返されたすべてのクライアントメタデータフィールドを含める必要があります。更新されたクライアントメタデータフィールドのリクエストには、セクション3で説明されている「registration_access_token」、「registration_client_uri」、「client_secret_expires_at」、または「client_id_issued_at」フィールドを含めないでください。
Valid values of client metadata fields in this request MUST replace, not augment, the values previously associated with this client. Omitted fields MUST be treated as null or empty values by the server, indicating the client's request to delete them from the client's registration. The authorization server MAY ignore any null or empty value in the request just as any other value.
このリクエストのクライアントメタデータフィールドの有効な値は、このクライアントに以前関連付けられていた値を拡張ではなく、置き換える必要があります。省略されたフィールドは、サーバーによってnullまたは空の値として扱われ、クライアントの登録からそれらを削除するクライアントの要求を示す必要があります。認可サーバーは、他の値と同様に、リクエスト内のnullまたは空の値を無視してもよい（MAY）。
The client MUST include its "client_id" field in the request, and it MUST be the same as its currently issued client identifier. If the client includes the "client_secret" field in the request, the value of this field MUST match the currently issued client secret for that client. The client MUST NOT be allowed to overwrite its existing client secret with its own chosen value.
クライアントはリクエストに "client_id"フィールドを含めなければならず、現在発行されているクライアント識別子と同じでなければなりません。クライアントがリクエストに「client_secret」フィールドを含める場合、このフィールドの値は、そのクライアントに対して現在発行されているクライアントシークレットと一致する必要があります。クライアントは、既存のクライアントシークレットを独自に選択した値で上書きすることを許可してはなりません。
For all metadata fields, the authorization server MAY replace any invalid values with suitable default values, and it MUST return any such fields to the client in the response.
すべてのメタデータフィールドについて、認証サーバーは無効な値を適切なデフォルト値で置き換えてもよい（MAY）、そのようなフィールドを応答でクライアントに返さなければならない（MUST）。
For example, a client could send the following request to the client registration endpoint to update the client registration in the above example with new information.
たとえば、クライアントは次のリクエストをクライアント登録エンドポイントに送信して、上記の例のクライアント登録を新しい情報で更新できます。
The following is a non-normative example request:
以下は、規範的でないリクエストの例です。
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"
}
This example uses client metadata values defined in [RFC7591].
この例では、[RFC7591]で定義されているクライアントメタデータ値を使用します。
Upon successful update, the authorization server responds with an HTTP 200 OK message with content type "application/json" and a payload as described in Section 3. Some values in the response, including the "client_secret" and "registration_access_token", MAY be different from those in the initial registration response. If the authorization server includes a new client secret and/or registration access token in its response, the client MUST immediately discard its previous client secret and/or registration access token. The value of the "client_id" MUST NOT change from the initial registration response.
更新が成功すると、認証サーバーは、セクション3で説明されているように、コンテンツタイプ「application / json」とペイロードを含むHTTP 200 OKメッセージで応答します。最初の登録応答のそれらから。承認サーバーの応答に新しいクライアントシークレットや登録アクセストークンが含まれている場合、クライアントは以前のクライアントシークレットや登録アクセストークンを直ちに破棄する必要があります。 「client_id」の値は、最初の登録応答から変更してはなりません。
If the registration access token used to make this request is not valid, the server MUST respond with an error as described in the OAuth Bearer Token Usage specification [RFC6750].
このリクエストを行うために使用された登録アクセストークンが有効でない場合、サーバーはOAuth Bearer Token Usage仕様[RFC6750]で説明されているエラーで応答する必要があります。
If the client does not exist on this server, the server MUST respond with HTTP 401 Unauthorized, and the registration access token used to make this request SHOULD be immediately revoked.
クライアントがこのサーバーに存在しない場合、サーバーはHTTP 401 Unauthorizedで応答する必要があり、この要求を行うために使用された登録アクセストークンは直ちに取り消される必要があります。
If the client is not allowed to update its records, the server MUST respond with HTTP 403 Forbidden.
クライアントがレコードの更新を許可されていない場合、サーバーはHTTP 403 Forbiddenで応答する必要があります。
If the client attempts to set an invalid metadata field and the authorization server does not set a default value, the authorization server responds with an error as described in [RFC7591].
クライアントが無効なメタデータフィールドを設定しようとし、承認サーバーがデフォルト値を設定しない場合、承認サーバーは[RFC7591]で説明されているエラーで応答します。
To deprovision itself on the authorization server, the client makes an HTTP DELETE request to the client configuration endpoint. This request is authenticated by the registration access token issued to the client.
承認サーバーで自身をプロビジョニング解除するために、クライアントはクライアント構成エンドポイントにHTTP DELETE要求を発行します。この要求は、クライアントに発行された登録アクセストークンによって認証されます。
The following is a non-normative example request:
以下は、規範的でないリクエストの例です。
DELETE /register/s6BhdRkqt3 HTTP/1.1
Host: server.example.com
Authorization: Bearer reg-23410913-abewfq.123483
A successful delete action will invalidate the "client_id", "client_secret", and "registration_access_token" for this client, thereby preventing the "client_id" from being used at either the authorization endpoint or token endpoint of the authorization server. If possible, the authorization server SHOULD immediately invalidate all existing authorization grants and currently active access tokens, all refresh tokens, and all other tokens associated with this client.
削除アクションが成功すると、このクライアントの「client_id」、「client_secret」、および「registration_access_token」が無効になり、「client_id」が認証サーバーの認証エンドポイントまたはトークンエンドポイントで使用されなくなります。可能であれば、承認サーバーは、既存のすべての承認付与と現在アクティブなアクセストークン、すべての更新トークン、およびこのクライアントに関連付けられているその他のすべてのトークンをただちに無効にする必要があります（SHOULD）。
If a client has been successfully deprovisioned, the authorization server MUST respond with an HTTP 204 No Content message.
クライアントが正常にプロビジョニング解除された場合、承認サーバーはHTTP 204 No Contentメッセージで応答する必要があります。
If the server does not support the delete method, the server MUST respond with HTTP 405 Not Supported.
サーバーが削除メソッドをサポートしていない場合、サーバーはHTTP 405 Not Supportedで応答する必要があります。
If the registration access token used to make this request is not valid, the server MUST respond with an error as described in the OAuth Bearer Token Usage specification [RFC6750].
このリクエストを行うために使用された登録アクセストークンが有効でない場合、サーバーはOAuth Bearer Token Usage仕様[RFC6750]で説明されているエラーで応答する必要があります。
If the client does not exist on this server, the server MUST respond with HTTP 401 Unauthorized and the registration access token used to make this request SHOULD be immediately revoked, if possible.
クライアントがこのサーバーに存在しない場合、サーバーはHTTP 401 Unauthorizedで応答する必要があり、この要求を行うために使用された登録アクセストークンは、可能であれば直ちに取り消す必要があります（SHOULD）。
If the client is not allowed to delete itself, the server MUST respond with HTTP 403 Forbidden.
クライアントが自身の削除を許可されていない場合、サーバーはHTTP 403 Forbiddenで応答する必要があります。
The following is a non-normative example response:
以下は、非規範的な応答例です。
HTTP/1.1 204 No Content Cache-Control: no-store Pragma: no-cache
HTTP / 1.1 204 No Content Cache-Control：no-storeプラグマ：no-cache
This specification extends the client information response defined in "OAuth 2.0 Client Dynamic Registration" [RFC7591], which states that the response contains the client identifier (as well as the client secret if the client is a confidential client). When used with this specification, the client information response also contains the fully qualified URL of the client configuration endpoint (Section 2) for this specific client that the client or developer may use to manage the client's registration configuration, as well as a registration access token that is to be used by the client or developer to perform subsequent operations at the client configuration endpoint.
この仕様は、「OAuth 2.0クライアント動的登録」[RFC7591]で定義されているクライアント情報応答を拡張します。これは、応答にクライアント識別子（およびクライアントが機密クライアントの場合はクライアントシークレット）を含むことを示しています。この仕様で使用する場合、クライアント情報応答には、クライアントまたは開発者がクライアントの登録構成を管理するために使用できるこの特定のクライアントのクライアント構成エンドポイント（セクション2）の完全修飾URLと、登録アクセストークンも含まれます。これは、クライアントまたは開発者がクライアント構成エンドポイントで後続の操作を実行するために使用されます。
registration_client_uri REQUIRED. String containing the fully qualified URL of the client configuration endpoint for this client.
registration_client_uriが必要です。このクライアントのクライアント構成エンドポイントの完全修飾URLを含む文字列。
registration_access_token REQUIRED. String containing the access token to be used at the client configuration endpoint to perform subsequent operations upon the client registration.
registration_access_tokenが必要です。クライアント登録時に後続の操作を実行するためにクライアント構成エンドポイントで使用されるアクセストークンを含む文字列。
Additionally, the authorization server MUST return all registered metadata about this client, including any fields provisioned by the authorization server itself. The authorization server MAY reject or replace any of the client's requested metadata values submitted during the registration or update requests and substitute them with suitable values.
さらに、承認サーバーは、承認サーバー自体によってプロビジョニングされたフィールドを含む、このクライアントに関するすべての登録済みメタデータを返さなければなりません（MUST）。認可サーバーは、登録または更新要求中に送信されたクライアントの要求されたメタデータ値を拒否または置換して、それらを適切な値に置き換えることができます。
The response is an "application/json" document with all parameters as top-level members of a JSON object [RFC7159].
応答は、JSONオブジェクト[RFC7159]のトップレベルメンバーとしてすべてのパラメーターを持つ「application / json」ドキュメントです。
The following is a non-normative example response:
以下は、非規範的な応答例です。
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"
}
This specification registers the following client metadata names and descriptions in the "OAuth Dynamic Client Registration Metadata" registry established by [RFC7591]:
この仕様は、[RFC7591]によって確立された「OAuth動的クライアント登録メタデータ」レジストリに次のクライアントメタデータ名と説明を登録します。
o Client Metadata Name: "registration_access_token"
o クライアントメタデータ名：「registration_access_token」
o Client Metadata Description: OAuth 2.0 Bearer Token used to access the client configuration endpoint
o クライアントメタデータの説明：クライアント構成エンドポイントへのアクセスに使用されるOAuth 2.0ベアラートークン
o Change Controller: IESG
o コントローラーの変更：IESG
o Specification Document(s): RFC 7592
o 仕様書：RFC 7592
o Client Metadata Name: "registration_client_uri"
o クライアントメタデータ名：「registration_client_uri」
o Client Metadata Description: Fully qualified URI of the client registration endpoint
o クライアントメタデータの説明：クライアント登録エンドポイントの完全修飾URI
o Change Controller: IESG o Specification Document(s): RFC 7592
o変更管理者：IESG o仕様書：RFC 7592
While the client secret can expire, the registration access token SHOULD NOT expire while a client is still actively registered. If this token were to expire, a developer or client could be left in a situation where they have no means of retrieving, updating, or deleting the client's registration information. Were that the case, a new registration would be required, thereby generating a new client identifier. However, to limit the exposure surface of the registration access token, the registration access token MAY be rotated when the developer or client does a read or update operation on the client's client configuration endpoint. As the registration access tokens are relatively long-term credentials, and since the registration access token is a Bearer Token and acts as the sole authentication for use at the client configuration endpoint, it MUST be protected by the developer or client as described in the OAuth 2.0 Bearer Token Usage specification [RFC6750].
クライアントシークレットは期限切れになる可能性がありますが、クライアントがまだアクティブに登録されている間は、登録アクセストークンが期限切れになるべきではありません（SHOULD NOT）。このトークンの有効期限が切れた場合、開発者またはクライアントは、クライアントの登録情報を取得、更新、または削除する手段がない状況に置かれる可能性があります。その場合、新しい登録が必要になり、それによって新しいクライアント識別子が生成されます。ただし、登録アクセストークンの公開面を制限するために、開発者またはクライアントがクライアントのクライアント構成エンドポイントで読み取りまたは更新操作を行うときに、登録アクセストークンをローテーションできます（MAY）。登録アクセストークンは比較的長期間の資格情報であり、登録アクセストークンはベアラートークンであり、クライアント構成エンドポイントで使用するための唯一の認証として機能するため、OAuthで説明されているように、開発者またはクライアントによって保護される必要があります。 2.0 Bearer Token Usage仕様[RFC6750]。
Since requests to the client configuration endpoint result in the transmission of clear-text credentials (in the HTTP request and response), the authorization server MUST require the use of a transport-layer security mechanism when sending requests to the endpoint. The server MUST support TLS 1.2 [RFC5246] and MAY support additional transport-layer security mechanisms meeting its security requirements. When using TLS, the client MUST perform a TLS/SSL server certificate check, per RFC 6125 [RFC6125]. Implementation security considerations can be found in Recommendations for Secure Use of TLS and DTLS [BCP195].
クライアント構成エンドポイントへの要求はクリアテキストのクレデンシャルの送信（HTTP要求と応答）になるため、承認サーバーは、要求をエンドポイントに送信するときにトランスポート層セキュリティメカニズムの使用を要求する必要があります。サーバーはTLS 1.2 [RFC5246]をサポートしなければならず（MUST）、そのセキュリティ要件を満たす追加のトランスポート層セキュリティメカニズムをサポートしてもよい（MAY）。 TLSを使用する場合、クライアントはRFC 6125 [RFC6125]に従ってTLS / SSLサーバー証明書チェックを実行する必要があります。実装のセキュリティに関する考慮事項は、TLSおよびDTLSの安全な使用に関する推奨事項[BCP195]に記載されています。
Since possession of the registration access token authorizes the holder to potentially read, modify, or delete a client's registration (including its credentials such as a client_secret), the registration access token MUST contain sufficient entropy to prevent a random guessing attack of this token, such as described in Section 5.2 of [RFC6750] and Section 5.1.4.2.2 of [RFC6819].
登録アクセストークンを所有することで、所有者はクライアントの登録（client_secretなどの資格情報を含む）を読み取り、変更、または削除する可能性があるため、登録トークンには、このトークンのランダムな推測攻撃を防ぐための十分なエントロピーが含まれている必要があります。 [RFC6750]のセクション5.2と[RFC6819]のセクション5.1.4.2.2に記載されています。
If a client is deprovisioned from a server, any outstanding registration access token for that client MUST be invalidated at the same time. Otherwise, this can lead to an inconsistent state wherein a client could make requests to the client configuration endpoint where the authentication would succeed but the action would fail because the client is no longer valid. The authorization server MUST treat all such requests as if the registration access token was invalid by returning an HTTP 401 Unauthorized error, as described.
クライアントがサーバーからプロビジョニング解除された場合、そのクライアントの未解決の登録アクセストークンは同時に無効にする必要があります。それ以外の場合、これは不整合な状態につながる可能性があり、認証が成功してもクライアントが有効ではなくなったためにアクションが失敗するクライアント構成エンドポイントにクライアントがリクエストを行う可能性があります。認可サーバーは、説明されているように、HTTP 401 Unauthorizedエラーを返すことによって、登録アクセストークンが無効であるかのように、そのようなすべての要求を処理する必要があります。
This specification poses no additional privacy considerations beyond those described in the core "OAuth 2.0 Dynamic Client Registration Protocol" [RFC7591].
この仕様では、コアの「OAuth 2.0動的クライアント登録プロトコル」[RFC7591]で説明されている以上のプライバシーに関する考慮事項はありません。
[BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, May 2015, <http://www.rfc-editor.org/info/bcp195>.
[BCP195] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、2015年5月、<http://www.rfc-editor.org/info/bcp195>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://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, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<http://www.rfc-editor.org/info / rfc5246>。
[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, <http://www.rfc-editor.org/info/rfc6125>.
[RFC6125] Saint-Andre、P。およびJ. Hodges、「トランスポート層セキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用したインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、 RFC 6125、DOI 10.17487 / RFC6125、2011年3月、<http://www.rfc-editor.org/info/rfc6125>。
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <http://www.rfc-editor.org/info/rfc6749>.
[RFC6749] Hardt、D。、編、「The OAuth 2.0 Authorization Framework」、RFC 6749、DOI 10.17487 / RFC6749、2012年10月、<http://www.rfc-editor.org/info/rfc6749>。
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, <http://www.rfc-editor.org/info/rfc6750>.
[RFC6750]ジョーンズ、M。およびD.ハート、「OAuth 2.0 Authorization Framework：Bearer Token Usage」、RFC 6750、DOI 10.17487 / RFC6750、2012年10月、<http://www.rfc-editor.org/info/ rfc6750>。
[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, <http://www.rfc-editor.org/info/rfc6819>.
[RFC6819] Lodderstedt、T.、Ed。、McGloin、M。、およびP. Hunt、「OAuth 2.0脅威モデルとセキュリティの考慮事項」、RFC 6819、DOI 10.17487 / RFC6819、2013年1月、<http：//www.rfc -editor.org/info/rfc6819>。
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7159]ブレイ、T。、編、「JavaScriptオブジェクト表記（JSON）データ交換フォーマット」、RFC 7159、DOI 10.17487 / RFC7159、2014年3月、<http://www.rfc-editor.org/info/ rfc7159>。
[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, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7231]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<http://www.rfc-editor.org/info/rfc7231 >。
[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, <http://www.rfc-editor.org/info/rfc7591>.
[RFC7591] Richer、J.、Ed。、Jones、M.、Bradley、J.、Machulak、M。、およびP. Hunt、「OAuth 2.0 Dynamic Client Registration Protocol」、RFC 7591、DOI 10.17487 / RFC7591、2015年7月、<http://www.rfc-editor.org/info/rfc7591>。
Throughout the course of the dynamic registration protocol, there are three different classes of credentials in play, each with different properties and targets.
動的登録プロトコルの過程全体を通じて、3つの異なる資格情報のクラスがあり、それぞれに異なるプロパティとターゲットがあります。
o The initial access token is optionally used by the client or developer at the registration endpoint. This is an OAuth 2.0 token that is used to authorize the initial client registration request. The content, structure, generation, and validation of this token are out of scope for this specification. The authorization server can use this token to verify that the presenter is allowed to dynamically register new clients. This token may be shared among multiple instances of a client to allow them to each register separately, thereby letting the authorization server use this token to tie multiple instances of registered clients (each with their own distinct client identifier) back to the party to whom the initial access token was issued, usually an application developer. This token is usually intended to be used only at the client registration endpoint.
o 初期アクセストークンは、登録エンドポイントでクライアントまたは開発者がオプションで使用します。これは、最初のクライアント登録要求を承認するために使用されるOAuth 2.0トークンです。このトークンのコンテンツ、構造、生成、および検証は、この仕様の範囲外です。許可サーバーはこのトークンを使用して、プレゼンターが新しいクライアントを動的に登録できることを確認できます。このトークンをクライアントの複数のインスタンス間で共有して、各インスタンスを個別に登録できるようにすることができます。これにより、承認サーバーはこのトークンを使用して、登録済みクライアントの複数のインスタンス（それぞれ独自のクライアント識別子を持つ）を、最初のアクセストークンが発行されました。通常はアプリケーション開発者です。このトークンは通常、クライアント登録エンドポイントでのみ使用することを目的としています。
o The registration access token is used by the client or developer at the client configuration endpoint and represents the holder's authorization to manage the registration of a client. This is an OAuth 2.0 Bearer Token that is issued from the client registration endpoint in response to a client registration request and is returned in a client information response. The registration access token is uniquely bound to the client identifier and is required to be presented with all calls to the client configuration endpoint. The registration access token should be protected as described in [RFC6750] and should not be shared between instances of a client. If a registration access token is shared between client instances, one instance could change or delete registration values for all other instances of the client. The registration access token can be rotated through the use of the client read or update method on the client configuration endpoint. The registration access token is intended to be used only at the client configuration endpoint.
o 登録アクセストークンは、クライアントまたは開発者がクライアント構成エンドポイントで使用し、クライアントの登録を管理するための所有者の承認を表します。これは、クライアント登録要求に応答してクライアント登録エンドポイントから発行され、クライアント情報応答で返されるOAuth 2.0ベアラートークンです。登録アクセストークンは、クライアント識別子に一意にバインドされ、クライアント構成エンドポイントへのすべての呼び出しで提示される必要があります。登録アクセストークンは、[RFC6750]で説明されているように保護する必要があり、クライアントのインスタンス間で共有しないでください。登録アクセストークンがクライアントインスタンス間で共有されている場合、1つのインスタンスがクライアントの他のすべてのインスタンスの登録値を変更または削除する可能性があります。登録アクセストークンは、クライアント構成エンドポイントでクライアントの読み取りまたは更新メソッドを使用してローテーションできます。登録アクセストークンは、クライアント構成エンドポイントでのみ使用することを目的としています。
o The client credentials (such as "client_secret") are optional depending on the type of client and are used to retrieve OAuth tokens. Client credentials are most often bound to particular instances of a client and should not be shared between instances. Note that since not all types of clients have client credentials, they cannot be used to manage client registrations at the client configuration endpoint. The client credentials can be rotated through the use of the client read or update method on the client configuration endpoint. The client credentials are intended to be used only at the token endpoint.
o クライアントの資格情報（「client_secret」など）は、クライアントのタイプに応じてオプションであり、OAuthトークンを取得するために使用されます。ほとんどの場合、クライアント資格情報はクライアントの特定のインスタンスにバインドされており、インスタンス間で共有しないでください。すべてのタイプのクライアントがクライアント資格情報を持っているわけではないため、クライアント構成エンドポイントでクライアント登録を管理するためにそれらを使用することはできません。クライアントの資格情報は、クライアント構成エンドポイントでクライアントの読み取りまたは更新メソッドを使用してローテーションできます。クライアント資格情報は、トークンエンドポイントでのみ使用することを目的としています。
The authorization server may be configured to issue new registration access tokens and/or client credentials (such as a "client_secret") throughout the lifetime of the client. This may help minimize the impact of exposed credentials. The authorization server conveys new registration access tokens and client credentials (if applicable) to the client in the client information response of either a read or update request to the client configuration endpoint. The client's current registration access token and client credentials (if applicable) MUST be included in the client information response.
認可サーバーは、クライアントの存続期間を通じて新しい登録アクセストークンやクライアント資格情報（「client_secret」など）を発行するように構成できます。これにより、公開された資格情報の影響を最小限に抑えることができます。承認サーバーは、新しい登録アクセストークンとクライアント資格情報（該当する場合）を、クライアント構成エンドポイントへの読み取りまたは更新要求のクライアント情報応答でクライアントに伝達します。クライアントの現在の登録アクセストークンとクライアント資格情報（該当する場合）は、クライアント情報応答に含める必要があります。
The registration access token SHOULD be rotated only in response to a read or update request to the client configuration endpoint. At this point, the new registration access token is returned to the client, the old registration access token MUST be discarded by the client, and it SHOULD be discarded by the server, if possible. If, instead, the registration access token were to expire or be invalidated outside of such requests, the client or developer might be locked out of managing the client's configuration.
登録アクセストークンは、クライアント構成エンドポイントへの読み取りまたは更新リクエストに応答する場合にのみローテーションする必要があります（SHOULD）。この時点で、新しい登録アクセストークンはクライアントに返され、古い登録アクセストークンはクライアントによって破棄されなければならず（MUST）、可能であればサーバーによって破棄されるべきです（SHOULD）。代わりに、登録アクセストークンが期限切れになるか、そのようなリクエストの外部で無効になる場合、クライアントまたは開発者はクライアントの構成の管理からロックアウトされる可能性があります。
Note that the authorization server decides the frequency of the credential rotation and not the client. Methods by which the client can request credential rotation are outside the scope of this document.
承認サーバーは、クライアントではなく認証情報のローテーションの頻度を決定することに注意してください。クライアントが認証情報のローテーションをリクエストできるメソッドは、このドキュメントの範囲外です。
The authorization server MUST provide the client with the fully qualified URL in the "registration_client_uri" element of the Client Information Response, as specified in Section 3. The authorization server MUST NOT expect the client to construct or discover this URL on its own. The client MUST use the URL as given by the server and MUST NOT construct this URL from component pieces.
承認サーバーは、セクション3で指定されているように、クライアント情報応答の "registration_client_uri"要素の完全修飾URLをクライアントに提供する必要があります。承認サーバーは、クライアントがこのURLを独自に作成または発見することを期待してはなりません。クライアントは、サーバーによって指定されたURLを使用する必要があり、コンポーネントの一部からこのURLを構築してはなりません（MUST NOT）。
Depending on deployment characteristics, the client configuration endpoint URL may take any number of forms. It is RECOMMENDED that this endpoint URL be formed through the use of a server-constructed URL string that combines the client registration endpoint's URL and the issued "client_id" for this client, with the latter as either a path parameter or a query parameter. For example, a client with the client identifier "s6BhdRkqt3" could be given a client configuration endpoint URL of "https://server.example.com/register/s6BhdRkqt3" (path parameter) or of "https://server.example.com/ register?client_id=s6BhdRkqt3" (query parameter). In both of these cases, the client simply uses the URL as given by the authorization server.
デプロイメントの特性に応じて、クライアント構成エンドポイントURLはいくつもの形式を取る場合があります。このエンドポイントURLは、クライアント登録エンドポイントのURLとこのクライアント用に発行された「client_id」を組み合わせたサーバー構築のURL文字列を使用して形成することをお勧めします。後者は、パスパラメータまたはクエリパラメータのいずれかです。たとえば、クライアント識別子が「s6BhdRkqt3」のクライアントには、「https://server.example.com/register/s6BhdRkqt3」（パスパラメータ）または「https：//server.example」のクライアント構成エンドポイントURLを付与できます。 .com / register？client_id = s6BhdRkqt3 "（クエリパラメーター）。これらのどちらの場合でも、クライアントは認証サーバーから提供されたURLを使用します。
These common patterns can help the server to more easily determine the client to which the request pertains, which MUST be matched against the client to which the registration access token was issued. If desired, the server MAY simply return the client registration endpoint URL as the client configuration endpoint URL and change behavior based on the authentication context provided by the registration access token.
これらの共通パターンは、サーバーが、リクエストが関係するクライアントをより簡単に特定するのに役立ちます。これは、登録アクセストークンが発行されたクライアントと照合する必要があります。必要に応じて、サーバーはクライアント登録エンドポイントURLをクライアント構成エンドポイントURLとして単に返し、登録アクセストークンによって提供される認証コンテキストに基づいて動作を変更できます。
Acknowledgments
謝辞
The authors thank the OAuth Working Group, the User-Managed Access Working Group, and the OpenID Connect Working Group participants for their input to this document. In particular, the following individuals have been instrumental in their review and contribution to various draft versions of this document: 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, and Hannes Tschofenig.
著者は、このドキュメントへの入力について、OAuthワーキンググループ、ユーザー管理アクセスワーキンググループ、およびOpenID Connectワーキンググループの参加者に感謝します。特に、次の個人は、このドキュメントのさまざまなドラフトバージョンへのレビューと貢献に尽力しています。キム、トルステン・ロダーシュテット、イブ・マラー、ジョシュ・マンデル、ノヴ・マタケ、トニー・ナダリン、ナット・サキムラ、クリスチャン・ショルツ、そしてハネス・ショフェニグ。
Authors' Addresses
著者のアドレス
Justin Richer (editor)
ジャスティン・リチャー（編集者）
Email: ietf@justin.richer.org
Michael B. Jones Microsoft
マイケルB.ジョーンズマイクロソフト
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