You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Feat]: Add a PermissionDenied server error with HTTP 403 and gRPC PERMISSION_DENIED mappings #1410
Please expose a server-side PermissionDeniedError (or equivalent generic authorization error) with consistent transport mappings. With a2a-sdk==1.3.0, a2a.utils.errors has no authorization-denial type and A2A_ERROR_MAPPING has no HTTP 403 / gRPC PERMISSION_DENIED mapping.
Why this is needed
An authenticated client can lack the action permission to list or cancel tasks even though the agent supports the operation and the task is still cancelable. Raising UnsupportedOperationError or TaskNotCancelableError misrepresents the failure and can cause a client to cache the wrong capability or lifecycle conclusion.
A2A v1.0.1 §3.3.2 requires authorization errors for insufficient permissions. It gives HTTP 403, gRPC PERMISSION_DENIED and a JSON-RPC custom error as examples. Resource hiding remains a separate concern: inaccessible or nonexistent task IDs should still be indistinguishable via TaskNotFound where appropriate.
This passes with 1.3.0. A handler wishing to deny an authenticated caller's ListTasks or CancelTask action cannot raise a built-in exception with the required authorization semantics.
Requested behavior
A public server exception representing an action-policy denial.
HTTP/REST 403 and gRPC PERMISSION_DENIED mappings.
An SDK-owned JSON-RPC custom error mapping (rather than applications inventing conflicting numeric codes).
Structured google.rpc.ErrorInfo with a documented stable reason such as PERMISSION_DENIED, plus optional bounded missing-scope information.
Client-side reconstruction and transport regression tests.
Documentation distinguishing action denial from resource existence hiding, unsupported operations, and noncancelable lifecycle states.
Our HTTP teaching lab now authorizes in identity middleware and returns HTTP 403 before dispatch, which works around the HTTP gap. A shared handler-level exception would make this practical across JSON-RPC, HTTP+JSON and gRPC without separate application mappings.
I searched for PermissionDenied, PERMISSION_DENIED, and authorization-error reports before filing; this request is scoped to the missing public server error/mappings in 1.3.0.
Activity