Capture
One read of Model Context Protocol
3 pages moved out of 144 read.
community/interest-groups/auth Changed · +53 / -26 lines
### One channel, threads per topic ### Agenda-driven calls ### From problem to SEP ### Consolidated channels ### Working Group Incubation
from line 8
## Mission Statement -The Authorization Interest Group provides a venue for MCP implementers, identity-provider vendors, and security practitioners to surface real-world authorization challenges encountered when deploying MCP clients and servers. The group gathers use cases, documents gaps in the current OAuth 2.1–based authorization specification, and incubates validated problems until they are scoped well enough to propose a focused Working Group via the standard [group-creation process](/community/working-interest-groups#creating-a-working-group) to drive the corresponding [SEPs](/community/sep-guidelines). +The Authorization Interest Group is the single chartered venue for MCP authorization work. It brings MCP implementers, identity-provider vendors, and security practitioners together to surface real-world authorization problems, decide whether they are worth solving and whether they belong in MCP, and give authors a reliable place to present [SEPs](/community/sep-guidelines), [ext-auth](https://github.com/modelcontextprotocol/ext-auth) drafts, prototypes, and deployment results for cross-topic feedback. The charter defines the scope; discussion and rough consensus happen in one channel and one recurring call, and the work products are drafts and demos rather than new standing groups. ## Scope
from line 15
### In Scope * **Deployment experience reports**: how implementers have integrated the current authorization spec (OAuth 2.1, [RFC 9728](https://www.rfc-editor.org/rfc/rfc9728) Protected Resource Metadata, [RFC 7591](https://www.rfc-editor.org/rfc/rfc7591) Dynamic Client Registration, Client ID Metadata Documents) with real authorization servers, and where it falls short +* **Extension interoperability reports**: results of pairing independent implementations of the [ext-auth](https://github.com/modelcontextprotocol/ext-auth) extensions end to end (for example IdP, client, and authorization server through the [Enterprise-Managed Authorization](/extensions/auth/enterprise-managed-authorization) ID-JAG exchange), including IdP capability gaps, workarounds, and conformance scenario input * **Enterprise identity integration**: requirements and friction points when connecting MCP servers to enterprise IdPs (Okta, Entra ID, Ping, Keycloak, etc.), including SSO, tenant isolation, and admin consent flows * **Delegated and agentic access**: use cases for on-behalf-of token exchange, downstream resource access, audience restriction, and consent when an MCP client acts through chains of agents or tools -* **Scope and permission granularity**: whether and how MCP servers should advertise fine-grained scopes (per-tool, per-resource) and how clients should request and present them +* **Scope and permission granularity**: whether and how MCP servers should advertise fine-grained scopes (per-tool, per-resource) and how clients should request and present them, and authorization granularity beyond scope strings (Rich Authorization Requests, structured denials, remediation hints) * **Credentials for non-HTTP transports**: patterns for stdio, WebSocket, and future transports where the HTTP authorization spec does not directly apply * **Client identity and registration**: operator experience with Dynamic Client Registration, Client ID Metadata Documents, software statements, and pre-registered clients * **Threat modelling input**: cataloguing authorization-related attack surfaces (token confusion, confused-deputy, audience mismatch, redirect handling) to inform Security Best Practices documentation -* **Proposing Working Groups**: once a problem is validated and scoped, the IG submits a Working Group creation proposal via the standard `#wg-ig-group-creation` process; approval remains with community moderators and core maintainers -* **Problem statements and requirements**: use-case catalogues and recommendations published to GitHub Discussions for consumption by SEP authors and Working Groups +* **SEP and draft feedback**: authorization-related SEPs, ext-auth drafts, reference implementations, and demos are presented on the call and in `#auth-ig` threads for feedback before and during the [SEP process](/community/sep-guidelines); the IG's rough consensus is recorded in meeting notes for sponsors and Core Maintainers to draw on +* **Problem statements and requirements**: use-case catalogues and recommendations shared in `#auth-ig` threads and on SEP pull requests for consumption by SEP authors ### Out of Scope +* **Accepting SEPs or extensions**: the IG gives feedback and signals support; sponsorship and acceptance follow the [SEP guidelines](/community/sep-guidelines) and remain with Maintainers and Core Maintainers * **Authentication of end users to MCP clients**: how a host application authenticates its own users is a host concern, not a protocol concern * **Transport security (TLS, mTLS, certificate handling)**: belongs to the Transports WG * **Server identity, provenance, and trust signalling**: belongs to the Server Card / Registry efforts -* **End-user product configuration walk-throughs**: the IG discusses patterns, not step-by-step setup for individual IdP products. Vendor-reported constraints on what an authorization server can or cannot implement *are* in scope as deployment experience +* **End-user product configuration walk-throughs**: the IG discusses patterns, not step-by-step setup for individual IdP products. Vendor-reported constraints on what an authorization server or IdP can or cannot implement *are* in scope as deployment experience * **Competitively sensitive or non-public business information**, per the [MCP Antitrust Policy](/community/antitrust) ### Related Groups -* **[Enterprise-Managed Authorization IG](/community/interest-groups/enterprise-managed-authorization)**: coordinates IdP, client, and server interoperability testing for the EMA extension produced by the Profiles WG; spec-change requests surfaced there are routed back to this group +* **[Security IG](/community/interest-groups/security)**: token-audience confusion, issuer validation, and account-linking risks sit at the boundary between the two groups * **Transports WG**: authorization is currently specified at the HTTP transport level; changes to transports affect where credentials are carried * **Agents WG**: delegated/on-behalf-of access and consent for multi-agent chains overlap heavily with agentic use cases * **[Server Card WG](/community/working-groups/server-card) / [Registry](/community/working-groups/registry)**: client and server identity, discovery metadata, and trust establishment intersect with how authorization servers and resource servers are located and verified -* **SDK Maintainers**: SDKs ship the auth client implementations; IG findings should inform cross-SDK auth ergonomics +* **SDK Maintainers**: SDKs ship the auth client implementations; IG findings should inform cross-SDK auth ergonomics and defaults ## Leadership
from line 52
## Membership -Open to anyone; no formal membership or approval step is required to join the channel, attend calls, or contribute. +Open to anyone; no formal membership or approval step is required to join the channel, attend calls, or contribute. The group particularly seeks identity-provider vendors, MCP client and server implementers shipping authorization support, and operators integrating MCP with enterprise IdPs. -Join the `#auth-ig` channel on the [MCP Contributors Discord](/community/communication#discord) or open a thread in the Authorization category of [GitHub Discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions). If your topic clearly matches one of the Working Groups in the table below, you can post directly in that WG's channel. Calls are open and attendance is optional — async participation via Discord and GitHub is equally valued. +Join the `#auth-ig` channel on the [MCP Contributors Discord](/community/communication#discord) and start or join a thread for your topic. Calls are open and attendance is optional — async participation in Discord threads is equally valued. ## Operations -| Meeting | Frequency | Duration | Purpose | -| --------------- | ------------- | -------- | ---------------------------------------------------------------------------- | -| Discussion Call | Every 2 weeks | 45 min | Use-case sharing, problem triage, WG proposal decisions, implementer reports | +| Meeting | Frequency | Duration | Purpose | +| ------------ | ------------- | -------- | --------------------------------------------------------------------------------- | +| Auth IG Call | Every 2 weeks | 45 min | Agenda-driven: problem pitches, SEP and draft progress, demos, deployment reports | Discord: [#auth-ig](https://discord.com/channels/1358869848138059966/1360835991749001368) -### Working Group Incubation +### One channel, threads per topic -A topic graduates to a Working Group proposal when it has a written problem statement in GitHub Discussions and rough consensus on a bi-weekly call (recorded in published notes). A facilitator then files the standard WG creation template in `#wg-ig-group-creation`, citing that discussion. The IG's role ends at the proposal; approval remains with community moderators and core maintainers. +All authorization discussion happens in `#auth-ig`, with one Discord thread per topic (for example a SEP number, a draft name, or a deployment pairing). There are no per-topic channels. Meeting agendas and notes live in the channel's per-call agenda thread, with a link cross-posted to [GitHub Discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions) as the [group governance rules](/community/working-interest-groups) require. +### Agenda-driven calls + +The call keeps a fixed biweekly slot, but each meeting is built from its agenda: + +1. A facilitator opens an agenda thread in `#auth-ig` ahead of each call. Anyone may request a slot by replying with the topic, the ask (feedback, decision, awareness), and the time needed. +2. Facilitators agree the agenda and hand out time slots before the call. +3. If the agenda is thin, the call is cancelled in the thread and the slot is kept for next time. + +Typical slots are a problem pitch, a progress update on a SEP or ext-auth draft, a demo of a prototype or reference implementation, or a deployment or interoperability report from implementers of a shipped extension. + +### From problem to SEP + +Two standing questions are asked of every problem pitch before anyone invests in a SEP: + +* **Is this a problem worth solving?** Is there real deployment demand, and is the gap in the protocol rather than in one product? +* **Does it belong here?** Is the right home the core specification, an official extension in ext-auth, an unofficial extension, or an upstream standards body? + +When the answer to both is yes, the proposer drafts a SEP or ext-auth pull request through the normal [SEP process](/community/sep-guidelines), finds a sponsor, and returns to the call to present progress and demos as the draft matures. The IG does not charter a sub-group, channel, or meeting series per topic. Contributors who already meet separately on a topic are welcome to keep doing so, and bring outcomes back to the call as agenda slots. A separate [Working Group](/community/working-interest-groups) can still be proposed through the standard process when a deliverable genuinely needs its own decision rights, but that is the exception rather than the default path. + ## Deliverables & Success Metrics -The IG incubates problems until they are well-scoped, then proposes focused Working Groups to drive specific SEPs. Each spawned WG maintains its own charter; this list is a directory, not a substitute. The IG stewards [modelcontextprotocol/ext-auth](https://github.com/modelcontextprotocol/ext-auth), where individual WGs land authorization extension specifications via PR. +The IG's outputs are the drafts and demos that pass through it: authorization SEPs and ext-auth specifications with recorded IG feedback, reference implementations and conformance scenarios, interoperability and deployment reports, and published meeting notes. The IG stewards [modelcontextprotocol/ext-auth](https://github.com/modelcontextprotocol/ext-auth), where authorization extension specifications land via PR. Success looks like authorization proposals reaching Core Maintainer review with cross-topic feedback already incorporated, and shipped extensions accumulating independent interoperable implementations. -| Working Group | Discord | Focus | Status | Charter | -| -------------------------- | ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------- | ------- | -| Client Registration | `#auth-wg-client-registration` | Dynamic Client Registration, Client ID Metadata Documents, software statements, and pre-registered client workflows | Completed | — | -| Mix-up Protection | `#auth-wg-mixup-protection` | Mitigating OAuth authorization-server mix-up and token-audience confusion attacks | Completed | — | -| Profiles | `#auth-wg-profiles` | Extension specifications for additional grant types and token-binding mechanisms (Client Credentials, Enterprise-Managed Authorization, DPoP, Workload Identity Federation) | Completed | — | -| Tool Scopes | `#auth-wg-tool-scopes` | Per-tool OAuth scope advertisement, step-up authorization / scope challenge, and client-side scope accumulation — mechanics within the OAuth scope-string model | Active | Pending | -| Fine-Grained Authorization | `#auth-wg-fine-grained-authz` | Authorization granularity beyond scope strings — Rich Authorization Requests ([RFC 9396](https://www.rfc-editor.org/rfc/rfc9396)), remediation hints, and multi-credential handling | Active | Pending | -| Improve DevX | `#auth-wg-improve-devx` | Best-practices guidance and tutorials for building secure MCP clients and servers, beyond the normative spec | Completed | — | +### Consolidated channels +The following Discord channels previously hosted authorization sub-groups. They are archived (read-only) as of this re-charter and their topics continue as `#auth-ig` threads and agenda slots. The [Enterprise-Managed Authorization IG](/community/interest-groups/enterprise-managed-authorization) is folded into this group on the same basis: EMA implementers bring interoperability and deployment progress to the call as presentation slots rather than to a standing separate group. + +| Former channel | Topic | State at consolidation | Continues as | +| ------------------------------ | ----------------------------------------------------------------------------------------------------------------------- | ---------------------- | --------------------------------------------------------- | +| `#auth-wg-client-registration` | Dynamic Client Registration, Client ID Metadata Documents, software statements, pre-registration | Completed | `#auth-ig` threads as needed | +| `#auth-wg-mixup-protection` | Authorization-server mix-up and token-audience confusion mitigations | Completed | `#auth-ig` threads as needed | +| `#auth-wg-profiles` | Client Credentials, Enterprise-Managed Authorization, DPoP, Workload Identity Federation extensions | Completed | `#auth-ig` DPoP and Workload Identity Federation threads | +| `#auth-wg-tool-scopes` | Per-tool scope advertisement, step-up authorization, client-side scope accumulation | Active | `#auth-ig` thread | +| `#auth-wg-fine-grained-authz` | Rich Authorization Requests ([RFC 9396](https://www.rfc-editor.org/rfc/rfc9396)), structured denials, remediation hints | Active | `#auth-ig` SEP-2643 / fine-grained authorization thread | +| `#auth-wg-improve-devx` | Best-practices guidance and tutorials beyond the normative spec | Dormant | `#auth-ig` threads as needed | +| `#enterprise-managed-auth-ig` | EMA extension interoperability (IdP, client, authorization server) | Active | `#auth-ig` EMA interop thread and deployment-report slots | + ## Changelog -| Date | Change | -| ---------- | --------------- | -| 2026-06-02 | Initial charter | +| Date | Change | +| ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| 2026-08-17 | Re-charter: single venue and channel for authorization work; agenda-driven calls; SEP feedback in scope; `#auth-wg-*` channels and the Enterprise-Managed Authorization IG folded in | +| 2026-06-02 | Initial charter |
community/interest-groups/enterprise-managed-authorization Changed · +12 / -3 lines
from line 2
> Charter for the MCP Enterprise-Managed Authorization Interest Group. +<Note> + As of 2026-08-17 this Interest Group is folded into the [Authorization + IG](/community/interest-groups/auth). EMA interoperability and deployment + progress is presented as agenda slots on the Auth IG call, discussion + continues in `#auth-ig` threads, and `#enterprise-managed-auth-ig` is + archived. This page is kept for reference. +</Note> + ## Group Type **Interest Group**
from line 68
## Changelog -| Date | Change | -| ---------- | --------------- | -| 2026-06-16 | Initial charter | +| Date | Change | +| ---------- | -------------------------------------------------- | +| 2026-08-17 | Folded into the Authorization IG; channel archived | +| 2026-06-16 | Initial charter |
community/working-interest-groups Changed · +2 / -3 lines
from line 228
**Working Group Formation:** * There must be a widely acknowledged concern requiring coordination -* PR for creation of WG into `docs/community/working-groups/<name>/overview.mdx`, gated by CODEOWNERS requiring approval by Maintainers -* PR for charter into `docs/community/working-groups/<name>.mdx`, gated by CODEOWNERS requiring approval from Core Maintainers +* PR adding the WG charter as `docs/community/working-groups/<name>.mdx`, written from the [Group Charter Template](/community/charter-template) and including the corresponding navigation entry in `docs/docs.json`, gated by CODEOWNERS requiring approval from Core Maintainers * Initial member list approved by WG Lead **Interest Group Formation:**
from line 235
* Fill out the creation template in the `#wg-ig-group-creation` channel on [Discord](https://discord.gg/6CSzBmMkjX) * A Core Maintainer reviews the proposal; the IG and its Facilitator(s) must be sponsored by at least two Core Maintainers or one Lead Maintainer -* Once sponsored, the Facilitator(s) organize the IG and create a charter +* Once sponsored, the Facilitator(s) organize the IG and create a charter via a PR adding `docs/community/interest-groups/<name>.mdx`, written from the same template and including the corresponding navigation entry in `docs/docs.json`, gated by CODEOWNERS requiring approval from Core Maintainers **Retirement:**