MCP Gateway expected to get an Access Token, use token claims (sub, amr, acr,...)
For NHI, issue token to Agent - negociated with Client Creds, SPIFFE,...
Discuss semantics of Actions vs resource
Vladi - multiple lvls of AuthZ, Tool level, MCP Server level, fine-grained level
Martin - We can have multiple PEPs: underlying API layer, Gateway, MCP Server. All options are possible. Coarse-grained control easy at the Gtwy lvl (or MCP Server) - Fine-grained authZ could be implemented at the Gtway level. AuthZen gives you the option to have different PEPs.
David H - We should not issue tokens to Agents. How does this interop with OAuth principles, scopes and RAR types. Let's not repeat here what's already been done within those other standards.
Martin - the MCP client must send an access token, whatever is contains.
David H - API dev use scopes. Should we restrict access earlier, before even issuing tokens. More logic at the authorization endpoint. At the AS layer - role of the As and Token Issuance. We should be opinionated about how scopes must be used.
Martin - believes we're not breaking anything. Same idea as API Gateway.
David H - 2 authZ: Client & Subject, let's make it clear how these things work together. Enforcement could be done at the AS level and not issue token if possible. Best practices should be communicated. Agents should explicitly state which tools they access - registration. Eg banking: this is an Agent for this product type.
Vladi: need to define best practices
David H - Least privilege
AlexB - How?
Vladi - Where to enforce it?
Dave H - as early as possible.
Dave H -Define Entitlement, discover that earlier. vs resource detailed to be determined at the resource level. Agent registration - KYA
To be continued next week...
Atul's MCP proposal
How to generated the context for the AuthZEN call ? --. let the LLM tdo the mapping
Access decisions are goiong to be much more dynamic than what OAuth can do.
COAZ = "Compatible with AuthZEN" ("cosy")
Provide a mapping, let the client LLM construct the call.
during tools/list call, server specifies if the tool is coaz compatible + provide a coa mapping
Action defaults to the tool name (like Martin's proposal), but can be overwritten.
PR Comments in Github
MCP Server can be aware, but the Gway can do the mapping itself and return it to the client.
Can be combined with Martin's proposal. The idea was to have a generic mapping
Julio: can we have several mappings, e.g., customers -> mapping 1, others ?
Atul: MCP doesn't enable several input params, but the structure could be amended.
Julio: property in the Resource that identifies MCP Server?
TODO: Combine both specs
Actions
From last week
AlexB - revive the use case doc
Atul - create proposal of MCP profile - done
AlexO - split up the certification spec into core and core+