Authorization Charter changedcommunity/interest-groups/auth
Nearest release: v2.1.305, published under an hour before upstream edited the page. Shown because the two are within 24 hours of each other. Nothing here says the release caused the edit.
Upstream edited this page at 20 Oct 2026 20:02 UTC, give or take a minute or two: the time comes from Anthropic’s own sitemap rather than from a commit. This site recorded the change at 22 Oct 2026 20:37 UTC.
Upstream edited
Recorded here
Lines+12added
Lines−12removed
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
The whole hunk
from line 8, old and new numbered
/
from line 8
88
99## Mission Statement
1010
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.
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.md), [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
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.md) ID-JAG exchange), including IdP capability gaps, workarounds, and conformance scenario input
1919* **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
2020* **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
2121* **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)
from line 22
2222* **Credentials for non-HTTP transports**: patterns for stdio, WebSocket, and future transports where the HTTP authorization spec does not directly apply
2323* **Client identity and registration**: operator experience with Dynamic Client Registration, Client ID Metadata Documents, software statements, and pre-registered clients
2424* **Threat modelling input**: cataloguing authorization-related attack surfaces (token confusion, confused-deputy, audience mismatch, redirect handling) to inform Security Best Practices documentation
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
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.md); the IG's rough consensus is recorded in meeting notes for sponsors and Core Maintainers to draw on
2626* **Problem statements and requirements**: use-case catalogues and recommendations shared in `#auth-ig` threads and on SEP pull requests for consumption by SEP authors
2727
2828### Out of Scope
2929
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
30* **Accepting SEPs or extensions**: the IG gives feedback and signals support; sponsorship and acceptance follow the [SEP guidelines](/community/sep-guidelines.md) and remain with Maintainers and Core Maintainers
3131* **Authentication of end users to MCP clients**: how a host application authenticates its own users is a host concern, not a protocol concern
3232* **Transport security (TLS, mTLS, certificate handling)**: belongs to the Transports WG
3333* **Server identity, provenance, and trust signalling**: belongs to the Server Card / Registry efforts
3434* **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
35* **Competitively sensitive or non-public business information**, per the [MCP Antitrust Policy](/community/antitrust)
35* **Competitively sensitive or non-public business information**, per the [MCP Antitrust Policy](/community/antitrust.md)
3636
3737### Related Groups
3838
39* **[Security IG](/community/interest-groups/security)**: token-audience confusion, issuer validation, and account-linking risks sit at the boundary between the two groups
40* **[Transports WG](/community/working-groups/transports)**: authorization is currently specified at the HTTP transport level; changes to transports affect where credentials are carried
39* **[Security IG](/community/interest-groups/security.md)**: token-audience confusion, issuer validation, and account-linking risks sit at the boundary between the two groups
40* **[Transports WG](/community/working-groups/transports.md)**: authorization is currently specified at the HTTP transport level; changes to transports affect where credentials are carried
4141* **Agents IG**: delegated/on-behalf-of access and consent for multi-agent chains overlap heavily with agentic use cases
42* **[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
42* **[Server Card WG](/community/working-groups/server-card.md) / [Registry](/community/working-groups/registry.md)**: client and server identity, discovery metadata, and trust establishment intersect with how authorization servers and resource servers are located and verified
4343* **SDK Maintainers**: SDKs ship the auth client implementations; IG findings should inform cross-SDK auth ergonomics and defaults
4444
4545## Leadership
from line 54
5454
5555Open 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.
5656
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.
57Join the `#auth-ig` channel on the [MCP Contributors Discord](/community/communication.md#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.
5858
5959## Operations
6060
from line 66
6666
6767### One channel, threads per topic
6868
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.
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.md) require.
7070
7171### Agenda-driven calls
7272
from line 85
8585* **Is this a problem worth solving?** Is there real deployment demand, and is the gap in the protocol rather than in one product?
8686* **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?
8787
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.
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.md), 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.md) 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.
8989
9090## Deliverables & Success Metrics
9191
from line 93
9393
9494### Consolidated channels
9595
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.
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.md) 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.
9797
9898| Former channel | Topic | State at consolidation | Continues as |
9999| - | - | - | - |
No line in this hunk matches that.