Auth binding: no error code represents a denial, and SEP-1686's disclosure requirement did not carry over #20

PR #9 restored the Auth binding bullet that was dropped in the SEP-2663 port, and #19 locked it into 2026-07-28. Both versions of specification/draft/tasks.md now carry:

• Auth binding. Servers MUST perform authentication and authorization checks on each task-related request to ensure that the client has permission to access a task.

That was the right restoration. Two things that follow from it are still open, and I think both are cheap to close.

1. There is no error code for a denial

Protocol Errors defines three cases: -32602 for an invalid or nonexistent taskId, -32603 for internal errors, and -32021 for a missing required client capability. None of them represents "this task exists and you may not access it".

So a server that performs the mandated check and denies has nothing to return that expresses the denial. In practice it returns -32602, which is also the answer for a task that never existed. A client cannot distinguish a refusal from a typo, and neither can anything reading the logs afterwards.

That collapse may well be deliberate, as an anti-enumeration measure, and if so it is a reasonable design. The request is that it be written down, because right now the spec mandates a check whose failure has no defined representation.

There is precedent for both halves of this. The same shape was raised for requestState integrity failures during SEP-2663 review, and resolved on 2026-05-04 by allowing a synchronous error path on tasks/update and tasks/cancel as SHOULD statements, which is why those two lines read SHOULD today. And the 2026-08-28 Agents WG meeting settled the general principle for agent operations: operation-specific error codes should be defined, reusing an existing protocol code where an appropriate one exists. Applying that same principle here would resolve this.

Concretely, either:

• state normatively that servers MUST return -32602 for both unknown and unauthorized task IDs, and say why, or
• define a distinct code for permission denied.

The first is probably correct given the cross-caller correlation argument. It just needs saying.

2. The disclosure requirement from SEP-1686 was not ported

SEP-2663's Motivation is explicit that the binding the Auth binding bullet requires is not always available:

all tasks should be bound to some sort of "authorization context," the implementation of which is left to individual servers according to their existing bespoke permission models. However, in many cases, it is not possible to perform this binding, in which case the task ID becomes the only line of defense against contamination.

With sessions removed by SEP-2567, there is, in the SEP's own words, "no other natural scope a server can define unilaterally". In those deployments the mandated check reduces to the bearer check that the neighbouring bullet permits, where a server MAY use task IDs as bearer tokens. Possession of the handle becomes the authorization. That is a different property from the one the MUST describes.

SEP-1686 handled this, at §8.1.2:

Receivers that do not implement session or authentication binding SHOULD document this limitation clearly, as task results may be accessible to any requestor that can guess the task ID.

That sentence did not survive into SEP-2663, and the Motivation paragraph that explains why it is needed is in the SEP rather than in tasks.md, so an implementer working from this repo alone sees the MUST with none of the context that bounds it. It looks like the same class of loss as the Auth binding bullet in #9: normative text dropped in a transition rather than deliberately removed.

Restoring an equivalent of §8.1.2 to Security Considerations would close it.

Why it matters now

The roadmap post of 22 August sets a direction of servers recognising agent identities "built on existing standards rather than pasted API keys and long-lived tokens", and names maturing this extension so it can move into the specification. In the draft schema ttlMs is number | null with null documented as unlimited. A handle that may be used as a bearer token and need never expire is worth reconciling with that direction before the extension moves into the core spec, where it gets more expensive to change.

What I checked

Read on 31 August 2026 against specification/draft/tasks.md and specification/2026-07-28/tasks.md at main in this repo, schema/draft/schema.ts, and seps/2663-tasks-extension.md at main in modelcontextprotocol/modelcontextprotocol. Error codes present in this repo's spec text: -32021, -32602, -32603. The words identity, revoke, revocation and audit appear zero times in either document; bearer appears once.

This is a reading of the specification, not a report against a running implementation. I have not tested what servers actually return for a denial today, so if the answer to point 1 is already settled somewhere I have not found, please point me at it and I will close this.