@sberyozkin - if I understand this proposal correctly, your proposing a model in which the OAuth interactions are handled by the HTTP Server, and the Access Tokens are given to the MCP client, rather than having the MCP client obtain the access tokens from the OAuth server directly?

If that is the case, I think what your proposing here is not anything new in the context of OAuth or how authorizations is done, but rather an architectural change to MCP that separates out the OAuth Client from the MCP Client. To me this feels a bit like an implementation detail, at least from an interop perspective.

Can you expand a little on why it is necessary to formalise this separation between the OAuth client (the HTTP server in your case) and the MCP Client, rather than just treating it as an implementation detail?

@PieterKas Thanks for having a look at this proposal,

If that is the case, I think what your proposing here is not anything new in the context of OAuth

Indeed, you are right

Can you expand a little on why it is necessary to formalise this separation between the OAuth client (the HTTP server in your case) and the MCP Client, rather than just treating it as an implementation detail?

We've seen some concerns that an HTTP server software that uses MCP client to access protected MCP servers with access tokens is not compliant with the main MCP Authorization specification, it can be problematic when a standard compliance is a must, and when convincing that it is an implementation detail is not easy.

I hope it can give OAuth2 aware HTTP server applications that use MCP clients internally an option to claim a compliance with this extension, and make it clearer to their users that MCP client plays a different role in the main and this extension authorization specifications.

The other thing is that with traditional HTTP applications that require OAuth2 logins, using a scope redirect parameter is a typical mechanism for requesting extra access token capabilities. I like the main Authorization spec's focus on a resource parameter to support protected MCP server invocations. This extension attempts to keep the resource parameter requirement in sync with the main specification, and might encourage existing HTTP server applications move to supporting a resource parameter faster.

I also have a RAR addition in mind where authorization_details might, for example, list not only a specific MCP server resource URL but also a specific tool, but if RAR does get adopted, it should probably start from the main specification.