SEP-646の内容や、レビューコメント確認スクラップ

動機と内容について
動機については以下の通りです。
This extension is designed to facilitate secure and interoperable authorization of MCP clients within corporate environments, leveraging existing enterprise identity infrastructure.
ざっくりまとめると、MPCクライアントの認可を既存の会社で使用するIDインフラで管理できるようにしようです。
具体的には以下の内容で管理します。
For end users, this removes the need to manually connect and authorize the MCP Client to individual services within the organization.
For enterprise admins, this enables visibility and control over which MCP Servers are able to be used within the organization.
ユーザーの手動接続や、管理者が使用しているMCPサーバーの可視化や管理を行うことを考えたようです。

プルリクエスト起票者のブログが提案のバックグラウンドになっているとのことです。
上記ブログをざっくりまとめていきます。
Single Sign-On
- 会社のアプリはSSOできることが望まれる。MCPを使っているAIツールもその一つであると考えます。
Connecting to External Apps
- AIツールでSSOした後、AIツール内でMCPと接続するときもSSOが必要になります。
- 例えば、ClaudeでSSOした後、Claude内でGoogle Calenderなどと接続する場合、再度SSOをする必要があります。
- これは以下の二つの問題を抱えています。
- ユーザー体験が悪い
- IT管理者が誰がどのツールと接続しているかがわからない
- ユーザービリティと管理者が把握できるようにするためにも、会社が使用しているIdPに管理を任せるべきです。
- そのための方法として、
Identity and Authorization Chaining Across Domains
を利用することが挙げられます。

A Brief Intro to Cross-App Access
以下の画像郡が全てです。
ざっくりやっていることとして、以下の通りです。
- ClaudeがIdPと認証のやり取りを行い、認証したことを示すID トークンを取得する
- IDトークンをIdPに投げて、外部接続用のトークンをIdPが発行してClaudeに返す
- ClaudeはMCPサーバーに外部接続用のトークンを投げて、MCPサーバーの検証がとおれば接続する
これによって、MCPサーバーの接続の権限をIdPが管理でき、接続事態もユーザーの操作が不要になります。
そのため、ツールの管理とユーティリティの向上を図れるとのことです。
Cross-App Access Protocol
「A Brief Intro to Cross-App Access」の詳細についてでした。
Identity and Authorization Chaining Across Domainsを基本としているようです。
Identity and Authorization Chaining Across DomainsはToken Exchange (RFC 8693)と JWT Profile for Authorization Grants (RFC 7523)を組み合わせたものになります。
ただ、それぞれの仕様は柔軟性があるので、細部は今回のケースに合わせて、埋めているとのことです。
リクエスト例は凄くざっくりまとめると、以下の流れだと理解しました。
- OpenID ConnectでIDトークンを取得する
- Token ExchangeでIDトークンをMCPの認可サーバー用に変換したものを取得する
- 上記トークンをMCPの認可サーバーに渡して、JWT Profile for Authorization Grants で認可する
具体的なパラメータは記事に記載されているので、参照お願いします。