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

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 24 October 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

OAuth 2.0 Rich Authorization Requests [RFC9396] 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) [RFC9396] 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.¶

2. Intent-Based Authorization: The intent_request Type

   {
     "type": "intent_request",
     "intent": "Plan and book my business trip to the IETF meeting in Paris.",
     "constraints": {
       "max_budget": "2000",
       "currency": "EUR",
       "travel_class": "economy"
     }
   }

3. 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.¶

   {
     "assurance_level": "financial_grade_v1",
     "compliance_frameworks": ["pci-dss", "gdpr","iso27001"]
   }

   {
     "type": "task_status_webhook",
     "task_id": "job-d4a3b2-8c7e-4f5a-9b1c-2d3e4f5a6b7c",
     "termination_states": ["COMPLETED", "FAILED", "CANCELLED"]
   }

4. Example Authorization Request

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

"authorization_details": [
  {
    "type": "intent_request",
    "intent": "Plan and book my business trip to the IETF meeting in Paris.",
    "constraints": {
      "max_budget": "2000",
      "currency": "EUR"
    },
    "policy_context": {
      "assurance_level": "financial_transaction_v2",
      "compliance_frameworks": ["gdpr"]
    },
    "lifecycle_binding": {
      "type": "task_status_webhook",
      "task_id": "trip-planning-job-a1b2c3",
      "termination_states": ["COMPLETED", "CANCELLED_BY_USER"]
    }
  }
]

• 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.¶

5. Authorization Server Metadata

This specification adds the following parameters to the OAuth Authorization Server Metadata [RFC8414].¶

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.¶

6. 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.¶

7. 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.¶

8. IANA Considerations

9. Acknowledgements

This document based on RFC9396¶

10. References

Authors' Addresses