Skip to content

Conversation

@localden
Copy link
Contributor

Related to #544

Co-authored-by: Aaron Parecki <aaron@parecki.com>
[RFC 8707 Section 2](https://www.rfc-editor.org/rfc/rfc8707.html#section-2) and aligns with the `resource` parameter in
[RFC 9728](https://datatracker.ietf.org/doc/html/rfc9728). This URI:

1. **MUST** be an absolute URI, as specified by [Section 4.3 of RFC 3986](https://www.rfc-editor.org/rfc/rfc3986#section-4.3).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to list these or should we just refer to RFC 8707.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dsp-ant IMO these are helpful to list explicitly as guidance for implementers.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find the examples useful, this list slightly less so since I ended up bringing up 8707 to see if there was a diff. I'm inclined to remove it to keep it brief.

Copy link
Member

@pcarleton pcarleton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

overall lgtm.

left a few optional tweaks.

[RFC 8707 Section 2](https://www.rfc-editor.org/rfc/rfc8707.html#section-2) and aligns with the `resource` parameter in
[RFC 9728](https://datatracker.ietf.org/doc/html/rfc9728). This URI:

1. **MUST** be an absolute URI, as specified by [Section 4.3 of RFC 3986](https://www.rfc-editor.org/rfc/rfc3986#section-4.3).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find the examples useful, this list slightly less so since I ended up bringing up 8707 to see if there was a diff. I'm inclined to remove it to keep it brief.

Comment on lines +221 to +223
- `https://mcp.example.com`
- `https://mcp.example.com:8443`
- `https://mcp.example.com/server` (when path component is necessary to identify individual MCP server)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- `https://mcp.example.com`
- `https://mcp.example.com:8443`
- `https://mcp.example.com/server` (when path component is necessary to identify individual MCP server)
- `https://mcp.example.com/mcp`
- `https://mcp.example.com`
- `https://mcp.example.com:8443`
- `https://mcp.example.com/server/mcp` (when path component is necessary to identify individual MCP server)

wydt about this? I want to make it clear that passing the "server URL" is completely valid, like the one people would likely pass into a client.

@localden localden merged commit 20a951a into main Jun 16, 2025
7 checks passed
@localden localden deleted the localden/rfc8707 branch June 16, 2025 20:15
@github-project-automation github-project-automation bot moved this from In Review to Approved in Standards Track Jun 16, 2025
@mcguinness
Copy link

Requiring the client to pass the resource indicator is necessary but not sufficient for mitigating phishing attacks as the client has no way of knowing that an discovered Authorization Server successfully processed the resource indicator or not. Many authorization servers today will silently ignore a resource param. RFC 8707 does not provide any token response parameters (e.g audience) or authorization server metadata params to enable a client to detect whether an AS will process a resource request or return an invalid_state error.

See #284 (comment)) and oauth-wg/oauth-v2-1#215

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

No open projects
Status: Approved

Development

Successfully merging this pull request may close these issues.

7 participants