The four-predicate list is the right unit of standardization, and I want to name what it implies for where the write-up lands.
Each mechanism in this thread is correct about its own layer. RAR is correct that the AS can carry an act-specific authority object when concrete intent exists before the call; RFC 9396 was built for that. The transaction-token work is correct that tctx and agentic context must propagate so downstream services authorize the same act rather than a mutated one. The AIC work is correct that bounds must be principal-signed and verifiable independently of the model emission, and the v1.1.0 matrix now separates tool-identity denial from argument-subset denial cleanly. The mission and mandate work are correct that the independent authority source must be something the model cannot write, durable approved intent in one case and verifiable evidence of human approval in the other. And the boundary rule stated here, the first point whose successful admission is necessary for the effect, plus the per-path closure test, is the correct enforcement semantics. What the write-up should not do is bind those predicates to any one carrier. The predicate set and the evidence claims that satisfy it are the interoperable surface. The carrier is deployment-shaped: authorization_details at the AS, tctx on the chain, a capability certificate at a gateway, a host-local check at a function table. The MCP authorization spec already forces this conclusion. An MCP server is an ordinary OAuth resource server, but the host's in-process dispatch never crosses a resource server, so a predicate welded to one carrier or one component fails the closure test on the other path by construction. The phrase already on the record is the one to keep normative: the boundary is a role in the effectuation path, not a component identity. Specify the claim semantics and the closure test, list each mechanism as one conforming carrier, and the five drafts compose instead of competing. Kieran Sweeney
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
