[RamjotSingh]

The original issue is described in #62

This is a split from #63 and builds on #67

Applies the server's resource-level access checks, such as ACLs and membership, to every notification on a subscriptions/listen stream, not only to the request that opened it. Notifications the principal could not obtain with a request are dropped. A stream that loses access to some of its entries keeps the rest; one that loses access to all of them ends with revoked.

Motivation and Context

A server checks two things before it serves a request: that the token is valid, and that the principal may access what the request asks for (#62). The proposal this builds on covers the token; this one covers the resource. Today, a stream opened before a user lost access to a resource keeps delivering its change notifications, revealing when a resource they can no longer read changes, and notifications about sub-resources, such as a private channel in a watched team, raise the same problem without any change in access.

How Has This Been Tested?

Prototype on a TypeScript SDK fork, branch poc/authorization-lifetime (reviewer guide), which implements the combined draft in #63. Every notification passes through a pluggable access check, authorize(authInfo, target).

• Demo (pnpm --filter @mcp-examples/authorization-lifetime start:fast), scenario 3, step 3: access to an HR case is revoked during a change to it. One stream keeps receiving changes to config.json while notifications about the HR case stop; another, whose only entry is the HR case, stays open past the change rather than revealing when it happened.
• Tests: a denied entry stops while the stream stays open; an access-change signal ends a stream left with no entries with revoked; a last entry lost during a change ends the stream only at its deadline.
• Build, lint, typecheck, and the SDK test suites pass, apart from three Windows-only failures that also occur on unmodified upstream main.

Breaking Changes

None for clients, and no wire change. Servers that deliver these notifications today must stop, but the notifications dropped are ones the principal could not obtain with a request, and a client cannot tell a dropped notification from no change. A stream ends only when nothing it watches is still readable, which older clients see as a close without a response, the same as any other unexpected disconnect.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

AI disclosure: Ideas and specs are mine but I have used AI to link it back into the existing protocol and SEPs that introduced them as well as formulate into official language from my draft. POC has been built by AI as well on my guidance.