Internet-Draft AI Agent Authorization March 2026
Liu, et al. Expires 18 September 2026 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-liu-ai-agent-authorization-integration-00
Published:
Intended Status:
Informational
Expires:
Authors:
D. Liu
Alibaba Group
H. Zhu
Alibaba Group
S. Krishnan
Cisco
A. Parecki
Okta

AI Agent Authorization Integration Framework

Abstract

This document describes how to integrate multiple OAuth 2.0 extensions to enable secure authorization for AI agents acting on behalf of users. It combines cross-domain identity, policy-based authorization, user consent evidence, and multi-hop delegation into a cohesive framework for autonomous agent authorization.

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 18 September 2026.

▲

Table of Contents

1. Introduction

AI agents increasingly need to access protected resources on behalf of users across different trust domains. Traditional OAuth 2.0 provides basic delegation mechanisms, but AI agent scenarios require additional capabilities:

This document describes how to combine several OAuth 2.0 extensions into an integrated framework for AI agent authorization. It does not define new protocol mechanisms, but rather profiles existing specifications for this use case.

Two key design principles guide this framework:

1.1. Component Specifications

This framework integrates the following specifications:

Table 1: Framework Components
Component Specification Purpose
Agent Authentication draft-ietf-oauth-spiffe-client-auth Agent workload identity via SPIFFE/WIT-SVID
User Identity draft-liu-oauth-cross-domain-id-token-hint Cross-domain user identity assertion
Policy Authorization draft-liu-oauth-rego-policy Fine-grained Rego policy support
Consent Evidence draft-liu-oauth-authorization-evidence User confirmation records
Multi-hop Delegation draft-liu-oauth-chain-delegation Agent-to-agent delegation chains

2. Authorization Model: Policy vs Scope

AOA uses a policy-based authorization model that replaces traditional OAuth 2.0 scopes with fine-grained Rego policies. This section clarifies the relationship between scopes and policies in AOA.

2.1. Rego Policy as Primary Authorization Mechanism

In AOA, the primary authorization mechanism is Rego policy, not OAuth 2.0 scopes. The policy_proposal and policy_ref claims defined in [I-D.liu-oauth-rego-policy] carry the authorization logic:

  • Authorization Request: Clients submit policy_proposal containing Rego policy that defines permitted operations (e.g., "allow add_to_cart if amount <= 50").
  • Access Token: AS issues token with policy_ref referencing the registered policy.
  • Resource Server: RS evaluates the policy at runtime using OPA engine 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 AOA 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                                   |
+-----------------------------------------------------------+
|  +-----------------------------------------------------+  |
|  |
|  |                                                     |  |
|  |  +-----------------------------------------------+  |  |
|  |  |  Policy (Primary)                             |  |  |
|  |  |  "allow if amount <= 50 AND time < 6pm"       |  |  |
|  |  |  - Fine-grained conditions                    |  |  |
|  |  +-----------------------------------------------+  |  |
|  +-----------------------------------------------------+  |
+-----------------------------------------------------------+
Figure 1

2.3. Complete Authorization Mechanism

AOA's complete authorization mechanism comprises four integrated components:

  1. Cross-Domain Identity ([I-D.liu-oauth-cross-domain-id-token-hint]): Proves "who the user is" across trust domains.
  2. Consent Evidence ([I-D.liu-oauth-authorization-evidence]): Provides cryptographic proof of "what the user agreed to".
  3. Chain Delegation ([I-D.liu-oauth-chain-delegation]): Enables secure "agent-to-agent transfer" of authorization.
  4. Rego Policy ([I-D.liu-oauth-rego-policy]): Defines "what operations are allowed" with fine-grained conditions.

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

+---------------------------------------------------------+
|  Integration Framework (This Draft)                     |
|  "How to combine all components"                        |
+---------------------------------------------------------+
|  +-------------+  +-------------+  +-------------+      |
|  |  Identity   |  |  Evidence   |  | Delegation  |      |
|  |  (Who)      |  |  (What)     |  | (Transfer)  |      |
|  +-------------+  +-------------+  +-------------+      |
|                                                         |
|  +---------------------------------------------------+  |
|  |           Policy Engine (Rules)                   |  |
|  |         "Under what conditions allow"             |  |
|  +---------------------------------------------------+  |
+---------------------------------------------------------+
|           OAuth 2.0 Core + PAR + OIDC                   |
+---------------------------------------------------------+
Figure 2

3. Architecture

3.1. Participants 

+------------------+     +------------------+     +------------------+
|    Home IdP      |     |   AI Agent       |     |   External AS    |
|                  |     |                  |     |                  |
| - User authn     |     | - SPIFFE identity|     | - Policy engine  |
| - ID Token issue |     | - PAR client     |     | - Token issuance |
+------------------+     +------------------+     +------------------+
        |                        |                        |
        |   ID Token             |                        |
        |----------------------->|                        |
        |                        |                        |
        |                        |   PAR + id_token_hint  |
        |                        |----------------------->|
        |                        |                        |
        |                        |   Access Token         |
        |                        |<-----------------------|
        |                        |                        |
        |                        |                  +------------------+
        |                        |                  | Resource Server  |
        |                        |                  |                  |
        |                        |   API Request   | - Token validation|
        |                        |---------------->| - OPA enforcement |
        |                        |                  +------------------+
Figure 3
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 cross-domain identity and policy proposals.
Resource Server (RS):
Hosts protected resources. Validates access tokens and enforces policies using OPA.

3.2. Token Structure

The framework uses JWT access tokens 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 extracts this value from the third_party_binding.user_id claim in the id_token_hint.

  • 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. 
{
  // Standard OAuth claims
  "iss": "https://as.external.example",
  "sub": "user_12345",                    // Resource App user ID
  "aud": "https://api.external.example",
  "exp": 1731369540,
  "iat": 1731320700,
  "jti": "urn:uuid:token-abc-123",

  // Actor claim (RFC 8693) - identifies the agent acting on behalf of the user
  "act": {
    "sub": "wit://agent.example/sha256.abc123...",
    "agent_user_id": "agent_user_001"     // Optional: for agent-side audit
  },

  // Policy reference
  "policy_ref": {
    "id": "policy-abc123",
    "endpoint": "https://as.external.example/policies/..."
  },

  // User consent evidence
  "evidence": {
    "id": "evidence-xyz",
    "user_confirmation": { ... },
    "as_signature": "..."
  },

  // Semantic traceability
  "audit_trail": {
    "evidence_ref": "evidence-xyz",
    "semantic_expansion_level": "medium"
  },

  // Delegation chain (if delegated)
  "delegation_chain": [ ... ]
}
Figure 4

4. Authorization Workflow

4.1. Overview 

+-------+    +-------+    +--------+    +-------+    +-------+    +-----+
| User  |    | Home  |    |  AI    |    |External    |  RS   |    | OPA |
|       |    |  IdP  |    | Agent  |    |   AS  |    |       |    |     |
+-------+    +-------+    +--------+    +-------+    +-------+    +-----+
    |            |             |            |            |           |
(1) | Authn     |             |            |            |           |
    |----------->|             |            |            |           |
    |            |             |            |            |           |
(2) |  ID Token (aud=agent)   |            |            |           |
    |<------------------------->            |            |           |
    |            |             |            |            |           |
(3) |            |   Agent builds PAR:     |            |           |
    |            |   - id_token_hint       |            |           |
    |            |   - policy_proposal     |            |           |
    |            |   - policy_context      |            |           |
    |            |             |            |            |           |
(4) |            |   PAR Request           |            |           |
    |            |   + SPIFFE client auth  |            |           |
    |            |             |----------->|            |           |
    |            |             |            |            |           |
(5) |            |             |  Validate: |            |           |
    |            |             |  - SPIFFE  |            |           |
    |            |             |  - ID Token|            |           |
    |            |             |  - aud bind|            |           |
    |            |             |  - policy  |            |           |
    |            |             |            |            |           |
(6) | Consent UI (via redirect or CIBA)    |            |           |
    |<-------------------------------------|            |           |
    |            |             |            |            |           |
(7) | User confirms            |            |            |           |
    |------------------------------------->|            |           |
    |            |             |            |            |           |
(8) |            |             |  Issue token with:     |           |
    |            |             |  - act                 |           |
    |            |             |  - policy_ref         |           |
    |            |             |  - evidence           |           |
    |            |             |<-----------|            |           |
    |            |             |            |            |           |
(9) |            |             | API Request|            |           |
    |            |             |------------------------>|           |
    |            |             |            |            |           |
(10)|            |             |            |  Validate  |           |
    |            |             |            |  token     |           |
    |            |             |            |            |           |
(11)|            |             |            |  Policy    |           |
    |            |             |            |  eval      |---------->|
    |            |             |            |            |           |
(12)|            |             |            |  Decision  |           |
    |            |             |            |            |<----------|
    |            |             |            |            |           |
(13)|            |             | Response   |            |           |
    |            |             |<------------------------|           |
Figure 5

4.2. Step-by-Step Description

  1. User Authentication at Agent: User authenticates with the Agent's Identity Provider (IdP). The Agent's IdP issues an ID Token containing:

    • sub: The user's identifier at the Agent system (e.g., agent_user_001);
    • aud: The agent's SPIFFE ID, binding this token to the specific agent;
    • third_party_binding (OPTIONAL): If the user has completed OAuth login with a third-party Resource Application (e.g., shop.example), this claim asserts the user's identity at that application (e.g., user_12345). This enables lazy binding scenarios where users authenticate with third-party apps on-demand rather than pre-registering.

  2. ID Token as id_token_hint: The Agent uses this ID Token as the id_token_hint parameter in the PAR request. The AS validates the Agent IdP's signature and extracts the user's Resource Application identity from the third_party_binding claim if present.

  3. PAR Construction: Agent builds a PAR request including:

    • id_token_hint: The user's ID Token;
    • policy_proposal: Rego policy defining operations;
    • policy_context: Context data for policy evaluation.

  4. PAR Submission: Agent sends PAR to External AS with SPIFFE client authentication (WIT-SVID in headers).

  5. AS Validation: AS validates:

    • SPIFFE client credentials;
    • ID Token signature from Home IdP;
    • Audience binding (id_token_hint.aud == agent's SPIFFE ID);
    • Policy syntax and safety.

  6. User Consent: AS presents consent UI showing the interpreted operation (redirect or CIBA push).

  7. User Confirmation: User reviews and approves the operation.

  8. Token Issuance: AS issues access token containing:

    • act: Agent's SPIFFE ID;
    • policy_ref: Reference to registered policy;
    • evidence: Signed user confirmation record.

  9. API Request: Agent presents token to Resource Server.

  10. Token Validation: RS validates token signature and claims.

  11. Policy Evaluation: RS sends policy and request context to OPA.

  12. Authorization Decision: OPA returns allow/deny decision.

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

5. Agent-to-Agent Delegation

When Agent A needs to delegate operations to Agent B, the framework extends the basic workflow:

+---------+       +---------+       +--------+       +---------+
| Agent A |       |   AS    |       | Agent B|       |   RS    |
+---------+       +---------+       +--------+       +---------+
     |                 |                 |                |
     | (has token)     |                 |                |
     |                 |                 |                |
     | Delegation PAR  |                 |                |
     | - subject_token |                 |                |
     | - Agent B creds |                 |                |
     | - sub-scope     |                 |                |
     |---------------->|                 |                |
     |                 |                 |                |
     |                 | Validate:       |                |
     |                 | - Token A valid |                |
     |                 | - Scope subset  |                |
     |                 | - Agent B auth  |                |
     |                 |                 |                |
     |                 | Issue Token B   |                |
     |                 | with delegation_chain            |
     |                 |---------------->|                |
     |                 |                 |                |
     |                 |                 | API Request    |
     |                 |                 |--------------->|
     |                 |                 |                |
     |                 |                 |     Validate   |
     |                 |                 |     chain      |
     |                 |                 |                |
     |                 |                 | Response       |
     |                 |                 |<---------------|
Figure 6

The resulting token for Agent B includes a delegation_chain recording the delegation hop, as defined in draft-liu-oauth-chain-delegation.

7. Progressive Deployment

The AOA framework supports progressive deployment through a two-dimensional matrix, allowing organizations to adopt capabilities gradually based on their security requirements and operational maturity.

7.1. Identity Deployment Levels

Implementations MAY deploy agent identity at three progressive levels:

7.1.1. Level 0: Self-Issued Identity

The agent generates its own key pair and self-issues identity assertions. Suitable for development, testing, and low-trust scenarios such as personal or small-team agents.

7.1.2. Level 1: WIMSE Workload Identity

The agent obtains workload identity tokens through WIMSE infrastructure. Provides cross-domain verifiability without requiring full enterprise IdP deployment. This level can be enhanced with optional trusted execution environment verification using WIT Attestation.

7.1.3. Level 2: Enterprise Identity

The agent's identity is managed by an enterprise IdP with full X.509 or SAML/OIDC trust chains. Required for high-assurance enterprise deployments.

7.2. Token Deployment Levels

Authorization tokens can be deployed at three levels:

7.2.1. Level A: Pre-configured Tokens

Static tokens configured at deployment time. No runtime AS interaction required. Suitable for internal services and well-known agents.

7.2.2. Level B: Admin-Assigned Tokens

Tokens assigned by administrators through a management interface. Policy binding without end-user consent. Suitable for enterprise automation scenarios.

7.2.3. Level C: Runtime AOA Tokens

Full AOA flow with user consent, policy evaluation, and evidence recording. Required for high-sensitivity operations and cross-domain access. This level utilizes the JWT Grant Interaction Response mechanism for user consent.

7.3. Deployment Matrix

The combination of identity and token levels creates a deployment matrix:

Table 2: AOA Deployment Matrix
Identity \ Token A (Pre-configured) B (Admin-assigned) C (Runtime AOA)
0 (Self-Issued) Personal agents, IoT Small team automation Dynamic authorization
1 (WIMSE) Trusted lightweight agents Enterprise operations Cross-domain access
2 (Enterprise) High-trust static auth Compliance scenarios Full AOA enterprise

Organizations typically progress through the matrix as their requirements evolve, starting from lower levels (e.g., 0A) and upgrading to higher levels (e.g., 2C) based on security needs.

8. Reverse-Guided Authorization

Traditional OAuth error responses indicate authorization failure without guidance on how to obtain valid authorization. In AI agent scenarios, where agents may autonomously navigate authorization requirements, resource servers can provide structured guidance through error responses.

When an agent's request lacks sufficient authorization, the resource server returns a 403 Forbidden response with a rego_profile object that specifies:

The AI agent parses this guidance and constructs a new authorization request that satisfies the specified requirements. This enables agents to "learn" authorization requirements dynamically rather than requiring pre-programmed knowledge of each resource server's policies.

Detailed specification of the Rego Profile format and agent adaptive behavior is defined in draft-liu-oauth-rego-policy.

9. Security Considerations

9.1. Trust Boundaries

The framework establishes clear trust boundaries:

  • Home IdP → Agent: ID Token with agent in audience;
  • Agent → External AS: SPIFFE authentication + ID Token hint;
  • External AS → RS: Signed access token with policy reference;
  • Delegation: AS-signed delegation chain entries.

9.2. Threat Mitigations

Table 3: Threat Mitigations
Threat Mitigation
Token substitution Audience binding (id_token_hint.aud == agent ID)
Privilege escalation Scope subset validation in delegation
Unauthorized actions OPA policy enforcement at RS
Consent forgery AS-signed evidence records
Delegation chain tampering AS signature on each chain entry

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.

10. Relationship to Other Specifications

This section clarifies the relationship between this framework and other OAuth 2.0 specifications. Understanding these relationships is essential for implementers to determine which specifications are required for their specific use cases.

10.1. Relationship to Identity Assertion Grant (ID-JAG)

This framework extends the Identity Assertion Authorization Grant ([I-D.ietf-oauth-identity-assertion-authz-grant]) by adding explicit user consent through the confirmation URL mechanism. While ID-JAG focuses on service-to-service scenarios where the requesting client already has user authorization, this framework addresses user-to-agent scenarios requiring explicit consent.

Key differences:

  • ID-JAG assumes the client has already obtained user consent through out-of-band means;
  • This framework defines a confirmation URL mechanism for obtaining explicit user consent within the OAuth flow;
  • This framework adds policy-based authorization (Rego) beyond ID-JAG's scope-based approach.

Implementations of this framework MUST implement ID-JAG as the base grant type.

10.2. Relationship to Token Exchange (RFC 8693)

This framework uses Token Exchange ([RFC8693]) as the base delegation mechanism and extends it with the delegation_chain claim for complete auditability. While RFC 8693 provides point-to-point token exchange, this framework enables end-to-end delegation chain tracking.

Key extensions:

  • delegation_chain claim records all delegation hops with cryptographic signatures;
  • Policy subset validation ensures privilege escalation prevention across delegation hops;
  • Evidence records provide cryptographic proof of user consent at each delegation step.

Implementations MUST support RFC 8693 for token exchange operations and MAY implement the delegation chain extension for multi-hop scenarios.

10.3. Relationship to Transaction Tokens

Transaction Tokens (draft-ietf-oauth-transaction-tokens) focus on short-lived service-to-service authorization in microservices architectures. This framework focuses on longer-lived user-to-agent delegation with explicit human consent.

Comparison:

Table 4: Transaction Tokens vs AOA Framework
Aspect Transaction Tokens AOA Framework
Primary use case Service-to-service User-to-agent
Human consent Not required Required
Token lifetime Minutes Hours to days
Authorization model Capability-based Policy-based

The two specifications can be combined: AOA for initial user authorization, Transaction Tokens for subsequent service-to-service calls within the authorized scope.

10.4. Relationship to CIBA

This framework profiles the OpenID Connect Client-Initiated Backchannel Authentication (CIBA) specification for out-of-band user consent. While CIBA focuses on user authentication, this framework uses it for authorization and consent collection.

CIBA is used in this framework for:

  • Scenarios where the agent cannot redirect the user to a browser (e.g., voice assistants, IoT devices);
  • High-security scenarios requiring out-of-band consent verification;
  • Mobile scenarios where the user completes consent on a separate device.

The framework extends CIBA by adding policy presentation to the consent interface and evidence recording of the consent decision.

10.5. Relationship to Rich Authorization Requests (RAR)

Rich Authorization Requests ([RFC9396]) provide a structured JSON format for authorization requests. This framework uses the Rego policy language instead of RAR for authorization requests.

Rationale for using Rego:

  • Rego provides Turing-complete expressiveness suitable for complex AI agent scenarios;
  • Rego policies can be evaluated by standard OPA engines at resource servers;
  • Rego enables context-aware authorization decisions based on runtime parameters.

Implementations MAY support RAR as an alternative to Rego for simpler scenarios, but Rego is RECOMMENDED for AI agent authorization.

10.6. Relationship to SPIFFE Client Authentication

This framework uses OAuth SPIFFE Client Authentication ([I-D.ietf-oauth-spiffe-client-auth]) for agent authentication. SPIFFE provides workload identity through WIT-SVID (Workload Identity Token with SPIFFE Verifiable Identity Document).

The relationship is:

  • SPIFFE Client Auth proves "who the agent is" through cryptographic workload identity;
  • This framework proves "what the agent is allowed to do" through user consent and policy authorization;
  • Together, they provide complete agent identity and authorization.

Implementations MUST support SPIFFE Client Authentication for agent identification.

10.7. Implementation Requirements

The following table summarizes the implementation requirements for different components of this framework:

Table 5: Implementation Requirements
Specification Requirement Level Component
OAuth 2.0 (RFC 6749) MUST All
PAR (RFC 9126) MUST All
ID-JAG MUST All
SPIFFE Client Auth MUST Agent, AS
Cross-Domain ID Token Hint MUST Agent, AS
Rego Policy SHOULD Agent, AS, RS
Authorization Evidence SHOULD AS, RS
Chain Delegation MAY AS (if supporting delegation)
Token Exchange (RFC 8693) SHOULD AS
CIBA MAY AS (if supporting out-of-band consent)

11. IANA Considerations

This document has no IANA actions. All claims and parameters are defined in the referenced component specifications.

12. References

12.1. Normative References

[RFC6749]
Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, , <https://www.rfc-editor.org/info/rfc6749>.
[RFC9126]
Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", RFC 9126, DOI 10.17487/RFC9126, , <https://www.rfc-editor.org/info/rfc9126>.
[RFC8693]
Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, , <https://www.rfc-editor.org/info/rfc8693>.
[RFC9396]
Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, , <https://www.rfc-editor.org/info/rfc9396>.
[I-D.ietf-oauth-identity-assertion-authz-grant]
Ying, K. and B. Campbell, "OAuth 2.0 Identity Assertion Authorization Grant", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-assertion-authz-grant, , <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-identity-assertion-authz-grant>.
[I-D.ietf-oauth-spiffe-client-auth]
Schwenkschuster, A., "OAuth SPIFFE Client Authentication", Work in Progress, Internet-Draft, draft-ietf-oauth-spiffe-client-auth, , <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-spiffe-client-auth>.
[I-D.liu-oauth-cross-domain-id-token-hint]
Liu, D., "Cross-Domain ID Token Hint for OAuth 2.0", Work in Progress, Internet-Draft, draft-liu-oauth-cross-domain-id-token-hint, , <https://datatracker.ietf.org/doc/html/draft-liu-oauth-cross-domain-id-token-hint>.
[I-D.liu-oauth-rego-policy]
Liu, D., "Rego Policy Language for OAuth 2.0", Work in Progress, Internet-Draft, draft-liu-oauth-rego-policy, , <https://datatracker.ietf.org/doc/html/draft-liu-oauth-rego-policy>.
[I-D.liu-oauth-authorization-evidence]
Liu, D., "Authorization Evidence for OAuth 2.0", Work in Progress, Internet-Draft, draft-liu-oauth-authorization-evidence, , <https://datatracker.ietf.org/doc/html/draft-liu-oauth-authorization-evidence>.
[I-D.liu-oauth-chain-delegation]
Liu, D., "Chain Delegation for OAuth 2.0", Work in Progress, Internet-Draft, draft-liu-oauth-chain-delegation, , <https://datatracker.ietf.org/doc/html/draft-liu-oauth-chain-delegation>.
[I-D.ietf-oauth-transaction-tokens]
Tulshibagwale, A., Fletcher, G., and P. Kasselman, "Transaction Tokens", Work in Progress, Internet-Draft, draft-ietf-oauth-transaction-tokens, , <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens>.

12.2. Informative References

[CIBA]
OpenID Foundation, "OpenID Connect CIBA Core", , <https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html>.
[OPA]
CNCF, "Open Policy Agent", , <https://www.openpolicyagent.org/>.

Appendix A. Complete Example

A.1. PAR Request 

POST /par HTTP/1.1
Host: as.shop.example
Content-Type: application/x-www-form-urlencoded
OAuth-Client-Attestation: eyJ0eXAiOiJ3aXQrand0IiwiYWxnIjoiRVMyNTYifQ...
OAuth-Client-Attestation-PoP: eyJ0eXAiOiJvYXV0aC1jbGllbnQtYXR0ZXN0...

client_id=spiffe://myassistant.example/agent
&id_token_hint=eyJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodHRwczovL2lkc...
&redirect_uri=https://myassistant.example/callback
&policy_proposal={"type":"rego","content":"package agent...","entry_point":"allow"}
&policy_context={"user":{"id":"user_12345"},"action":"add_to_cart"}
Figure 7

A.2. Access Token 

{
  "iss": "https://as.shop.example",
  "sub": "user_12345",                    // Third-party app user ID
  "aud": "https://api.shop.example",
  "exp": 1731369540,
  "iat": 1731320700,
  "jti": "urn:uuid:token-shop-123",

  "act": {
    "sub": "wit://myassistant.example/sha256.xyz789...",
    "agent_user_id": "agent_user_001"     // Optional: correlation at agent side
  },

  "policy_ref": {
    "id": "policy-cart-50",
    "endpoint": "https://as.shop.example/policies/policy-cart-50"
  },

  "evidence": {
    "id": "evidence-consent-abc",
    "user_confirmation": {
      "displayed_content": "Add items under $50 to cart",
      "user_action": "confirmed_via_button_click",
      "timestamp": 1731320595
    },
    "as_signature": "eyJhbGciOiJSUzI1NiJ9..."
  }
}
Figure 8

Acknowledgments

The authors would like to thank Brian Campbell for his valuable feedback and insightful discussions on OAuth extension design. His contributions helped shape key aspects of this framework.

Authors' Addresses

Dapeng Liu
Alibaba Group
Hongru Zhu
Alibaba Group
Suresh Krishnan
Cisco
Aaron Parecki
Okta