From 264ead333877e37d9ecf1d094e40ed32fb02c432 Mon Sep 17 00:00:00 2001 From: Imran Siddique <45405841+imran-siddique@users.noreply.github.com> Date: Thu, 15 Oct 2026 09:55:48 -0700 Subject: [PATCH] docs: restore SEP-1686 disclosure SHOULD for unbound tasks SEP-1686 section 8.1 item 2 told receivers without session or authentication binding to document that limitation. It did not carry into SEP-2663 or tasks.md, which now pairs a MAY for task IDs as bearer tokens with a MUST for auth binding and nothing reconciling the two. Add one Security Considerations bullet to the draft spec. The locked 2026-07-28 page is unchanged. Fixes #20 Co-Authored-By: Claude Opus 5.5 --- specification/draft/tasks.md | 1 + 1 file changed, 1 insertion(+) diff --git a/specification/draft/tasks.md b/specification/draft/tasks.md index c4f96bf..ac6b623 100644 --- a/specification/draft/tasks.md +++ b/specification/draft/tasks.md @@ -901,6 +901,7 @@ The `tasks/get` endpoint returns exactly what the underlying request would have - **Task ID unguessability.** A server **MAY** use task IDs as bearer tokens for a server's stored state. Servers **MUST** generate them with sufficient entropy that a third party cannot enumerate or guess them. - **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. +- **Unbound tasks.** Servers that do not bind tasks to an authorization context **SHOULD** document this limitation clearly, as the task ID is then a bearer credential and task results may be accessible to any requestor that holds it. - **Cross-caller correlation.** Because there is no `tasks/list`, a server cannot inadvertently leak the existence of one caller's tasks to another. This is an improvement over the `2025-11-25` tasks specification, in which a poorly-scoped list could expose unrelated task IDs. - **Input-request trust model.** `inputRequests` carry elicitation and sampling payloads from the server through the client to the user or model. Hosts **MUST** apply the same trust model to these payloads as they would to standard elicitation/sampling requests. A task is not a higher-trust channel.