Policy, Lifecycle, and Intent Extensions for OAuth Rich Authorization Requests

Introduction OAuth 2.0 Rich Authorization Requests significantly enhances the expressive power of authorization requests beyond simple string- based scopes. This enables clients, such as sophisticated AI agents, to articulate their needs with greater precision. The OAuth 2.0 Rich Authorization Requests (RAR) framework provides a vital, standardized syntax for clients to request structured, fine-grained permissions. This moves beyond the limitations of simple string-based scopes. However, as automated systems and AI-driven agents become more prevalent, their authorization requirements introduce new complexities that the current RAR standard does not explicitly address. This document identifies three such challenges: Goal-Oriented Authorization: Complex clients, such as coordinator agents, often operate based on a high-level user goal (e.g., "book a trip") rather than a pre-defined set of API permissions. The initial authorization request needs a way to seek consent for the overall intent, which is subsequently decomposed into specific actions. This creates an "intent-to-permission gap" in the protocol. Policy Assurance Mismatch: A client might request a high-risk action (e.g., a payment), but the authorization server (AS) might evaluate this request against a default, low-assurance security policy (e.g., one not requiring multi-factor authentication). This ambiguity can be exploited in "policy downgrade" attacks. The protocol lacks a mechanism for a client to assert the required security posture for a given request. Over-privileged Token Lifetime: For long-running, automated tasks, access tokens with a fixed expiration time (exp claim) violate the principle of least privilege. If the task finishes early or is cancelled, the token remains valid, creating an unnecessary window of risk. The authorization grant's validity should ideally be coupled to the task's actual lifecycle. To address these challenges, this document extends RAR in two primary ways: It introduces a new authorization_details type, intent_request, to allow clients to request authorization for a high-level goal. It introduces two new parameters, policy_context and lifecycle_binding, which can be included within any authorization_details object to provide essential context about security requirements and validity constraints. This specification addresses these gaps by extending the RAR framework to include explicit policy context and lifecycle binding information within the authorization request itself.

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. This document uses the terms "Authorization Server" (AS), "Client", "Resource Server" (RS), and "Access Token" as defined in The OAuth 2.0 Authorization Framework . The term "authorization_details" is used as defined in Rich Authorization Requests .

Intent-Based Authorization: The intent_request Type

The intent_request Authorization Details Type This specification defines a new value, intent_request, for the type member of the authorization_details object. This type allows a client to seek authorization for a high-level user goal, which the AS can then use as a basis for issuing more specific, fine-grained authorizations at a later stage.

Object Structure When the type member has a value of intent_request, the object has the following members:

intent (string, REQUIRED): A human-readable, textual description of the user's goal. This value is intended for display on user consent screens and for auditing purposes.
constraints (object, OPTIONAL): A JSON object containing structured, machine-readable parameters that define the boundaries of the intent. The structure and semantics of these parameters are specific to the intent and are to be defined by the ecosystem or the AS.

for example

Authorization Flow and The Role of Token Exchange The intent_request flow is typically a two-stage process: Initial Intent Authorization: The client makes an authorization request including an authorization_details object of type intent_request. The AS authenticates the user and presents the intent and a summary of the constraints for consent. If the user approves, the AS issues an authorization grant (and subsequently, an access token) that represents the approved intent. This initial "intent token" MAY NOT be audience-restricted to any specific resource server and may have limited usability on its own. Just-in-Time Permission Issuance: As the client decomposes the intent into concrete sub-tasks, it uses the "intent token" to request task-specific access tokens. This is accomplished via the Token Exchange grant type [RFC8693]. The client presents the "intent token" as the subject_token and includes a new authorization_details parameter in the request, specifying the fine-grained permissions needed for the sub-task. The AS is responsible for validating that the requested permissions are a legitimate and safe decomposition of the originally consented intent.

Contextual Parameters for Authorization Details This specification defines two new JSON object members, policy_context and lifecycle_binding, that can be included in any authorization_details object, including intent_request.

The "policy_context" Parameter This specification defines a new JSON object member, "policy_context", for the "authorization_details" object. This member allows a client to request that the authorization decision be evaluated under a specific set of policy constraints and assurance levels.

Structure of the "policy_context" Object The "policy_context" member, A JSON object containing members that provide context for the policy decision.

assurance_level (string): An identifier for a desired policy assurance level (e.g., "financial_grade_v1"), which MUST be a value supported and advertised by the AS.
compliance_frameworks (array of strings): Identifiers for specific compliance frameworks (e.g., "gdpr") that the operation must adhere to.

AS Processing: When present, the AS MUST validate the requested context against its supported policies. It SHOULD present the implications of the policy (e.g., "This requires multi-factor authentication") to the user during consent. If granted, the AS SHOULD include the validated policy_context in the authorization_details claim of the resulting JWT access token.

The "lifecycle_binding" Parameter This specification defines another new JSON object member, "lifecycle_binding", for the "authorization_details" object. This member ties the authorization's validity to the lifecycle of an external entity.

Structure of the "lifecycle_binding" Object The "lifecycle_binding" member, A JSON object defining the binding mechanism. The "type" member indicates the mechanism by which the AS can monitor the external entity's state. The "task_status_webhook" type indicates that the external task provider will notify the AS of terminal state changes via a pre-configured webhook. The object MUST also contain:

"task_id" (string): A unique identifier for the task.
"termination_states" (array of strings): A list of states that, once the task enters, will trigger the immediate revocation of the associated authorization.

AS Processing: The AS MUST be capable of monitoring the entity's state via the specified mechanism. It MUST record the link between the task_id and the issued authorization grant. Upon notification of a terminal state, the AS MUST immediately revoke the grant and all associated tokens. Resource Server Responsibilities: An RS receiving a token with a lifecycle_binding claim MUST NOT rely solely on the exp claim. It MUST use a real-time validation method, such as token introspection or a revocation feed, to ensure the token has not been revoked due to a lifecycle event.

Example Authorization Request The following example demonstrates a coordinator agent requesting authorization for a user's travel planning intent, utilizing all three extensions.

intent_request: The client asks for approval of the high-level goal.
policy_context: It asserts that all subsequent actions derived from this intent (like payments) must be processed under a high-assurance financial policy.
lifecycle_binding: It ensures that once the planning task is complete or cancelled, all associated permissions are automatically revoked.

Authorization Server Metadata This specification adds the following parameters to the OAuth Authorization Server Metadata . 1.policy_assurance_levels_supported: OPTIONAL. A JSON array of objects, where each object represents a supported assurance level. Each object has the following members:

"level" (string): A structured identifier for the assurance level (e.g., "nist_ial2"). REQUIRED.
"description" (string): A human-readable description. OPTIONAL.
"uri" (string): A URI pointing to the detailed definition of the level. OPTIONAL.

2.policy_compliance_frameworks_supported: OPTIONAL. A JSON array of strings containing the compliance framework identifiers supported by the AS.

Error Response When a request is denied due to a failure in validating the "policy_context", the AS returns an error response with the following error code: Error Code: policy_requirement_not_met Description: The requested "policy_context" is not supported or cannot be satisfied. The AS SHOULD include an "error_description" parameter to provide developers with more details about the failure.

Security Considerations Intent-to-Permission Escalation: The intent_request type shifts significant responsibility to the AS's policy engine. A primary threat is a client using a broadly-phrased intent to acquire excessive or unrelated permissions via subsequent token exchanges. The AS MUST implement a strict and carefully designed policy engine to govern this decomposition. The constraints provided in the initial request MUST be treated as strict, non-negotiable boundaries. Preventing Policy Downgrade Attacks: The "policy_context" member allows the AS to enforce that high-risk actions are always requested with a corresponding high-assurance policy context. The AS MUST reject requests where this mapping is violated, thus preventing a client from obtaining a privileged token under weak security pretenses. Ensuring Timely Revocation: The "lifecycle_binding" member significantly reduces the risk window of compromised tokens for long-running tasks. The effectiveness of this mechanism is entirely dependent on the reliability of the state notification and revocation propagation systems. Implementations MUST include robust error handling and fallbacks. The token's "exp" claim serves as an essential fallback mechanism. User Consent and Transparency: The structured nature of these new members allows the AS to present a far more intelligible and accurate consent screen to the user, leading to more meaningful and informed authorization decisions. Reliability of External State Monitoring: The AS must trust the source of the lifecycle events (e.g., the task provider's webhook). Mechanisms such as mutual TLS authentication and request signing SHOULD be used to secure the communication channel for state updates.

IANA Considerations

OAuth Authorization Server Metadata This specification requests the registration of the following values in the "OAuth Authorization Server Metadata" registry:

policy_assurance_levels_supported
policy_compliance_frameworks_supported

OAuth Extensions Error Registry This specification requests the registration of the following value in the "OAuth Extensions Error Registry":

Error Code: policy_requirement_not_met

Acknowledgements This document based on RFC9396