Authorization 兴趣组章程

社区译文；来源： MCP 80041ab0

小组类型

兴趣组

使命陈述

Authorization 兴趣组是 MCP 授权工作唯一经章程确立的场所。它汇集 MCP 实现者、身份提供商厂商和安全从业者，以发现现实世界中的授权问题，判断这些问题是否值得解决以及是否属于 MCP，并为作者提供一个可靠场所，用于展示 SEP、ext-auth 草案、原型和部署结果，以获得跨主题反馈。章程界定范围；讨论和粗略共识在一个频道和一次定期会议中形成，工作产出是草案和演示，而不是新的常设小组。

范围

范围内

• 部署经验报告：实现者如何将当前授权规范（OAuth 2.1、RFC 9728 Protected Resource Metadata、RFC 7591 Dynamic Client Registration、Client ID Metadata Documents）与真实授权服务器集成，以及规范在哪些方面仍有不足
• 扩展互操作性报告：独立实现对 ext-auth 扩展进行端到端配对的结果（例如 IdP、客户端和授权服务器通过 Enterprise-Managed Authorization ID-JAG 交换实现互操作），包括 IdP 能力缺口、变通方案和一致性场景输入
• 企业身份集成：将 MCP 服务器连接到企业 IdP（Okta、Entra ID、Ping、Keycloak 等）时的需求和阻碍，包括 SSO、租户隔离和管理员同意流程
• 委派访问和 Agent 访问：当 MCP 客户端通过 Agent 或工具链执行操作时，代表用户的令牌交换、下游资源访问、受众限制和同意相关用例
• Scope 和权限粒度：MCP 服务器是否以及如何公布细粒度 scope（按工具、按资源），客户端应如何请求和呈现这些 scope，以及 scope 字符串之外的授权粒度（Rich Authorization Requests、结构化拒绝、补救提示）
• 非 HTTP 传输的凭据：适用于 stdio、WebSocket 和未来传输的模式；HTTP 授权规范并不直接适用于这些传输
• 客户端身份和注册：运营方使用 Dynamic Client Registration、Client ID Metadata Documents、software statements 和预注册客户端的经验
• 威胁建模输入：对授权相关攻击面（令牌混淆、confused-deputy、受众不匹配、重定向处理）进行编目，为 Security Best Practices 文档提供信息
• SEP 和草案反馈：授权相关的 SEP、ext-auth 草案、参考实现和演示会在会议及 #auth-ig thread 中展示，以便在 SEP 流程之前和期间获得反馈；IG 的粗略共识记录在会议纪要中，供 sponsor 和 Core Maintainer 参考
• 问题陈述和需求：在 #auth-ig thread 和 SEP pull request 中分享用例目录和建议，供 SEP 作者采用

范围外

• 接受 SEP 或扩展：IG 提供反馈并表达支持信号；sponsorship 和接受流程遵循 SEP 指南，仍由 Maintainer 和 Core Maintainer 负责
• MCP 客户端对终端用户的身份验证：host 应用如何验证其自身用户是 host 关注的问题，而不是协议关注的问题
• 传输安全（TLS、mTLS、证书处理）：由 Transports WG 负责
• 服务器身份、来源和信任信号：由 Server Card / Registry 相关工作负责
• 终端用户产品配置演练：IG 讨论模式，而不是各个 IdP 产品的逐步设置方法。厂商报告的授权服务器或 IdP 能够或无法实现的限制，_属于_部署经验范围
• 根据 MCP 反垄断政策，具有竞争敏感性或未公开的商业信息不在范围内

相关小组

• Security IG：令牌受众混淆、issuer 验证和账户关联风险处于两个小组的交界处
• Transports WG：授权目前在 HTTP 传输层面定义；传输的变化会影响凭据的承载位置
• Agents IG：多 Agent 链的委派/代表用户访问和同意与 Agent 用例高度重叠
• Server Card WG / Registry：客户端和服务器身份、发现元数据及信任建立，与如何定位和验证授权服务器及资源服务器相交
• SDK Maintainers：SDK 提供授权客户端实现；IG 的发现应为跨 SDK 的授权易用性和默认值提供信息

领导

成员

任何人均可参与；加入频道、参加会议或贡献内容均不需要正式成员资格或审批步骤。该组尤其欢迎身份提供商厂商、正在交付授权支持的 MCP 客户端和服务器实现者，以及将 MCP 与企业 IdP 集成的运营方。

加入 MCP Contributors Discord 的 #auth-ig 频道，并为你的主题发起或加入一个 thread。会议对外开放，参与可选；通过 Discord thread 异步参与同样受到重视。

运作方式

Discord：#auth-ig

单一频道，每个主题一个 thread

所有授权讨论都在 #auth-ig 中进行，每个主题使用一个 Discord thread（例如一个 SEP 编号、草案名称或部署配对）。不设按主题划分的频道。会议议程和纪要位于频道中每次会议对应的议程 thread，其链接会交叉发布到 GitHub Discussions，这是小组治理规则的要求。

议程驱动的会议

会议保留固定的双周时段，但每次会议都根据议程安排：

1. Facilitator 在每次会议前于 #auth-ig 中创建议程 thread。任何人都可以回复主题、诉求（反馈、决策、知悉）和所需时间来申请一个时段。
2. Facilitator 在会前商定议程并分配时段。
3. 如果议程内容不足，则在 thread 中宣布取消本次会议，并为下次会议保留该时段。

典型时段包括问题提案、SEP 或 ext-auth 草案的进展更新、原型或参考实现演示，或已发布扩展实现者提供的部署或互操作性报告。

从问题到 SEP

在任何人为 SEP 投入精力之前，每个问题提案都要回答两个固定问题：

• 这个问题值得解决吗？ 是否存在真实的部署需求，缺口是否位于协议而不是某个产品中？
• 这个问题属于这里吗？ 正确的归属是核心规范、ext-auth 中的官方扩展、非官方扩展，还是上游标准组织？

当两个问题的答案都是肯定时，提议者通过正常的 SEP 流程起草 SEP 或 ext-auth pull request，寻找 sponsor，并随着草案逐渐成熟，回到会议展示进展和演示。IG 不会为每个主题设立子组、频道或系列会议。已经针对某个主题单独开会的贡献者可以继续这样做，并将结果作为议程时段带回会议。当某项交付物确实需要自己的决策权时，仍可通过标准流程提议单独设立工作组，但这是例外，而不是默认路径。

交付物与成功指标

IG 的产出是经由该组推进的草案和演示：带有已记录 IG 反馈的授权 SEP 和 ext-auth 规范、参考实现和一致性场景、互操作性和部署报告，以及已发布的会议纪要。IG 负责维护 modelcontextprotocol/ext-auth，授权扩展规范通过 PR 落入该仓库。成功表现为授权提案在进入 Core Maintainer 评审时已经纳入跨主题反馈，以及已发布的扩展逐步积累多个独立且可互操作的实现。

已整合的频道

以下 Discord 频道此前承载授权子组。自本次重新制定章程起，这些频道已归档（只读），其主题继续作为 #auth-ig thread 和议程时段处理。Enterprise-Managed Authorization IG 也以相同方式并入本组：EMA 实现者将互操作性和部署进展作为展示时段带到会议，而不是继续在单独的常设小组中推进。

变更日志