Authorization Charter changedcommunity/interest-groups/auth
Nearest release: v2.1.238, published 5 hours before this site recorded the change. Shown because the two are within 24 hours of each other. Nothing here says the release caused the edit.
Recorded here
Lines+53added
Lines−26removed
From line
8
where the diff opens
First seen
14 Aug 2026
this site's first read of the page
Recorded edits6to this page, all time
### One channel, threads per topic ### Agenda-driven calls ### From problem to SEP ### Consolidated channels ### Working Group Incubation
The whole hunk
from line 8, old and new numbered
/
from line 8
88
99## Mission Statement
1010
11The 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).
11The 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.
1212
1313## Scope
1414
from line 15
1515### In Scope
1616
1717* **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
18* **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
1819* **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
1920* **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
20* **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
21* **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)
2122* **Credentials for non-HTTP transports**: patterns for stdio, WebSocket, and future transports where the HTTP authorization spec does not directly apply
2223* **Client identity and registration**: operator experience with Dynamic Client Registration, Client ID Metadata Documents, software statements, and pre-registered clients
2324* **Threat modelling input**: cataloguing authorization-related attack surfaces (token confusion, confused-deputy, audience mismatch, redirect handling) to inform Security Best Practices documentation
24* **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
25* **Problem statements and requirements**: use-case catalogues and recommendations published to GitHub Discussions for consumption by SEP authors and Working Groups
25* **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
26* **Problem statements and requirements**: use-case catalogues and recommendations shared in `#auth-ig` threads and on SEP pull requests for consumption by SEP authors
2627
2728### Out of Scope
2829
30* **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
2931* **Authentication of end users to MCP clients**: how a host application authenticates its own users is a host concern, not a protocol concern
3032* **Transport security (TLS, mTLS, certificate handling)**: belongs to the Transports WG
3133* **Server identity, provenance, and trust signalling**: belongs to the Server Card / Registry efforts
32* **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
34* **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
3335* **Competitively sensitive or non-public business information**, per the [MCP Antitrust Policy](/community/antitrust)
3436
3537### Related Groups
3638
37* **[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
39* **[Security IG](/community/interest-groups/security)**: token-audience confusion, issuer validation, and account-linking risks sit at the boundary between the two groups
3840* **Transports WG**: authorization is currently specified at the HTTP transport level; changes to transports affect where credentials are carried
3941* **Agents WG**: delegated/on-behalf-of access and consent for multi-agent chains overlap heavily with agentic use cases
4042* **[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
41* **SDK Maintainers**: SDKs ship the auth client implementations; IG findings should inform cross-SDK auth ergonomics
43* **SDK Maintainers**: SDKs ship the auth client implementations; IG findings should inform cross-SDK auth ergonomics and defaults
4244
4345## Leadership
4446
from line 52
5052
5153## Membership
5254
53Open to anyone; no formal membership or approval step is required to join the channel, attend calls, or contribute.
55Open 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.
5456
55Join 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.
57Join 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.
5658
5759## Operations
5860
59| Meeting | Frequency | Duration | Purpose |
60| --------------- | ------------- | -------- | ---------------------------------------------------------------------------- |
61| Discussion Call | Every 2 weeks | 45 min | Use-case sharing, problem triage, WG proposal decisions, implementer reports |
61| Meeting | Frequency | Duration | Purpose |
62| ------------ | ------------- | -------- | --------------------------------------------------------------------------------- |
63| Auth IG Call | Every 2 weeks | 45 min | Agenda-driven: problem pitches, SEP and draft progress, demos, deployment reports |
6264
6365Discord: [#auth-ig](https://discord.com/channels/1358869848138059966/1360835991749001368)
6466
65### Working Group Incubation
67### One channel, threads per topic
6668
67A 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.
69All 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.
6870
71### Agenda-driven calls
72
73The call keeps a fixed biweekly slot, but each meeting is built from its agenda:
74
751. 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.
762. Facilitators agree the agenda and hand out time slots before the call.
773. If the agenda is thin, the call is cancelled in the thread and the slot is kept for next time.
78
79Typical 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.
80
81### From problem to SEP
82
83Two standing questions are asked of every problem pitch before anyone invests in a SEP:
84
85* **Is this a problem worth solving?** Is there real deployment demand, and is the gap in the protocol rather than in one product?
86* **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?
87
88When 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.
89
6990## Deliverables & Success Metrics
7091
71The 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.
92The 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.
7293
73| Working Group | Discord | Focus | Status | Charter |
74| -------------------------- | ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------- | ------- |
75| Client Registration | `#auth-wg-client-registration` | Dynamic Client Registration, Client ID Metadata Documents, software statements, and pre-registered client workflows | Completed | — |
76| Mix-up Protection | `#auth-wg-mixup-protection` | Mitigating OAuth authorization-server mix-up and token-audience confusion attacks | Completed | — |
77| Profiles | `#auth-wg-profiles` | Extension specifications for additional grant types and token-binding mechanisms (Client Credentials, Enterprise-Managed Authorization, DPoP, Workload Identity Federation) | Completed | — |
78| 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 |
79| 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 |
80| Improve DevX | `#auth-wg-improve-devx` | Best-practices guidance and tutorials for building secure MCP clients and servers, beyond the normative spec | Completed | — |
94### Consolidated channels
8195
96The 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.
97
98| Former channel | Topic | State at consolidation | Continues as |
99| ------------------------------ | ----------------------------------------------------------------------------------------------------------------------- | ---------------------- | --------------------------------------------------------- |
100| `#auth-wg-client-registration` | Dynamic Client Registration, Client ID Metadata Documents, software statements, pre-registration | Completed | `#auth-ig` threads as needed |
101| `#auth-wg-mixup-protection` | Authorization-server mix-up and token-audience confusion mitigations | Completed | `#auth-ig` threads as needed |
102| `#auth-wg-profiles` | Client Credentials, Enterprise-Managed Authorization, DPoP, Workload Identity Federation extensions | Completed | `#auth-ig` DPoP and Workload Identity Federation threads |
103| `#auth-wg-tool-scopes` | Per-tool scope advertisement, step-up authorization, client-side scope accumulation | Active | `#auth-ig` thread |
104| `#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 |
105| `#auth-wg-improve-devx` | Best-practices guidance and tutorials beyond the normative spec | Dormant | `#auth-ig` threads as needed |
106| `#enterprise-managed-auth-ig` | EMA extension interoperability (IdP, client, authorization server) | Active | `#auth-ig` EMA interop thread and deployment-report slots |
107
82108## Changelog
83109
84| Date | Change |
85| ---------- | --------------- |
86| 2026-06-02 | Initial charter |
110| Date | Change |
111| ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
112| 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 |
113| 2026-06-02 | Initial charter |
87114
No line in this hunk matches that.