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

登録されたクライアントは、有効なリダイレクト URI のリストや表示名など、認可サーバーでのクライアント識別子に関連付けられた一連のメタデータ値を持ちます。これらのクライアントメタデータ値は、次の 2 つの方法で使用されます。

登録リクエストへの入力値として、および
登録レスポンスの出力値として。

この仕様では、以下のクライアントメタデータフィールドが定義されています。すべてのクライアントメタデータフィールドの実装と使用は、特に明記されていない限り任意です。すべてのデータメンバータイプ（文字列、配列、数値）は、JSON [RFC7159] 表現の観点から定義されています。

redirect_uris 認可コードフローやインプリシットフローなどのリダイレクトベースのフローで使用するためのリダイレクト URI 文字列の配列。OAuth 2.0 [RFC6749] のセクション 2 で要求されているように、リダイレクトを伴うフローを使用するクライアントは、リダイレクト URI 値を登録する必要があります。リダイレクトベースのフローの動的登録をサポートする認可サーバーは、このメタデータ値のサポートを実装する必要があります。

token_endpoint_auth_method トークンエンドポイントに要求される認証方法の文字列表現。この仕様で定義されている値は次のとおりです。

"none": クライアントは OAuth 2.0 セクション 2.1 で定義されているパブリッククライアントであり、クライアントシークレットを持ちません。
"client_secret_post": クライアントは、OAuth 2.0 セクション 2.3.1 で定義されている HTTP POST パラメータを使用します。
"client_secret_basic": クライアントは、OAuth 2.0 セクション 2.3.1 で定義されている HTTP Basic を使用します。

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

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

"authorization_code": OAuth 2.0 セクション 4.1 で定義されている認可コードグラントタイプ。
"implicit": OAuth 2.0 セクション 4.2 で定義されているインプリシットグラントタイプ。
"password": OAuth 2.0 セクション 4.3 で定義されているリソース所有者パスワードクレデンシャルグラントタイプ。
"client_credentials": OAuth 2.0 セクション 4.4 で定義されているクライアントクレデンシャルグラントタイプ。
"refresh_token": OAuth 2.0 セクション 6 で定義されているリフレッシュトークングラントタイプ。
"urn:ietf:params:oauth:grant-type:jwt-bearer": OAuth JWT Bearer Token Profiles [RFC7523] で定義されている JWT ベアラートークングラントタイプ。
"urn:ietf:params:oauth:grant-type:saml2-bearer": OAuth SAML 2 Bearer Token Profiles [RFC7522] で定義されている SAML 2.0 ベアラーアサーショングラント。

トークンエンドポイントがグラントタイプで使用される場合、このパラメータの値は、グラントタイプ定義で定義されたトークンエンドポイントに渡される "grant_type" パラメータの値と同じでなければなりません。認可サーバーは、OAuth 2.0 セクション 4.5 で説明されているグラントタイプ拡張プロセスで定義されている他の値を許可する場合があります。省略された場合、デフォルトの動作として、クライアントは "authorization_code" グラントタイプのみを使用します。

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

"code": OAuth 2.0 セクション 4.1 で定義されている認可コードレスポンスタイプ。
"token": OAuth 2.0 セクション 4.2 で定義されているインプリシットレスポンスタイプ。

認可エンドポイントがグラントタイプで使用される場合、このパラメータの値は、グラントタイプ定義で定義された認可エンドポイントに渡される "response_type" パラメータの値と同じでなければなりません。認可サーバーは、OAuth 2.0 セクション 4.5 で説明されているグラントタイプ拡張プロセスで定義されている他の値を許可する場合があります。省略された場合、デフォルトでは、クライアントは "code" レスポンスタイプのみを使用します。

client_name 認可中にエンドユーザーに提示されるクライアントの人間が読める文字列名。省略された場合、認可サーバーは代わりに生の "client_id" 値をエンドユーザーに表示する場合があります。クライアントは常にこのフィールドを送信することをお勧めします。このフィールドの値は、セクション 2.2 で説明されているように国際化される場合があります。

client_uri クライアントに関する情報を提供する Web ページの URL 文字列。存在する場合、サーバーはこの URL をクリック可能な形式でエンドユーザーに表示する必要があります。クライアントは常にこのフィールドを送信することをお勧めします。このフィールドの値は、有効な Web ページを指している必要があります。このフィールドの値は、セクション 2.2 で説明されているように国際化される場合があります。

logo_uri クライアントのロゴを参照する URL 文字列。存在する場合、サーバーは承認中にこの画像をエンドユーザーに表示する必要があります。このフィールドの値は、有効な画像ファイルを指している必要があります。このフィールドの値は、セクション 2.2 で説明されているように国際化される場合があります。

scope クライアントがアクセストークンを要求するときに使用できるスコープ値のスペース区切りリスト（OAuth 2.0 [RFC6749] のセクション 3.3 で説明）を含む文字列。このリストの値の意味はサービス固有です。省略された場合、認可サーバーはデフォルトのスコープセットでクライアントを登録する場合があります。

contacts このクライアントの責任者に連絡する方法を表す文字列の配列（通常は電子メールアドレス）。認可サーバーは、これらの連絡先アドレスを、クライアントのサポート要求のためにエンドユーザーに利用可能にする場合があります。プライバシーに関する考慮事項については、セクション 6 を参照してください。

tos_uri クライアントを認可するときにエンドユーザーが同意する、エンドユーザーとクライアント間の契約関係を説明する、クライアントの人間が読める利用規約ドキュメントを指す URL 文字列。提供されている場合、認可サーバーはこの URL をエンドユーザーに表示する必要があります。このフィールドの値は、有効な Web ページを指している必要があります。このフィールドの値は、セクション 2.2 で説明されているように国際化される場合があります。

policy_uri デプロイ組織が個人データを収集、使用、保持、および開示する方法を説明する、人間が読めるプライバシーポリードキュメントを指す URL 文字列。提供されている場合、認可サーバーはこの URL をエンドユーザーに表示する必要があります。このフィールドの値は、有効な Web ページを指している必要があります。このフィールドの値は、セクション 2.2 で説明されているように国際化される場合があります。

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

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

software_id 動的に登録されるクライアントソフトウェアを識別するために登録エンドポイントで使用される、クライアント開発者またはソフトウェアパブリッシャーによって割り当てられた一意の識別子文字列（UUID など）。認可サーバーによって発行され、インスタンス間で異なる必要がある "client_id" とは異なり、"software_id" はクライアントソフトウェアのすべてのインスタンスで同じままである必要があります。"software_id" は、同じソフトウェアの複数の更新またはバージョンにわたって同じままである必要があります。このフィールドの値は人間が読むことを意図しておらず、通常、クライアントと認可サーバーには不透明です。

software_version "software_id" で識別されるクライアントソフトウェアのバージョン識別子文字列。"software_version" の値は、同じ "software_id" で識別されるクライアントソフトウェアの更新時に変更する必要があります。このフィールドの値は、文字列の等価一致を使用して比較することを目的としており、この仕様では他の比較セマンティクスは定義されていません。このフィールドの値はこの仕様の範囲外ですが、人間が読むことを意図しておらず、通常、クライアントと認可サーバーには不透明です。この値の変更をトリガーするクライアントソフトウェアの更新を構成するものの定義は、ソフトウェア自体に固有であり、この仕様の範囲外です。

この仕様の拡張およびプロファイルは、このドキュメントのセクション 4 にある IANA の考慮事項に従って登録されたメタデータ名と説明を使用して、このリストを拡張できます。認可サーバーは、理解できないクライアントから送信されたクライアントメタデータを無視する必要があります（たとえば、処理中にクライアントの登録レコードから不明なメタデータを黙って削除するなど）。認可サーバーは、リクエストされた値をセクション 3.2.1 で説明されている適切なデフォルト値に置き換えるか、セクション 3.2.2 で説明されているエラーレスポンスを返すことにより、リクエストされたクライアントメタデータ値を拒否する場合があります。

クライアントメタデータ値は、セクション 3.1 で説明されているように登録リクエストの本文で直接通信することも、セクション 2.3 で説明されているようにソフトウェアステートメントにクレームとして含めることもできます。両方の混合も可能です。同じクライアントメタデータ名が両方の場所に存在し、ソフトウェアステートメントが認可サーバーによって信頼されている場合、ソフトウェアステートメント内のクレームの値が優先されなければなりません。

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

上記の "grant_types" 値と "response_types" 値は、OAuth プロトコルの異なるエンドポイントに渡される引数を参照するため、部分的に直交しています。ただし、クライアントが利用できる "grant_types" はクライアントが使用できる "response_types" に影響し、その逆も同様であるという点で関連しています。たとえば、"authorization_code" を含む "grant_types" 値は、"code" を含む "response_types" 値を意味します。これは、両方の値が OAuth 2.0 認可コードグラントの一部として定義されているためです。そのため、これらのフィールドをサポートするサーバーは、たとえば、矛盾した登録リクエストに対して "invalid_client_metadata" エラーレスポンスを返すことによって、クライアントが矛盾した状態に登録できないようにするための措置を講じる必要があります。

2 つのフィールド間の相関関係を以下の表に示します。

`grant_types` 値に含まれるもの:	`response_types` 値に含まれるもの:
`authorization_code`	`code`
`implicit`	`token`
`password`	(なし)
`client_credentials`	(なし)
`refresh_token`	(なし)
`urn:ietf:params:oauth:grant-type:jwt-bearer`	(なし)
`urn:ietf:params:oauth:grant-type:saml2-bearer`	(なし)

"grant_types" パラメータまたは "response_types" パラメータのいずれかに新しい値を導入するこのドキュメントの拡張およびプロファイルは、これら 2 つのパラメータタイプ間のすべての対応関係を文書化する必要があります。

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

人間が読めるクライアントメタデータ値、および人間が読める値を参照するクライアントメタデータ値は、複数の言語およびスクリプトで表現される場合があります。たとえば、"client_name"、"tos_uri"、"policy_uri"、"logo_uri"、"client_uri" などのフィールドの値には、さまざまな場所での使用を容易にするために、一部のクライアント登録で複数のロケール固有の値が含まれる場合があります。

言語とスクリプトを指定するには、BCP 47 [RFC5646] 言語タグをクライアントメタデータメンバー名に追加し、"#" 文字で区切ります。JSON [RFC7159] メンバー名は大文字と小文字が区別されるため、クレーム名で使用される言語タグ値は、「IANA Language Subtag」レジストリ [IANA.Language] に登録されている文字の大文字と小文字を使用して綴ることをお勧めします。特に、通常、言語名は小文字、地域名は大文字、言語は混合文字で綴られます。ただし、BCP 47 言語タグ値は大文字と小文字を区別しないため、実装は提供された言語タグ値を大文字と小文字を区別しない方法で解釈する必要があります。BCP 47 の推奨事項に従い、メタデータメンバー名で使用される言語タグ値は、必要な場合にのみ具体的にする必要があります。たとえば、多くのコンテキストでは、"fr-CA" や "fr-FR" ではなく "fr" を使用するだけで十分な場合があります。

たとえば、クライアントは、同じ登録リクエスト内で、英語の名前を "client_name#en": "My Client" として、日本語の名前を "client_name#ja-Jpan-JP": "\u30AF\u30E9\u30A4\u30A2\u30F3\u30C8\u540D" として表すことができます。認可サーバーは、システム構成、ユーザー設定、またはその他の要因に基づいて表示する名前を選択し、認可ステップ中にこれらの名前の一部またはすべてをリソース所有者に表示する場合があります。

言語タグなしで人間が読めるフィールドが送信された場合、それを使用する当事者は、文字列値の言語、文字セット、またはスクリプトについていかなる仮定も行ってはならず、文字列値はユーザーインターフェイスに表示される場所であればどこでもそのまま使用する必要があります。相互運用性を促進するために、クライアントとサーバーは、言語固有のフィールドに加えて言語タグなしで人間が読めるフィールドを使用することをお勧めします。また、言語タグなしで送信される人間が読めるフィールドには、さまざまなシステムでの表示に適した値を含めることをお勧めします。

実装者への注意：多くの JSON ライブラリでは、JSON オブジェクトのメンバーを、ライブラリのネイティブプログラミング環境のオブジェクト構成体のメンバーとして参照できるようにしています。ただし、"#" 文字は JSON オブジェクトのメンバー名内では有効な文字ですが、多くのプログラミング環境ではオブジェクトメンバー名で使用するには無効な文字です。したがって、実装では、これらのクレームにアクセスするために代替のアクセス形式を使用する必要があります。たとえば、JavaScript では、JSON を "var j = JSON.parse(json);" のように解析する場合、回避策として、メンバー "client_name#en-us" には JavaScript 構文 "j["client_name#en-us"]" を使用してアクセスできます。

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

ソフトウェアステートメントは、クライアントソフトウェアに関するメタデータ値をバンドルとしてアサートする JSON Web Token (JWT) [RFC7519] です。ソフトウェアステートメントで使用できるクレームのセットは、セクション 2 で定義されています。クライアント登録リクエストの一部として認可サーバーに提示される場合、ソフトウェアステートメントは JSON Web Signature (JWS) [RFC7515] を使用してデジタル署名または MAC 処理されている必要があり、ソフトウェアステートメント内のクレームを証明する当事者を示す "iss" (発行者) クレームを含める必要があります。ソフトウェアステートメントには "RS256" 署名アルゴリズムを使用してデジタル署名することをお勧めしますが、特定のアプリケーションでは異なるアルゴリズムの使用を指定してもかまいません。認可サーバーが同じソフトウェアステートメントを使用してソフトウェアの異なるインスタンスを相関させることができるように、ソフトウェアステートメントに "software_id" クレームを含めることをお勧めします。

たとえば、ソフトウェアステートメントには次のクレームを含めることができます。

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

以下の非規範的な例の JWT にはこれらのクレームが含まれており、"RS256" を使用して非対称署名されています (表示のみを目的として改行されています)。

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

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

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

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

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

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

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

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

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

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