financial-services-interest-group

Summary The FSIG charter now lives in the central modelcontextprotocol repo at (merged in modelcontextprotocol/modelcontextprotocol#2979), and group governance rules are defined centrally in . This removes the now-duplicated in-repo docs and points the README at the canonical charter, matching the convention used by the repos (e.g. interceptors, skills). Changes Delete — mission/scope/extension strategy now in the canonical charter Delete — governance model, roles, and decision-making are central; leadership and membership live in the charter Rewrite — adds a Charter link block; keeps focus areas, meeting info, and repo structure Rewrite — defers governance/meetings/decisions to the charter and central docs; keeps antitrust, extension-development, and SEP guidance Net: +71 / −387 lines. Notes Membership/leadership now has a single source (the charter). Updating the roster means a PR to the modelcontextprotocol repo. Role terminology aligns with the charter's Facilitator/Participant model. Closes #9

Background The FSIG charter is being moved to the central modelcontextprotocol repo in the current official template format (). The new template intentionally omits governance boilerplate (decision-making, meeting rules, antitrust, maintainer ladder) because those now live centrally in Working and Interest Groups. Once that upstream charter is merged and live, our repo-local and will duplicate content that is now canonical elsewhere. Task After the upstream charter PR merges: [ ] Slim down to a short pointer to the canonical charter, keeping only FSIG-specific content not covered centrally (e.g. the extensions → SEP promotion strategy, meeting/agenda doc links). [ ] Slim similarly — defer governance rules to the central docs, keep only the current members table and anything FSIG-specific. [ ] Update links to point at the canonical charter. [ ] Reconcile any wording the upstream review changed (e.g. Facilitator vs. Maintainer role naming, scope edits). Why after merge, not before Keeps the repo docs authoritative for members until the upstream charter is actually live. Upstream review may tweak wording/role names/scope; slimming to the final merged version avoids a second pass. _This issue was drafted by Claude (Claude Code) on behalf of @PederHP._

Background: There's a common misconception among stakeholders that MCP provides protocol-level support for downstream authorization (AuthZ) propagation. In reality, authentication terminates at the MCP server boundary, and any downstream authorization or identity propagation is the responsibility of individual server implementations. Proposal: Develop a whitepaper documenting best practices and proven architectural patterns for implementing secure downstream authorization and identity propagation in MCP servers. Scope: The whitepaper should cover: Best practices for preventing privilege escalation Token exchange patterns (e.g., OAuth 2.0 Token Exchange RFC 8693) On-behalf-of (OBO) flows Identity propagation strategies Trust boundary considerations Security implications and common pitfalls Goal: Provide server authors with clear guidance on implementing robust, enterprise-grade authorization mechanisms that maintain security guarantees across service boundaries.