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 TBD

IANA Considerations TBD

Acknowledgements This document based on RFC7009