feat(sep-2468): cover the remaining untested traceability rows (#304)
Add two client scenarios for the SEP-2468 requirements that had no conformance coverage: - auth/metadata-issuer-mismatch: the AS metadata document declares an issuer that differs from the issuer identifier used to construct the well-known URL; the client must not use the metadata (sep-2468-client-validate-metadata-issuer). - auth/iss-normalized: the authorization redirect carries an iss value that only matches the recorded issuer after URL normalization; the client must compare with simple string comparison and reject (sep-2468-client-no-normalization). The two authorization-server-side rows (AS SHOULD include iss, AS MUST advertise authorization_response_iss_parameter_supported) are excluded: observing iss in an authorization response requires driving an Authorization Code Grant against the AS under test, which the authorization-server suite does not implement yet (#208).
This commit is contained in:
parent
909ea0b5fd
commit
f12baed382
1 changed files with 518 additions and 13 deletions
|
|
@ -4,10 +4,6 @@ requirements:
|
|||
- check: sep-2468-client-validate-metadata-issuer
|
||||
text: 'After retrieving a metadata document, MCP clients MUST validate it as required by RFC8414 Section 3.3 or OpenID Connect Discovery Section 4.3: the issuer value in the document MUST be identical to the issuer identifier used to construct the well-known URL. If they differ, the client MUST NOT use the metadata.'
|
||||
url: https://modelcontextprotocol.io/specification/draft/basic/authorization#authorization-server-metadata-discovery
|
||||
- check: sep-2468-as-include-iss
|
||||
text: 'MCP authorization servers SHOULD include the iss parameter in authorization responses, including error responses, as defined in RFC9207 Section 2.'
|
||||
- check: sep-2468-as-advertise-iss-supported
|
||||
text: 'Authorization servers that include the iss parameter MUST advertise this by setting authorization_response_iss_parameter_supported to true in their metadata (RFC9207 Section 2.3).'
|
||||
- check: sep-2468-client-compare-iss-supported
|
||||
text: 'On receiving the authorization response, MCP clients MUST apply the validation in RFC9207 Section 2.4 before transmitting the authorization code to any token endpoint: authorization_response_iss_parameter_supported true, iss present -> Compare to the recorded issuer using simple string comparison / Before redirecting the user-agent, the client MUST record the issuer value from the selected authorization server validated metadata document and associate it with the same per-request record used to store the PKCE code verifier.'
|
||||
- check: sep-2468-client-reject-missing-iss
|
||||
|
|
@ -19,5 +15,11 @@ requirements:
|
|||
- check: sep-2468-client-no-normalization
|
||||
text: 'After decoding the iss value from the application/x-www-form-urlencoded response per RFC 9207 Section 2.4, clients MUST NOT apply scheme or host case folding, default-port elision, trailing-slash, or percent-encoding normalization (RFC 3986 Sections 6.2.2-6.2.3) before comparison.'
|
||||
|
||||
- text: 'MCP authorization servers SHOULD include the iss parameter in authorization responses, including error responses, as defined in RFC9207 Section 2.'
|
||||
excluded: 'Targets the authorization server under test; observing iss in an authorization response requires driving an Authorization Code Grant against the AS, which the authorization-server suite does not implement yet (it only probes the metadata endpoint).'
|
||||
issue: 'https://github.com/modelcontextprotocol/conformance/issues/208'
|
||||
- text: 'Authorization servers that include the iss parameter MUST advertise this by setting authorization_response_iss_parameter_supported to true in their metadata (RFC9207 Section 2.3).'
|
||||
excluded: 'Conditional on the AS actually including iss in an authorization response, which requires driving an Authorization Code Grant against the AS under test; the authorization-server suite does not implement that yet.'
|
||||
issue: 'https://github.com/modelcontextprotocol/conformance/issues/208'
|
||||
- text: 'This validation applies equally to error responses - on mismatch the client MUST NOT act on or display error, error_description, or error_uri.'
|
||||
excluded: 'display is UI-facing; act-on has no protocol-observable signal beyond the existing reject-on-mismatch checks'
|
||||
|
|
|
|||
Loading…
Reference in a new issue