Policy Language Binding for OAuth 2.0 Authorization

1.1. Domain-Specific Authorization Schemas

This specification defines a framework for domain-specific authorization schemas: structured definitions of behavioral boundaries for a particular application domain. Each schema is identified by an authorization details type registered per [RFC9396], and schema instances are carried in authorization requests and access tokens via authorization_details. Schema instances are structured data, not executable code: Resource Servers verify agent behaviors against them through deterministic constraint evaluation. How the Authorization Server reviews requested instances is an implementation decision: server-side authorization policies MAY be expressed in any policy language (e.g., Rego [Rego]), but no policy language constructs are carried in authorization requests or access tokens (see Appendix A).¶

1.2. 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.3. RAR Integration

This specification defines a framework for domain-specific authorization schemas used with Rich Authorization Requests (RAR) [RFC9396]. Schema instances are carried within the authorization_details parameter as the primary mechanism.¶

Key aspects of the RAR integration:¶

• Authorization Data Types: Each domain-specific authorization schema is identified by a distinct authorization details type registered per RFC 9396. This specification defines the transaction_authority type as the initial registration (see Section 3.1) and the requirements that additional domain schema types MUST satisfy.¶
• Token Response: Per RFC 9396 Section 7.1, the access token includes enriched authorization_details as the primary mechanism for carrying the approved schema instance.¶
• Complementary Use: Implementations MAY combine domain-specific authorization schemas with other RAR types in a single request.¶

Resource Servers MAY advertise supported authorization details types via the authorization_details_types_supported attribute in Protected Resource Metadata ([RFC9728]), enabling clients to discover which domain-specific authorization schemas are accepted before constructing authorization requests. This discovery mechanism is particularly valuable in multi-tenant or federated environments where different resource servers may require different schema structures.¶

The authorization_details parameter provides one mechanism for carrying a schema instance in the authorization request; this specification standardizes the binding of the approved schema instance to the access token, not the specific input channel by which the instance reaches the Authorization Server.¶

4.1. Step Details

1. Authorization Request: The authorization request includes authorization_details containing a schema instance (e.g., of type transaction_authority, with the boundary constraints and optional context field). This leverages RAR (RFC 9396) for structured authorization requests.¶
2. Instance Validation: AS validates that the instance conforms to the definition of the declared schema (see Section 6).¶
3. Review and Approval: AS determines whether the proposed behavioral boundaries are appropriate for the specific client and resource owner, based on client registration metadata, organizational review policies, resource owner consent, and token binding context (see Section 6). The AS does not perform per-behavior verification (which occurs at the Resource Server).¶
4. Token Binding: AS issues an access token with enriched authorization_details array per RFC 9396 Section 7.1, binding the approved schema instance to the token. The AS MAY include additional metadata in the authorization_details object (e.g., server-assigned identifiers or normalized instance content) but MUST NOT alter the semantic meaning of the instance without client consent.¶
5. Behavior Execution: Client (agent) presents the token to the Resource Server when performing a behavior.¶
6. Instance Extraction: RS extracts the approved schema instance from the enriched authorization_details in the access token.¶
7. Behavior Verification: The RS verifies the agent's current behavior (action, target resource, context) against the boundary constraints of the approved instance through deterministic constraint evaluation. No policy engine is required.¶
8. Enforcement: RS enforces the per-behavior decision, allowing or denying the agent's action.¶
9. Response: RS returns the result to the client.¶

5.1. Error Response Format

When an agent's request lacks sufficient authorization, the resource server returns an HTTP 403 Forbidden response with a WWW-Authenticate header containing the insufficient_authorization error code and a schema_profile parameter. This parameter provides machine-readable guidance on the required authorization conditions.¶

HTTP/1.1 403 Forbidden
Content-Type: application/json
WWW-Authenticate: Bearer error="insufficient_authorization",
  schema_profile="eyJwcm9maWxlX3VyaSI6Imh0dHBzOi8vcmVzb3VyY2UuZXhhbXBsZS9..."

{
  "error": "insufficient_authorization",
  "error_description": "Additional authorization required"
}

Per RFC 6750 [RFC6750] Section 3 and RFC 6749 [RFC6749] Section 5.2, the error response includes both the WWW-Authenticate header with the insufficient_authorization error code and a JSON error body. The schema_profile parameter in the WWW-Authenticate header provides machine-readable guidance on the required authorization conditions.¶

The schema_profile parameter value is a base64url-encoded JSON object. Implementations SHOULD use base64url encoding without padding (no trailing = characters) per RFC 4648 [RFC4648] Section 5 to avoid quoting issues in the WWW-Authenticate header. The decoded object has the following structure:¶

{
  "profile_uri": "https://resource.example/policies/purchase",
  "required_scope": ["purchase.create"],
  "required_claims": ["agent_id", "user_id"],
  "constraints": {
    "max_amount": {
      "type": "number",
      "description": "Maximum transaction amount in USD",
      "required": true
    },
    "trigger_source": {
      "type": "string",
      "enum": ["user_initiated", "scheduled"],
      "description": "Source of the operation trigger"
    }
  },
  "confirmation_required": true,
  "auth_server": "https://as.example.com"
}

5.2. Relationship to insufficient_scope

RFC 6750 [RFC6750] defines the insufficient_scope error for cases where the access token lacks the scopes required by the resource server. The insufficient_authorization error defined in this specification addresses a broader condition: the token may include adequate scopes but lack the schema-based authorization structure (e.g., boundary constraints or user confirmation) required by the resource server.¶

For example, consider an agent holding an access token with scope purchase that attempts to create a $500 purchase. The resource server requires a schema instance that limits transaction amounts and requires user confirmation for purchases above $200. The scope is sufficient, but the token lacks the required schema binding. The insufficient_scope error cannot express this condition because the deficiency is structural (missing boundary constraints and confirmation signal), not scope-based. The insufficient_authorization error with a schema_profile payload allows the resource server to convey both the missing boundary constraints (e.g., max_amount: 200) and the need for user confirmation (confirmation_required: true) in a machine-parseable form that the agent can act on autonomously.¶

Resource servers SHOULD use insufficient_scope when the deficiency is purely scope-based and insufficient_authorization when the deficiency involves boundary constraints that cannot be expressed as additional scopes.¶

5.3. Schema Profile Structure

The schema_profile object contains the following fields:¶

profile_uri:

OPTIONAL. URI identifying the authorization profile for this resource. This URI is an opaque identifier that the agent MUST NOT dereference programmatically to derive authorization requirements. The resource server and intermediaries MAY use it as a cache key or audit reference. If the URI is resolvable, the retrieved document is intended for human consumption (e.g., developer documentation) and MUST NOT be parsed by the agent as part of the authorization flow.¶

required_scope:

OPTIONAL. Array of scope values that the access token MUST include.¶

required_claims:

OPTIONAL. Array of attribute names (e.g., agent_id, user_id) that MUST be present in the authorization context established by the access token. For JWT access tokens, these are claim names that MUST appear in the JWT. For opaque access tokens validated via introspection ([RFC7662]), these are field names that MUST appear in the introspection response.¶

constraints:

OPTIONAL. Object defining boundary constraint descriptors that MUST be satisfied. Each key is a constraint name; the value is an object with the following descriptors: type (data type), description (human-readable explanation), enum (allowed values), and required (boolean, whether the constraint must be provided).¶

confirmation_required:

OPTIONAL. Boolean indicating whether explicit user authorization is required for the requested behavioral boundaries. If true, the agent MUST initiate an OAuth authorization flow to obtain the resource owner's explicit consent for the submitted schema instance. This does not mean local user confirmation (e.g., a modal dialog) is sufficient; the authorization must be obtained through the AS to produce a token with appropriate grants. The specific interaction mechanism depends on the OAuth flow in use (e.g., the interaction_required error with JWT Grant Interaction Response [I-D.parecki-oauth-jwt-grant-interaction-response], or the prompt parameter in the authorization code flow).¶

auth_server:

REQUIRED. Identifier of the authorization server capable of issuing tokens that satisfy these requirements. The agent can discover the token endpoint and other metadata via OAuth 2.0 Authorization Server Metadata ([RFC8414]) or OAuth 2.0 Protected Resource Metadata ([RFC9728]) using this identifier.¶

5.4. Agent Adaptive Behavior

Upon receiving a reverse-guided authorization response, the AI agent SHOULD:¶

1. Parse the schema_profile to understand authorization requirements.¶
2. Verify that the specified auth_server is trusted before proceeding.¶
3. Construct a new authorization request including required scopes, a schema instance that satisfies the constraints specified in the schema_profile, and any additional parameters required by the resource server.¶
4. If confirmation_required is true, initiate user consent flow.¶
5. Discover the token endpoint via the auth_server's metadata (RFC 8414) and submit the authorization request.¶

This adaptive approach enables agents to "learn" authorization requirements dynamically, reducing the need for pre-programmed knowledge of each resource server's policies.¶

During multi-step task execution, an agent may encounter behavioral drift: situations where the next behavior in its plan falls outside the approved schema constraints. When this occurs, the agent has three options: (1) request a new authorization with an updated schema instance that accommodates the new behavior (using the reverse-guided authorization mechanism described above); (2) degrade its behavior to stay within the approved constraints (e.g., selecting an alternative, less privileged action); or (3) request human confirmation to approve an expanded behavioral boundary. The choice among these options depends on the agent's task context and the confirmation_required signal from the resource server. Implementations SHOULD prefer degradation over re-authorization for minor boundary violations to avoid excessive authorization round-trips in long-running agent workflows.¶

5.5. Security Considerations

Security considerations specific to reverse-guided authorization, including auth server verification and constraint validation, are described in Section 9.¶

6.1. Instance Validation

Upon receiving an authorization_details request containing a domain-specific schema instance, the AS MUST perform the following validation steps:¶

1. Type Check: Verify that the type field identifies a domain-specific authorization schema known to the AS (e.g., transaction_authority, Section 3.1).¶
2. Schema Conformance: Validate the instance against the definition of the declared schema, including required fields, value types, and formats. Unknown fields not defined by the schema MUST be rejected.¶
3. Constraint Values: Verify that constraint values are within the ranges and formats defined by the schema (e.g., non-negative monetary amounts, well-formed RFC 3339 timestamps with start earlier than end).¶
4. Behavioral Boundary Check: Verify that the RAR common fields (actions, locations) do not exceed the client's registered permissions. The AS SHOULD also verify that the boundary constraints are consistent with the common fields (e.g., every operation listed in boundary.operations corresponds to a declared action).¶

Because the request carries structured data rather than executable code, no syntax parsing, entry point resolution, or safety analysis of program code is required. This eliminates the class of vulnerabilities associated with evaluating client-submitted policy code.¶

6.2. Instance Registration

When the AS issues a schema_ref claim instead of embedding the full approved instance in authorization_details, the AS MUST register the instance:¶

1. Assign a unique instance identifier;¶
2. Store the approved instance content;¶
3. Associate the instance with the authorization session;¶
4. Optionally, pre-process the instance for faster verification.¶

When the AS embeds the approved instance directly in the enriched authorization_details (the primary path), explicit registration is not required; the instance travels with the token.¶

Instance registration in this specification is dynamic and on-demand. The Authorization Server does not need to maintain a pre-configured catalog of instances. When a schema instance is submitted for binding, the AS reviews it against pre-established approval principles (see Section 6.4) and registers it only if approved. This eliminates the operational burden of pre-deploying instances for every anticipated agent behavior, which is impractical given the dynamic and unpredictable nature of AI agent workflows.¶

Deployments MAY also pre-register instances for well-known agent workflows (e.g., automated reconciliation, scheduled reporting) where the behavioral boundaries are stable and known in advance. In such cases, the agent can reference the pre-registered instance by identifier rather than submitting the full instance content in each authorization request. Both modes are supported: dynamic registration is the default for exploratory agent tasks, while pre-registration is an optimization for predictable workflows.¶

7.1. Instance Retrieval

The RS obtains the approved instance from the access token. The primary mechanism is to extract the instance from the enriched authorization_details array included in the token per RFC 9396 Section 7.1.¶

The binding between the instance and the access token depends on the token type. For JWT access tokens, the instance content or schema_ref claim is integrity-protected by the token signature. For opaque tokens, the binding is established through token introspection [RFC7662] or a shared back-channel between the AS and RS.¶

When the token uses the schema_ref claim instead of inline instance content, the RS retrieves the instance using one of the following methods:¶

• Local Cache: Use a cached copy if available and not expired.¶
• Introspection: Retrieve the instance content via token introspection [RFC7662].¶

7.2. Constraint Evaluation

After extracting the approved instance from the token, the RS verifies each agent behavior against every constraint present in the boundary object. Each constraint check is a deterministic comparison between the behavior's attributes and the constraint value, for example:¶

• The behavior's operation identifier is contained in boundary.operations;¶
• The cumulative transaction amount including the current behavior does not exceed boundary.total_amount_limit;¶
• The target merchant is contained in boundary.merchant;¶
• The current time is within boundary.time_window.¶

The verification data assembled by the RS for these checks is described in Section 3.3.¶

7.3. Enforcement Decision

Based on the constraint evaluation:¶

• If the behavior is consistent with every present constraint: Allow the behavior;¶
• If the behavior violates any present constraint, or if the behavior cannot be mapped to the approved instance: Deny with 403 Forbidden. When the denial results from behavioral drift, the RS MAY apply the reverse-guided mechanism (Section 5) to guide the agent toward a new authorization;¶
• If the instance cannot be retrieved or parsed: Deny with 403 Forbidden.¶

8.1. JWT Grant with Interaction Response

The JWT Authorization Grant Interaction Response [I-D.parecki-oauth-jwt-grant-interaction-response] is the RECOMMENDED flow for AI agent scenarios. In this flow, an agent presents a JWT assertion to the token endpoint. If user interaction (e.g., consent) is required before the token can be issued, the AS returns an interaction_required error with an interaction_uri where the user can complete the interaction. The agent then polls for the token.¶

When combined with schema binding, the agent includes authorization_details containing a schema instance in the JWT grant request. The AS validates the instance, performs behavioral boundary checks, and determines whether user consent is needed before issuing the token.¶

POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
&assertion=eyJhbGciOiJSUzI1NiJ9...
&authorization_details=%5B%7B%22type%22%3A%22transaction_authority%22%2C
  %22domain%22%3A%22ecommerce%22%2C%22boundary%22%3A%7B%22total_...
  %22actions%22%3A%5B%22search%22%2C%22cart.add%22%5D%7D%5D

HTTP/1.1 400 Bad Request
Content-Type: application/json

{
  "error": "interaction_required",
  "interaction_uri": "https://as.example.com/interact/abc123",
  "interval": 5,
  "expires_in": 600
}

After the user completes the interaction, the agent retries the same JWT grant request. The AS then issues the access token with the enriched authorization_details containing the approved instance.¶

8.2. Client Credentials Grant

In machine-to-machine scenarios using client credentials, a schema instance can be included in the token request:¶

POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id=spiffe%3A%2F%2Fagent.example%2Fagent
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIs...
&authorization_details=%5B%7B%22type%22%3A%22transaction_authority%22%2C
  %22domain%22%3A%22ecommerce%22%2C%22boundary%22%3A%7B...%7D%7D%5D

8.3. Token Exchange (RFC 8693)

When exchanging tokens [RFC8693], a new schema instance can be provided to refine or restrict the approved behavioral boundaries:¶

POST /token HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&subject_token=eyJhbGciOiJSUzI1NiJ9...
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token
&authorization_details=%5B%7B%22type%22%3A%22transaction_authority%22%2C
  %22domain%22%3A%22ecommerce%22%2C%22boundary%22%3A%7B...%7D%7D%5D

The resulting access token MUST include the new approved schema instance. Unlike policies written in a general-purpose policy language, structured schema instances make subset verification decidable: each constraint in the new instance can be compared field-by-field against the corresponding constraint of the original instance (e.g., a lower total_amount_limit, a subset of operations, or a narrower time_window). When subset_rule is "strict" (Section 3.1), the AS MUST verify that the derived instance is a subset of the original instance and reject the exchange otherwise. When subset_rule is "loose", the AS MAY apply its own review policies (Appendix A) when deriving the new instance.¶

Token Exchange is a common trigger for behavioral drift: when an agent's next planned behavior falls outside the approved schema constraints, the Resource Server can return an insufficient_authorization error with a schema_profile (as defined in Section 5), guiding the agent toward constructing an appropriate Token Exchange request with an updated schema instance. This enables multi-hop delegation scenarios where each hop progressively refines the behavioral boundaries to match the delegatee's specific task requirements.¶

9.1. Trust Model

The behavioral authorization framework defined in this specification relies on the following trust assumptions, which deployments MUST evaluate before adoption:¶

• AS-to-RS trust: The Resource Server trusts the Authorization Server to validate, review, and bind approved schema instances to access tokens. The RS enforces the instance approved by the AS and does not re-evaluate the AS's approval decision at runtime. This trust relationship is consistent with the OAuth 2.0 trust model in which the RS trusts the AS's issuance of access tokens.¶
• Client-to-AS trust: The client (agent) trusts the AS to validate its submitted schema instance and issue a token reflecting the approved behavioral boundaries. The client MUST NOT trust instances or profiles received from other parties (including resource servers) without AS approval.¶
• AS/RS-to-client distrust: Neither the AS nor the RS trusts the client to act within its approved behavioral boundaries without verification. The AS performs validation and review; the RS performs per-behavior runtime verification.¶

A compromised or malicious AS could embed a wildly permissive instance in an access token, causing the RS to allow behaviors that the RS operator did not intend. To mitigate this risk, the RS MAY impose overlay constraints on top of the token-bound instance, such as:¶

• A hard deny list of dangerous or privileged actions that cannot be authorized by any token-bound instance;¶
• Rate limiting or transaction caps that apply regardless of the approved instance;¶
• Restriction of trusted ASes to a pre-registered allowlist, discoverable via Protected Resource Metadata ([RFC9728]).¶

The choice of which ASes to trust is a deployment decision. Resource Servers SHOULD restrict the set of trusted Authorization Servers and reject tokens issued by untrusted ASes. The authorization_servers field in Protected Resource Metadata ([RFC9728]) provides a mechanism for the RS to advertise its trusted ASes to clients.¶

9.2. No Executable Content

Schema instances carried in authorization requests and access tokens are structured data conforming to registered schema definitions; they contain no executable code. This eliminates the class of attacks associated with client-submitted policy code, including non-terminating or resource-intensive evaluations, catastrophic regular-expression backtracking, and built-in functions with side effects (e.g., outbound HTTP requests from within a policy evaluation). Neither the AS nor the RS executes client-supplied content at any point in the flow.¶

To preserve this property, the AS MUST reject instances containing fields not defined by the declared schema, and the RS MUST ignore or reject instances containing unknown fields. Policy languages, where used at all, are confined to the Authorization Server's internal review of instances (Appendix A) and are never supplied by clients.¶

9.3. Instance Integrity

The schema_ref claim in access tokens MUST reference instances registered and stored securely by the AS. When the access token is opaque, the Resource Server retrieves the instance through token introspection ([RFC7662]). The introspection response SHOULD include the approved schema instance using the same mechanisms as the access token: either the enriched authorization_details array containing the approved instance (the primary mechanism), or the schema_ref claim (the lightweight alternative). When a JWT access token is introspected, the introspection response SHOULD reflect the claims present in the JWT, including authorization_details and schema_ref, per RFC 7662 Section 2.2.¶

Resource Servers SHOULD invalidate cached instance content when the associated access token expires. If the AS revokes a registered instance before the token expires, the AS SHOULD also revoke the associated access token, causing subsequent introspection calls to return active: false per RFC 7662. Resource servers that observe active: false (or that are otherwise notified of instance revocation through a deployment-specific mechanism) MUST treat subsequent verifications for the token as failed (deny-by-default).¶

9.4. Instance Size Limits

Instances embedded inline within authorization_details can increase token request and access token size. Implementations MUST enforce limits on:¶

• Maximum instance size (RECOMMENDED limit: 4 KB for inline instances). Note that JWT access tokens are typically carried in HTTP Authorization headers, where many proxies and load balancers enforce an 8 KB total header size limit;¶
• Maximum instance complexity (e.g., nesting depth, number of constraint entries);¶
• Total authorization_details payload size in token requests.¶

For instances exceeding these limits, clients SHOULD use pre-registered instances referenced via schema_ref rather than inline instance content.¶

9.5. Reverse-Guided Authorization

Implementations of reverse-guided authorization (Section 5) MUST consider the following security aspects:¶

• Auth Server Verification: Agents MUST verify that the auth_server specified in the schema_profile is trusted before submitting authorization requests. Verification SHOULD be performed by comparing the auth_server value against one of the following trust anchors: (1) the authorization_servers field in the Protected Resource Metadata ([RFC9728]) obtained from the resource server that returned the error; (2) a pre-registered allowlist of trusted authorization servers configured at client provisioning time; or (3) a deployment-specific trust registry. If none of these trust anchors are available, agents MUST NOT submit authorization requests to the specified auth_server. Agents MUST use only the token endpoint discovered from the auth_server's Authorization Server Metadata ([RFC8414]). Blindly following redirects or trusting unverified auth_server values could lead to credential theft.¶
• Constraint Validation: Agents SHOULD validate that constraint values are reasonable before including them in authorization requests. Malicious resource servers might attempt to induce agents to request excessive permissions.¶

All communications in the reverse-guided flow MUST use TLS to prevent man-in-the-middle attacks on error responses.¶

11.1. RAR Authorization Data Type Registration

This specification defines the following authorization data type for use with the authorization_details parameter defined in RFC 9396:¶

Type Name:

transaction_authority¶

Description:

A domain-specific authorization schema instance defining transaction behavioral boundaries (amount limits, permitted operations, categories, merchants, and time windows) for per-behavior authorization verification.¶

Change Controller:

IETF¶

Specification Document:

Section 3.1 of this document¶

11.3. JWT Access Token Claims Registration

This specification registers the following claim in the "JWT Access Token JWT Claims" registry established by [RFC9068]:¶

Claim Name:

schema_ref¶

Claim Description:

A reference to a registered, approved schema instance in JWT access tokens.¶

Change Controller:

IETF¶

Specification Document:

Section 3.2 of this document¶

11.4. OAuth 2.0 Bearer Token Error Values Registration

This specification registers the following error code in the "OAuth 2.0 Bearer Token Error Values" registry established by [RFC6750]:¶

Name:

insufficient_authorization¶

Error Usage Location:

Resource server error response using the WWW-Authenticate header per [RFC6750].¶

Related Error Codes:

The existing insufficient_scope error defined in [RFC6750] addresses scope insufficiency. insufficient_authorization (this specification) addresses the case where the resource server returns structured boundary constraints (schema_profile) for clients capable of constructing schema-based authorization requests.¶

Reference:

Section 5 of this document¶

11.5. WWW-Authenticate Parameter Definition

This specification defines a new parameter for use in the WWW-Authenticate header field with the Bearer authentication scheme, as defined in [RFC6750].¶

Parameter Name:

schema_profile¶

Parameter Usage Location:

WWW-Authenticate response header field, used in resource server error responses per [RFC6750] Section 3.¶

Parameter Description:

A base64url-encoded JSON object containing structured boundary constraint descriptors and authorization requirements that guide the client toward obtaining sufficient authorization. The structure is defined in Section 5 of this document.¶

Change Controller:

IETF¶

Specification Document:

Section 5 of this document¶

RFC 6750 does not establish an IANA sub-registry for Bearer authentication scheme parameters. This section serves as the specification reference for the schema_profile parameter.¶

A.1. Scope of AS Review Policies

An AS review policy expresses the AS's approval principles: per-client allowlists of behavioral patterns, organizational limits (e.g., maximum transaction amounts per client class), and rules requiring resource owner consent for specific boundary combinations. When an instance is submitted, the AS evaluates the instance's structured fields against these review policies and approves or rejects the request.¶

AS review policies MUST NOT be transmitted to clients or embedded in access tokens. They are an implementation detail of the Authorization Server; the only normative artifacts on the wire are the schema instance and, optionally, the schema_ref identifier assigned by the AS. Because the AS never executes client-supplied content and clients never observe the review policies, the attack surface associated with policy exchange is eliminated (see the "No Executable Content" subsection of Section 9).¶

A.2. Example: Rego Review Policy

The following non-normative example shows how an AS might implement one review rule using Rego [Rego] and Open Policy Agent (OPA) [OPA]. The rule approves a transaction_authority instance only if the requested amount limit is within the client's registered maximum and consent is recorded when the amount exceeds a consent threshold:¶

package as.review

default approve = false

approve if {
  input.instance.type == "transaction_authority"
  input.instance.boundary.total_amount_limit.value <= input.client.max_amount
  (
    input.instance.boundary.total_amount_limit.value <= 100
    or input.consent_recorded == true
  )
}

Here input.instance is the schema instance submitted by the client, input.client is the client's registration metadata, and input.consent_recorded reflects the outcome of the resource owner interaction. Equivalent rules could be written in any rule system; the choice of Rego is illustrative only.¶