AI Agent Authorization Integration Framework

1.1. Requirements Language

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] [RFC8174] when, and only when, they appear in all capitals.¶

1.2. Component Specifications

This framework integrates the following specifications. The first two (Agent Authentication and Identity Assertion Grant) are external OAuth Working Group specifications that this framework profiles. The remaining four are companion specifications developed alongside this framework:¶

2.1. Policy as Primary Authorization Mechanism

In this framework, the primary authorization mechanism is policy carried via Rich Authorization Requests (RAR, [RFC9396]), not OAuth 2.0 scopes. The rego_policy authorization data type defined in [I-D.liu-oauth-rego-policy] carries the authorization logic within the authorization_details parameter:¶

• Authorization Request: Clients submit authorization_details containing a rego_policy type with Rego policy that defines permitted operations (e.g., "allow add_to_cart if amount <= 50").¶
• Access Token: AS returns an enriched authorization_details response per RFC 9396 Section 7.1, including the evaluated policy reference.¶
• Resource Server: RS evaluates the policy at runtime using a Rego-compatible policy engine (e.g., Open Policy Agent [OPA]) with request context.¶

This approach enables dynamic, context-aware authorization that goes beyond static scope lists.¶

2.2. Scope as Optional Supplement

Traditional OAuth 2.0 scope parameter is OPTIONAL in this framework and serves different purposes:¶

• When to use scope: For coarse-grained resource categorization (e.g., "read", "write") or backward compatibility with existing OAuth deployments.¶
• When NOT to use scope: When fine-grained, conditional authorization is required. In this case, Rego policy provides all necessary authorization logic.¶
• Relationship: If both scope and policy are present, the policy takes precedence. Scope acts as an outer boundary, while policy defines specific conditions.¶

+-----------------------------------------------------------+
|  Authorization Boundary                                   |
+-----------------------------------------------------------+
|  +-----------------------------------------------------+  |
|  |  Scope (Traditional OAuth)                          |  |
|  |  +-----------------------------------------------+  |  |
|  |  |  Policy via RAR (Primary)                     |  |  |
|  |  |  authorization_details: rego_policy           |  |  |
|  |  |  "allow if amount <= 50 AND time < 6pm"       |  |  |
|  |  +-----------------------------------------------+  |  |
|  +-----------------------------------------------------+  |
+-----------------------------------------------------------+

2.3. Complete Authorization Mechanism

The complete authorization mechanism comprises six integrated components:¶

1. Agent Authentication ([I-D.ietf-oauth-spiffe-client-auth]): Proves "who the agent is" through cryptographic workload identity.¶
2. Cross-Domain Identity ([I-D.ietf-oauth-identity-assertion-authz-grant]): Proves "who the user is" across trust domains via JWT assertion.¶
3. User Interaction & Consent ([I-D.parecki-oauth-jwt-grant-interaction-response]): Obtains explicit user consent through structured interaction flow.¶
4. Rego Policy ([I-D.liu-oauth-rego-policy]): Defines "what operations are allowed" with fine-grained conditions.¶
5. Authorization Evidence ([I-D.liu-oauth-authorization-evidence]): Provides cryptographic proof of "what the user agreed to".¶
6. Chain Delegation ([I-D.liu-oauth-chain-delegation]): Enables secure "agent-to-agent transfer" of authorization.¶

Together, these components provide end-to-end authorization for AI agents:¶

+------------------------------------------------------------+
|  Integration Framework (This Draft)                        |
|  "How to combine all components"                           |
+------------------------------------------------------------+
|  +------------+ +------------+ +------------+ +----------+  |
|  |  Agent     | |  Identity  | |  Consent   | | Delegat. |  |
|  |  Authn     | |  (ID-JAG)  | |  (JAG-IR)  | | (Chain)  |  |
|  | (SPIFFE)   | +------------+ +------------+ +----------+  |
|  +------------+                                             |
|  +------------------------------------------------------+  |
|  |     Policy Engine via RAR (rego_policy)              |  |
|  |         "Under what conditions allow"                |  |
|  +------------------------------------------------------+  |
|  +------------------------------------------------------+  |
|  |     Authorization Evidence (consent + audit trail)   |  |
|  |         "What did the user agree to"                 |  |
|  +------------------------------------------------------+  |
+------------------------------------------------------------+
|        OAuth 2.0 Core + RAR (RFC 9396)                     |
+------------------------------------------------------------+

3.1. Participants

+------------------+     +------------------+     +------------------+
|    Home IdP      |     |   AI Agent       |     |   External AS    |
|                  |     |                  |     |                  |
| - User authn     |     | - SPIFFE identity|     | - Policy engine  |
| - ID Token issue |     | - JWT Grant clnt |     | - Token issuance |
+------------------+     +------------------+     +------------------+
        |                        |                        |
        |   ID Token             |                        |
        |----------------------->|                        |
        |                        |                        |
        |                        | JWT Grant + authz_det  |
        |                        |----------------------->|
        |                        |                        |
        |                        | interaction_required   |
        |                        |<-----------------------|
        |                        |                        |
        |  interaction_uri       |                        |
        |<-----------------------|                        |
        |  (user consent)        |                        |
        |----------------------->|                        |
        |                        | Poll token endpoint    |
        |                        |----------------------->|
        |                        |                        |
        |                        |   Access Token         |
        |                        |<-----------------------|
        |                        |                        |
        |                        |                  +-------------------+
        |                        |                  | Resource Server   |
        |                        |                  |                   |
        |                        |   API Request    | - Token validation|
        |                        |----------------->| - Policy engine   |
        |                        |                  +-------------------+

Home Identity Provider (Home IdP):

Authenticates the user and issues ID Tokens. This is the user's trusted identity service.¶

AI Agent:

An autonomous software agent acting on behalf of the user. Has its own workload identity (SPIFFE/WIT-SVID).¶

External Authorization Server (AS):

Issues access tokens for resources in its domain. Validates JWT assertions, evaluates authorization_details, and manages user interaction.¶

Resource Server (RS):

Hosts protected resources. Validates access tokens and enforces policies using a Rego-compatible policy engine.¶

3.2. Token Structure

The framework uses JWT access tokens ([RFC7519], [RFC9068]) following OAuth 2.0 standards. Key claim semantics:¶

• sub (Subject): MUST contain the user's identifier at the Resource Application (third-party app), NOT the Agent's internal user identifier. This enables the Resource Server to immediately identify the resource owner without additional identity mapping lookups. The AS maps the Home IdP subject to the resource-domain identifier through account linking, federation metadata, or additional identity claims (e.g., email) present in the JWT assertion.¶

• act (Actor): Identifies the entity exercising delegated authority. Contains:¶

  • sub: The Agent's WIT URI, identifying which agent is acting on behalf of the user;¶
  • agent_user_id (OPTIONAL): The user's identifier at the Agent system, enabling audit trail correlation at the Agent side. Note: This is a non-registered extension field within the act claim structure.¶

• authorization_details: Carries multiple authorization data types via Rich Authorization Requests ([RFC9396]):¶

  • rego_policy type: The Rego policy defining what operations the agent is permitted to perform. Defined in [I-D.liu-oauth-rego-policy].¶
  • authorization_evidence type: The signed record of the user's confirmation action during authorization, including what was displayed to the user, how the user confirmed, a cryptographic signature from the AS, and the audit_trail sub-object for semantic traceability. Defined in [I-D.liu-oauth-authorization-evidence].¶

• delegation_chain: Records the chain of delegation hops when authorization is transferred between agents, with cryptographic signatures for each hop. Only present in delegated scenarios. Defined in [I-D.liu-oauth-chain-delegation].¶

{
  "iss": "https://as.external.example",
  "sub": "user_12345",
  "aud": "https://api.external.example",
  "exp": 1731369540,
  "iat": 1731320700,
  "jti": "urn:uuid:token-abc-123",

  "act": {
    "sub": "wit://agent.example/sha256.abc123...",
    "agent_user_id": "agent_user_001"
  },

  "authorization_details": [
    {
      "type": "rego_policy",
      "policy": {
        "type": "rego",
        "uri": "https://as.external.example/policies/policy-abc123",
        "entry_point": "allow"
      },
      "context": {
        "user": { "id": "user_12345" },
        "action": "add_to_cart"
      }
    },
    {
      "type": "authorization_evidence",
      "evidence": {
        "id": "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6",
        "user_confirmation": {
          "displayed_content": "Add items under $50 to cart",
          "user_action": "confirmed_via_button_click",
          "timestamp": 1731320595
        },
        "as_signature": "eyJhbGciOiJFUzI1NiJ9..MEUCIQDx...",
        "audit_trail": {
          "evidence_ref": "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6",
          "semantic_expansion_level": "medium",
          "proposal_ref": "urn:uuid:proposal-xyz"
        }
      }
    }
  ],

  "delegation_chain": [
    {
      "delegator_id": "wit://agent-a.example/sha256.aaa111...",
      "delegatee_id": "wit://agent-b.example/sha256.bbb222...",
      "as_id": "https://as.external.example",
      "delegation_timestamp": 1731320800,
      "root_evidence_ref": "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6",
      "delegated_policy": {
        "type": "rego",
        "uri": "https://as.external.example/policies/policy-delegated-456",
        "entry_point": "allow"
      },
      "operation_summary": "Delegate cart operations",
      "delegator_signature": "eyJhbGciOiJFUzI1NiJ9..MEYCIQD...",
      "as_signature": "eyJhbGciOiJSUzI1NiJ9..MEUCIQDx..."
    }
  ]
}

4.1. Overview

+-------+    +-------+    +--------+    +---------+    +-------+    +------+
| User  |    | Home  |    |  AI    |    |External |    |  RS   |    |Policy|
|       |    |  IdP  |    | Agent  |    |   AS    |    |       |    |      |
+-------+    +-------+    +--------+    +---------+    +-------+    +------+
    |            |             |            |            |           |
(1) | Authn      |             |            |            |           |
    |----------->|             |            |            |           |
    |            |             |            |            |           |
(2) |  ID Token (aud=External AS)           |            |           |
    |<------------------------>|            |            |           |
    |            |             |            |            |           |
(3) |            |   Agent builds token req:|            |           |
    |            |   - JWT assertion        |            |           |
    |            |   - authorization_details|            |           |
    |            |     (rego_policy type)   |            |           |
    |            |             |            |            |           |
(4) |            |   Token Request          |            |           |
    |            |   + SPIFFE client auth   |            |           |
    |            |             |----------->|            |           |
    |            |             |            |            |           |
(5) |            |             |  Validate: |            |           |
    |            |             |  - SPIFFE  |            |           |
    |            |             |  - JWT     |            |           |
    |            |             |  - policy  |            |           |
    |            |             |            |            |           |
(6) |            |             |  interaction_required   |           |
    |            |             |  + interaction_uri      |           |
    |            |             |<-----------|            |           |
    |            |             |            |            |           |
(7) | User interaction via browser          |            |           |
    |<--------------------------------------|            |           |
    |            |             |            |            |           |
(8) | User confirms            |            |            |           |
    |-------------------------------------->|            |           |
    |            |             |            |            |           |
(9) |            |             |  Poll token endpoint    |           |
    |            |             |----------->|            |           |
    |            |             |            |            |           |
(10)|            |             |  Issue token with:      |           |
    |            |             |  - act                  |           |
    |            |             |  - authorization_details|           |
    |            |             |  - evidence             |           |
    |            |             |  - audit_trail          |           |
    |            |             |<-----------|            |           |
    |            |             |            |            |           |
(11)|            |             | API Request|            |           |
    |            |             |------------------------>|           |
    |            |             |            |            |           |
(12)|            |             |            |  Validate  |           |
    |            |             |            |  token     |           |
    |            |             |            |            |           |
(13)|            |             |            |  Policy    |           |
    |            |             |            |  eval      |---------->|
    |            |             |            |            |           |
(14)|            |             |            |  Decision  |           |
    |            |             |            |            |<----------|
    |            |             |            |            |           |
(15)|            |             | Response   |            |           |
    |            |             |<------------------------|           |

4.2. Step-by-Step Description

1. User Authentication at Agent: User authenticates with the Agent's Identity Provider (Home IdP). The Agent requests an ID Token suitable for cross-domain assertion, containing:¶

   • sub: The user's identifier at the Agent system (e.g., agent_user_001);¶
   • aud: The External AS's identifier, binding this assertion to the target authorization server per [I-D.ietf-oauth-identity-assertion-authz-grant].¶

2. ID Token as JWT Assertion: The Agent uses the ID Token as the JWT assertion in the token request per [I-D.ietf-oauth-identity-assertion-authz-grant]. The AS validates the Home IdP's signature and extracts the user's identity claims.¶

3. Token Request Construction: Agent builds a token request including:¶

   • grant_type: urn:ietf:params:oauth:grant-type:jwt-bearer;¶
   • assertion: The user's ID Token (JWT);¶
   • authorization_details: Containing rego_policy type with policy and context.¶

4. Token Request Submission: Agent sends the token request to External AS with SPIFFE client authentication (WIT-SVID in headers).¶

5. AS Validation: AS validates:¶

   • SPIFFE client credentials;¶
   • JWT assertion signature, audience (aud), and expiration (exp) from Home IdP;¶
   • Policy syntax and safety in authorization_details.¶

6. Interaction Required: AS determines user interaction is needed and returns an interaction_required error response per [I-D.parecki-oauth-jwt-grant-interaction-response] containing an interaction_uri for user consent.¶

7. User Interaction: The agent launches the interaction_uri in the user's browser. The AS presents the consent UI showing the interpreted operation.¶

8. User Confirmation: User reviews and approves (or denies) the operation.¶

9. Polling: Agent polls the token endpoint (re-sending its original request with a fresh SPIFFE client attestation) until the AS completes user interaction. If the user denies consent, the AS returns an access_denied error to subsequent polling requests.¶

10. Token Issuance: AS issues access token containing:¶

    • act: Agent's SPIFFE ID;¶
    • authorization_details: Enriched response per RFC 9396 Section 7.1, including both rego_policy and authorization_evidence types;¶
    • delegation_chain: (only in delegation scenarios).¶

11. API Request: Agent presents token to Resource Server.¶

12. Token Validation: RS validates token signature and claims.¶

13. Policy Evaluation: RS sends policy and request context to the policy engine.¶

14. Authorization Decision: Policy engine returns allow/deny decision.¶

15. Response: RS executes (or denies) the operation and returns response.¶

6.1. Redirect-Based Consent

Traditional OAuth redirect flow where the agent redirects the user to the AS's consent page. This is the most common consent mechanism and is suitable for web-based agents that can launch a browser for user interaction.¶

6.2. CIBA-Based Consent

Client-Initiated Backchannel Authentication (CIBA) [CIBA] for out-of-band consent, useful when the agent cannot redirect the user. Typical scenarios include voice assistants, IoT devices, and mobile applications where the user completes consent on a separate device.¶

6.3. Consent-Only Flow

When the user has a valid, non-expired session at the AS and the agent's identity is already trusted, the AS MAY skip re-authentication and only prompt for consent to the specific operation. This is a deployment-level optimization that does not change the protocol flow; the AS still returns an interaction_required response, but the consent interface presented to the user omits the authentication step. This mode reduces user friction for repeat operations while maintaining explicit consent for each authorized action.¶

9.1. Trust Boundaries

The framework establishes clear trust boundaries:¶

• Home IdP → Agent: ID Token with agent in audience;¶
• Agent → External AS: SPIFFE authentication + JWT assertion (Identity Assertion Grant, ID-JAG);¶
• External AS → RS: Signed access token with policy reference (JWS [RFC7515]);¶
• Delegation: AS-signed delegation chain entries.¶

9.2. Threat Mitigations

9.3. LLM Threat Model

This framework assumes the agent implementation (including authorization logic) is trusted, while the Large Language Model (LLM) used to derive operations is NOT trusted. The policy-based authorization ensures:¶

• LLM cannot directly control authorization decisions;¶
• All operations are bounded by user-approved policies;¶
• Audit trails enable post-hoc verification.¶

9.4. Token Size

A full access token in this framework may carry multiple claims beyond the standard JWT fields: act, authorization_details (with embedded Rego policy and authorization evidence), and delegation_chain (for multi-hop scenarios). The combined size of these claims can exceed typical HTTP header limits when the token is passed in an Authorization header.¶

Implementations SHOULD consider:¶

• Using token introspection ([RFC7662]) to retrieve detailed evidence and policy information rather than embedding all data in the token;¶
• Using policy references (URIs) instead of inline Rego policy in authorization_details;¶
• Applying the Reference strategy for evidence in token exchange scenarios, as defined in [I-D.liu-oauth-authorization-evidence].¶

9.5. Evidence Freshness

In this framework, evidence records capture user consent at a specific point in time. When tokens are exchanged or refreshed across delegation hops, the original consent timestamp may become significantly older than the current request time. Deployments SHOULD define an evidence freshness policy that specifies the maximum acceptable age of an evidence record and the actions to take when evidence is stale (e.g., reject the request, require re-consent). See [I-D.liu-oauth-authorization-evidence] for detailed guidance.¶

9.6. Policy Injection and Server-Side Request Forgery

When agents submit Rego policy via authorization_details, the AS must validate the policy before evaluation. Malicious or compromised agents could attempt to inject policies that exploit the policy engine (e.g., resource exhaustion, data exfiltration via external calls). The AS SHOULD enforce policy size limits, restrict available Rego built-in functions (particularly those that perform network I/O), and validate policy syntax before evaluation. See [I-D.liu-oauth-rego-policy] for the complete threat model and mitigation strategies.¶

9.7. Cross-Domain Trust

This framework operates across multiple trust domains (Home IdP, Agent domain, External AS, Resource Server). Trust establishment between these domains relies on:¶

• The External AS trusting the Home IdP's JWT assertions (ID-JAG), which requires either a pre-established trust relationship or federation;¶
• The Resource Server trusting the External AS's signing keys for both token validation and evidence signature verification;¶
• Cross-domain delegation requiring trust in each intermediate AS's signing key for delegation chain verification.¶

Deployments SHOULD establish explicit trust frameworks or federation agreements that define key distribution, revocation, and liability across participating domains.¶

9.8. Delegation Depth and Privilege Escalation

Multi-hop delegation chains introduce the risk of unbounded delegation depth and privilege escalation at intermediate hops. The framework mitigates these risks through:¶

• AS-enforced maximum delegation depth limits;¶
• Scope subset validation ensuring each delegation hop can only narrow (never broaden) the authorized scope;¶
• Cryptographic chain integrity via per-hop AS signatures in the delegation_chain claim.¶

See [I-D.liu-oauth-chain-delegation] for the complete delegation security model and validation checklist.¶

10.1. Cross-Domain Identity Correlation

This framework inherently links user identities across multiple trust domains: the Home IdP (where the user authenticates), the Agent domain (where the user interacts with the AI agent), and the External AS/RS domain (where resources are accessed). The act.agent_user_id field and the evidence record within the authorization_evidence authorization details type both carry identifiers that could be used to correlate a user's activities across these domains.¶

Implementations SHOULD minimize cross-domain correlation by:¶

• Using domain-specific subject identifiers in the access token's sub claim rather than globally unique identifiers;¶
• Treating agent_user_id as optional and including it only when required for audit correlation;¶
• Avoiding inclusion of stable, globally correlatable identifiers in the evidence record's displayed_content field.¶

10.2. Agent Observability

AI agents acting on behalf of users can observe resource contents, policy evaluation outcomes, and error responses (including reverse-guided authorization hints). A compromised or malicious agent could accumulate sensitive information about the user's access patterns, resource contents, and organizational policy structure.¶

Mitigations include:¶

• Applying the principle of least privilege to agent capabilities via Rego policy constraints;¶
• Using the semantic_expansion_level in the audit_trail sub-object to flag operations where significant interpretation was applied, enabling post-hoc review of agent behavior;¶
• Limiting the information exposed in reverse-guided authorization error responses to what is necessary for constructing a valid request.¶

10.3. Displayed Content Sensitivity

The displayed_content field in the evidence record (within the authorization_evidence authorization details type) records the human-readable description shown to the user during consent. This field may contain sensitive information about the user's intent, financial parameters, health-related operations, or personal data. Since the evidence record is included in the access token and may be logged by resource servers, implementations MUST minimize personal data in this field and SHOULD use operation identifiers rather than natural-language descriptions that may contain PII.¶

See [I-D.liu-oauth-authorization-evidence] for detailed guidance on displayed content minimization, evidence retention, and the tension between audit retention and the right to erasure under GDPR and CCPA.¶

10.4. Delegation Chain Privacy

Delegation chains record the identity of each intermediate agent in the delegation_chain claim. In multi-hop scenarios, this creates a record of all agents involved in a transaction, which may reveal organizational structure or agent relationships that participants consider sensitive. Implementations SHOULD evaluate whether the full delegation chain needs to be visible to the final resource server, or whether a summarized view is sufficient.¶

See [I-D.liu-oauth-chain-delegation] for delegation chain privacy considerations.¶