Repository navigation
chore: Add requirement for RFC8707 - #734
localden merged 15 commits into
Conversation
Sorry, something went wrong.
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). |
There was a problem hiding this comment.
Do we need to list these or should we just refer to RFC 8707.
Sorry, something went wrong.
There was a problem hiding this comment.
@dsp-ant IMO these are helpful to list explicitly as guidance for implementers.
Sorry, something went wrong.
There was a problem hiding this comment.
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.
Sorry, something went wrong.
pcarleton
left a comment
There was a problem hiding this comment.
overall lgtm.
left a few optional tweaks.
Sorry, something went wrong.
| [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). |
There was a problem hiding this comment.
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.
Sorry, something went wrong.
| - `https://mcp.example.com` | ||
| - `https://mcp.example.com:8443` | ||
| - `https://mcp.example.com/server` (when path component is necessary to identify individual MCP server) |
There was a problem hiding this comment.
| - `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.
Sorry, something went wrong.
|
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 |
Sorry, something went wrong.
Related to #544