]> Alibaba Group

max.ldp@alibaba-inc.com

Alibaba Group

hongru.zhr@alibaba-inc.com

Cisco

suresh.krishnan@gmail.com

Okta

aaron@parecki.com

Alibaba Group

hui.xueh@alibaba-inc.com

Security Web Authorization Protocol AI Agent Authorization OAuth Integration 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.

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:

• Cross-domain user identity verification;
• Fine-grained, policy-based authorization;
• Verifiable user consent evidence;
• Secure multi-agent delegation chains.

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:

• Progressive Deployment: Organizations can adopt the framework's capabilities gradually through a two-dimensional deployment matrix, starting with simple configurations and upgrading to full runtime authorization as requirements evolve (see ).
• Reverse-Guided Authorization: Resource servers can guide agents toward appropriate authorization by returning structured error responses that specify required policies and constraints, enabling AI agents to adaptively construct valid authorization requests (see ).

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

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: Framework Components

Component	Specification	Purpose
Agent Authentication		Agent workload identity via SPIFFE/WIT-SVID
Identity Assertion Grant		JWT-based cross-domain identity assertion
User Interaction & Consent		User consent via JWT grant interaction flow
Policy Authorization		Fine-grained Rego policy support
Consent Evidence		User confirmation records, audit trail, and consent-to-evidence pipeline
Multi-hop Delegation		Agent-to-agent delegation chains

This framework 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 this framework.

In this framework, the primary authorization mechanism is policy carried via Rich Authorization Requests (RAR, ), not OAuth 2.0 scopes. The rego_policy authorization data type defined in 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 ) with request context.

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

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.

The complete authorization mechanism comprises six integrated components:

1. Agent Authentication (): Proves "who the agent is" through cryptographic workload identity.
2. Cross-Domain Identity (): Proves "who the user is" across trust domains via JWT assertion.
3. User Interaction & Consent (): Obtains explicit user consent through structured interaction flow.
4. Rego Policy (): Defines "what operations are allowed" with fine-grained conditions.
5. Authorization Evidence (): Provides cryptographic proof of "what the user agreed to".
6. Chain Delegation (): Enables secure "agent-to-agent transfer" of authorization.

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

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

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 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 ():
  • rego_policy type: The Rego policy defining what operations the agent is permitted to perform. Defined in .
  • 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 .
• 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 .

| | | | | | | | | | | (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 | | | | | |<------------------------| | ]]>

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 .
2. ID Token as JWT Assertion: The Agent uses the ID Token as the JWT assertion in the token request per . 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 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.

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

| | | | | | | | | Validate: | | | | - Token A valid | | | | - Policy subset | | | | - Agent B auth | | | | - delegator_sig | | | | | | | | AS countersigns | | | | (as_signature) | | | | | | | | Issue Token B | | | | with delegation_chain | | | (del_sig+as_sig)| | | |---------------->| | | | | | | | | API Request | | | |--------------->| | | | | | | | Validate | | | | chain | | | | (dual sig) | | | | | | | | Response | | | |<---------------| ]]>

The resulting token for Agent B includes a delegation_chain recording the delegation hop, as defined in . Each delegation chain entry carries a dual signature: the delegator's signature (delegator_signature) over the delegation record and the AS's countersignature (as_signature), ensuring non-repudiation and preventing unilateral scope escalation. The AS MUST also decide how to handle the original authorization_evidence entry from Agent A's token. Three strategies are defined in : Propagate (copy the original authorization_evidence entry into Agent B's token), Reference (replace the embedded evidence with an audit_trail sub-object containing only the evidence_ref), or Omit (do not include evidence). The Propagate strategy is RECOMMENDED when the delegated policy is a subset of the original token's policy. When using delegation chains, the root_evidence_ref in the delegation chain entry SHOULD reference the same evidence record, creating an unbroken audit trail from the original user consent through all delegation hops.

The framework supports multiple consent mechanisms:

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.

Client-Initiated Backchannel Authentication (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.

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.

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

Implementations MAY deploy agent identity at three progressive levels:

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.

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 .

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.

Authorization tokens can be deployed at three levels:

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

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

The full framework 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.

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

Identity \ Token	A (Pre-configured)	B (Admin-assigned)	C (Runtime Authz)
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 framework 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.

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:

• Required scopes or authorization details;
• Policy constraints that must be satisfied;
• Whether user consent is required;
• Reference to the authorization server capable of issuing appropriate tokens.

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 .

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 );
• Delegation: AS-signed delegation chain entries.

Threat Mitigations

Threat	Mitigation
Token substitution	JWT assertion audience binding (assertion.aud == AS identifier)
Privilege escalation	Scope subset validation in delegation
Unauthorized actions	Rego policy enforcement at RS
Consent forgery	AS-signed evidence records
Delegation chain tampering	AS signature on each chain entry

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.

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 () 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 .

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 for detailed guidance.

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 for the complete threat model and mitigation strategies.

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.

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 for the complete delegation security model and validation checklist.

The privacy considerations in this section are informed by the Internet protocol privacy analysis framework described in . This section addresses privacy considerations specific to the integrated framework; implementers MUST also consult the privacy considerations in each component specification.

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.

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.

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 for detailed guidance on displayed content minimization, evidence retention, and the tension between audit retention and the right to erasure under GDPR and CCPA.

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 for delegation chain privacy considerations.

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.

This framework builds on the Identity Assertion Authorization Grant () as the base grant type for cross-domain identity assertion. ID-JAG enables AI agents to present a JWT assertion (e.g., an ID Token from the user's Home IdP) to an external authorization server as proof of user identity. This framework extends ID-JAG with:

• The JWT Grant Interaction Response () for obtaining explicit user consent when the AS requires user interaction;
• RAR-based policy authorization via the rego_policy authorization data type in authorization_details;
• Evidence recording of user consent decisions.

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

The JWT Grant Interaction Response () defines an extension to the JWT Authorization Grant that enables an authorization server to indicate that user interaction is required. Instead of immediately returning an access token or error, the AS returns an interaction_uri where the user can provide consent, along with a polling interval. This framework uses JWT Grant Interaction Response for:

• Obtaining explicit user consent for AI agent operations without requiring a traditional OAuth redirect flow;
• Enabling the agent to launch a browser for user interaction and then poll for completion;
• Supporting both polling-based and redirect-based notification of interaction completion.

Implementations MUST support JWT Grant Interaction Response for user consent in AI agent authorization scenarios.

This framework uses Token Exchange () 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 the original user consent, propagated across delegation hops via root_evidence_ref;

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

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: Transaction Tokens vs This Framework

Aspect	Transaction Tokens	This Framework
Primary use case	Service-to-service	User-to-agent
Human consent	Not required	Required
Token lifetime	Minutes	Minutes to hours
Authorization model	Capability-based	Policy-based

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

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.

This framework uses Rich Authorization Requests () as the mechanism for carrying Rego policy in authorization requests via the authorization_details parameter. The rego_policy authorization data type defined in enables fine-grained, policy-based authorization within the RAR framework. RAR integration provides:

• A standardized container (authorization_details) for carrying Rego policy and evaluation context;
• Enriched token responses (RFC 9396 Section 7.1) that include the evaluated policy in the access token;
• Compatibility with other RAR types, enabling combined authorization scenarios.

Implementations MUST support RAR (RFC 9396) with the rego_policy authorization data type.

This framework uses OAuth SPIFFE Client Authentication () 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 using Identity Level 1 or Level 2 () MUST support SPIFFE Client Authentication for agent identification. Deployments using Identity Level 0 (self-issued identity) MAY use alternative client authentication mechanisms.

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

Specification	Requirement Level	Component
OAuth 2.0 (RFC 6749)	MUST	All
PAR ()	MAY	Agent, AS
RAR (RFC 9396)	MUST	Agent, AS, RS
ID-JAG	MUST	Agent, AS
JWT Grant Interaction Response	MUST	Agent, AS
SPIFFE Client Auth	SHOULD (see note)	Agent, AS
Rego Policy	MUST	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)

Note: SPIFFE Client Authentication is required for Identity Levels 1 and 2 (). Identity Level 0 deployments (self-issued identity) MAY use alternative client authentication mechanisms such as client_secret_post or private_key_jwt.

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

References Normative References Informative References OpenID Foundation CNCF

The agent re-sends the original request with a fresh SPIFFE client attestation at the interval specified in the interaction response. Upon successful user consent, the AS returns the access token shown above.

The Resource Server validates the access token, extracts the rego_policy from authorization_details, and evaluates it against the request context (action, item price, user identity) using a Rego-compatible policy engine.

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.