OAuth 2.0 Agent Authorization Explicit Revocation

Introduction RFC 7009 defines the standard OAuth 2.0 token revocation flow, which operates at the granularity of individual tokens (access tokens or refresh tokens). This design works well in traditional client-server architectures but reveals significant limitations in emerging scenarios:

Agent Networks: Multiple agent proxies form delegation chains through authorization topology
Autonomous Systems: Agents can dynamically generate sub-agents and distribute permissions
Cross-Domain Collaboration: Agents migrate across different trust domains In these scenarios, revoking access for an upstream agent typically requires simultaneously revoking all its delegated sub-agents. RFC 7009 lacks mechanisms to support such cascade revocation.

Existing RFC 7009 exhibits the following core deficiencies:

Single Granularity: Supports only per-token revocation, cannot batch process by agent ID
No Cascade Propagation: After upstream agent revocation, downstream sub-agent tokens remain valid
Insufficient Response Information: 200 OK status does not provide revocation confirmation, execution results, or failure details
No Audit Context: Cannot convey revocation reasons, operator identity, or other critical audit information
No Event Notification: No standard mechanism to notify relevant parties (e.g., resource servers, downstream agents) of token status changes
Missing Conditional Revocation: Does not support suspension, partial permission revocation, or other fine-grained policies

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119. Readers are expected to be familiar with the terms and concepts described in the core OAuth 2.0 Framework and .

Agent Revocation Endpoint

Endpoint Definition To support agent-based explicit revocation, a new endpoint is defined: This endpoint accepts a JSON request body containing the revocation target, reason, and propagation strategy.

Request Format The request MUST include the following parameters:

Metadata Field	Type	Required	Description
`agent_id`	String	Yes	Identifier of the agent to be revoked.
`reason`	Object	Yes	Revocation reason, containing code and description.
`cascade_depth`	integer	Yes	Cascade depth, -1 for unlimited, 0 for this agent only.
`context`	Object	Recommended	Operation context including operator, source_ip, request_id.

Status Parameters:

Parameter	Type	Required	Description
`revoke_all_tokens`	boolean	No	Whether to revoke all tokens for this agent, default true.
`revoke_for_duration`	integer	No	Temporary suspension duration in seconds, absent means permanent.
`revoke_scopes`	array	No	List of scopes to be removed.
`retain_scopes`	array	No	List of scopes to be retained.

Example Requst:

Response Format The server MUST return a JSON response containing execution status and detailed statistics. Example Successful Response (HTTP 200): Example Failure Response (HTTP 400) Response Status Codes

HTTP Status	Description
`200 OK`	Revocation completed successfully
`400 Bad Request`	Invalid request parameters (e.g., missing required fields, malformed agent_id)
`401 Unauthorized`	Missing or invalid authentication credentials
`403 Forbidden`	Authenticated client lacks permission to revoke the specified agent
`404 Not Found`	Agent ID not recognized
`409 Conflict`	Revocation conflicts with an existing operation (e.g., partial revocation already in progress)
`429 Too Many Requests`	Rate limit exceeded
`500 Internal Server Error`	Unexpected server error

Security Considerations The agent revocation endpoint introduces significant capabilities and, consequently, significant security risks if not properly secured. Its misuse can lead to widespread service disruptions. Implementers MUST address the following points.

Strict Authorization: The ability to revoke an agent's access is a highly privileged operation. Authorization servers MUST enforce strict access control, for example, by requiring a specific OAuth 2.0 scope (e.g., agent.revoke). Policies MUST also ensure a client can only revoke agents it is authorized to manage (e.g., based on ownership or hierarchy), and MUST NOT be able to revoke arbitrary agents. Critical system agents SHOULD have additional protections, such as requiring multi-party approval before revocation.
Denial of Service (DoS) Mitigation: The cascade_depth parameter can be used as an amplification vector for DoS attacks. A single request could trigger a massive, resource-intensive operation. Servers MUST implement rate limiting on this endpoint. It is also RECOMMENDED that servers enforce a configurable maximum cascade_depth and process large-scale revocations asynchronously to prevent server overload.
Information Disclosure: The detailed response, particularly the affected_agents list, could leak the internal structure of an agent hierarchy to an unauthorized party. The server MUST filter the response to ensure it only contains information that the requesting client is permitted to see.
Auditing and Non-Repudiation: All revocation attempts, whether successful or failed, MUST be logged in a secure, tamper-evident audit trail. These logs are critical for forensic analysis and holding operators accountable. The context object in the request is intended to facilitate this.
Transport Security: As with all OAuth 2.0 endpoints, communication between the client and the agent revocation endpoint MUST be protected using Transport Layer Security (TLS) to ensure confidentiality and integrity.

IANA Considerations TBD

Acknowledgements This document based on RFC7009