modelcontextprotocol/conformance
Watch
1
0
Fork
You've already forked conformance
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

chore(sep-2350): exclude the server single-challenge requirement from traceability (#302)

Browse source 
'All scopes required for the current operation' has no harness-observable
ground truth: the WWW-Authenticate challenge is the only place the server
declares what an operation requires, so there is nothing independent to
compare it against. Detecting the negative (incremental challenging) would
need server-side auth scenarios that do not exist yet and would exercise the
example app's scope configuration rather than SDK behavior, and the spec
explicitly permits dynamic per-request scope determination, so a second
challenge is not conclusively non-conformant.

The client-side half of SEP-2350 (scope union on re-authorization) remains
tested by auth/scope-step-up.
This commit is contained in:
Paul Carleton 2026-05-22 23:22:13 +01:00 • committed by GitHub
commit d31a0299af
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
2 changed files with 8 additions and 9 deletions
Download patch file Download diff file Expand all files Collapse all files

4
src/seps/sep-2350.yaml
View file

@ -4,8 +4,8 @@ requirements:
- check: sep-2350-scope-union-on-reauth
text: 'When re-authorizing, clients SHOULD include these scopes alongside any previously granted scopes to avoid losing permissions needed for other operations. / Clients SHOULD compute the union of previously requested scopes and newly challenged scopes when initiating re-authorization.'
url: https://modelcontextprotocol.io/specification/draft/basic/authorization#protected-resource-metadata-discovery-requirements
- check: sep-2350-server-single-challenge
text: 'Regardless of the approach chosen, servers SHOULD include all scopes required for the current operation in a single challenge.'
- text: 'Regardless of the approach chosen, servers SHOULD include all scopes required for the current operation in a single challenge.'
excluded: '"All scopes required for the current operation" has no harness-observable ground truth; the challenge is the only place the server declares its requirements. Detecting the negative (incremental challenging) would need server-side auth scenarios that do not exist yet and would test the example app''s scope config rather than SDK behavior; the spec also permits dynamic per-request scope determination, so a second challenge is not conclusively non-conformant.'
- text: 'When responding with insufficient scope errors, servers SHOULD include the scopes needed to satisfy the current operation in the scope parameter, consistent with RFC 6750 Section 3.1.'
excluded: 'reword of pre-existing requirement (request->operation, +RFC6750 cite); no normative delta; harness already emits scope= in WWW-Authenticate'

13
src/seps/traceability.json
View file

@ -500,14 +500,13 @@
"status": "tested",
"text": "When re-authorizing, clients SHOULD include these scopes alongside any previously granted scopes to avoid losing permissions needed for other operations. / Clients SHOULD compute the union of previously requested scopes and newly challenged scopes when initiating re-authorization.",
"url": "https://modelcontextprotocol.io/specification/draft/basic/authorization#protected-resource-metadata-discovery-requirements"
},
{
"check": "sep-2350-server-single-challenge",
"status": "untested",
"text": "Regardless of the approach chosen, servers SHOULD include all scopes required for the current operation in a single challenge."
}
],
"excluded": [
{
"text": "Regardless of the approach chosen, servers SHOULD include all scopes required for the current operation in a single challenge.",
"reason": "\"All scopes required for the current operation\" has no harness-observable ground truth; the challenge is the only place the server declares its requirements. Detecting the negative (incremental challenging) would need server-side auth scenarios that do not exist yet and would test the example app's scope config rather than SDK behavior; the spec also permits dynamic per-request scope determination, so a second challenge is not conclusively non-conformant."
},
{
"text": "When responding with insufficient scope errors, servers SHOULD include the scopes needed to satisfy the current operation in the scope parameter, consistent with RFC 6750 Section 3.1.",
"reason": "reword of pre-existing requirement (request->operation, +RFC6750 cite); no normative delta; harness already emits scope= in WWW-Authenticate"
@ -517,8 +516,8 @@
"untracked": [],
"summary": {
"tested": 1,
"untested": 1,
"excluded": 1,
"untested": 0,
"excluded": 2,
"untracked": 0,
"unkeyed": 0
}