OAuth 2.0 Dynamic Client Registration Protocol

Abstract

概要

This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration.

本仕様は、OAuth 2.0 クライアントを認可サーバーに動的に登録するための仕組みを定義する。登録リクエストは、希望するクライアントメタデータ値の集合を認可サーバーに送る。その結果の登録レスポンスは、その認可サーバーで使用するクライアント識別子と、そのクライアントについて登録されたクライアントメタデータ値を返す。クライアントはその後、この登録情報を使って OAuth 2.0 プロトコルで認可サーバーと通信できる。本仕様はまた、クライアントが登録時に使用する共通のクライアントメタデータフィールドと値の集合も定義する。

1.Introduction

1.はじめに

In order for an OAuth 2.0 [RFC6749] 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 at that server. This specification describes how an OAuth 2.0 client can be dynamically registered with an authorization server to obtain this information.

OAuth 2.0 [RFC6749] クライアントが OAuth 2.0 認可サーバーを利用するには、そのサーバーで使用する OAuth 2.0 クライアント識別子を含め、サーバーとやり取りするための特定の情報がクライアントに必要である。本仕様は、OAuth 2.0 クライアントがこの情報を得るために認可サーバーに動的に登録する方法を記述する。

As part of the registration process, this specification also defines a mechanism for the client to present the authorization server with a set of metadata, such as a set of valid redirection URIs. This metadata can either be communicated in a self-asserted fashion or as a set of metadata called a software statement, which is digitally signed or protected with a Message Authentication Code (MAC); in the case of a software statement, the issuer is vouching for the validity of the data about the client.

登録プロセスの一部として、本仕様はまた、有効なリダイレクト URI の集合などのメタデータの集合をクライアントが認可サーバーに提示するための仕組みも定義する。このメタデータは、自己申告の形で伝えることも、ソフトウェアステートメントと呼ばれる、デジタル署名されるかメッセージ認証コード (MAC) で保護されたメタデータの集合として伝えることもできる。ソフトウェアステートメントの場合、発行者がそのクライアントに関するデータの妥当性を保証している。

Traditionally, registration of a client with an authorization server is performed manually. The mechanisms defined in this specification can be used either for a client to dynamically register itself with authorization servers or for a client developer to programmatically register the client with authorization servers. Multiple applications using OAuth 2.0 have previously developed mechanisms for accomplishing such registrations. This specification generalizes the registration mechanisms defined by "OpenID Connect Dynamic Client Registration 1.0" [OpenID.Registration] and used by "User Managed Access (UMA) Profile of OAuth 2.0" [UMA-Core] in a way that is compatible with both, while being applicable to a wider set of OAuth 2.0 use cases.

従来、認可サーバーへのクライアントの登録は手動で行われてきた。本仕様で定義する仕組みは、クライアントが自身を認可サーバーに動的に登録するためにも、クライアント開発者がクライアントを認可サーバーにプログラム的に登録するためにも使用できる。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

1.1.表記規約

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.

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

1.2.Terminology

1.2.用語

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 uses the term "Claim" defined by JSON Web Token (JWT) [RFC7519].

本仕様は、OAuth 2.0 [RFC6749] で定義される「アクセストークン」「認可コード」「認可エンドポイント」「認可グラント」「認可サーバー」「クライアント」「クライアント識別子」「クライアントシークレット」「グラントタイプ」「保護リソース」「リダイレクト URI」「リフレッシュトークン」「リソースオーナー」「リソースサーバー」「レスポンスタイプ」「トークンエンドポイント」の各用語、および JSON Web Token (JWT) [RFC7519] で定義される「クレーム」という用語を用いる。

This specification defines the following terms:

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

Client Software Software implementing an OAuth 2.0 client.

クライアントソフトウェア (Client Software): OAuth 2.0 クライアントを実装するソフトウェア。

Client Instance A deployed instance of a piece of client software.

クライアントインスタンス (Client Instance): あるクライアントソフトウェアのデプロイされたインスタンス。

Client Developer The person or organization that builds a client software package and prepares it for distribution. At the time the client is built, the developer is often not aware of who the deploying service provider organizations will be. Client developers will need to use dynamic registration when they are unable to predict aspects of the software, such as the deployment URLs, at compile time. For instance, this can occur when the software API publisher and the deploying organization are not the same.

クライアント開発者 (Client Developer): クライアントソフトウェアパッケージを構築し、配布のために準備する人または組織。クライアントが構築される時点では、開発者はデプロイするサービスプロバイダー組織が誰になるかを知らないことが多い。クライアント開発者は、デプロイ先 URL などソフトウェアの側面をコンパイル時に予測できない場合に、動的登録を使用する必要がある。たとえば、ソフトウェア API 公開者とデプロイ組織が同一でない場合にこれが起こりうる。

Client Registration Endpoint OAuth 2.0 endpoint through which a client can be registered at an authorization server. The means by which the URL for this endpoint is obtained are out of scope for this specification.

クライアント登録エンドポイント (Client Registration Endpoint): クライアントを認可サーバーに登録できる OAuth 2.0 エンドポイント。このエンドポイントの URL を取得する手段は本仕様の範囲外である。

Initial Access Token OAuth 2.0 access token optionally issued by an authorization server to a developer or client and used to authorize calls to the client registration endpoint. The type and format of this token are likely service specific and are out of scope for this specification. The means by which the authorization server issues this token as well as the means by which the registration endpoint validates this token are out of scope for this specification. Use of an initial access token is required when the authorization server limits the parties that can register a client.

初期アクセストークン (Initial Access Token): 認可サーバーが開発者またはクライアントに任意で発行する OAuth 2.0 アクセストークンで、クライアント登録エンドポイントへの呼び出しを認可するために使用される。このトークンの種類と形式はサービス固有になると考えられ、本仕様の範囲外である。認可サーバーがこのトークンを発行する手段、および登録エンドポイントがこのトークンを検証する手段は本仕様の範囲外である。認可サーバーがクライアントを登録できる当事者を制限する場合、初期アクセストークンの使用が必要となる。

Deployment Organization An administrative security domain under which a software API (service) is deployed and protected by an OAuth 2.0 framework. In some OAuth scenarios, the deployment organization and the software API publisher are the same. In these cases, the deploying organization will often have a close relationship with client software developers. In many other cases, the definer of the service may be an independent third-party publisher or a standards organization. When working to a published specification for an API, the client software developer is unable to have a prior relationship with the potentially many deployment organizations deploying the software API (service).

Deployment Organization (デプロイ組織) ソフトウェア API (サービス) がデプロイされ、OAuth 2.0 フレームワークによって保護される管理上のセキュリティドメイン。OAuth のシナリオによっては、デプロイ組織とソフトウェア API の発行者が同一である。その場合、デプロイする組織はクライアントソフトウェアの開発者と密接な関係を持つことが多い。それ以外の多くの場合、サービスの定義者は独立した第三者の発行者や標準化団体であることがある。公開された API 仕様に沿って開発する場合、クライアントソフトウェアの開発者は、そのソフトウェア API (サービス) をデプロイする潜在的に多数のデプロイ組織と事前の関係を持つことができない。

Software API Deployment A deployed instance of a software API that is protected by OAuth 2.0 (a protected resource) in a particular deployment organization domain. For any particular software API, there may be one or more deployments. A software API deployment typically has an associated OAuth 2.0 authorization server as well as a client registration endpoint. The means by which endpoints are obtained are out of scope for this specification.

ソフトウェア API デプロイメント (Software API Deployment): 特定のデプロイ組織ドメインにおいて OAuth 2.0 で保護される、ソフトウェア API のデプロイされたインスタンス (保護リソース)。ある特定のソフトウェア API について、1 つ以上のデプロイメントが存在しうる。ソフトウェア API デプロイメントは通常、関連する OAuth 2.0 認可サーバーおよびクライアント登録エンドポイントを持つ。エンドポイントを取得する手段は本仕様の範囲外である。

Software API Publisher The organization that defines a particular web-accessible API that may be deployed in one or more deployment environments. A publisher may be any standards body, commercial, public, private, or open source organization that is responsible for publishing and distributing software and API specifications that may be protected via OAuth 2.0. In some cases, a software API publisher and a client developer may be the same organization. At the time of publication of a web-accessible API, the software publisher often does not have a prior relationship with the deploying organizations.

ソフトウェア API 公開者 (Software API Publisher): 1 つ以上のデプロイ環境にデプロイされうる、特定のウェブアクセス可能な API を定義する組織。公開者は、OAuth 2.0 で保護されうるソフトウェアおよび API 仕様の公開と配布に責任を負う、標準化団体、商業組織、公的組織、民間組織、オープンソース組織のいずれでもありうる。場合によっては、ソフトウェア API 公開者とクライアント開発者が同一の組織であることもある。ウェブアクセス可能な API の公開時点では、ソフトウェア公開者はデプロイ組織と事前の関係を持たないことが多い。

Software Statement A digitally signed or MACed JSON Web Token (JWT) [RFC7519] that asserts metadata values about the client software. In some cases, a software statement will be issued directly by the client developer. In other cases, a software statement will be issued by a third-party organization for use by the client developer. In both cases, the trust relationship the authorization server has with the issuer of the software statement is intended to be used as an input to the evaluation of whether the registration request is accepted. A software statement can be presented to an authorization server as part of a client registration request.

ソフトウェアステートメント (Software Statement): クライアントソフトウェアに関するメタデータ値を表明する、デジタル署名または MAC が付与された JSON Web Token (JWT) [RFC7519]。場合によっては、ソフトウェアステートメントはクライアント開発者が直接発行する。別の場合には、クライアント開発者が使用するためにサードパーティ組織が発行する。いずれの場合も、認可サーバーがソフトウェアステートメントの発行者と持つ信頼関係は、登録リクエストを受け入れるかどうかの評価への入力として使われることを意図している。ソフトウェアステートメントは、クライアント登録リクエストの一部として認可サーバーに提示できる。

1.3.Protocol Flow

1.3.プロトコルフロー

The abstract OAuth 2.0 client dynamic registration flow illustrated in Figure 1 describes the interaction between the client or developer and the endpoint defined in this specification. This figure does not demonstrate error conditions. This flow includes the following steps:

図 1 に示す抽象的な OAuth 2.0 クライアント動的登録フローは、クライアントまたは開発者と、本仕様で定義するエンドポイントとのやり取りを記述する。この図はエラー条件を示していない。このフローは以下のステップからなる。

(D) The authorization server registers the client and returns:

(D) 認可サーバーはクライアントを登録し、以下を返す。

* the client's registered metadata,

* the client's registered metadata,

* a client identifier that is unique at the server, and

* a client identifier that is unique at the server, and

* a set of client credentials such as a client secret, if applicable for this client.

* このクライアントに該当する場合は、クライアントシークレットなどの一式のクライアントクレデンシャル。

Examples of different configurations and usages are included in Appendix A.

異なる構成と使い方の例は付録 A に含まれている。

2.Client Metadata

2.クライアントメタデータ

Registered clients have a set of metadata values associated with their client identifier at an authorization server, such as the list of valid redirection URIs or a display name.

登録済みクライアントは、有効なリダイレクト URI のリストや表示名など、認可サーバーにおいてクライアント識別子に関連付けられたメタデータ値の集合を持つ。

These client metadata values are used in two ways:

これらのクライアントメタデータ値は 2 つの方法で使用される。

o as input values to registration requests, and

o 登録リクエストへの入力値として、および

o as output values in registration responses.

o 登録レスポンスにおける出力値として。

The following client metadata fields are defined by this specification. The implementation and use of all client metadata fields is OPTIONAL, unless stated otherwise. All data member types (strings, arrays, numbers) are defined in terms of their JSON [RFC7159] representations.

本仕様は以下のクライアントメタデータフィールドを定義する。特に断りのない限り、すべてのクライアントメタデータフィールドの実装と使用は任意である (OPTIONAL)。すべてのデータメンバーの型 (文字列、配列、数値) は、その JSON [RFC7159] 表現の観点で定義される。

redirect_uris Array of redirection URI strings for use in redirect-based flows such as the authorization code and implicit flows. As required by Section 2 of OAuth 2.0 [RFC6749], clients using flows with redirection MUST register their redirection URI values. Authorization servers that support dynamic registration for redirect-based flows MUST implement support for this metadata value.

redirect_uris: 認可コードフローやインプリシットフローなどのリダイレクトベースのフローで使用するリダイレクト URI 文字列の配列。OAuth 2.0 [RFC6749] の 2 節で要求されるとおり、リダイレクトを伴うフローを使用するクライアントはリダイレクト URI 値を登録しなければならない (MUST)。リダイレクトベースのフローの動的登録をサポートする認可サーバーは、このメタデータ値のサポートを実装しなければならない (MUST)。

token_endpoint_auth_method String indicator of the requested authentication method for the token endpoint. Values defined by this specification are:

token_endpoint_auth_method: トークンエンドポイントに対して要求する認証方式を示す文字列。本仕様で定義される値は以下のとおり。

* "none": The client is a public client as defined in OAuth 2.0, Section 2.1, and does not have a client secret.

* "none": クライアントは OAuth 2.0 の 2.1 節で定義されるパブリッククライアントであり、クライアントシークレットを持たない。

* "client_secret_post": The client uses the HTTP POST parameters as defined in OAuth 2.0, Section 2.3.1.

* "client_secret_post": クライアントは OAuth 2.0 の 2.3.1 節で定義される HTTP POST パラメーターを用いる。

* "client_secret_basic": The client uses HTTP Basic as defined in OAuth 2.0, Section 2.3.1.

* "client_secret_basic": クライアントは OAuth 2.0 の 2.3.1 節で定義される HTTP Basic を用いる。

Additional values can be defined via the IANA "OAuth Token Endpoint Authentication Methods" registry established in Section 4.2. Absolute URIs can also be used as values for this parameter without being registered. If unspecified or omitted, the default is "client_secret_basic", denoting the HTTP Basic authentication scheme as specified in Section 2.3.1 of OAuth 2.0.

追加の値は、4.2 節で確立される IANA の "OAuth Token Endpoint Authentication Methods" レジストリを通じて定義できる。絶対 URI も、登録なしにこのパラメータの値として使用できる。未指定または省略された場合、デフォルトは "client_secret_basic" であり、これは OAuth 2.0 の 2.3.1 節で規定される HTTP Basic 認証スキームを示す。

grant_types Array of OAuth 2.0 grant type strings that the client can use at the token endpoint. These grant types are defined as follows:

grant_types: クライアントがトークンエンドポイントで使用できる OAuth 2.0 グラントタイプ文字列の配列。これらのグラントタイプは以下のように定義される。

* "authorization_code": The authorization code grant type defined in OAuth 2.0, Section 4.1.

* "authorization_code": OAuth 2.0 の 4.1 節で定義される認可コードグラントタイプ。

* "implicit": The implicit grant type defined in OAuth 2.0, Section 4.2.

* "implicit": OAuth 2.0 の 4.2 節で定義されるインプリシットグラントタイプ。

* "password": The resource owner password credentials grant type defined in OAuth 2.0, Section 4.3.

* "password": OAuth 2.0 の 4.3 節で定義されるリソースオーナーパスワードクレデンシャルグラントタイプ。

* "client_credentials": The client credentials grant type defined in OAuth 2.0, Section 4.4.

* "client_credentials": OAuth 2.0 の 4.4 節で定義されるクライアントクレデンシャルグラントタイプ。

* "refresh_token": The refresh token grant type defined in OAuth 2.0, Section 6.

* "refresh_token": OAuth 2.0 の 6 節で定義されるリフレッシュトークングラントタイプ。

* "urn:ietf:params:oauth:grant-type:jwt-bearer": The JWT Bearer Token Grant Type defined in OAuth JWT Bearer Token Profiles [RFC7523].

* "urn:ietf:params:oauth:grant-type:jwt-bearer": OAuth JWT Bearer Token Profiles [RFC7523] で定義される JWT Bearer トークングラントタイプ。

* "urn:ietf:params:oauth:grant-type:saml2-bearer": The SAML 2.0 Bearer Assertion Grant defined in OAuth SAML 2 Bearer Token Profiles [RFC7522].

* "urn:ietf:params:oauth:grant-type:saml2-bearer": OAuth SAML 2 Bearer Token Profiles [RFC7522] で定義される SAML 2.0 Bearer アサーショングラント。

If the token endpoint is used in the grant type, the value of this parameter MUST be the same as the value of the "grant_type" parameter passed to the token endpoint defined in the grant type definition. Authorization servers MAY allow for other values as defined in the grant type extension process described in OAuth 2.0, Section 4.5. If omitted, the default behavior is that the client will use only the "authorization_code" Grant Type.

グラントタイプでトークンエンドポイントが使用される場合、このパラメータの値は、そのグラントタイプ定義で定義されるトークンエンドポイントに渡される "grant_type" パラメータの値と同じでなければならない (MUST)。認可サーバーは、OAuth 2.0 の 4.5 節に記述されるグラントタイプ拡張プロセスで定義される他の値を許可してもよい (MAY)。省略された場合、デフォルトの動作はクライアントが "authorization_code" グラントタイプのみを使用するというものである。

response_types Array of the OAuth 2.0 response type strings that the client can use at the authorization endpoint. These response types are defined as follows:

response_types: クライアントが認可エンドポイントで使用できる OAuth 2.0 レスポンスタイプ文字列の配列。これらのレスポンスタイプは以下のように定義される。

* "code": The authorization code response type defined in OAuth 2.0, Section 4.1.

* "code": OAuth 2.0 の 4.1 節で定義される認可コードレスポンスタイプ。

* "token": The implicit response type defined in OAuth 2.0, Section 4.2.

* "token": OAuth 2.0 の 4.2 節で定義されるインプリシットレスポンスタイプ。

If the authorization endpoint is used by the grant type, the value of this parameter MUST be the same as the value of the "response_type" parameter passed to the authorization endpoint defined in the grant type definition. Authorization servers MAY allow for other values as defined in the grant type extension process is described in OAuth 2.0, Section 4.5. If omitted, the default is that the client will use only the "code" response type.

グラントタイプで認可エンドポイントが使用される場合、このパラメータの値は、そのグラントタイプ定義で定義される認可エンドポイントに渡される "response_type" パラメータの値と同じでなければならない (MUST)。認可サーバーは、OAuth 2.0 の 4.5 節に記述されるグラントタイプ拡張プロセスで定義される他の値を許可してもよい (MAY)。省略された場合、デフォルトはクライアントが "code" レスポンスタイプのみを使用するというものである。

client_name Human-readable string name of the client to be presented to the end-user during authorization. If omitted, the authorization server MAY display the raw "client_id" value to the end-user instead. It is RECOMMENDED that clients always send this field. The value of this field MAY be internationalized, as described in Section 2.2.

client_name: 認可の際にエンドユーザーに提示される、人間が読めるクライアントの名前文字列。省略された場合、認可サーバーは代わりに生の "client_id" 値をエンドユーザーに表示してもよい (MAY)。クライアントは常にこのフィールドを送ることが推奨される (RECOMMENDED)。このフィールドの値は、2.2 節に記述されるとおり国際化してもよい (MAY)。

client_uri URL string of a web page providing information about the client. If present, the server SHOULD display this URL to the end-user in a clickable fashion. It is RECOMMENDED that clients always send this field. The value of this field MUST point to a valid web page. The value of this field MAY be internationalized, as described in Section 2.2.

client_uri: クライアントに関する情報を提供するウェブページの URL 文字列。存在する場合、サーバーはこの URL をクリック可能な形でエンドユーザーに表示すべきである (SHOULD)。クライアントは常にこのフィールドを送ることが推奨される (RECOMMENDED)。このフィールドの値は有効なウェブページを指していなければならない (MUST)。このフィールドの値は、2.2 節に記述されるとおり国際化してもよい (MAY)。

logo_uri URL string that references a logo for the client. If present, the server SHOULD display this image to the end-user during approval. The value of this field MUST point to a valid image file. The value of this field MAY be internationalized, as described in Section 2.2.

logo_uri: クライアントのロゴを参照する URL 文字列。存在する場合、サーバーは承認の際にこの画像をエンドユーザーに表示すべきである (SHOULD)。このフィールドの値は有効な画像ファイルを指していなければならない (MUST)。このフィールドの値は、2.2 節に記述されるとおり国際化してもよい (MAY)。

scope String containing a space-separated list of scope values (as described in Section 3.3 of OAuth 2.0 [RFC6749]) that the client can use when requesting access tokens. The semantics of values in this list are service specific. If omitted, an authorization server MAY register a client with a default set of scopes.

scope: クライアントがアクセストークンを要求する際に使用できるスコープ値 (OAuth 2.0 [RFC6749] の 3.3 節に記述) のスペース区切りリストを含む文字列。このリスト内の値の意味はサービス固有である。省略された場合、認可サーバーはデフォルトのスコープの集合でクライアントを登録してもよい (MAY)。

contacts Array of strings representing ways to contact people responsible for this client, typically email addresses. The authorization server MAY make these contact addresses available to end-users for support requests for the client. See Section 6 for information on Privacy Considerations.

contacts: このクライアントの責任者に連絡する手段を表す文字列の配列で、通常はメールアドレスである。認可サーバーは、このクライアントに関するサポート要求のために、これらの連絡先をエンドユーザーに提供してもよい (MAY)。プライバシーに関する考慮事項については 6 節を参照。

tos_uri URL string that points to a human-readable terms of service document for the client that describes a contractual relationship between the end-user and the client that the end-user accepts when authorizing the client. The authorization server SHOULD display this URL to the end-user if it is provided. The value of this field MUST point to a valid web page. The value of this field MAY be internationalized, as described in Section 2.2.

tos_uri: クライアントの人間が読めるサービス利用規約文書を指す URL 文字列。この文書は、エンドユーザーがクライアントを認可する際に受け入れる、エンドユーザーとクライアントの間の契約関係を記述する。認可サーバーは、提供された場合にはこの URL をエンドユーザーに表示すべきである (SHOULD)。このフィールドの値は有効なウェブページを指していなければならない (MUST)。このフィールドの値は、2.2 節に記述されるとおり国際化してもよい (MAY)。

policy_uri URL string that points to a human-readable privacy policy document that describes how the deployment organization collects, uses, retains, and discloses personal data. The authorization server SHOULD display this URL to the end-user if it is provided. The value of this field MUST point to a valid web page. The value of this field MAY be internationalized, as described in Section 2.2.

policy_uri: デプロイ組織が個人データをどのように収集、使用、保持、開示するかを記述する、人間が読めるプライバシーポリシー文書を指す URL 文字列。認可サーバーは、提供された場合にはこの URL をエンドユーザーに表示すべきである (SHOULD)。このフィールドの値は有効なウェブページを指していなければならない (MUST)。このフィールドの値は、2.2 節に記述されるとおり国際化してもよい (MAY)。

jwks_uri URL string referencing the client's JSON Web Key (JWK) Set [RFC7517] document, which contains the client's public keys. The value of this field MUST point to a valid JWK Set document. These keys can be used by higher-level protocols that use signing or encryption. For instance, these keys might be used by some applications for validating signed requests made to the token endpoint when using JWTs for client authentication [RFC7523]. Use of this parameter is preferred over the "jwks" parameter, as it allows for easier key rotation. The "jwks_uri" and "jwks" parameters MUST NOT both be present in the same request or response.

jwks_uri: クライアントの公開鍵を含む、クライアントの JSON Web Key (JWK) Set [RFC7517] 文書を参照する URL 文字列。このフィールドの値は有効な JWK Set 文書を指していなければならない (MUST)。これらの鍵は、署名や暗号化を使用する上位プロトコルで使用できる。たとえば、クライアント認証に JWT を使用する際 [RFC7523]、トークンエンドポイントに対して行われた署名付きリクエストを検証するために、一部のアプリケーションがこれらの鍵を使用することがある。鍵のローテーションがより容易になるため、このパラメータの使用は "jwks" パラメータより優先される。"jwks_uri" パラメータと "jwks" パラメータの両方を同じリクエストまたはレスポンスに含めてはならない (MUST NOT)。

jwks Client's JSON Web Key Set [RFC7517] document value, which contains the client's public keys. The value of this field MUST be a JSON object containing a valid JWK Set. These keys can be used by higher-level protocols that use signing or encryption. This parameter is intended to be used by clients that cannot use the "jwks_uri" parameter, such as native clients that cannot host public URLs. The "jwks_uri" and "jwks" parameters MUST NOT both be present in the same request or response.

jwks: クライアントの公開鍵を含む、クライアントの JSON Web Key Set [RFC7517] 文書の値。このフィールドの値は有効な JWK Set を含む JSON オブジェクトでなければならない (MUST)。これらの鍵は、署名や暗号化を使用する上位プロトコルで使用できる。このパラメータは、公開 URL をホストできないネイティブクライアントなど、"jwks_uri" パラメータを使用できないクライアントによる使用を意図している。"jwks_uri" パラメータと "jwks" パラメータの両方を同じリクエストまたはレスポンスに含めてはならない (MUST NOT)。

software_id A unique identifier string (e.g., a Universally Unique Identifier (UUID)) assigned by the client developer or software publisher used by registration endpoints to identify the client software to be dynamically registered. Unlike "client_id", which is issued by the authorization server and SHOULD vary between instances, the "software_id" SHOULD remain the same for all instances of the client software. The "software_id" SHOULD remain the same across multiple updates or versions of the same piece of software. The value of this field is not intended to be human readable and is usually opaque to the client and authorization server.

software_id クライアント開発者またはソフトウェア発行者が割り当てる一意の識別子文字列 (例: Universally Unique Identifier (UUID)) で、動的に登録されるクライアントソフトウェアを識別するために登録エンドポイントが用いる。認可サーバーが発行しインスタンスごとに異なるべき (SHOULD) "client_id" とは異なり、"software_id" はそのクライアントソフトウェアのすべてのインスタンスで同じ値であるべきである (SHOULD)。"software_id" は、同じソフトウェアの複数のアップデートやバージョンにまたがって同じ値であるべきである (SHOULD)。このフィールドの値は人間が読めることを意図しておらず、通常はクライアントと認可サーバーにとって不透明である。

software_version A version identifier string for the client software identified by "software_id". The value of the "software_version" SHOULD change on any update to the client software identified by the same "software_id". The value of this field is intended to be compared using string equality matching and no other comparison semantics are defined by this specification. The value of this field is outside the scope of this specification, but it is not intended to be human readable and is usually opaque to the client and authorization server. The definition of what constitutes an update to client software that would trigger a change to this value is specific to the software itself and is outside the scope of this specification.

software_version: "software_id" で識別されるクライアントソフトウェアのバージョン識別子文字列。"software_version" の値は、同じ "software_id" で識別されるクライアントソフトウェアのあらゆる更新時に変化すべきである (SHOULD)。このフィールドの値は文字列の等価比較で比較されることを意図しており、本仕様ではそれ以外の比較の意味論を定義しない。このフィールドの値は本仕様の範囲外であるが、人間が読めることを意図しておらず、通常はクライアントと認可サーバーにとって不透明である。この値の変更を引き起こすクライアントソフトウェアの更新が何に当たるかの定義は、ソフトウェア自体に固有であり、本仕様の範囲外である。

Extensions and profiles of this specification can expand this list with metadata names and descriptions registered in accordance with the IANA Considerations in Section 4 of this document. The authorization server MUST ignore any client metadata sent by the client that it does not understand (for instance, by silently removing unknown metadata from the client's registration record during processing). The authorization server MAY reject any requested client metadata values by replacing requested values with suitable defaults as described in Section 3.2.1 or by returning an error response as described in Section 3.2.2.

本仕様の拡張やプロファイルは、本文書の 4 節の IANA に関する考慮事項に従って登録されたメタデータ名と説明によって、このリストを拡張できる。認可サーバーは、クライアントから送られた理解できないクライアントメタデータを無視しなければならない (MUST) (たとえば、処理中にクライアントの登録レコードから未知のメタデータを黙って取り除くなど)。認可サーバーは、3.2.1 節に記述されるとおり要求された値を適切なデフォルトに置き換えるか、3.2.2 節に記述されるとおりエラーレスポンスを返すことで、要求されたクライアントメタデータ値を拒否してもよい (MAY)。

Client metadata values can be either communicated directly in the body of a registration request, as described in Section 3.1, or included as claims in a software statement, as described in Section 2.3; a mixture of both is also possible. If the same client metadata name is present in both locations and the software statement is trusted by the authorization server, the value of a claim in the software statement MUST take precedence.

クライアントメタデータ値は、3.1 節に記述されるとおり登録リクエストのボディで直接伝えることも、2.3 節に記述されるとおりソフトウェアステートメント内のクレームとして含めることもでき、両者の混在も可能である。同じクライアントメタデータ名が両方の場所に存在し、認可サーバーがそのソフトウェアステートメントを信頼する場合、ソフトウェアステートメント内のクレームの値が優先されなければならない (MUST)。

2.1.Relationship between Grant Types and Response Types

2.1.グラントタイプとレスポンスタイプの関係

The "grant_types" and "response_types" values described above are partially orthogonal, as they refer to arguments passed to different endpoints in the OAuth protocol. However, they are related in that the "grant_types" available to a client influence the "response_types" that the client is allowed to use, and vice versa. For instance, a "grant_types" value that includes "authorization_code" implies a "response_types" value that includes "code", as both values are defined as part of the OAuth 2.0 authorization code grant. As such, a server supporting these fields SHOULD take steps to ensure that a client cannot register itself into an inconsistent state, for example, by returning an "invalid_client_metadata" error response to an inconsistent registration request.

上述の "grant_types" と "response_types" の値は、OAuth プロトコルの異なるエンドポイントに渡される引数を指すため、部分的に直交する。しかし、クライアントが利用できる "grant_types" はそのクライアントが使用を許される "response_types" に影響し、その逆も同様であるという点で、両者は関連している。たとえば、"authorization_code" を含む "grant_types" の値は、"code" を含む "response_types" の値を含意する。どちらの値も OAuth 2.0 認可コードグラントの一部として定義されているからである。したがって、これらのフィールドをサポートするサーバーは、たとえば整合しない登録リクエストに対して "invalid_client_metadata" エラーレスポンスを返すなどして、クライアントが自身を整合しない状態に登録できないようにする措置を講じるべきである (SHOULD)。

The correlation between the two fields is listed in the table below.

2 つのフィールドの対応関係を以下の表に示す。

Extensions and profiles of this document that introduce new values to either the "grant_types" or "response_types" parameter MUST document all correspondences between these two parameter types.

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

2.2.Human-Readable Client Metadata

2.2.人間が読めるクライアントメタデータ

Human-readable client metadata values and client metadata values that reference human-readable values MAY be represented in multiple languages and scripts. For example, the values of fields such as "client_name", "tos_uri", "policy_uri", "logo_uri", and "client_uri" might have multiple locale-specific values in some client registrations to facilitate use in different locations.

人間が読めるクライアントメタデータ値、および人間が読める値を参照するクライアントメタデータ値は、複数の言語や文字体系で表現してもよい (MAY)。たとえば、"client_name"、"tos_uri"、"policy_uri"、"logo_uri"、"client_uri" などのフィールドの値は、異なる地域での使用を容易にするため、一部のクライアント登録において複数のロケール固有の値を持つことがある。

To specify the languages and scripts, BCP 47 [RFC5646] language tags are added to client metadata member names, delimited by a "#" character. Since JSON [RFC7159] member names are case sensitive, it is RECOMMENDED that language tag values used in Claim Names be spelled using the character case with which they are registered in the "IANA Language Subtag" registry [IANA.Language]. In particular, normally language names are spelled with lowercase characters, region names are spelled with uppercase characters, and languages are spelled with mixed-case characters. However, since BCP 47 language tag values are case-insensitive, implementations SHOULD interpret the language tag values supplied in a case insensitive manner. Per the recommendations in BCP 47, language tag values used in metadata member names should only be as specific as necessary. For instance, using "fr" might be sufficient in many contexts, rather than "fr-CA" or "fr-FR".

言語と文字体系を指定するには、BCP 47 [RFC5646] 言語タグを "#" 文字で区切ってクライアントメタデータのメンバー名に付加する。JSON [RFC7159] のメンバー名は大文字小文字を区別するため、クレーム名で使用する言語タグ値は、"IANA Language Subtag" レジストリ [IANA.Language] に登録されている大文字小文字で綴ることが推奨される (RECOMMENDED)。特に、通常、言語名は小文字で、地域名は大文字で、文字体系名は大文字小文字混在で綴られる。ただし、BCP 47 言語タグ値は大文字小文字を区別しないため、実装は与えられた言語タグ値を大文字小文字を区別せずに解釈すべきである (SHOULD)。BCP 47 の推奨に従い、メタデータのメンバー名で使用する言語タグ値は必要な程度にのみ具体的であるべきである。たとえば、多くの文脈では "fr-CA" や "fr-FR" ではなく "fr" を使用すれば十分である。

If any human-readable field is sent without a language tag, parties using it MUST NOT make any assumptions about the language, character set, or script of the string value, and the string value MUST be used as is wherever it is presented in a user interface. To facilitate interoperability, it is RECOMMENDED that clients and servers use a human-readable field without any language tags in addition to any language-specific fields, and it is RECOMMENDED that any human- readable fields sent without language tags contain values suitable for display on a wide variety of systems.

人間が読めるフィールドが言語タグなしで送られた場合、それを使用する当事者は文字列値の言語、文字集合、文字体系についていかなる仮定も置いてはならず (MUST NOT)、文字列値はユーザーインターフェースに提示されるあらゆる場所でそのまま使用されなければならない (MUST)。相互運用性を促進するため、クライアントとサーバーは言語固有のフィールドに加えて言語タグのない人間が読めるフィールドを使用することが推奨され (RECOMMENDED)、言語タグなしで送られる人間が読めるフィールドは幅広いシステムでの表示に適した値を含むことが推奨される (RECOMMENDED)。

Implementer's Note: Many JSON libraries make it possible to reference members of a JSON object as members of an object construct in the native programming environment of the library. However, while the "#" character is a valid character inside of a JSON object's member names, it is not a valid character for use in an object member name in many programming environments. Therefore, implementations will need to use alternative access forms for these claims. For instance, in JavaScript, if one parses the JSON as follows, "var j = JSON.parse(json);", then as a workaround the member "client_name#en-us" can be accessed using the JavaScript syntax "j["client_name#en-us"]".

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

2.3.Software Statement

2.3.ソフトウェアステートメント

A software statement is a JSON Web Token (JWT) [RFC7519] that asserts metadata values about the client software as a bundle. A set of claims that can be used in a software statement are defined in Section 2. When presented to the authorization server as part of a client registration request, the software statement MUST be digitally signed or MACed using JSON Web Signature (JWS) [RFC7515] and MUST contain an "iss" (issuer) claim denoting the party attesting to the claims in the software statement. It is RECOMMENDED that software statements be digitally signed using the "RS256" signature algorithm, although particular applications MAY specify the use of different algorithms. It is RECOMMENDED that software statements contain the "software_id" claim to allow authorization servers to correlate different instances of software using the same software statement.

ソフトウェアステートメントは、クライアントソフトウェアに関するメタデータ値をひとまとめにして表明する JSON Web Token (JWT) [RFC7519] である。ソフトウェアステートメントで使用できるクレームの集合は 2 節で定義されている。クライアント登録リクエストの一部として認可サーバーに提示される場合、ソフトウェアステートメントは JSON Web Signature (JWS) [RFC7515] を用いてデジタル署名または MAC 付与されていなければならず (MUST)、ソフトウェアステートメント内のクレームを証明する当事者を示す "iss" (発行者) クレームを含んでいなければならない (MUST)。ソフトウェアステートメントは "RS256" 署名アルゴリズムでデジタル署名することが推奨される (RECOMMENDED) が、特定のアプリケーションは異なるアルゴリズムの使用を規定してもよい (MAY)。認可サーバーが同じソフトウェアステートメントを使用するソフトウェアの異なるインスタンスを関連付けられるよう、ソフトウェアステートメントは "software_id" クレームを含むことが推奨される (RECOMMENDED)。

For example, a software statement could contain the following claims:

たとえば、ソフトウェアステートメントは以下のクレームを含みうる。

The following non-normative example JWT includes these claims and has been asymmetrically signed using "RS256" (with line breaks for display purposes only):

以下の非規範的な JWT の例はこれらのクレームを含み、"RS256" で非対称署名されている (改行は表示上の都合によるものである)。

The software statement is typically distributed with all instances of a client application. The means by which a client or developer obtains a software statement are outside the scope of this specification. Some common methods could include a client developer generating a client-specific JWT by registering with a software API publisher to obtain a software statement for a class of clients.

ソフトウェアステートメントは通常、クライアントアプリケーションのすべてのインスタンスとともに配布される。クライアントまたは開発者がソフトウェアステートメントを取得する手段は本仕様の範囲外である。一般的な方法としては、クライアント開発者がソフトウェア API 公開者に登録してあるクラスのクライアント向けのソフトウェアステートメントを取得し、クライアント固有の JWT を生成するといったものがありうる。

The criteria by which authorization servers determine whether to trust and utilize the information in a software statement are outside the scope of this specification.

認可サーバーがソフトウェアステートメント内の情報を信頼し利用するかどうかを判断する基準は、本仕様の範囲外である。

In some cases, authorization servers MAY choose to accept a software statement value directly as a client identifier in an authorization request, without a prior dynamic client registration having been performed. The circumstances under which an authorization server would do so, and the specific software statement characteristics required in this case, are outside the scope of this specification.

場合によっては、認可サーバーは、事前に動的クライアント登録が行われていなくても、認可リクエストにおけるクライアント識別子としてソフトウェアステートメントの値を直接受け入れることを選んでもよい (MAY)。認可サーバーがそうする状況、およびその場合に必要となる具体的なソフトウェアステートメントの特性は、本仕様の範囲外である。

3.Client Registration Endpoint

3.クライアント登録エンドポイント

The client registration endpoint is an OAuth 2.0 endpoint defined in this document that is designed to allow a client to be registered with the authorization server. The client registration endpoint MUST accept HTTP POST messages with request parameters encoded in the entity body using the "application/json" format. The client registration endpoint MUST be protected by a transport-layer security mechanism, as described in Section 5.

クライアント登録エンドポイントは、本書で定義する OAuth 2.0 エンドポイントであり、クライアントを認可サーバーに登録できるように設計されている。クライアント登録エンドポイントは、リクエストパラメーターを "application/json" 形式でエンティティボディにエンコードした HTTP POST メッセージを受け付けなければならない (MUST)。クライアント登録エンドポイントは、5 節で述べるとおり、トランスポート層のセキュリティ機構によって保護されなければならない (MUST)。

The client registration endpoint MAY be an OAuth 2.0 [RFC6749] protected resource and it MAY accept an initial access token in the form of an OAuth 2.0 access token to limit registration to only previously authorized parties. The method by which the initial access token is obtained by the client or developer is generally out of band and is out of scope for this specification. The method by which the initial access token is verified and validated by the client registration endpoint is out of scope for this specification.

クライアント登録エンドポイントは OAuth 2.0 [RFC6749] 保護リソースであってもよく (MAY)、登録を事前に認可された当事者のみに制限するために、OAuth 2.0 アクセストークンの形で初期アクセストークンを受け付けてもよい (MAY)。クライアントまたは開発者が初期アクセストークンを取得する方法は、一般に帯域外であり、本仕様の範囲外である。クライアント登録エンドポイントが初期アクセストークンを検証する方法は、本仕様の範囲外である。

To support open registration and facilitate wider interoperability, the client registration endpoint SHOULD allow registration requests with no authorization (which is to say, with no initial access token in the request). These requests MAY be rate-limited or otherwise limited to prevent a denial-of-service attack on the client registration endpoint.

オープンな登録をサポートし、より広い相互運用性を促進するため、クライアント登録エンドポイントは認可のない登録リクエスト (すなわち、リクエストに初期アクセストークンのないもの) を許可すべきである (SHOULD)。これらのリクエストは、クライアント登録エンドポイントに対するサービス拒否攻撃を防ぐために、レート制限やその他の制限を課してもよい (MAY)。

3.1.Client Registration Request

3.1.クライアント登録リクエスト

This operation registers a client with the authorization server. The authorization server assigns this client a unique client identifier, optionally assigns a client secret, and associates the metadata provided in the request with the issued client identifier. The request includes any client metadata parameters being specified for the client during the registration. The authorization server MAY provision default values for any items omitted in the client metadata.

この操作はクライアントを認可サーバーに登録する。認可サーバーはこのクライアントに一意なクライアント識別子を割り当て、任意でクライアントシークレットを割り当て、リクエストで提供されたメタデータを発行したクライアント識別子に関連付ける。リクエストには、登録時にそのクライアントについて指定されるあらゆるクライアントメタデータパラメータが含まれる。認可サーバーは、クライアントメタデータで省略された項目にデフォルト値を設定してもよい (MAY)。

To register, the client or developer sends an HTTP POST to the client registration endpoint with a content type of "application/json". The HTTP Entity Payload is a JSON [RFC7159] document consisting of a JSON object and all requested client metadata values as top-level members of that JSON object.

登録するには、クライアントまたは開発者はコンテンツタイプ "application/json" でクライアント登録エンドポイントに HTTP POST を送る。HTTP エンティティペイロードは、1 つの JSON オブジェクトからなる JSON [RFC7159] 文書であり、要求するすべてのクライアントメタデータ値をその JSON オブジェクトのトップレベルメンバーとして含む。

For example, if the server supports open registration (with no initial access token), the client could send the following registration request to the client registration endpoint.

たとえば、サーバーがオープンな登録 (初期アクセストークンなし) をサポートする場合、クライアントはクライアント登録エンドポイントに以下の登録リクエストを送ることができる。

The following is a non-normative example request not using an initial access token:

以下は、初期アクセストークンを使用しない非規範的なリクエストの例である。

Alternatively, if the server supports authorized registration, the developer or the client will be provisioned with an initial access token. (The method by which the initial access token is obtained is out of scope for this specification.) The developer or client sends the following authorized registration request to the client registration endpoint. Note that the initial access token sent in this example as an OAuth 2.0 Bearer Token [RFC6750], but any OAuth 2.0 token type could be used by an authorization server.

あるいは、サーバーが認可付きの登録をサポートする場合、開発者またはクライアントには初期アクセストークンが提供される。(初期アクセストークンを取得する方法は本仕様の範囲外である。) 開発者またはクライアントは、クライアント登録エンドポイントに以下の認可付き登録リクエストを送る。この例では初期アクセストークンを OAuth 2.0 Bearer トークン [RFC6750] として送っているが、認可サーバーはどの OAuth 2.0 トークンタイプを使用してもよいことに注意。

The following is a non-normative example request using an initial access token and registering a JWK Set by value (with line breaks within values for display purposes only):

以下は、初期アクセストークンを使用し、JWK Set を値で登録する非規範的なリクエストの例である (値内の改行は表示上の都合によるものである)。

3.1.1.Client Registration Request Using a Software Statement

3.1.1.ソフトウェアステートメントを使用するクライアント登録リクエスト

In addition to JSON elements, client metadata values MAY also be provided in a software statement, as described in Section 2.3. The authorization server MAY ignore the software statement if it does not support this feature. If the server supports software statements, client metadata values conveyed in the software statement MUST take precedence over those conveyed using plain JSON elements.

JSON 要素に加えて、クライアントメタデータ値は 2.3 節に記述されるとおりソフトウェアステートメントで提供してもよい (MAY)。認可サーバーは、この機能をサポートしない場合にはソフトウェアステートメントを無視してもよい (MAY)。サーバーがソフトウェアステートメントをサポートする場合、ソフトウェアステートメントで伝えられたクライアントメタデータ値は、通常の JSON 要素で伝えられたものより優先されなければならない (MUST)。

Software statements are included in the requesting JSON object using this OPTIONAL member:

ソフトウェアステートメントは、以下の任意の (OPTIONAL) メンバーを使ってリクエストの JSON オブジェクトに含める。

software_statement A software statement containing client metadata values about the client software as claims. This is a string value containing the entire signed JWT.

software_statement: クライアントソフトウェアに関するクライアントメタデータ値をクレームとして含むソフトウェアステートメント。これは署名付き JWT 全体を含む文字列値である。

In the following example, some registration parameters are conveyed as claims in a software statement from the example in Section 2.3, while some values specific to the client instance are conveyed as regular parameters (with line breaks within values for display purposes only):

以下の例では、一部の登録パラメータは 2.3 節の例のソフトウェアステートメント内のクレームとして伝えられ、クライアントインスタンスに固有の一部の値は通常のパラメータとして伝えられている (値内の改行は表示上の都合によるものである)。

3.2.Responses

3.2.レスポンス

Upon a successful registration request, the authorization server returns a client identifier for the client. The server responds with an HTTP 201 Created status code and a body of type "application/json" with content as described in Section 3.2.1.

登録リクエストが成功すると、認可サーバーはクライアントのクライアント識別子を返す。サーバーは HTTP 201 Created ステータスコードと、3.2.1 節に記述される内容を持つ "application/json" 型のボディで応答する。

Upon an unsuccessful registration request, the authorization server responds with an error, as described in Section 3.2.2.

登録リクエストが失敗すると、認可サーバーは 3.2.2 節に記述されるとおりエラーで応答する。

3.2.1.Client Information Response

3.2.1.クライアント情報レスポンス

The response contains the client identifier as well as the client secret, if the client is a confidential client. The response MAY contain additional fields as specified by extensions to this specification.

レスポンスにはクライアント識別子と、クライアントがコンフィデンシャルクライアントである場合にはクライアントシークレットが含まれる。レスポンスには本仕様の拡張で規定される追加のフィールドが含まれてもよい (MAY)。

client_id REQUIRED. OAuth 2.0 client identifier string. It SHOULD NOT be currently valid for any other registered client, though an authorization server MAY issue the same client identifier to multiple instances of a registered client at its discretion.

client_id: 必須 (REQUIRED)。OAuth 2.0 クライアント識別子文字列。他の登録済みクライアントに対して現在有効であるべきではない (SHOULD NOT) が、認可サーバーはその裁量で、登録済みクライアントの複数のインスタンスに同じクライアント識別子を発行してもよい (MAY)。

client_secret OPTIONAL. OAuth 2.0 client secret string. If issued, this MUST be unique for each "client_id" and SHOULD be unique for multiple instances of a client using the same "client_id". This value is used by confidential clients to authenticate to the token endpoint, as described in OAuth 2.0 [RFC6749], Section 2.3.1.

client_secret: 任意 (OPTIONAL)。OAuth 2.0 クライアントシークレット文字列。発行される場合、"client_id" ごとに一意でなければならず (MUST)、同じ "client_id" を使用するクライアントの複数のインスタンスの間でも一意であるべきである (SHOULD)。この値は、OAuth 2.0 [RFC6749] の 2.3.1 節に記述されるとおり、コンフィデンシャルクライアントがトークンエンドポイントに対して認証するために使用する。

client_id_issued_at OPTIONAL. Time at which the client identifier was issued. The time is represented as the number of seconds from 1970-01-01T00:00:00Z as measured in UTC until the date/time of issuance.

client_id_issued_at: 任意 (OPTIONAL)。クライアント識別子が発行された時刻。時刻は、UTC で計測した 1970-01-01T00:00:00Z から発行日時までの秒数で表される。

client_secret_expires_at REQUIRED if "client_secret" is issued. Time at which the client secret will expire or 0 if it will not expire. The time is represented as the number of seconds from 1970-01-01T00:00:00Z as measured in UTC until the date/time of expiration.

client_secret_expires_at: "client_secret" が発行される場合は必須 (REQUIRED)。クライアントシークレットが期限切れになる時刻。期限切れにならない場合は 0。時刻は、UTC で計測した 1970-01-01T00:00:00Z から期限切れ日時までの秒数で表される。

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 and substitute them with suitable values. The client or developer can check the values in the response to determine if the registration is sufficient for use (e.g., the registered "token_endpoint_auth_method" is supported by the client software) and determine a course of action appropriate for the client software. The response to such a situation is out of scope for this specification but could include filing a report with the application developer or authorization server provider, attempted re-registration with different metadata values, or various other methods. For instance, if the server also supports a registration management mechanism such as that defined in [RFC7592], the client or developer could attempt to update the registration with different metadata values. This process could also be aided by a service discovery protocol, such as [OpenID.Discovery], which can list a server's capabilities, allowing a client to make a more informed registration request. The use of any such management or discovery system is optional and outside the scope of this specification.

加えて、認可サーバーは、認可サーバー自身が設定したフィールドを含め、このクライアントに関して登録されたすべてのメタデータを返さなければならない (MUST)。認可サーバーは、登録時に提出されたクライアントの要求するメタデータ値を拒否または置換し、適切な値に差し替えてもよい (MAY)。クライアントまたは開発者はレスポンス内の値を確認して、その登録が使用に足るものか (たとえば、登録された "token_endpoint_auth_method" がクライアントソフトウェアでサポートされているか) を判断し、クライアントソフトウェアに適した対応方針を決めることができる。そのような状況への対応は本仕様の範囲外であるが、アプリケーション開発者または認可サーバー提供者への報告、異なるメタデータ値での再登録の試み、その他さまざまな方法がありうる。たとえば、サーバーが [RFC7592] で定義されるような登録管理機構もサポートしている場合、クライアントまたは開発者は異なるメタデータ値で登録の更新を試みることができる。このプロセスは、サーバーの機能を列挙できる [OpenID.Discovery] のようなサービスディスカバリープロトコルによっても支援されうる。これにより、クライアントはより情報に基づいた登録リクエストを行える。そのような管理やディスカバリーのシステムの使用は任意であり、本仕様の範囲外である。

The successful registration response uses an HTTP 201 Created status code with a body of type "application/json" consisting of a single JSON object [RFC7159] with all parameters as top-level members of the object.

登録成功レスポンスは、HTTP 201 Created ステータスコードを使用し、すべてのパラメータをオブジェクトのトップレベルメンバーとして持つ単一の JSON オブジェクト [RFC7159] からなる "application/json" 型のボディを伴う。

If a software statement was used as part of the registration, its value MUST be returned unmodified in the response along with other metadata using the "software_statement" member name. Client metadata elements used from the software statement MUST also be returned directly as top-level client metadata values in the registration response (possibly with different values, since the values requested and the values used may differ).

登録の一部としてソフトウェアステートメントが使用された場合、その値は "software_statement" メンバー名を使って、他のメタデータとともにレスポンスで変更なしに返されなければならない (MUST)。ソフトウェアステートメントから使用されたクライアントメタデータ要素は、登録レスポンスにおいてトップレベルのクライアントメタデータ値としても直接返されなければならない (MUST) (要求された値と使用された値は異なりうるため、異なる値になる可能性がある)。

The following is a non-normative example response of a successful registration:

以下は、登録成功時の非規範的なレスポンスの例である。

3.2.2.Client Registration Error Response

3.2.2.クライアント登録エラーレスポンス

When an OAuth 2.0 error condition occurs, such as the client presenting an invalid initial access token, the authorization server returns an error response appropriate to the OAuth 2.0 token type.

クライアントが無効な初期アクセストークンを提示した場合など、OAuth 2.0 のエラー条件が発生した場合、認可サーバーはその OAuth 2.0 トークンタイプに適したエラーレスポンスを返す。

When a registration error condition occurs, the authorization server returns an HTTP 400 status code (unless otherwise specified) with content type "application/json" consisting of a JSON object [RFC7159] describing the error in the response body.

登録のエラー条件が発生した場合、認可サーバーは (特に規定のない限り) HTTP 400 ステータスコードを、レスポンスボディにエラーを記述する JSON オブジェクト [RFC7159] からなるコンテンツタイプ "application/json" とともに返す。

Two members are defined for inclusion in the JSON object:

JSON オブジェクトに含めるメンバーとして 2 つが定義されている。

error REQUIRED. Single ASCII error code string.

error: 必須 (REQUIRED)。単一の ASCII エラーコード文字列。

error_description OPTIONAL. Human-readable ASCII text description of the error used for debugging.

error_description: 任意 (OPTIONAL)。デバッグに用いる、人間が読める ASCII テキストのエラー説明。

Other members MAY also be included and, if they are not understood, they MUST be ignored.

他のメンバーも含めてもよく (MAY)、理解できない場合には無視しなければならない (MUST)。

This specification defines the following error codes:

本仕様は以下のエラーコードを定義する。

invalid_redirect_uri The value of one or more redirection URIs is invalid.

invalid_redirect_uri: 1 つ以上のリダイレクト URI の値が無効である。

invalid_client_metadata The value of one of the client metadata fields is invalid and the server has rejected this request. Note that an authorization server MAY choose to substitute a valid value for any requested parameter of a client's metadata.

invalid_client_metadata: クライアントメタデータフィールドのいずれかの値が無効であり、サーバーはこのリクエストを拒否した。認可サーバーは、クライアントメタデータの要求されたパラメータのいずれについても有効な値で置き換えることを選んでもよい (MAY) ことに注意。

invalid_software_statement The software statement presented is invalid.

invalid_software_statement: 提示されたソフトウェアステートメントが無効である。

unapproved_software_statement The software statement presented is not approved for use by this authorization server.

unapproved_software_statement: 提示されたソフトウェアステートメントは、この認可サーバーでの使用が承認されていない。

The following is a non-normative example of an error response resulting from a redirection URI that has been blacklisted by the authorization server (with line breaks within values for display purposes only):

以下は、認可サーバーによってブラックリストに登録されたリダイレクト URI に起因するエラーレスポンスの非規範的な例である (値内の改行は表示上の都合によるものである)。

The following is a non-normative example of an error response resulting from an inconsistent combination of "response_types" and "grant_types" values (with line breaks within values for display purposes only):

以下は、"response_types" と "grant_types" の値の一貫性のない組み合わせに起因するエラーレスポンスの非規範的な例である (値内の改行は表示上の都合によるものである)。

4.IANA Considerations

4.IANA に関する考慮事項

4.1.OAuth Dynamic Client Registration Metadata Registry

4.1.OAuth Dynamic Client Registration Metadata レジストリ

This specification establishes the "OAuth Dynamic Client Registration Metadata" registry.

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

OAuth registration client metadata names and descriptions are registered with a Specification Required ([RFC5226]) after a two-week review period on the oauth-ext-review@ietf.org mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of names prior to publication, the Designated Experts may approve registration once they are satisfied that such a specification will be published, per [RFC7120].

OAuth 登録クライアントメタデータの名前と説明は、oauth-ext-review@ietf.org メーリングリストでの 2 週間のレビュー期間の後、1 名以上の指名専門家 (Designated Expert) の助言に基づき、Specification Required ([RFC5226]) で登録される。ただし、公開前の名前の割り当てを可能にするため、指名専門家は [RFC7120] に従い、そのような仕様が公開されると確信できた時点で登録を承認してもよい。

Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register OAuth Dynamic Client Registration Metadata name: example").

レビューのためにメーリングリストに送る登録リクエストは、適切な件名 (例: "Request to register OAuth Dynamic Client Registration Metadata name: example") を使用すべきである。

Within the review period, the Designated Experts will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful.

レビュー期間内に、指名専門家は登録リクエストを承認または却下し、その決定をレビューリストと IANA に伝える。却下には説明を含めるべきであり、該当する場合にはリクエストを成功させる方法についての提案も含めるべきである。

IANA must only accept registry updates from the Designated Experts and should direct all requests for registration to the review mailing list.

IANA は指名専門家からのレジストリ更新のみを受け付けなければならず、すべての登録リクエストをレビューメーリングリストに回すべきである。

4.1.1.Registration Template

4.1.1.登録テンプレート

Client Metadata Name: The name requested (e.g., "example"). This name is case sensitive. Names that match other registered names in a case- insensitive manner SHOULD NOT be accepted.

Client Metadata Name: 要求する名前 (例: "example")。この名前は大文字小文字を区別する。大文字小文字を区別しない比較で他の登録済みの名前と一致する名前は受け付けるべきではない (SHOULD NOT)。

Client Metadata Description: Brief description of the metadata value (e.g., "Example description").

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

Change Controller: For Standards Track RFCs, list "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.

Change Controller: Standards Track の RFC の場合は "IESG" と記載する。それ以外の場合は責任を負う当事者の名前を記載する。その他の詳細 (例: 郵送先住所、メールアドレス、ホームページ URI) を含めてもよい。

Specification Document(s): Reference to the document or documents that specify the client metadata definition, preferably including a URI that can be used to retrieve a copy of the documents. An indication of the relevant sections may also be included but is not required.

Specification Document(s): クライアントメタデータの定義を規定する文書への参照。文書のコピーを取得するために使用できる URI を含めることが望ましい。関連する節の指示を含めてもよいが、必須ではない。

4.1.2.Initial Registry Contents

4.1.2.初期レジストリ内容

The initial contents of the "OAuth Dynamic Client Registration Metadata" registry are:

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

o Client Metadata Name: "redirect_uris"

o クライアントメタデータ名: "redirect_uris"

o Client Metadata Description: Array of redirection URIs for use in redirect-based flows

o クライアントメタデータの説明: リダイレクトベースのフローで用いるリダイレクト URI の配列

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): RFC 7591

o 仕様文書: RFC 7591

o Client Metadata Name: "token_endpoint_auth_method"

o クライアントメタデータ名: "token_endpoint_auth_method"

o Client Metadata Description: Requested authentication method for the token endpoint

o クライアントメタデータの説明: トークンエンドポイントに対して要求する認証方式

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): RFC 7591

o 仕様文書: RFC 7591

o Client Metadata Name: "grant_types"

o クライアントメタデータ名: "grant_types"

o Client Metadata Description: Array of OAuth 2.0 grant types that the client may use

o クライアントメタデータの説明: クライアントが使用してよい OAuth 2.0 グラントタイプの配列

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): RFC 7591

o 仕様文書: RFC 7591

o Client Metadata Name: "response_types"

o クライアントメタデータ名: "response_types"

o Client Metadata Description: Array of the OAuth 2.0 response types that the client may use

o クライアントメタデータの説明: クライアントが使用してよい OAuth 2.0 レスポンスタイプの配列

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): RFC 7591

o 仕様文書: RFC 7591

o Client Metadata Name: "client_name"

o クライアントメタデータ名: "client_name"

o Client Metadata Description: Human-readable name of the client to be presented to the user

o クライアントメタデータの説明: ユーザーに提示する、人間が読めるクライアント名

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): RFC 7591

o 仕様文書: RFC 7591

o Client Metadata Name: "client_uri"

o クライアントメタデータ名: "client_uri"

o Client Metadata Description: URL of a web page providing information about the client

o クライアントメタデータの説明: クライアントに関する情報を提供する Web ページの URL

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): RFC 7591

o 仕様文書: RFC 7591

o Client Metadata Name: "logo_uri"

o クライアントメタデータ名: "logo_uri"

o Client Metadata Description: URL that references a logo for the client

o クライアントメタデータの説明: クライアントのロゴを参照する URL

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): RFC 7591

o 仕様文書: RFC 7591

o Client Metadata Name: "scope"

o クライアントメタデータ名: "scope"

o Client Metadata Description: Space-separated list of OAuth 2.0 scope values

o クライアントメタデータの説明: スペース区切りの OAuth 2.0 スコープ値のリスト

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): RFC 7591

o 仕様文書: RFC 7591

o Client Metadata Name: "contacts"

o クライアントメタデータ名: "contacts"

o Client Metadata Description: Array of strings representing ways to contact people responsible for this client, typically email addresses

o クライアントメタデータの説明: このクライアントの責任者への連絡手段を表す文字列の配列。通常はメールアドレス

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): RFC 7591

o 仕様文書: RFC 7591

o Client Metadata Name: "tos_uri"

o クライアントメタデータ名: "tos_uri"

o Client Metadata Description: URL that points to a human-readable terms of service document for the client

o クライアントメタデータの説明: クライアントの人間が読めるサービス利用規約文書を指す URL

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): RFC 7591

o 仕様文書: RFC 7591

o Client Metadata Name: "policy_uri"

o クライアントメタデータ名: "policy_uri"

o Client Metadata Description: URL that points to a human-readable policy document for the client

o クライアントメタデータの説明: クライアントの人間が読めるポリシー文書を指す URL

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): RFC 7591

o 仕様文書: RFC 7591

o Client Metadata Name: "jwks_uri"

o クライアントメタデータ名: "jwks_uri"

o Client Metadata Description: URL referencing the client's JSON Web Key Set [RFC7517] document representing the client's public keys

o クライアントメタデータの説明: クライアントの公開鍵を表す、クライアントの JSON Web Key Set [RFC7517] 文書を参照する URL

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): RFC 7591

o 仕様文書: RFC 7591

o Client Metadata Name: "jwks"

o クライアントメタデータ名: "jwks"

o Client Metadata Description: Client's JSON Web Key Set [RFC7517] document representing the client's public keys

o クライアントメタデータの説明: クライアントの公開鍵を表す、クライアントの JSON Web Key Set [RFC7517] 文書

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): RFC 7591

o 仕様文書: RFC 7591

o Client Metadata Name: "software_id"

o クライアントメタデータ名: "software_id"

o Client Metadata Description: Identifier for the software that comprises a client

o クライアントメタデータの説明: クライアントを構成するソフトウェアの識別子

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): RFC 7591

o 仕様文書: RFC 7591

o Client Metadata Name: "software_version"

o クライアントメタデータ名: "software_version"

o Client Metadata Description: Version identifier for the software that comprises a client

o クライアントメタデータの説明: クライアントを構成するソフトウェアのバージョン識別子

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): RFC 7591

o 仕様文書: RFC 7591

o Client Metadata Name: "client_id"

o クライアントメタデータ名: "client_id"

o Client Metadata Description: Client identifier

o クライアントメタデータの説明: クライアント識別子

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): RFC 7591

o 仕様文書: RFC 7591

o Client Metadata Name: "client_secret"

o クライアントメタデータ名: "client_secret"

o Client Metadata Description: Client secret

o クライアントメタデータの説明: クライアントシークレット

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): RFC 7591

o 仕様文書: RFC 7591

o Client Metadata Name: "client_id_issued_at"

o クライアントメタデータ名: "client_id_issued_at"

o Client Metadata Description: Time at which the client identifier was issued

o クライアントメタデータの説明: クライアント識別子が発行された時刻

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): RFC 7591

o 仕様文書: RFC 7591

o Client Metadata Name: "client_secret_expires_at"

o クライアントメタデータ名: "client_secret_expires_at"

o Client Metadata Description: Time at which the client secret will expire

o クライアントメタデータの説明: クライアントシークレットが失効する時刻

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): RFC 7591

o 仕様文書: RFC 7591

4.2.OAuth Token Endpoint Authentication Methods Registry

4.2.OAuth Token Endpoint Authentication Methods レジストリ

This specification establishes the "OAuth Token Endpoint Authentication Methods" registry.

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

Additional values for use as "token_endpoint_auth_method" values are registered with a Specification Required ([RFC5226]) after a two-week review period on the oauth-ext-review@ietf.org mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of values prior to publication, the Designated Experts may approve registration once they are satisfied that such a specification will be published, per [RFC7120].

"token_endpoint_auth_method" の値として使用する追加の値は、oauth-ext-review@ietf.org メーリングリストでの 2 週間のレビュー期間の後、1 名以上の指名専門家 (Designated Expert) の助言に基づき、Specification Required ([RFC5226]) で登録される。ただし、公開前の値の割り当てを可能にするため、指名専門家は [RFC7120] に従い、そのような仕様が公開されると確信できた時点で登録を承認してもよい。

Registration requests must be sent to the oauth-ext-review@ietf.org mailing list for review and comment, with an appropriate subject (e.g., "Request to register token_endpoint_auth_method value: example").

登録リクエストは、レビューとコメントのために、適切な件名 (例: "Request to register token_endpoint_auth_method value: example") を付けて oauth-ext-review@ietf.org メーリングリストに送らなければならない。

Within the review period, the Designated Experts will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful.

レビュー期間内に、指名専門家は登録リクエストを承認または却下し、その決定をレビューリストと IANA に伝える。却下には説明を含めるべきであり、該当する場合にはリクエストを成功させる方法についての提案も含めるべきである。

IANA must only accept registry updates from the Designated Experts and should direct all requests for registration to the review mailing list.

IANA は指名専門家からのレジストリ更新のみを受け付けなければならず、すべての登録リクエストをレビューメーリングリストに回すべきである。

4.2.1.Registration Template

4.2.1.登録テンプレート

Token Endpoint Authentication Method Name: The name requested (e.g., "example"). This name is case sensitive. Names that match other registered names in a case- insensitive manner SHOULD NOT be accepted.

Token Endpoint Authentication Method Name: 要求する名前 (例: "example")。この名前は大文字小文字を区別する。大文字小文字を区別しない比較で他の登録済みの名前と一致する名前は受け付けるべきではない (SHOULD NOT)。

Change Controller: For Standards Track RFCs, list "IESG". For others, give the name of the responsible party. Other details (e.g., postal address, email address, home page URI) may also be included.

Change Controller: Standards Track の RFC の場合は "IESG" と記載する。それ以外の場合は責任を負う当事者の名前を記載する。その他の詳細 (例: 郵送先住所、メールアドレス、ホームページ URI) を含めてもよい。

Specification Document(s): Reference to the document or documents that specify the token endpoint authentication method, preferably including a URI that can be used to retrieve a copy of the document or documents. An indication of the relevant sections may also be included but is not required.

Specification Document(s): トークンエンドポイント認証方式を規定する文書への参照。文書のコピーを取得するために使用できる URI を含めることが望ましい。関連する節の指示を含めてもよいが、必須ではない。

4.2.2.Initial Registry Contents

4.2.2.初期レジストリ内容

The initial contents of the "OAuth Token Endpoint Authentication Methods" registry are:

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

o Token Endpoint Authentication Method Name: "none"

o トークンエンドポイント認証方式名: "none"

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): RFC 7591

o 仕様文書: RFC 7591

o Token Endpoint Authentication Method Name: "client_secret_post"

o トークンエンドポイント認証方式名: "client_secret_post"

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): RFC 7591

o 仕様文書: RFC 7591

o Token Endpoint Authentication Method Name: "client_secret_basic"

o トークンエンドポイント認証方式名: "client_secret_basic"

o Change Controller: IESG

o 変更管理者: IESG

o Specification Document(s): RFC 7591

o 仕様文書: RFC 7591

5.Security Considerations

5.セキュリティに関する考慮事項

Since requests to the client registration 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 registration 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 のリクエストとレスポンスにおいて) 平文のクレデンシャルの送信を伴うため、認可サーバーは登録エンドポイントへのリクエスト送信時にトランスポート層セキュリティ機構の使用を要求しなければならない (MUST)。サーバーは TLS 1.2 [RFC5246] をサポートしなければならず (MUST)、そのセキュリティ要件を満たす追加のトランスポート層セキュリティ機構をサポートしてもよい (MAY)。TLS を使用する場合、クライアントは RFC 6125 [RFC6125] に従って TLS/SSL サーバー証明書の確認を行わなければならない (MUST)。実装上のセキュリティに関する考慮事項は、Recommendations for Secure Use of TLS and DTLS [BCP195] にある。

For clients that use redirect-based grant types such as "authorization_code" and "implicit", authorization servers MUST require clients to register their redirection URI values. This can help mitigate attacks where rogue actors inject and impersonate a validly registered client and intercept its authorization code or tokens through an invalid redirection URI or open redirector. Additionally, in order to prevent hijacking of the return values of the redirection, registered redirection URI values MUST be one of:

"authorization_code" や "implicit" のようなリダイレクトベースのグラントタイプを使用するクライアントについて、認可サーバーはクライアントにリダイレクト URI 値の登録を要求しなければならない (MUST)。これは、不正な行為者が正当に登録されたクライアントを注入・なりすまし、無効なリダイレクト URI やオープンリダイレクターを通じてその認可コードやトークンを横取りする攻撃の軽減に役立つ。加えて、リダイレクトの戻り値の乗っ取りを防ぐため、登録されるリダイレクト URI 値は以下のいずれかでなければならない (MUST)。

o A remote web site protected by TLS (e.g., https://client.example.com/oauth_redirect)

o TLS で保護されたリモートの Web サイト (例: https://client.example.com/oauth_redirect)

o A web site hosted on the local machine using an HTTP URI (e.g., http://localhost:8080/oauth_redirect)

o HTTP URI を用いてローカルマシン上でホストされる Web サイト (例: http://localhost:8080/oauth_redirect)

o A non-HTTP application-specific URL that is available only to the client application (e.g., exampleapp://oauth_redirect)

o クライアントアプリケーションだけが利用できる、HTTP 以外のアプリケーション固有の URL (例: exampleapp://oauth_redirect)

Public clients MAY register with an authorization server using this protocol, if the authorization server's policy allows them. Public clients use a "none" value for the "token_endpoint_auth_method" metadata field and are generally used with the "implicit" grant type. Often these clients will be short-lived in-browser applications requesting access to a user's resources and access is tied to a user's active session at the authorization server. Since such clients often do not have long-term storage, it is possible that such clients would need to re-register every time the browser application is loaded. To avoid the resulting proliferation of dead client identifiers, an authorization server MAY decide to expire registrations for existing clients meeting certain criteria after a period of time has elapsed. Alternatively, such clients could be registered on the server where the in-browser application's code is served from, and the client's configuration could be pushed to the browser alongside the code.

パブリッククライアントは、認可サーバーのポリシーが許す場合、このプロトコルを使って認可サーバーに登録してもよい (MAY)。パブリッククライアントは "token_endpoint_auth_method" メタデータフィールドに "none" 値を使用し、一般に "implicit" グラントタイプとともに使用される。多くの場合、こうしたクライアントはユーザーのリソースへのアクセスを要求する短命なブラウザ内アプリケーションであり、アクセスは認可サーバーにおけるユーザーのアクティブなセッションに結び付いている。こうしたクライアントは長期的なストレージを持たないことが多いため、ブラウザアプリケーションが読み込まれるたびに再登録が必要になる可能性がある。その結果として生じる死んだクライアント識別子の増殖を避けるため、認可サーバーは一定の基準を満たす既存クライアントの登録を、一定期間の経過後に失効させることを決めてもよい (MAY)。あるいは、こうしたクライアントはブラウザ内アプリケーションのコードを配信するサーバー上で登録し、クライアントの設定をコードとともにブラウザへ送り出すこともできる。

Since different OAuth 2.0 grant types have different security and usage properties, an authorization server MAY require separate registrations for a piece of software to support multiple grant types. For instance, an authorization server might require that all clients using the "authorization_code" grant type make use of a client secret for the "token_endpoint_auth_method" but any clients using the "implicit" grant type not use any authentication at the token endpoint. In such a situation, a server MAY disallow clients from registering for both the "authorization_code" and "implicit" grant types simultaneously. Similarly, the "authorization_code" grant type is used to represent access on behalf of an end-user, but the "client_credentials" grant type represents access on behalf of the client itself. For security reasons, an authorization server could require that different scopes be used for these different use cases, and, as a consequence, it MAY disallow these two grant types from being registered together by the same client. In all of these cases, the authorization server would respond with an "invalid_client_metadata" error response.

OAuth 2.0 のグラントタイプはそれぞれセキュリティ特性と利用特性が異なるため、認可サーバーは、ひとつのソフトウェアが複数のグラントタイプをサポートするために個別の登録を要求してもよい (MAY)。たとえば、認可サーバーは "authorization_code" グラントタイプを用いるすべてのクライアントに "token_endpoint_auth_method" としてクライアントシークレットの使用を要求する一方で、"implicit" グラントタイプを用いるクライアントにはトークンエンドポイントでの認証を一切用いさせない、ということがありうる。そのような状況では、サーバーはクライアントが "authorization_code" と "implicit" の両グラントタイプを同時に登録することを禁止してもよい (MAY)。同様に、"authorization_code" グラントタイプはエンドユーザーに代わるアクセスを表すのに用いられるが、"client_credentials" グラントタイプはクライアント自身に代わるアクセスを表す。セキュリティ上の理由から、認可サーバーはこれらの異なるユースケースに対して異なるスコープを用いることを要求することがあり、その結果として、同一クライアントがこの 2 つのグラントタイプを一緒に登録することを禁止してもよい (MAY)。これらのいずれの場合も、認可サーバーは "invalid_client_metadata" エラーレスポンスで応答することになる。

Unless used as a claim in a software statement, the authorization server MUST treat all client metadata as self-asserted. For instance, a rogue client might use the name and logo of a legitimate client that it is trying to impersonate. Additionally, a rogue client might try to use the software identifier or software version of a legitimate client to attempt to associate itself on the authorization server with instances of the legitimate client. To counteract this, an authorization server MUST take appropriate steps to mitigate this risk by looking at the entire registration request and client configuration. For instance, an authorization server could issue a warning if the domain/site of the logo doesn't match the domain/site of redirection URIs. An authorization server could also refuse registration requests from a known software identifier that is requesting different redirection URIs or a different client URI. An authorization server can also present warning messages to end-users about dynamically registered clients in all cases, especially if such clients have been recently registered or have not been trusted by any users at the authorization server before.

ソフトウェアステートメント内のクレームとして使用される場合を除き、認可サーバーはすべてのクライアントメタデータを自己申告として扱わなければならない (MUST)。たとえば、不正なクライアントは、なりすまそうとしている正当なクライアントの名前やロゴを使用するかもしれない。加えて、不正なクライアントは、正当なクライアントのソフトウェア識別子やソフトウェアバージョンを使用して、認可サーバー上で自身を正当なクライアントのインスタンスと関連付けようとするかもしれない。これに対抗するため、認可サーバーは登録リクエスト全体とクライアント設定を見て、このリスクを軽減する適切な措置を取らなければならない (MUST)。たとえば、認可サーバーは、ロゴのドメイン/サイトがリダイレクト URI のドメイン/サイトと一致しない場合に警告を出すことができる。認可サーバーはまた、既知のソフトウェア識別子からの登録リクエストで異なるリダイレクト URI や異なるクライアント URI を要求するものを拒否することもできる。認可サーバーはさらに、動的に登録されたクライアントについて、特にそのクライアントが最近登録されたものである場合や、その認可サーバーでこれまでどのユーザーからも信頼されていない場合には、あらゆる場合にエンドユーザーに警告メッセージを提示することもできる。

In a situation where the authorization server is supporting open client registration, it must be extremely careful with any URL provided by the client that will be displayed to the user (e.g., "logo_uri", "tos_uri", "client_uri", and "policy_uri"). For instance, a rogue client could specify a registration request with a reference to a drive-by download in the "policy_uri", enticing the user to click on it during the authorization. The authorization server SHOULD check to see if the "logo_uri", "tos_uri", "client_uri", and "policy_uri" have the same host and scheme as the those defined in the array of "redirect_uris" and that all of these URIs resolve to valid web pages. Since these URI values that are intended to be displayed to the user at the authorization page, the authorization server SHOULD protect the user from malicious content hosted at the URLs where possible. For instance, before presenting the URLs to the user at the authorization page, the authorization server could download the content hosted at the URLs, check the content against a malware scanner and blacklist filter, determine whether or not there is mixed secure and non-secure content at the URL, and other possible server-side mitigations. Note that the content in these URLs can change at any time and the authorization server cannot provide complete confidence in the safety of the URLs, but these practices could help. To further mitigate this kind of threat, the authorization server can also warn the user that the URL links have been provided by a third party, should be treated with caution, and are not hosted by the authorization server itself. For instance, instead of providing the links directly in an HTML anchor, the authorization server can direct the user to an interstitial warning page before allowing the user to continue to the target URL.

認可サーバーがオープンなクライアント登録をサポートしている状況では、クライアントが提供しユーザーに表示されることになるあらゆる URL (例: "logo_uri"、"tos_uri"、"client_uri"、"policy_uri") について、きわめて慎重でなければならない。たとえば、悪意あるクライアントが "policy_uri" にドライブバイダウンロードへの参照を含む登録リクエストを指定し、認可の最中にユーザーがそれをクリックするよう誘導することがありうる。認可サーバーは、"logo_uri"、"tos_uri"、"client_uri"、"policy_uri" が "redirect_uris" の配列で定義されたものと同じホストとスキームを持つこと、およびこれらの URI がすべて有効な Web ページに解決されることを確認すべきである (SHOULD)。これらの URI の値は認可ページでユーザーに表示されることを意図したものであるため、認可サーバーは可能な限り、それらの URL でホストされる悪意あるコンテンツからユーザーを保護すべきである (SHOULD)。たとえば、認可ページで URL をユーザーに提示する前に、認可サーバーはその URL でホストされるコンテンツをダウンロードし、マルウェアスキャナーやブラックリストフィルターで検査し、その URL に安全なコンテンツと安全でないコンテンツが混在していないかを判定するなど、サーバー側で可能な緩和策を講じることができる。これらの URL のコンテンツはいつでも変わりうるため、認可サーバーは URL の安全性について完全な確信を与えることはできないが、こうした実践は助けになりうる。この種の脅威をさらに緩和するために、認可サーバーは、URL リンクが第三者によって提供されたものであり、注意して扱うべきであり、認可サーバー自身がホストしているものではないことをユーザーに警告することもできる。たとえば、HTML のアンカーでリンクを直接提供する代わりに、認可サーバーはユーザーが対象の URL へ進むのを許可する前に、中間の警告ページへ誘導することができる。

Clients MAY use both the direct JSON object and the JWT-encoded software statement to present client metadata to the authorization server as part of the registration request. A software statement is cryptographically protected and represents claims made by the issuer of the statement, while the JSON object represents the self-asserted claims made by the client or developer directly. If the software statement is valid and signed by an acceptable authority (such as the software API publisher), the values of client metadata within the software statement MUST take precedence over those metadata values presented in the plain JSON object, which could have been intercepted and modified.

クライアントは、登録リクエストの一部としてクライアントメタデータを認可サーバーに提示するために、直接の JSON オブジェクトと JWT エンコードされたソフトウェアステートメントの両方を使用してもよい (MAY)。ソフトウェアステートメントは暗号的に保護されており、ステートメントの発行者による主張を表すのに対し、JSON オブジェクトはクライアントまたは開発者が直接行う自己申告の主張を表す。ソフトウェアステートメントが有効であり、受け入れ可能な権威 (ソフトウェア API 公開者など) によって署名されている場合、ソフトウェアステートメント内のクライアントメタデータの値は、傍受され改変されていた可能性のある通常の JSON オブジェクトで提示されたメタデータ値より優先されなければならない (MUST)。

Like all metadata values, the software statement is an item that is self-asserted by the client, even though its contents have been digitally signed or MACed by the issuer of the software statement. As such, presentation of the software statement is not sufficient in most cases to fully identify a piece of client software. An initial access token, in contrast, does not necessarily contain information about a particular piece of client software but instead represents authorization to use the registration endpoint. An authorization server MUST consider the full registration request, including the software statement, initial access token, and JSON client metadata values, when deciding whether to honor a given registration request.

すべてのメタデータ値と同様に、ソフトウェアステートメントは、その内容がソフトウェアステートメントの発行者によってデジタル署名または MAC 付与されていても、クライアントが自己申告する項目である。したがって、ソフトウェアステートメントの提示は、ほとんどの場合、クライアントソフトウェアを完全に識別するには十分でない。対照的に、初期アクセストークンは、必ずしも特定のクライアントソフトウェアに関する情報を含むわけではなく、登録エンドポイントを使用する認可を表す。認可サーバーは、ある登録リクエストを受け入れるかどうかを決める際に、ソフトウェアステートメント、初期アクセストークン、JSON クライアントメタデータ値を含む登録リクエスト全体を考慮しなければならない (MUST)。

If an authorization server receives a registration request for a client that is not intended to have multiple instances registered simultaneously and the authorization server can infer a duplication of registration (e.g., it uses the same "software_id" and "software_version" values as another existing client), the server SHOULD treat the new registration as being suspect and reject the registration. It is possible that the new client is trying to impersonate the existing client in order to trick users into authorizing it, or that the original registration is no longer valid. The details of managing this situation are specific to the authorization server deployment and outside the scope of this specification.

認可サーバーが、複数のインスタンスを同時に登録することを意図していないクライアントの登録リクエストを受け取り、登録の重複を推測できる場合 (たとえば、他の既存クライアントと同じ "software_id" と "software_version" の値を使用している場合)、サーバーはその新しい登録を疑わしいものとして扱い、登録を拒否すべきである (SHOULD)。新しいクライアントがユーザーを騙して認可させるために既存のクライアントになりすまそうとしている可能性も、元の登録がもはや有効でない可能性もある。この状況の管理の詳細は認可サーバーのデプロイメントに固有であり、本仕様の範囲外である。

Since a client identifier is a public value that can be used to impersonate a client at the authorization endpoint, an authorization server that decides to issue the same client identifier to multiple instances of a registered client needs to be very particular about the circumstances under which this occurs. For instance, the authorization server can limit a given client identifier to clients using the same redirect-based flow and the same redirection URIs. An authorization server SHOULD NOT issue the same client secret to multiple instances of a registered client, even if they are issued the same client identifier, or else the client secret could be leaked, allowing malicious impostors to impersonate a confidential client.

クライアント識別子は認可エンドポイントでクライアントになりすますのに使える公開の値であるため、登録済みクライアントの複数のインスタンスに同じクライアント識別子を発行すると決めた認可サーバーは、それが起こる状況についてきわめて厳密でなければならない。たとえば、認可サーバーは、あるクライアント識別子を、同じリダイレクトベースのフローと同じリダイレクト URI を用いるクライアントに限定することができる。認可サーバーは、たとえ同じクライアント識別子を発行していても、登録済みクライアントの複数のインスタンスに同じクライアントシークレットを発行すべきではない (SHOULD NOT)。さもなければクライアントシークレットが漏洩し、悪意ある偽装者がコンフィデンシャルクライアントになりすますことを許してしまうおそれがある。

6.Privacy Considerations

6.プライバシーに関する考慮事項

As the protocol described in this specification deals almost exclusively with information about software and not people, there are very few privacy concerns for its use. The notable exception is the "contacts" field as defined in Section 2, which contains contact information for the developers or other parties responsible for the client software. These values are intended to be displayed to end- users and will be available to the administrators of the authorization server. As such, the developer may wish to provide an email address or other contact information expressly dedicated to the purpose of supporting the client instead of using their personal or professional addresses. Alternatively, the developer may wish to provide a collective email address for the client to allow for continuing contact and support of the client software after the developer moves on and someone else takes over that responsibility.

本仕様で記述するプロトコルはほぼもっぱらソフトウェアに関する情報を扱い、人に関する情報は扱わないため、その使用に関するプライバシー上の懸念はごくわずかである。注目すべき例外は 2 節で定義される "contacts" フィールドであり、これはクライアントソフトウェアの開発者やその他の責任者の連絡先情報を含む。これらの値はエンドユーザーに表示されることを意図しており、認可サーバーの管理者も利用できる。したがって、開発者は個人用や業務用のアドレスを使用する代わりに、クライアントのサポート専用のメールアドレスやその他の連絡先情報を提供したいと考えるかもしれない。あるいは、開発者が離れて他の誰かがその責任を引き継いだ後もクライアントソフトウェアへの継続的な連絡とサポートを可能にするため、開発者はクライアント用の共有メールアドレスを提供したいと考えるかもしれない。

In general, the metadata for a client, such as the client name and software identifier, are common across all instances of a piece of client software and therefore pose no privacy issues for end-users. Client identifiers, on the other hand, are often unique to a specific instance of a client. For clients such as web sites that are used by many users, there may not be significant privacy concerns regarding the client identifier, but for clients such as native applications that are installed on a single end-user's device, the client identifier could be uniquely tracked during OAuth 2.0 transactions and its use tied to that single end-user. However, as the client software still needs to be authorized by a resource owner through an OAuth 2.0 authorization grant, this type of tracking can occur whether or not the client identifier is unique by correlating the authenticated resource owner with the requesting client identifier.

一般に、クライアント名やソフトウェア識別子などのクライアントのメタデータは、あるクライアントソフトウェアのすべてのインスタンスに共通であり、したがってエンドユーザーにとってプライバシー上の問題はない。一方、クライアント識別子は特定のクライアントインスタンスに固有であることが多い。多くのユーザーが使用するウェブサイトのようなクライアントでは、クライアント識別子に関して重大なプライバシー上の懸念はないかもしれないが、単一のエンドユーザーのデバイスにインストールされるネイティブアプリケーションのようなクライアントでは、クライアント識別子は OAuth 2.0 のトランザクション中に一意に追跡され、その使用がその単一のエンドユーザーに結び付けられうる。ただし、クライアントソフトウェアは依然として OAuth 2.0 認可グラントを通じてリソースオーナーによる認可を必要とするため、認証されたリソースオーナーと要求元のクライアント識別子を相関させることで、クライアント識別子が一意であるかどうかにかかわらず、この種の追跡は起こりうる。

Note that clients are forbidden by this specification from creating their own client identifier. If the client were able to do so, an individual client instance could be tracked across multiple colluding authorization servers, leading to privacy and security issues. Additionally, client identifiers are generally issued uniquely per registration request, even for the same instance of software. In this way, an application could marginally improve privacy by registering multiple times and appearing to be completely separate applications. However, this technique does incur significant usability cost in the form of requiring multiple authorizations per resource owner and is therefore unlikely to be used in practice.

本仕様では、クライアントが自身のクライアント識別子を作成することを禁じていることに注意すること。クライアントがそれをできるとすると、個々のクライアントインスタンスが複数の共謀する認可サーバーをまたいで追跡される可能性があり、プライバシーとセキュリティの問題につながる。加えて、クライアント識別子は一般に、同じソフトウェアインスタンスに対してであっても、登録リクエストごとに一意に発行される。このため、アプリケーションは複数回登録してまったく別のアプリケーションであるかのように見せることで、プライバシーをわずかに改善できる。しかし、この手法はリソースオーナーごとに複数回の認可を要するという大きなユーザビリティ上のコストを伴うため、実際に用いられることはまずない。

7.References

7.参考資料

7.1.Normative References

7.1.引用規格

7.2.Informative References

7.2.参考文献

A.Use Cases

A.ユースケース

This appendix describes different ways that this specification can be utilized, including describing some of the choices that may need to be made. Some of the choices are independent and can be used in combination, whereas some of the choices are interrelated.

本付録は、本仕様を利用できるさまざまな方法を記述し、必要となりうる選択のいくつかも説明する。選択のいくつかは独立しており組み合わせて使用できるが、いくつかは相互に関連している。

A.1.Open versus Protected Dynamic Client Registration

A.1.オープンな動的クライアント登録と保護された動的クライアント登録

A.1.1.Open Dynamic Client Registration

A.1.1.オープンな動的クライアント登録

Authorization servers that support open registration allow registrations to be made with no initial access token. This allows all client software to register with the authorization server.

オープンな登録をサポートする認可サーバーは、初期アクセストークンなしで登録を行うことを許可する。これにより、すべてのクライアントソフトウェアが認可サーバーに登録できる。

A.1.2.Protected Dynamic Client Registration

A.1.2.保護された動的クライアント登録

Authorization servers that support protected registration require that an initial access token be used when making registration requests. While the method by which a client or developer receives this initial access token and the method by which the authorization server validates this initial access token are out of scope for this specification, a common approach is for the developer to use a manual preregistration portal at the authorization server that issues an initial access token to the developer.

保護された登録をサポートする認可サーバーは、登録リクエストを行う際に初期アクセストークンを使用することを要求する。クライアントまたは開発者がこの初期アクセストークンを受け取る方法、および認可サーバーがこの初期アクセストークンを検証する方法は本仕様の範囲外であるが、一般的なアプローチは、開発者が認可サーバーの手動の事前登録ポータルを使用し、そのポータルが開発者に初期アクセストークンを発行するというものである。

A.2.Registration without or with Software Statements

A.2.ソフトウェアステートメントを使用しない登録と使用する登録

A.2.1.Registration without a Software Statement

A.2.1.ソフトウェアステートメントを使用しない登録

When a software statement is not used in the registration request, the authorization server must be willing to use client metadata values without them being digitally signed or MACed (and thereby attested to) by any authority. (Note that this choice is independent of the Open versus Protected choice, and that an initial access token is another possible form of attestation.)

登録リクエストでソフトウェアステートメントが使用されない場合、認可サーバーは、いかなる権威によってもデジタル署名や MAC 付与 (すなわち証明) がなされていないクライアントメタデータ値を使用する用意がなければならない。(この選択はオープンか保護かの選択とは独立であり、初期アクセストークンも別の形の証明となりうることに注意。)

A.2.2.Registration with a Software Statement

A.2.2.ソフトウェアステートメントを使用する登録

A software statement can be used in a registration request to provide attestation by an authority for a set of client metadata values. This can be useful when the authorization server wants to restrict registration to client software attested to by a set of authorities or when it wants to know that multiple registration requests refer to the same piece of client software.

ソフトウェアステートメントは、登録リクエストにおいて、クライアントメタデータ値の集合に対する権威による証明を提供するために使用できる。これは、認可サーバーが登録を一連の権威によって証明されたクライアントソフトウェアに制限したい場合や、複数の登録リクエストが同じクライアントソフトウェアを指していることを知りたい場合に有用でありうる。

A.3.Registration by the Client or Developer

A.3.クライアントまたは開発者による登録

A.3.1.Registration by the Client

A.3.1.クライアントによる登録

In some use cases, client software will dynamically register itself with an authorization server to obtain a client identifier and other information needed to interact with the authorization server. In this case, no client identifier for the authorization server is packaged with the client software.

一部のユースケースでは、クライアントソフトウェアは、クライアント識別子やその他認可サーバーとやり取りするために必要な情報を得るために、自身を認可サーバーに動的に登録する。この場合、その認可サーバー用のクライアント識別子はクライアントソフトウェアに同梱されない。

A.3.2.Registration by the Developer

A.3.2.開発者による登録

In some cases, the developer (or development software being used by the developer) will preregister the client software with the authorization server or a set of authorization servers. In this case, the client identifier value(s) for the authorization server(s) can be packaged with the client software.

場合によっては、開発者 (または開発者が使用する開発ソフトウェア) が、クライアントソフトウェアを認可サーバーまたは一連の認可サーバーに事前登録する。この場合、その認可サーバー用のクライアント識別子の値をクライアントソフトウェアに同梱できる。

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

A.4.クライアントインスタンスごとのクライアント ID とクライアントソフトウェアごとのクライアント ID

A.4.1.Client ID per Client Software Instance

A.4.1.クライアントソフトウェアインスタンスごとのクライアント ID

In some cases, each deployed instance of a piece of client software will dynamically register and obtain distinct client identifier values. This can be advantageous, for instance, if the code flow is being used, as it also enables each client instance to have its own client secret. This can be useful for native clients, which cannot maintain the secrecy of a client secret value packaged with the software, but which may be able to maintain the secrecy of a per- instance client secret.

場合によっては、あるクライアントソフトウェアのデプロイされた各インスタンスが動的に登録し、それぞれ異なるクライアント識別子の値を取得する。これは、たとえばコードフローを使用している場合に有利でありうる。各クライアントインスタンスが自身のクライアントシークレットを持てるようにもなるからである。これは、ソフトウェアに同梱されたクライアントシークレット値の秘密を保てないが、インスタンスごとのクライアントシークレットの秘密は保てるかもしれないネイティブクライアントにとって有用でありうる。

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

A.4.2.クライアントソフトウェアのすべてのインスタンスで共有されるクライアント ID

In some cases, each deployed instance of a piece of client software will share a common client identifier value. For instance, this is often the case for in-browser clients using the implicit flow, when no client secret is involved. Particular authorization servers might choose, for instance, to maintain a mapping between software statement values and client identifier values, and return the same client identifier value for all registration requests for a particular piece of software. The circumstances under which an authorization server would do so, and the specific software statement characteristics required in this case, are beyond the scope of this specification.

場合によっては、あるクライアントソフトウェアのデプロイされた各インスタンスが共通のクライアント識別子の値を共有する。たとえば、クライアントシークレットが関与しない、インプリシットフローを使用するブラウザ内クライアントではこれがよくある。特定の認可サーバーは、たとえばソフトウェアステートメントの値とクライアント識別子の値のマッピングを維持し、特定のソフトウェアに対するすべての登録リクエストに同じクライアント識別子の値を返すことを選ぶかもしれない。認可サーバーがそうする状況、およびその場合に必要となる具体的なソフトウェアステートメントの特性は、本仕様の範囲を超える。

A.5.Stateful or Stateless Registration

A.5.ステートフルな登録とステートレスな登録

A.5.1.Stateful Client Registration

A.5.1.ステートフルなクライアント登録

In some cases, authorization servers will maintain state about registered clients, typically indexing this state using the client identifier value. This state would typically include the client metadata values associated with the client registration, and possibly other state specific to the authorization server's implementation. When stateful registration is used, operations to support retrieving and/or updating this state may be supported. One possible set of operations upon stateful registrations is described in [RFC7592].

場合によっては、認可サーバーは登録済みクライアントに関する状態を維持し、通常はクライアント識別子の値でこの状態を索引付けする。この状態には通常、クライアント登録に関連付けられたクライアントメタデータ値と、場合によっては認可サーバーの実装に固有のその他の状態が含まれる。ステートフルな登録が使用される場合、この状態の取得や更新をサポートする操作がサポートされることがある。ステートフルな登録に対する操作の集合の一例が [RFC7592] に記述されている。

A.5.2.Stateless Client Registration

A.5.2.ステートレスなクライアント登録

In some cases, authorization servers will be implemented in a manner the enables them to not maintain any local state about registered clients. One means of doing this is to encode all the registration state in the returned client identifier value, and possibly encrypting the state to the authorization server to maintain the confidentiality and integrity of the state.

場合によっては、認可サーバーは登録済みクライアントに関するローカルな状態を一切維持しなくて済むように実装される。これを行う手段の一つは、すべての登録状態を返却するクライアント識別子の値にエンコードし、状態の機密性と完全性を維持するために、場合によっては認可サーバー向けにその状態を暗号化することである。

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, William Kim, Torsten Lodderstedt, Eve Maler, Josh Mandel, Nov Matake, Tony Nadalin, Nat Sakimura, Christian Scholz, and Hannes Tschofenig.

著者らは、本文書への意見を寄せてくれた OAuth ワーキンググループ、User-Managed Access ワーキンググループ、OpenID Connect ワーキンググループの参加者に感謝する。特に、以下の方々は本文書のさまざまなドラフト版のレビューと貢献において重要な役割を果たした: 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、Hannes Tschofenig。