draft-ietf-oauth-client-id-metadata-document-03

一言で言うと: OAuth クライアントが HTTPS の URL を client_id として使い、認可サーバーが事前登録の代わりにその URL からクライアントのメタデータ文書を取得する仕組みである。

概要

OAuth 2.0 のクライアントは、通常、利用する認可サーバーごとに事前登録が必要である。両者に関係がない場合は手動登録が不可能であり、Dynamic Client Registration [RFC7591] も実用的でないことがあり、登録データの管理と掃除の負担が残る（Section 1）。本ドラフトは、クライアントが自分の登録情報を Client Identifier URL で公開し、その URL を client_id とする（Section 3）。認可サーバーはその URL から JSON 文書である Client ID Metadata Document を取得する（Section 4、6）。文書内の client_id は取得元の URL と一致しなければならないため、URL は識別子であると同時にメタデータの置き場所でもある。ドラフトは、この方式が安定した公開 Web サイトを持つクライアントに向き、開発中や短命なクライアントにはあまり向かないとしている（Section 1）。リビジョン 03 は OAuth ワーキンググループの Standards Track 作業項目である。

仕組み

sequenceDiagram
    participant C as クライアント
    participant U as ユーザーエージェント
    participant AS as 認可サーバー
    participant H as Client Identifier URL のホスト
    C->>U: client_id に Client Identifier URL を指定してリダイレクト
    U->>AS: 認可リクエスト
    AS->>H: Client Identifier URL を GET、Accept application/json、リダイレクトは追従しない
    H-->>AS: 200 OK と Client ID Metadata Document
    AS->>AS: client_id の一致、リダイレクト URI、grant と response の型、認証方式を検証
    AS->>U: クライアントのホスト名とメタデータを含む同意画面
    U->>AS: ユーザーが承認
    AS->>U: iss を含む認可レスポンス
    U->>C: クライアントへリダイレクト
    C->>AS: トークンリクエスト、宣言した場合は private_key_jwt
    AS->>H: クライアントアサーションの検証のため jwks_uri を取得

1. クライアントは、Client Identifier URL を client_id としてユーザーを認可サーバーへ送る。URL は https でなければならず、/ 以外のパスを持ち、userinfo、ドットセグメント、フラグメントを含んではならない（Section 3）。
2. 認可サーバーは文書を自動的に取得することが推奨される（SHOULD）。Accept: application/json を送ることが推奨され（SHOULD）、200 OK のみを受け入れなければならず（MUST）、リダイレクトを追従してはならない（MUST NOT）（Section 6）。
3. サーバーは、文書の client_id が URL と単純な文字列比較で一致することを確認する（Section 4）。また、リダイレクト URI が登録済みのものと完全一致することも確認する。ただしポート番号についてはループバックの例外がある（Section 4.2）。
4. サーバーは、文書の grant_types と response_types を自身が対応するものと突き合わせて共通部分を求めなければならず（MUST）、どちらかが空であれば invalid_client で拒否しなければならない（MUST）（Section 6）。
5. サーバーはクライアント認証方式を決定する。token_endpoint_auth_method も token_endpoint_auth_methods_supported も存在しない場合は none と見なさなければならない（Section 5）。
6. サーバーは同意画面に client_id のホスト名を表示することが推奨される。ロゴを表示する場合は、事前取得して自身で配信しなければならない（Section 10.6、10.9）。
7. 認可レスポンスには iss を含めなければならない（Section 7）。
8. クライアントが private_key_jwt を宣言し、サーバーがそれに対応する場合、サーバーはメタデータ文書の鍵を用いて [RFC7523] の Section 2.2 に従うクライアント認証を要求しなければならない（Section 5）。

ユースケース

• 安定した公開 Web サイトを持つクライアントが、事前の関係がない多数の認可サーバーと通信する際に、各所に登録する代わりに 1 つのメタデータ文書を公開する（Section 1）。
• 企業の ID プロバイダーが特定のクライアントを受け入れるため Client Identifier URL を事前登録し、登録時に文書を取得してクライアント認証を設定する（Section 9.2）。
• CIMD のクライアントと自身が登録したクライアントの両方に対応する認可サーバーが、自ら生成する client_id を https:// で始まらないようにする（Section 9.1）。
• 開発者が localhost 上で、redirect_uris を制限する認可サーバーに対して開発し、安定した Client Identifier URL を発行する CIMD Service を使う（Section 10.13、Appendix A）。
• 機密クライアントが jwks_uri を公開して ["private_key_jwt"] を宣言する。あるいは ["none", "private_key_jwt"] を宣言し、対応状況の異なるサーバーに対応する（Section 5.1）。

なぜ今重要か

• きっかけ: -03 が公開された 2026 年 11 月 2 日に、ドラフトの GitHub リポジトリで 11 件の issue がクローズされ、PR #99「Add Client Authentication section」がマージされた。11 月 8 日には issue #131 が立てられた。この issue は、Section 6 の response_types の共通部分の規則により、クライアントクレデンシャルのようなトークンエンドポイントだけを使うグラントのクライアントが拒否されると指摘している。issue はまだオープンで、返信もない。
• 資料上の根拠: リビジョン 03 は 2026 年 11 月 2 日付である。Client Authentication はセキュリティ上の考慮事項から独立した Section 5 に移り、内容も拡充された。あわせて、取得失敗時のエラー処理（Section 6.1）、grant_types と response_types の共通部分の規則（Section 6）、iss パラメーターの必須化（Section 7）、複数の新しいセキュリティ上の考慮事項（Section 10）が加わった。OAuth のメーリングリストでは、-03 の公開通知に対する現時点で唯一の返信（2026 年 11 月 9 日）が、さらなる変更を提案している。
• 期待される影響: URL 形式の client_id を受け入れる認可サーバーの実装者は、認証のデフォルト、取得とキャッシュの挙動、エラー応答、ロゴの扱いを見直す必要がある。クライアントは URL を正規化し、文書を安定させ、リクエストに依存する内容を含めないようにする必要がある。

変更点

• 仕様・文書の変更の要約: 改版履歴と差分から、次の実質的な変更が読み取れる。
  • Client Identifier URL のパスを / にすることは認められなくなり、クライアントは URL を正規化することが推奨され（SHOULD）、サーバーは正規化してはならない（MUST NOT）（Section 3）。
  • ループバックのリダイレクト URI は、[RFC9700] に従いポート番号の完全一致の対象外となった（Section 4.2）。
  • 認証情報の制限が token_endpoint_auth_methods_supported にも及び、jwks と jwks_uri の併用が禁止され、software_statement の内容にも適用される（Section 4.1、4.3）。
  • 新設の Section 4.4 が機能的 URI と情報提供的 URI を区別し、サーバーは client_uri が client_id や redirect_uris と同一オリジンであることを要求してはならない（MUST NOT）。
  • 新設の Section 4.5 が、信頼できない外部入力から文書の内容を導くことを禁止する。
  • Client Authentication がセキュリティ上の考慮事項から Section 5 に移った。token_endpoint_auth_methods_supported が優先され、token_endpoint_auth_method は推奨されず（NOT RECOMMENDED）、RFC7591 の既定値 client_secret_basic を適用してはならない（MUST NOT）。
  • サーバーは文書の grant_types と response_types を自身が対応するものと突き合わせて共通部分を求めなければならず（MUST）、どちらかが空なら invalid_client で拒否しなければならない（MUST）。取得時には Accept: application/json を送ることが推奨される（SHOULD）（Section 6。理由は Section 10.7.1）。
  • 文書取得の失敗は一時的な失敗と恒久的な失敗に分けられ、リフレッシュトークンへの影響と HTTP 503 の選択肢が定められた（Section 6.1）。
  • キャッシュ: -02 では、サーバーはキャッシュ期間の上限と下限を独自に定めてもよい（MAY）とされていた。-03 では、レスポンスの指示にかかわらず実効的な最大期間を適用することが推奨され（SHOULD）、指示がない場合は最小期間を適用することも推奨される（SHOULD）。Expires ヘッダーには従わなくてよく、再取得のレート制限も認められる（MAY）（Section 6.2）。
  • 認可レスポンスには iss を含めなければならない（Section 7）。
  • ロゴの事前取得と自前での配信が MUST になった（Section 10.9）。
  • 新しいセキュリティ上の考慮事項として、発行者識別子との URL 混同（Section 10.1）、クライアントの提示（Section 10.10）、リソース単位で範囲を限定した永続的な認可状態（Section 10.12）が加わった。
  • client_id_expires_at のようなプロパティに関する TBD の注記は削除された。
• 互換性・移行上の懸念: Section 1 から 4.3 までの番号は変わらないが、Section 5 以降はすべて番号が変わった（たとえば Client Information Discovery は Section 5 から Section 6 へ、Client Authentication は Section 8.2 から Section 5 へ移った）。そのため、これらの節を -02 の番号で参照している箇所は古くなる。認証関連のプロパティを両方とも省略した文書は、RFC7591 では client_secret_basic が想定されるのに対し、今後はパブリッククライアントとして扱われる。認可レスポンスで iss を要求していなかったサーバー、logo_uri を直接参照していたサーバーは変更が必要である。/ を有効なパスとして扱っていたサーバーや、client_uri に同一オリジンを要求していたサーバーも変更が必要である。token_endpoint_auth_method は代替として引き続き使えるが推奨されない（Section 5）。

技術分析

• 脅威モデルへの含意:
  • 文書はクライアントが管理するため、内容はすべてクライアントの主張である。クライアントは名前やロゴによって、より著名なクライアントを装うことができる（Section 10.10）。ドラフトは、client_id のホスト名の表示と、任意のドメイン信頼ヒューリスティクスを提案している（Section 10.6、10.8）。
  • 攻撃者が選んだ URL の取得は SSRF の危険を生む。サーバーは、特殊用途アドレス [RFC6890] に解決される URL を取得してはならず（MUST NOT）、開発向けに限ったループバックの例外がある（Section 10.7）。レスポンスの読み取り量は制限することが推奨され（SHOULD）、推奨される上限は 5 キロバイトである（Section 10.11）。
  • ドラフトによれば、サーバー自身の発行者識別子や他の信頼する識別子と同じ URL はトークン混同を招くため、サーバーはそれを拒否することが推奨される（Section 10.1）。
  • 過去の認可判断を永続化または再利用する仕組みは、少なくとも Client Identifier URL とリソースの組で範囲を限定しなければならない（MUST）（Section 10.12）。
  • リクエストに依存する文書は、誰が問い合わせているかを漏らしたり、相手ごとに異なる内容を見せたりし得る。Section 4.5 がこれを禁止し、Section 11.1 が説明している。
• プロトコルフローへの含意:
  • 200 OK のみが成功と見なされ、リダイレクトは追従されない（Section 6）。文書を取得できない、または文書が不正であるためにリクエストが失敗した場合、サーバーはユーザーエージェントをクライアントへリダイレクトしてはならない（MUST NOT）（Section 6.1）。
  • client_id の不一致による恒久的な失敗では、未失効のリフレッシュトークンを直ちに失効させることが推奨される（SHOULD）。一時的な失敗では、信頼の無効化やキャッシュ済みメタデータの破棄を行わないことが推奨される（Section 6.1）。
  • サーバーメタデータでは、client_id_metadata_document_supported という真偽値で対応を示す（Section 8）。
  • クライアント認証は jwks または jwks_uri による公開鍵のみに依存する。JWT に関する指針は [RFC8725] と、rfc7523bis の typ 値 client-authentication+jwt を参照している（Section 5）。
• 相互運用上の懸念:
  • 比較は単純な文字列比較であるため、https://example.com/client と https://example.com:443/client は別のクライアントになる（Section 3）。
  • [OpenID.RPMetadataChoices] を実装しないサーバーも、token_endpoint_auth_methods_supported の存在を認識しなければならない（Section 5）。
  • ["none", "private_key_jwt"] を宣言したクライアントは、private_key_jwt に対応しないサーバーではパブリッククライアントになる。対応するサーバーで none を使うと invalid_client で拒否されることがある（Section 5.1）。
  • キャッシュ期間は一部がサーバーのポリシーに委ねられ、Expires ヘッダーには従わなくてよい（Section 6.2）。そのため、同じ文書でもサーバーによって見え方が異なり得る。

未解決の論点

• Section 5 は、文書が jwks または jwks_uri を含まなければならず、含まない場合は認可リクエストが invalid_client を返すと述べている。この文は JWT ベースの認証方式の段落にあり、改版履歴では private_key_jwt を使う場合の要件とされている。この文は、鍵を持たずに private_key_jwt を宣言した文書の扱いを問う issue #100 を解決するため、PR #99 のレビューコメント（2026 年 10 月 28 日）で「When using private_key_jwt for client auth」という形で提案されたものである。["none", "private_key_jwt"] を宣言し、実際にはパブリッククライアントとして使われる文書も「使う場合」に含まれるかは書かれていない。ただし、Section 5.1 の例にはいずれも jwks_uri が含まれている。
• Section 5 には、認可エンドポイントでの invalid_client を裏付ける文が基となる仕様にない（OAuth 2.1 の issue 266）という編集上の注記がある。そのためエラーの対応付けは未確定である。
• Section 6 は、grant_types または response_types の共通部分が空なら拒否するとしているが、文書がこれらを省略した場合の扱いは述べていない。RFC 7591 の Section 2 では、grant_types を省略すると authorization_code、response_types を省略すると code が既定値になる。Section 5 は token_endpoint_auth_method について RFC 7591 の既定値を明示的に退けているが、Section 6 はこの 2 つについて何も述べていない。issue #131 は RFC 7591 の既定値が適用されると見なしたうえで、その場合この規則が、認可エンドポイントを持たないサーバーでトークンエンドポイントだけを使うクライアントを拒否してしまうことを示している。ワーキンググループはまだ応答していない。
• Section 6.1 は、取得に失敗した場合に認可リクエストを中止することを SHOULD としており、Section 10.6 も取得に失敗して client_id の URL しか表示できない同意画面を想定している。文書を取得できない、または文書が不正であるためにリクエストが失敗した場合、サーバーはユーザーエージェントをクライアントへリダイレクトしてはならず（MUST NOT）、ユーザーにエラーを知らせることが推奨される（SHOULD）。invalid_client、または一時的な失敗であれば HTTP 503 を返さなければならない（MUST）のは、トークンエンドポイントとプッシュ型認可リクエストのエンドポイントだけである。これは、認可エンドポイントではクライアントへリダイレクトせず、トークンエンドポイントと PAR エンドポイントでは定められたエラーを返すよう求めた issue #85 と一致する。したがって、2 つの文は矛盾していない。
• Section 8 は client_id_metadata_document_supported を OPTIONAL としながら、メタデータを公開するサーバーはこれを含めなければならない（MUST）としている。OAuth のメーリングリストへの返信は、この真偽値では「事前登録済みの URL のみ対応」を表せないことも指摘し、client_id_metadata_document_registration_types_supported というリストを提案している（Section 9.2）。
• 同じ返信は、Section 6 に取得前の検証手順を設けることと、クエリ成分を SHOULD NOT から MUST NOT に改めること（Section 3）も提案している。これはまだオープンの issue #112 を受けたものである。いずれも一参加者の提案であり、2026 年 11 月 11 日時点でスレッドにほかの返信はないため、ワーキンググループの支持は確認できない。
• Section 6.2 は、実効的なキャッシュ期間の最大値と最小値をサーバーに委ねており、推奨値を示していない。

実験

• Lab 1: CIMD を取得するテスト用認可サーバーを立て、プロパティを 1 つずつ変えた文書（client_id の不一致、301 リダイレクト、500、5 キロバイト超の本文、パスが / だけの URL）を配信し、Section 4、6、6.1 に照らして各ケースのエラーを記録する。
• Lab 2: 認証関連のプロパティがない文書、token_endpoint_auth_method のみの文書、両方を矛盾した値で持つ文書、["none", "private_key_jwt"] と jwks_uri を持つ文書を公開する。サーバーが推定する認証方式と、none のクライアントにクライアントアサーションを送った場合に invalid_client になるかを確認する（Section 5）。
• Lab 3: logo_uri を持ち、別オリジンの client_uri を持つ文書を追加し、サーバーがロゴを自身のホストから配信して画像を検証し、client_uri に同一オリジンを要求しないことを確認する（Section 4.4、10.9）。

出典

• https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/03/
• https://www.ietf.org/archive/id/draft-ietf-oauth-client-id-metadata-document-03.txt
• https://author-tools.ietf.org/iddiff?url1=draft-ietf-oauth-client-id-metadata-document-02&url2=draft-ietf-oauth-client-id-metadata-document-03
• https://mailarchive.ietf.org/arch/msg/oauth/VGYXFHqx9gft63TPdmVtAUaYkLU/
• https://github.com/oauth-wg/draft-ietf-oauth-client-id-metadata-document/pull/99
• https://github.com/oauth-wg/draft-ietf-oauth-client-id-metadata-document/issues/85
• https://github.com/oauth-wg/draft-ietf-oauth-client-id-metadata-document/issues/100
• https://github.com/oauth-wg/draft-ietf-oauth-client-id-metadata-document/issues/112
• https://github.com/oauth-wg/draft-ietf-oauth-client-id-metadata-document/issues/131
• https://www.rfc-editor.org/rfc/rfc7591#section-2

きっかけ

選定理由はドラフトの GitHub リポジトリの動きである。-03 が公開された 2026 年 11 月 2 日に 11 件の issue がクローズされ、PR #99「Add Client Authentication section」がマージされた。11 月 8 日には、Section 6 の response_types の共通部分の規則に関する issue #131 が立てられた。ドラフトはリビジョン 03（2026 年 11 月 2 日）であり、Datatracker の状態は Active、I-D Exists、WG Document で、oauth-wg トラックにある。

なぜ重要か

本ドラフトは、クライアントが HTTPS の URL を client_id として使い、認可サーバーがそこからメタデータを取得する方式を定める（Section 3、6）。リビジョン 03 では、規範的な規則がいくつも追加または強化された。たとえば、クライアント認証のデフォルト（Section 5）、失敗時の扱い（Section 6.1）、iss パラメーターの必須化（Section 7）、ロゴの自前配信（-02 の SHOULD から MUST へ）（Section 10.9）である。URL 形式の client_id に依存する認可サーバーとクライアントの実装者は直接影響を受け、Section 5 以降の節番号もすべて変わった。

未解決の論点

• Section 5 の jwks または jwks_uri の要件は、private_key_jwt を実際に使う場合だけに適用されるのか。それとも、複数の方式の 1 つとして private_key_jwt を提示するすべての文書に適用されるのか。
• 文書に grant_types や response_types がない場合、サーバーはどう扱うのか（Section 6）。ドラフトは述べておらず、RFC 7591 の既定値（authorization_code と code）が適用されるかも書かれていない。issue #131 はこの点を含めて規則の見直しを求めている。
• OAuth 2.1 の issue 266 に関する編集上の注記を踏まえると、認可エンドポイントでの invalid_client はどう対応付けるべきか（Section 5）。
• メーリングリストで一参加者が出した提案、すなわち取得前の検証手順、クエリ成分の MUST NOT 化、サーバーメタデータの登録タイプ一覧を、ワーキンググループは取り上げるのか（Section 3、6、8、9.2）。

参考文献

ドラフトが挙げる規範的参考文献（Section 13.1）:

• [OpenID.RPMetadataChoices] OpenID Connect Relying Party Metadata Choices 1.0（-03 で追加）
• [RFC2119] および [RFC8174]（BCP 14）
• [RFC3986] URI の汎用構文
• [RFC6749] OAuth 2.0
• [RFC6819] OAuth 2.0 の脅威モデル
• [RFC6890] 特殊用途 IP アドレスレジストリ
• [RFC7523] OAuth 2.0 クライアント認証のための JWT プロファイル（-02 では参考情報、-03 では規範的参考文献）
• [RFC7591] Dynamic Client Registration
• [RFC8259] JSON
• [RFC8414] Authorization Server Metadata
• [RFC8725] JWT のベストカレントプラクティス（-03 で追加）
• [RFC9110] HTTP のセマンティクス（-03 で追加）
• [RFC9207] 認可サーバーの発行者識別（-03 で追加）
• [RFC9700] OAuth 2.0 セキュリティのベストカレントプラクティス

参考情報の参考文献（Section 13.2）:

• [I-D.draft-ietf-oauth-attestation-based-client-auth]（-12。-02 では -09）
• [I-D.draft-ietf-oauth-rfc7523bis]（新規、-11）
• [I-D.draft-ietf-oauth-spiffe-client-auth]（-03。-02 では -02）
• [IndieAuth]
• [OpenID] Connect Core 1.0
• [OpenID.Federation]（1.1。-02 では 1.0）
• [OWASP.SSRF]（新規）
• [RFC9111] HTTP キャッシュ
• [Solid-OIDC]

主な変更

• Section 3: パス / は禁止され、クライアントは [RFC3986] の Section 6.2.2、6.2.3 に従って URL を正規化することが推奨され（SHOULD）、サーバーは正規化してはならない（MUST NOT）。
• Section 4.1: 制限が token_endpoint_auth_methods_supported と software_statement の内容にも及び、jwks と jwks_uri を同時に含めてはならない（MUST NOT）。
• Section 4.4、4.5: 機能的 URI と情報提供的 URI の区別、および信頼できない外部入力から文書の内容を導くことの禁止。
• Section 5（セキュリティ上の考慮事項の -02 Section 8.2 から移設し、拡充）: 認証は既定で none となり、token_endpoint_auth_method は推奨されず、RFC7591 の既定値は適用されず、宣言された方式を 1 つも扱えないサーバーは invalid_client で拒否する。
• Section 6: grant_types と response_types の共通部分を求め、空なら invalid_client とする。あわせて Accept ヘッダーの推奨がある。
• Section 6.1: 一時的な失敗と恒久的な失敗の区分、ユーザーエージェントをクライアントへ戻さないこと、トークンエンドポイントと PAR エンドポイントでの invalid_client または HTTP 503。
• Section 6.2: -02 ではサーバーがキャッシュ期間の上限と下限を独自に定めてもよい（MAY）とされていたが、実効的な最大期間を適用すること、指示がない場合に最小期間を適用することがそれぞれ推奨（SHOULD）になった。Expires には従わなくてよく、キャッシュの対象は jwks_uri や logo_uri から取得したデータにも及び、レート制限も認められる（MAY）。エラーや不正な文書をキャッシュしないことは変わらない。
• Section 7（新設）: 認可レスポンスには iss を含めなければならない（MUST）。
• Section 10: URL 混同（10.1）、Accept ヘッダー（10.7.1）、クライアントの提示（10.10）、リソース単位で範囲を限定した永続状態（10.12）の各小節を追加。ロゴの事前取得と自前配信は SHOULD から MUST になり、画像の検証も MUST になった（10.9）。Section 10.7 には OWASP の SSRF チートシートに従うことの推奨（SHOULD）が加わった。
• Section 11.1: 問い合わせ元ごとに文書を変えることへの警告を追加。
• Section 12.1: 仕様文書の参照先が -03 の Section 8 になった。

影響分析

• 上流: OAuth 2.0 [RFC6749]、Dynamic Client Registration のメタデータ [RFC7591]、Authorization Server Metadata [RFC8414]、セキュリティのベストカレントプラクティス [RFC9700]、発行者識別 [RFC9207]、および token_endpoint_auth_methods_supported のための OpenID メタデータ選択仕様に依存する。JWT の typ に関する推奨は作業中のドラフト（rfc7523bis）を指しており、確定したものではない。
• 下流: URL 形式の client_id を受け入れる認可サーバーの実装、クライアントライブラリ、メタデータ文書の公開者、CIMD Service の運営者。今後の仕様が文書の内容に追加の制限を課す可能性がある（Section 4）。IANA への依頼は、認可サーバーメタデータ名 client_id_metadata_document_supported のみである（Section 12.1）。
• 互換性: Section 5 以降の節番号が -02 と異なる。既定の認証方式、ロゴ、iss の要件により、観測できる挙動が変わる。token_endpoint_auth_method は代替として引き続き読み取れる。本ドラフトは作業中であり、再び変わる可能性がある。

• Client Identifier URL が https を使い、userinfo、ドットセグメント、フラグメントを含まず、/ 以外のパスを持つ（Section 3）。
• クエリ成分を持つ URL が一貫して扱われる。ドラフトは SHOULD NOT としており、メーリングリストでの一参加者の提案では MUST NOT になる（Section 3）。
• サーバーは URL を単純な文字列比較で比べ、正規化しない。https://example.com/client と https://example.com:443/client は別のクライアントである（Section 3）。
• 文書の client_id が、Client Identifier URL と実際に取得した URL の両方に一致する（Section 4）。
• サーバー自身の発行者識別子、または信頼関係にある認可サーバーやリソースサーバーの識別子と同じ client_id は拒否される（SHOULD）（Section 10.1）。
• 取得時に Accept: application/json を送り、200 OK のみを受け入れ、URL 短縮サービスを含むあらゆるリダイレクトをエラーとして扱い、追従しない（Section 6）。
• 読み取り上限（推奨は 5 キロバイト）を超えるレスポンス本文はエラーとして扱われる（Section 10.11）。
• 特殊用途アドレス [RFC6890] に解決される URL は、本体の文書、jwks_uri、logo_uri のいずれでも拒否される。ループバックの例外は本番環境では無効である（Section 10.7）。
• 文書に client_secret、client_secret_expires_at、いずれの認証プロパティにも共有秘密を使う認証方式、秘密鍵の素材が含まれず、jwks と jwks_uri が両方存在することもない。software_statement 経由の内容にも同じ規則が適用される（Section 4.1、4.3）。
• token_endpoint_auth_method も token_endpoint_auth_methods_supported もない文書は、client_secret_basic ではなく none として扱われる。none のクライアントにクライアントアサーションが送られた場合は invalid_client となる（Section 5）。
• 両方のプロパティを持つ文書では、token_endpoint_auth_method が token_endpoint_auth_methods_supported に含まれる（Section 5）。
• [OpenID.RPMetadataChoices] を実装しないサーバーも、token_endpoint_auth_methods_supported を認識する（Section 5）。
• サーバーは一覧から対応する方式を選び、対応しない方式があってもエラーにせず、1 つも対応しない場合は invalid_client を返す（Section 5）。
• jwks も jwks_uri もない private_key_jwt の文書は invalid_client で拒否される。また、["none", "private_key_jwt"] の場合にこの要件がどう解釈されるかを試験する（Section 5）。
• クライアントアサーションは typ ヘッダーを持ち、その推奨値は client-authentication+jwt である（SHOULD）。サーバーはそれを検証し（SHOULD）、アルゴリズムの許可リストを実装する（MUST）（Section 5）。
• grant_types または response_types の共通部分が空の場合は invalid_client となる。ドラフトは RFC 7591 の既定値が適用されるかを述べていないため、これらのフィールドを省略した文書の扱いをサーバー側で文書化している（Section 6）。
• 一時的な取得失敗では、キャッシュ済みメタデータとリフレッシュトークンを無効にしない（SHOULD NOT）。トークンエンドポイントと PAR エンドポイントでは、失敗時に invalid_client を、一時的な失敗なら HTTP 503 を返す（MUST）。恒久的な失敗のうち client_id の不一致によるものでは、リフレッシュトークンを直ちに失効させる（SHOULD）。いずれの場合もユーザーエージェントをクライアントへリダイレクトしない（MUST NOT）（Section 6.1）。
• エラー応答と不正な文書はキャッシュされず、ヘッダーの内容にかかわらず実効的なキャッシュ期間の最大値が適用される（Section 6.2）。
• 認可レスポンスに iss が含まれ、クライアントがそれを検証する（Section 7）。
• サーバーメタデータが client_id_metadata_document_supported を公開し、クライアントはユーザーをリダイレクトする前にそれを確認する（Section 8）。
• 事前登録のクライアントと CIMD のクライアントが内部で区別でき、生成する client_id が https:// で始まらない（Section 9.1）。
• 文書の内容を、URL のパスやクエリ、リクエストヘッダー、Cookie、問い合わせ元のユーザーやサーバーといった信頼できない入力から導いていない（MUST NOT）。サーバーは取得時に Cookie、ユーザー固有の情報、不要なヘッダーを送らないようにしている（SHOULD）（Section 4.5、11.1）。
• client_id と異なるオリジンの client_uri が受け入れられ、redirect_uris の制限はサーバーのポリシーに従う（Section 4.4、10.2）。
• logo_uri の内容は事前取得され、画像として検証され、直接リンクされずにサーバー自身のホストから配信される（Section 10.9）。
• 同意画面には client_id のホスト名が表示され、client_name とロゴはポリシーが許す場合にのみ表示される（Section 10.6、10.10）。
• 永続化または再利用される認可判断は、少なくとも Client Identifier URL とリソースの組で範囲が限定されている（Section 10.12）。
• ポート番号が変わるループバックのリダイレクト URI は受け入れられ、それ以外のリダイレクト URI は完全一致が必要である（Section 4.2）。

環境

• ランタイム:
• ツール:
• バージョン:

手順

結果

失敗パターン

次にやること