Skip to content

SEP-2352 follow-up: key credential/state stores per authorization server #982

Closed as not planned

Description

@DaleSeo

Follow-up to #879 / PR #965 (repurposed from a duplicate of #879).

PR #965 implements the SEP-2352 binding rule: stored credentials are stamped with the issuer that minted them, get_access_token() rejects issuer mismatches (AuthError::AuthorizationServerMismatch), and stale credentials are cleared on mismatch so the next flow re-registers with the new AS.

What it intentionally leaves out (from the PR's scope note): per-AS keying of custom credential/state stores. Today there is a single active credential set, so:

  • Credentials for AS "A" are destroyed when the client talks to AS "B", even though the "A" credentials are still valid — switching back requires a full re-auth.
  • A client connecting to multiple MCP servers backed by different authorization servers cannot hold credentials for both simultaneously.

Work: key stored credentials (and any registration state) by AS issuer so multiple credential sets can coexist, and select the right set based on the issuer of the currently discovered metadata.

Not required for 2026-07-28 conformance (the auth/authorization-server-migration scenario is covered by #965), so this is not on the 2026-07-28 milestone.

Activity

  1. added this to the 2026-07-28 spec milestone on Jul 13, 2026
  2. added
    T-enhancementNew features and enhancements
    T-securitySecurity-related changes
    T-transportTransport layer changes
    P1High: significant functionality gap or spec violation
    on Jul 13, 2026
  3. removed this from the 2026-07-28 spec milestone on Jul 13, 2026
  4. changed the title [-]Implement SEP-2352: re-register client when the authorization server changes[/-] [+]SEP-2352 follow-up: key credential/state stores per authorization server[/+] on Jul 13, 2026
  5. added
    T-enhancementNew features and enhancements
    P2Medium: important but non-blocking improvement
    and removed
    P1High: significant functionality gap or spec violation
    on Jul 13, 2026
  6. self-assigned this
    on Jul 16, 2026
  7. github-actions commented on Sep 15, 2026

    @github-actions
    Contributor

    This issue has had no activity for 60 days and is now marked as stale. It will be closed in 14 days if there is no further activity. Add the keep label to keep it open.

  8. github-actions commented on Sep 29, 2026

    @github-actions
    Contributor

    Closing this issue after 14 days of inactivity since it was marked stale. Feel free to reopen if it is still relevant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

P2Medium: important but non-blocking improvementStaleT-enhancementNew features and enhancementsT-securitySecurity-related changesT-transportTransport layer changes

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions