-
Notifications
You must be signed in to change notification settings - Fork 9
Open
Description
Overview
Add conformance tests for OAuth Resource Indicators (RFC 8707) implementation, ensuring clients correctly specify target resources and use canonical server URIs.
Specification References
- Resource Parameter Implementation
- Canonical Server URI
- Protected Resource Metadata Discovery Requirements
- RFC 8707 - Resource Indicators for OAuth 2.0
- RFC 9728 Section 3 - Protected Resource Metadata
Key Requirements from Specification
Resource Parameter (MUST)
- Clients MUST implement Resource Indicators per RFC 8707
resourceparameter MUST be included in both authorization and token requestsresourceparameter MUST identify the MCP server the client intends to use the token withresourceparameter MUST use the canonical URI of the MCP server- Clients MUST send this parameter regardless of whether authorization servers support it
Canonical Server URI (SHOULD)
- Clients SHOULD provide the most specific URI for the MCP server
- Canonical form uses lowercase scheme and host components
- Implementations SHOULD accept uppercase scheme/host for robustness
Resource Identifier Options
The resource identifier can be either:
- The full MCP request URL (e.g.,
https://mcp.example.com/public/mcp) - The base URL (e.g.,
https://mcp.example.com)
This aligns with the resource parameter in RFC 9728 and the Protected Resource Metadata discovery requirements.
Valid Canonical URI Examples
https://mcp.example.com/mcphttps://mcp.example.comhttps://mcp.example.com:8443https://mcp.example.com/server/mcp
Invalid Canonical URI Examples
mcp.example.com(missing scheme)https://mcp.example.com#fragment(contains fragment)
URI Trailing Slash
- Both
https://mcp.example.com/andhttps://mcp.example.comare valid - Implementations SHOULD consistently use form without trailing slash unless semantically significant
Scenarios to Cover
Positive Tests
- Client includes
resourceparameter in authorization request - Client includes
resourceparameter in token request - Client uses correct canonical URI format (full MCP request URL)
- Client uses correct canonical URI format (base URL)
- Client handles URIs with port numbers correctly
- Client handles URIs with path components correctly
- Client normalizes scheme and host to lowercase
Negative Tests
- Client omits
resourceparameter from authorization request - Client omits
resourceparameter from token request - Client uses invalid URI (missing scheme)
- Client uses invalid URI (contains fragment)
- Client uses inconsistent URIs between requests
- Client fails to normalize canonical URI properly
Implementation Notes
- Register spec references in src/scenarios/client/auth/spec-references.ts
- Build on existing auth scenarios in
src/scenarios/client/auth/ - Follow patterns from
basic-dcr.tsandbasic-metadata.ts - Include at least one negative test scenario per requirement
- Test both full URL and base URL as resource identifiers
Acceptance Criteria
- Test scenarios cover resource parameter implementation per spec
- Test scenarios cover canonical server URI requirements
- Tests validate resource parameter presence in both authorization and token requests
- Tests verify correct URI format and normalization
- Tests cover both full MCP request URL and base URL as resource identifiers
- At least one negative test included for each major requirement
- Spec references registered in check definitions file
- All checks properly documented and follow existing patterns
Metadata
Metadata
Assignees
Labels
No labels