spec(oauth): decide whether to retire dynamic client registration #254

目的

RFC 7591 Dynamic Client Registration を撤去し、Client ID Metadata Documents へ移行するかを決める。

経緯 — 相乗り前提が実装で否定された

#249（2026-07-28 ステートレス移行）の本文には「OAuth 周辺を触る本移行に相乗りさせる」と書かれていた。本文を書いたのは親であり、書いた時点の想定が実装で否定された。

PR #253 の変更ファイルに worker/src/oauth.ts は含まれていない。本移行がしたのはブリッジ側の認証を transport の authProvider へ配線し直すことだけで、認可サーバ実装には触れていない。したがって「どうせ触るなら一緒に」という相乗りの前提が成立しなかった。

加えて、同一リリースに載せると利用者に強いる 1 回の再起動に破壊面が 2 つ乗る。#249 は既にプロトコル破断を 1 つ持ち込んでいる。

前提

• 本 repo は worker/src/oauth.ts:160 に RFC 7591 を手書き実装し、worker/src/oauth.ts:147 でメタデータに registration_endpoint を広告している
• MCP 仕様 2026-07-28 で DCR は Deprecated。移行先は Client ID Metadata Documents
• 最短撤去 = 2027-07-28 以降の最初のリビジョン。ただし「最短撤去」は撤去が可能になる時点であり、実際の撤去は Core Maintainer 判断でそれ以降にずれうる
• 変更履歴には「Client ID Metadata Documents に対応しない認可サーバとの後方互換のため、DCR は引き続き利用可能」と明記されている

判断の軸

急ぐ理由は無い。ただし本 repo は認可サーバ側に立っているため、クライアント側が CIMD 前提へ移っていくと、新しいクライアントが登録できなくなる方向の圧力がかかる。その圧力が実際に観測されるまでは着手しない、という判断が妥当と見る。

発火条件の候補:

• MCP クライアント実装が CIMD を要求し始め、DCR のみのサーバへ接続できない事例が出る
• 仕様側が撤去を実際に予告する（最短撤去日の到来ではなく、Core Maintainer の撤去判断）
• OAuth 周辺を別の理由で触ることになり、今度こそ相乗りの前提が成立する

制約

• 単独で着手する価値は現時点で低い。相乗り可能な変更が来るまで待つのが安い
• 姉妹リポジトリ Liplus-Project/github-rag-mcp も同じ状態（@cloudflare/workers-oauth-provider 経由で /oauth/register を公開）。方式を揃えるか個別にするかも判断対象

対象ファイル

• worker/src/oauth.ts — RFC 7591 実装と registration_endpoint の広告
• docs/ — 要求仕様（PR Serve MCP protocol revision 2026-07-28 only, single lane [worker, bridges, deps, docs, tests] #253 で F7 節に判断が記録済み）

関連

• spec: MCP 2026-07-28 migration plan - single-lane flip, no dual-lane fallback #249 / Serve MCP protocol revision 2026-07-28 only, single lane [worker, bridges, deps, docs, tests] #253 — 相乗り前提が否定された経緯