-
Notifications
You must be signed in to change notification settings - Fork 762
(spec) Primitive authorization #850
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
One of the interesting discussion points from @wdawson and @nbarbettini is whether this belongs at protocol-level or SDK level. I stronly agree that the |
IMO, this proposal can be analogous to SecuritySchemas in the OpenAPI definition. |
When an MCP client invokes discovery operations (such as `tools/list`, `resources/list`, | ||
`prompts/list`, or `roots/list`), the server **MUST**: | ||
|
||
1. Extract authorization context from the request (e.g., `Authorization` header) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This implies that the initial token that is presented for discovery needs to carry all the authorizations for the user/app interacting at the given time, breaking the rule of just-enough privileges. In an agentic setup, primitive access is dynamic based on the reasoning at the host. Better if the discovery is orthogonal to authorization evaluation at the primitive level.
|
||
### Policy Engine Flexibility | ||
|
||
The authorization framework is designed to be policy engine-agnostic. Servers **MAY** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with this goal but its not clear to me how this works. Is the authorization
field in the JSON example above just an opaque blob that can contain any values?
}, | ||
"authorization": { | ||
"allowed_roles": ["admin", "contributor", "manager"], | ||
"allowed_scopes": ["files:write", "workspace:modify"], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This only support an "OR" logic, so that brings the question of how to support "AND" ?🙂
For reference, OpenAPI support both (even if their syntax is not very explicit, in my opinion).
If we want to support both, we could either reuse a similar syntax and come up with a more explicit one.
For example we could reuse JSON Schema's anyOf
/allOf
.
- OR syntax:
"authorization": {
"required_scope": {"anyOf": ["files:write", "workspace:modify"]},
}
- AND syntax:
"authorization": {
"required_scope": {"allOf": ["files:write", "workspace:modify"]},
}
- single scope syntax:
"authorization": {
"required_scope": "files:write",
}
This could be done similarly for roles.
Working draft for a pull request that tackles primitive authorization, as discussed in a Google doc. This work is complementary to #475.
Warning
This is a draft, therefore this description may be incomplete or inaccurate until the PR goes into review.