Domain-Specific Authorization Schemas for OAuth 2.0

1.1. Scope

This specification defines the profile: how schema instances are constructed and discovered, requested, reviewed, bound to access tokens, given a lifecycle, verified at resource servers, and negotiated through structured error responses.¶

The governance layer is out of scope: how an organization records authorization decisions as approval evidence is defined by complementary work. This specification defines the binding-layer state machine on which such governance decisions act; it does not define the decisions themselves.¶

Guardrails (Section 3.5) are type-scoped: a guardrail instance of one schema type constrains instances of that type only. The only cross-type apparatus available above specific schemas is the RAR common fields (actions, locations) of [RFC9396] Section 2. This specification does not define a universal guardrail spanning multiple schema types.¶

Out of scope: schema definitions for particular domains are expected in follow-up specifications, and the transaction_authority type (Appendix "Example: transaction_authority") is a non-normative worked example; how a deployment determines work membership or plans task sequences is not specified; how the Authorization Server expresses its internal review policies is an implementation decision.¶

3.1. Type Identifiers

The type field of a schema instance identifies the domain-specific authorization schema it instantiates. A type value is either:¶

• a short name: a lowercase ASCII string with optional underscore separators, no spaces, no leading or trailing whitespace; or¶

• an HTTPS URI: e.g., https://api.shop.example/schemas/transaction_v2.¶

RFC 9396 imposes no syntax constraints on the type field, so URI-valued types are wire-compatible. The registry of Section 12.1 is an optional endorsement channel for schemas intended for cross-vendor reuse, not an admission control (the hard gates are "known to the Authorization Server" on the AS side and deterministic resolvability on the Resource Server side).¶

Type identity is exact string match: two instances have the same type if and only if their type values are byte-for-byte identical. Implementations MUST NOT normalize URI type values.¶

A URI type value SHOULD be dereferenceable: an HTTP GET over TLS returns a JSON Schema [JSONSchema] document describing the structure of conforming instances. This aligns with the schema / schema_uri attributes served by the authorization details types metadata endpoint of [I-D.ietf-oauth-rar-metadata-remediation]. The document obtained by dereferencing is a descriptive input for instance construction, not an authorization and not authoritative for the AS's validation, which is performed against the schema known to the AS (fail-safe: an instance constructed from a drifted document fails validation). The same schema MUST NOT be simultaneously identified by both a short name and a URI; registered URI types MUST commit to semantic immutability: changed semantics require a new URI (see Section 12.1).¶

3.2. Framework Requirements

Authorization details types intended for use as domain-specific authorization schemas MUST satisfy the following requirements. These requirements apply to every schema used with this framework, whether or not its type is registered:¶

1. Structured Constraints: The type MUST define its constraint fields with unambiguous data types and deterministic verification semantics, such that a Resource Server can verify a behavior against an approved instance without policy interpretation;¶

2. Allowlist Semantics: The type MUST define constraint fields that express what is permitted: a behavior is permitted only when explicitly allowed by the present constraint fields of the approved instance;¶

3. Common Fields: The type uses the common fields defined in Section 2 of [RFC9396] (actions, locations, datatypes, identifier) to declare a declarative upper bound on the requested operations and resources;¶

4. Subset Definition: The type SHOULD define what it means for one instance to be a subset of another, to support progressive narrowing in Token Exchange (Section 9). There is no standardized mechanism for comparing two arbitrary authorization details requests (Section 6.1 of [RFC9396]); each schema type defines its own subset semantics under this requirement.¶

Schema instances used with this specification MUST adhere to the following:¶

1. Schema Conformance: Every instance MUST validate against the definition of the schema it instantiates. Unknown fields not defined by the schema MUST be rejected by the Authorization Server.¶

2. Constraint Values: Constraint values MUST be within the ranges and formats defined by the schema (e.g., quantities with units such as a currency or a count, or timestamps per [RFC3339]).¶

3. Deny by Default: An instance constrains behavior only through its present fields. Any behavior not consistent with every present constraint is denied; an empty or absent boundary grants no behavior (Section 7).¶

Because instances are structured data rather than executable code, verification at the Resource Server is deterministic constraint evaluation; review logic is an Authorization Server implementation detail.¶

3.3. Framework Fields

The following fields are defined by this framework and MAY appear in instances of any domain-specific authorization schema. Schema types MUST NOT redefine them.¶

work_id:

OPTIONAL. The AS-assigned identifier of an approved work instance. When approving a work instance, the AS assigns a unique work_id and makes it available to the client (e.g., in the enriched authorization_details of the issued access token or in the token response). Task-level requests include the AS-assigned work_id verbatim so that the Resource Server evaluates each task against the approved work boundaries (Section 3.4). Clients MUST NOT invent work_id values.¶

work_ref:

OPTIONAL. An AS-assigned reference to the approved work instance, embedded by the AS in the enriched authorization_details of a task token, from which the Resource Server resolves the work instance via local cache or token introspection (Section 7). It is not client-supplied.¶

evidence_ref:

OPTIONAL. A reference to an approval evidence record associated with the approval decision for this instance. This specification defines only the carriage of the field; the format of the reference and the resolution of the record are outside its scope (see [I-D.liu-oauth-authorization-evidence]). The presence or successful verification of approval evidence does not establish current permission (Section 8).¶

3.4. Bounded Work and Task Requests

An overall objective delegated to a client, such as "help me find and buy a laptop", is modeled as a bounded work. A client requests work authorization by submitting a schema instance that captures the proposed boundaries for the entire work, for example permitted operations, targeted resources, and a time window. When the Authorization Server approves the work instance, it assigns a work_id (Section 3.3) and makes it available to the client, e.g., in the enriched authorization_details of the issued access token or in the token response. Subsequent authorization requests for individual tasks performed under the work include the same work_id and are verified against the work's approved boundaries: at runtime, the Resource Server evaluates each requested task against the work instance through deterministic constraint evaluation (Section 7), a task-in-work evaluation request.¶

The approved schema instance represents the current authorized state of the work. Schemas MAY define cumulative constraints, whose values the Resource Server accumulates across the tasks performed under the work; derived authorizations can progressively narrow the work boundaries via Token Exchange subset semantics (Section 9).¶

3.5. Guardrail Instances

A guardrail instance is a schema instance used as an upper bound on other instances of the same type. An instance is a hard constraint on behaviors; a guardrail is a hard constraint on instances. Guardrails introduce no new mechanism: they reuse the schema instance structure, the subset semantics of the type, and deny-by-default. The core rule is one sentence:¶

• Every schema instance approved under this framework MUST be a subset of every guardrail instance of the same type (byte-exact type identity, Section 3.1) that is in effect for that approval.¶

Guardrail instances come from two sources:¶

• Administrative guardrails are configured by deployment administrators or organizational policy. They express hard ceilings, such as regulatory requirements, risk appetite, and organizational limits, and clients cannot propose instances beyond them.¶

• Proposed guardrails are submitted by clients and become effective upon AS approval. Typical uses are limits set by the resource owner ("at most 500 USD this month", in a payment schema), client self-limitation, and subject-level limits. A proposed guardrail that represents a user-set limit or a subject-level limit MUST obtain the resource owner's consent before the AS approves it; a proposed guardrail that purely self-limits the client MAY be approved according to AS policy.¶

Two rules prevent the obvious implementation mistakes:¶

• The guardrail check is a necessary condition for approval, never a sufficient one. Approval of an instance is the conjunction of schema conformance, the AS's approval basis (Section 6.4), and the guardrail subset check. An implementation MUST NOT treat a subset relation between an instance and a guardrail as authorization to approve the instance: a wide guardrail, once approved, never exempts subsequent instances from the remaining checks.¶

• A proposed guardrail must itself respect the administrative ceiling. When administrative guardrails exist for a type, a proposed guardrail of that type MUST be a subset of every administrative guardrail of that type to be approvable. Clients may propose to tighten, never to exceed.¶

When multiple guardrails are in effect, an instance must be a subset of each: their constraints compose by intersection. A guardrail that omits a constraint field defined by the schema does not constrain that field. This is distinct from deny-by-default, which bounds a behavior relative to the approved instance: the instance is the complete statement of what is permitted, while each guardrail bounds only the fields it mentions. Guardrail instances sit above work and task instances; the same schema and subset machinery is reused at every level.¶

The lifecycle of guardrails follows the instance lifecycle (Section 8) with two clarifications. Tightening a guardrail applies to subsequently approved instances immediately; the AS SHOULD revoke already-approved instances that exceed the tightened guardrail, reusing existing mechanisms (token revocation, token introspection reporting the tokens inactive, and RS deny-by-default); whether such revocation is enforced immediately is a deployment configuration. Removing a guardrail removes a ceiling and revokes nothing: ending a constraint is not ending an authorization, and implementations MUST NOT conflate the two. Relaxing a guardrail (e.g., raising a limit) is not a derivation and MUST NOT be performed via Token Exchange: it requires a new, independent authorization decision, with resource owner consent where required and revocation or supersession of the old guardrail, consistent with the monotonic narrowing principle, which constrains derivation chains, not new authorizations. Automatic widening is prohibited.¶

An administrative guardrail limiting a transaction type to a total of 1000 USD and a fixed set of operations:¶

{
  "type": "transaction_authority",
  "boundary": {
    "total_amount_limit": { "value": 1000, "currency": "USD" },
    "operations": ["ecommerce.search", "ecommerce.cart.add",
                   "ecommerce.purchase"]
  }
}

A client then requesting an instance of the same type with total_amount_limit of 1200 USD exceeds the guardrail and is rejected by the AS, whatever the approval basis would otherwise conclude.¶

Security considerations specific to guardrails (probing, the descriptive nature of guardrail documents, and the closed-operator restriction) are described in Section 10. The type-scoped limitation of guardrails is recorded in Section 1.1.¶

3.6. schema_ref Claim

The schema_ref claim is an OPTIONAL shorthand mechanism for referencing an approved schema instance in access tokens. When the AS uses Rich Authorization Requests (RAR), the enriched authorization_details array in the access token (per Section 7.1 of [RFC9396]) is the primary mechanism for carrying the approved schema instance. The schema_ref claim MAY be used as a lightweight alternative when:¶

• The inline instance content would make the access token exceed practical size limits (see Section 10);¶

• The Resource Server already has a cached copy of the instance and only needs an identifier to look it up;¶

• The deployment uses opaque (non-JWT) access tokens where token introspection [RFC7662] provides the instance content.¶

When schema_ref is used, the AS performs instance registration as described in Section 6.¶

Claim Name:

schema_ref¶

Claim Type:

String¶

Usage:

JWT access tokens (the claim may also appear in introspection responses for opaque tokens per [RFC7662])¶

The schema_ref claim value is a string containing the unique instance identifier assigned by the Authorization Server during instance registration.¶

{
  "iss": "https://as.example.com",
  "sub": "agent-xyz",
  "schema_ref": "schema-instance-abc123"
}

The Resource Server uses this identifier to look up the full approved instance from a local cache or via token introspection ([RFC7662]).¶

5.1. Error Response Format

When a client's request lacks sufficient authorization, the resource server returns an error response with a WWW-Authenticate header containing the insufficient_authorization error code, the error code defined and registered by [I-D.ietf-oauth-rar-metadata-remediation], together with a schema_profile_uri parameter defined by this specification. The parameter is a URI referencing a schema profile document, a machine-readable JSON description of the required authorization conditions.¶

HTTP/1.1 401 Unauthorized
Content-Type: application/json
WWW-Authenticate: Bearer error="insufficient_authorization",
  schema_profile_uri="https://resource.example/profiles/purchase"

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

Per Section 3 of [RFC6750], the error response includes the WWW-Authenticate header with the error code and a JSON error body. The schema_profile_uri parameter carries a URI rather than an encoded payload: this keeps the header well within practical size limits and follows the precedent of the resource_metadata parameter in Protected Resource Metadata ([RFC9728]). The client fetches the schema profile document referenced by the URI with an HTTP GET request over TLS. The fetched document has the following structure:¶

{
  "schema_type": "transaction_authority",
  "required_scope": ["purchase.create"],
  "required_claims": ["agent_id", "user_id"],
  "constraints": {
    "boundary.total_amount_limit": {
      "type": "object",
      "description": "Maximum cumulative transaction amount",
      "required": true
    },
    "boundary.operations": {
      "type": "array",
      "enum": ["ecommerce.search", "ecommerce.cart.add",
               "ecommerce.purchase"],
      "description": "Permitted operations",
      "required": true
    }
  },
  "confirmation_required": true,
  "auth_server": "https://as.example.com"
}

When the schema_type of a profile document is a URI type value (Section 3.1), the client MAY dereference it to obtain the type's JSON Schema description, which complements the profile's constraint descriptors with the structural definition of the schema.¶

5.2. Relationship to insufficient_scope

[RFC6750] defines the insufficient_scope error for cases where the access token lacks the scopes required by the resource server. The insufficient_authorization error used by 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 a client holding an access token with scope purchase that attempts to create a 500 USD purchase. The resource server requires a schema instance that limits transaction amounts and requires user confirmation for purchases above 200 USD. 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_uri allows the resource server to convey both the missing boundary constraints (e.g., boundary.total_amount_limit) and the need for user confirmation (confirmation_required: true) in a machine-parseable form that the client 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. Relationship to RAR Metadata and Error Remediation

The error code and type-level metadata defined by [I-D.ietf-oauth-rar-metadata-remediation] address a related but different granularity than the reverse-guided mechanism defined here. That document registers the insufficient_authorization error code used above and defines the authorization_remediation error parameter, whose decoded contents carry actionable authorization details objects the client can request directly. This specification defines the schema_profile_uri parameter, which references a reusable profile document describing the shape of acceptable instances.¶

The two remediation styles are complementary:¶

• an RS that knows the exact authorization details objects it needs (e.g., a specific direct debit mandate) returns them inline via authorization_remediation;¶

• an RS that publishes reusable behavioral requirements, as in multi-tenant or federated environments where many clients need the same shape of authorization, references a profile document via schema_profile_uri, which is cacheable (the URI MAY be used as a cache key) and additionally discoverable upfront via the schema_profiles attribute in Protected Resource Metadata.¶

A resource server MAY combine both. Profile documents defined here use schema_type and JSON Schema descriptor vocabulary so they remain compatible with the type-level JSON Schema descriptions served by the metadata endpoint of that document.¶

5.4. Schema Profile Structure

The schema profile document contains the following fields:¶

schema_type:

REQUIRED. The authorization details type identifier (a short name or URI, Section 3.1; e.g., transaction_authority as defined in Appendix "Example: transaction_authority") that the client MUST use in the constructed schema instance. Because the constraint descriptors below use the field names of this schema, the client can map a profile document to an instance mechanically.¶

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 dotted path into the schema instance structure (e.g., boundary.total_amount_limit), using the field names of the schema identified by schema_type. Each value is a descriptor object using the JSON Schema vocabulary [JSONSchema]: type (data type), description (human-readable explanation), enum (allowed values), and required (boolean, whether a value for this path must be present in the instance).¶

confirmation_required:

OPTIONAL. Boolean indicating whether explicit user authorization is required for the requested behavioral boundaries. If true, the client 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 client 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.5. Profile-to-Instance Example

Given the profile document above, a client constructs a transaction_authority instance that satisfies every constraint descriptor: the instance uses the type named by schema_type, the paths under constraints are populated with conforming values, and the request includes the scope named by required_scope:¶

{
  "scope": "purchase.create",
  "authorization_details": [
    {
      "type": "transaction_authority",
      "domain": "ecommerce",
      "boundary": {
        "total_amount_limit": { "value": 200, "currency": "USD" },
        "operations": ["ecommerce.search", "ecommerce.cart.add",
                       "ecommerce.purchase"]
      },
      "actions": ["search", "cart.add", "purchase"]
    }
  ]
}

The client submits this authorization request to the authorization server identified by auth_server. Because confirmation_required is true, the client initiates the user consent flow before the token is issued.¶

5.6. Client Adaptive Behavior

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

1. Fetch the schema profile document referenced by schema_profile_uri over TLS and parse it to understand the authorization requirements.¶

2. Verify that the specified auth_server is trusted before proceeding.¶

3. Construct a new authorization request including the required scopes and a schema instance of the type named by schema_type that satisfies the constraints specified in the profile document, 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 ([RFC8414]) and submit the authorization request.¶

This allows clients to obtain authorization requirements dynamically instead of pre-programming them per resource server.¶

During multi-step task execution, a client may encounter behavioral drift: situations where the next behavior in its plan falls outside the approved schema constraints. When this occurs, the client 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 client's task context and the confirmation_required signal from the resource server.¶

5.7. Denial Semantics

When the Resource Server denies a request under this framework, the reason falls into one of three classes, and the correct client response differs by class:¶

1. The authorization has ended (withdrawn, terminated, expired, or completed, Section 8): the operation is impermissible no matter how valid the credential appears, and the client MUST NOT retry it under the same or an equivalent authorization. Work under an ended authorization requires a fresh authorization decision.¶

2. The operation is outside the approved bounds while the authorization is active: the client's options are a new authorization decision (potentially via reverse-guided guidance), behavioral degradation, or human confirmation for an expanded boundary (Section 5.6).¶

3. Only the credential is invalid (e.g., the access token has expired while the authorization remains active): the client obtains a new credential for the same authorization (e.g., via the refresh token, Section 6.5).¶

The resource server signals class 3 with the invalid_token error of [RFC6750] and classes 1 and 2 with insufficient_authorization (with a schema_profile_uri parameter when guidance is available); distinguishing class 1 from class 2 in the response is deployment policy, for example via error_description, and a client that cannot distinguish them MUST treat the denial as class 2 and attempt remediation at most once before stopping.¶

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, Appendix "Example: transaction_authority"), whether a registered short name or a URI the AS recognizes.¶

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 [RFC3339] 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.¶

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, including its lifecycle state (Section 8);¶

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

6.3. Error Responses

If instance validation or approval fails, the AS MUST return an error response per Section 5.2 of [RFC6749]. The following table consolidates the error taxonomy for schema-instance-related conditions. The AS selects the error code based on the nature of the failure:¶

Example error response:¶

{
  "error": "invalid_request",
  "error_description": "Invalid schema instance: boundary.total_amount_limit.value must be a non-negative number"
}

6.4. Approval Basis

The Authorization Server's approval of a schema instance is not limited to conformance validation. The AS determines whether the proposed behavioral boundaries are appropriate for the specific client and resource owner based on the following factors:¶

• Client registration metadata: pre-registered client capabilities, allowed scopes, and trust level established during OAuth 2.0 Dynamic Client Registration [RFC7591] or out-of-band provisioning.¶

• Organizational review policies: administrative rules defining which behavioral patterns are permitted for specific client types, user roles, or resource classes within the deployment. These rules are internal to the AS and are never carried in authorization requests or access tokens.¶

• Resource owner consent: explicit authorization from the approver (Section 2) approving the submitted behavioral boundaries, obtained through the OAuth 2.0 authorization interaction (e.g., the consent screen in the authorization code flow, or the interaction_uri mechanism in JWT Grant Interaction Response).¶

• Token binding context: the authorization grant type, requested scopes, and other token request parameters that establish the context in which the schema instance is reviewed.¶

• Guardrail subset checks: for every guardrail instance in effect for the type (Section 3.5), the submitted instance MUST be a subset. The guardrail check is a necessary condition for approval, never a sufficient one: approval is the conjunction of schema conformance, the approval factors in this section, and the guardrail subset checks, and no conjunct may substitute for the others.¶

For example, the AS MAY maintain a per-client allowlist of approved behavioral patterns (e.g., permitted actions, maximum transaction limits, allowed resource classes). When a new schema instance is submitted, the AS verifies that the declared RAR common fields (actions, locations) and the boundary constraints fall within the client's pre-approved boundaries. If the proposed instance exceeds these boundaries, the AS SHOULD return invalid_scope when the behavioral boundaries exceed the client's registered permissions, or invalid_request for other review violations (see the consolidated taxonomy in Section 6.3). Alternatively, the AS MAY escalate to the resource owner for explicit consent before issuing the token.¶

Because instances are structured data with schema-defined fields, this review is a comparison of constraint values against the AS's approval principles, rather than analysis of arbitrary program code.¶

The schema instance carried in the access token is therefore backed by both schema conformance and the review policies governing the client and resource owner. The Resource Server can rely on this when enforcing the approved instance at runtime.¶

6.5. Refresh Token Handling

When an access token carrying an approved schema instance expires and the client obtains a new access token via a refresh token, the AS re-binds the same approved instance to the new access token. The client does not resubmit the instance in the refresh request; the AS retrieves it from the authorization session state associated with the refresh token.¶

Refresh is a token-renewal operation, not an authorization request. A refresh request MUST NOT modify the approved schema instance. If the client's task requires different behavioral boundaries, the client MUST either initiate a new authorization request (using the reverse-guided mechanism described in Section 5 if applicable) or use Token Exchange ([RFC8693]) as described in Section 9. Both paths go through the full validation and approval process defined in this section.¶

The refresh token lifetime SHOULD NOT exceed the validity period of the associated schema instance. If the instance has a natural expiration (e.g., a time-window constraint), the AS SHOULD align the refresh token lifetime accordingly.¶

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 Section 7.1 of [RFC9396].¶

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

• Work Instances: When the task token's enriched authorization_details carries an AS-assigned work_ref, resolve the approved work instance from the local cache or via token introspection (Section 3.4).¶

7.2. Constraint Evaluation

After extracting the approved instance from the token, the RS verifies each client 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.¶

When a behavior is performed under an approved work (see Section 3.4), these checks constitute task-in-work evaluation: the RS verifies the task against the work instance's boundary constraints, including cumulative constraints, where defined by the schema, evaluated across all tasks performed under the work.¶

Cumulative constraints are evaluated against state maintained by the Resource Server, which observes the underlying business activity (e.g., cart and order state in an e-commerce deployment). The Authorization Server approves the bound but does not track runtime usage.¶

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 client toward a new authorization;¶

• If the instance cannot be retrieved or parsed, or if the authorization bound to the token has ended (Section 8): Deny with 403 Forbidden.¶

10.1. Trust Model

The 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 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 an overly 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 constraints on top of the token-bound instance, for example by deploying guardrail instances (Section 3.5), which are schema-native upper bounds the RS-side deployment can also enforce deterministically, or by:¶

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

10.2. No Executable Content

Schema instances carried in authorization requests and access tokens are structured data conforming to schema definitions; they contain no executable code. This eliminates the class of attacks associated with client-submitted code, including non-terminating or resource-intensive evaluations, catastrophic regular-expression backtracking, and built-in functions with side effects (e.g., outbound HTTP requests performed during 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.¶

10.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 Section 2.2 of [RFC7662].¶

Resource Servers SHOULD invalidate cached instance content when the associated access token expires. If the AS revokes a registered instance before the token expires, because the work was withdrawn or terminated (Section 8), the AS SHOULD also revoke the associated access token, causing subsequent introspection calls to return active: false per [RFC7662]. 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).¶

10.4. Instance Size Limits

Instances embedded inline within authorization_details increase the size of authorization requests and access tokens, and deployments commonly face size limits on HTTP headers carrying JWT access tokens. Deployments facing such constraints can use the schema_ref claim (Section 3.6), which binds a reference to the AS-registered instance instead of inline content.¶

10.5. Reverse-Guided Authorization

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

• Auth Server Verification: Clients MUST verify that the auth_server specified in the schema profile document 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, clients MUST NOT submit authorization requests to the specified auth_server. Clients 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: Clients SHOULD validate that constraint values are reasonable before including them in authorization requests. Malicious resource servers might attempt to induce clients to request excessive permissions.¶

• Profile Document Retrieval: The schema_profile_uri is received from the resource server in the error response. Clients MUST fetch the profile document over TLS and SHOULD verify that the URI origin matches the resource server or a domain under its control. The profile document is guidance from the resource server; it does not constitute authorization, and only the Authorization Server can approve a schema instance.¶

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

10.6. Guardrails

Implementations of guardrail instances (Section 3.5) MUST consider the following:¶

• Guardrail probing: A client that submits proposed guardrails to discover the AS's ceilings learns no more than error responses to over-broad instances already reveal; the approval boundary is exposed either way. ASs MAY rate-limit proposed-guardrail submissions nonetheless.¶

• Descriptive inputs: Guardrail documents and metadata are descriptive inputs, like schema documents. The document a client dereferences may differ from the AS's known copy; validation failure is fail-safe, since the AS validates instances and proposed guardrails against its own knowledge.¶

• Closed operators only: Guardrail fields are limited to the closed constraint fields defined by the schema and closed comparison operators. Conditional logic MUST NOT be introduced through guardrails: a guardrail is an upper bound, not a policy decision point. Complex conditions belong to the AS's review policy, which is not carried on the wire.¶

12.1. Domain-Specific Authorization Schema Types Registry

This specification establishes a new IANA registry titled "Domain-Specific Authorization Schema Types" for identifiers used in the type field of schema instances carried in authorization_details. The registry is an endorsement channel for schemas intended for cross-vendor reuse; schemas MAY be used with this framework without registration, subject to the "known to the Authorization Server" condition of Section 6.¶

Registration requests MUST be sent to the oauth-ext-review@ietf.org mailing list for review and comment, using the "Specification Required" policy ([RFC8126]).¶

The Designated Expert for this registry SHOULD verify that each registration request satisfies the following criteria before approval:¶

1. The proposed type identifier is syntactically valid: a lowercase ASCII string with optional underscore separators, no spaces, no leading or trailing whitespace, or an HTTPS URI;¶

2. The referenced specification defines a complete schema: the full set of fields, their types and formats, which fields are required, deny-by-default semantics, and subset semantics for use in Token Exchange, consistent with the framework requirements defined in Section 3;¶

3. The schema carries structured data only and defines no executable content;¶

4. The identifier does not conflict with or confusingly resemble existing registrations, and the same schema is not identified by both a short name and a URI. For URI identifiers, the URI's semantics are immutable: changed semantics require a new URI.¶

Future registrations MUST include:¶

• Type identifier (lowercase ASCII string or HTTPS URI);¶

• Description of the schema and its intended domain;¶

• Reference to the specification defining the schema;¶

• Change controller.¶

For URI identifiers, the registration SHOULD also include a hash of the schema document.¶

The registry is initially empty. The transaction_authority example in Appendix "Example: transaction_authority" is non-normative and is not registered.¶

12.2. 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.6 of this document¶

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

Parameter Usage Location:

WWW-Authenticate response header field, used in resource server error responses that carry the insufficient_authorization error code defined by [I-D.ietf-oauth-rar-metadata-remediation].¶

Parameter Description:

A URI referencing a schema profile document containing structured boundary constraint descriptors and authorization requirements that guide the client toward obtaining sufficient authorization. The document 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_uri parameter.¶

12.4. OAuth Protected Resource Metadata Registration

This specification registers the following attribute in the "OAuth Protected Resource Metadata" registry established by [RFC9728]:¶

Metadata Name:

schema_profiles¶

Metadata Description:

Array of URIs referencing schema profile documents in the format defined in Section 5 of this document, describing the authorization required by this resource server.¶

Change Controller:

IETF¶

Specification Document:

Section 5 of this document¶

12.5. Error Code Usage

This specification does not register a new error code. The reverse-guided mechanism uses the insufficient_authorization error code defined and registered by [I-D.ietf-oauth-rar-metadata-remediation] in the "OAuth 2.0 WWW-Authenticate Error Code Registry" established by that document.¶

13.1. Normative References

[RFC9396]

Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, <https://www.rfc-editor.org/info/rfc9396>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC9728]

Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0 Protected Resource Metadata", RFC 9728, DOI 10.17487/RFC9728, April 2025, <https://www.rfc-editor.org/info/rfc9728>.

[I-D.ietf-oauth-rar-metadata-remediation]

Zehavi, Y., "OAuth 2.0 RAR Metadata and Error Remediation", Work in Progress, Internet-Draft, draft-ietf-oauth-rar-metadata-remediation-00, 23 August 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar-metadata-remediation-00>.

[RFC3339]

Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/info/rfc3339>.

[RFC7662]

Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, <https://www.rfc-editor.org/info/rfc7662>.

[RFC6750]

Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, <https://www.rfc-editor.org/info/rfc6750>.

[RFC6749]

Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/info/rfc6749>.

[RFC8693]

Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, <https://www.rfc-editor.org/info/rfc8693>.

[RFC7009]

Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, August 2013, <https://www.rfc-editor.org/info/rfc7009>.

[RFC6973]

Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC9068]

Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021, <https://www.rfc-editor.org/info/rfc9068>.

13.2. Informative References

[JSONSchema]

JSON Schema, "JSON Schema: A Media Type for Describing JSON Documents", 2020, <https://json-schema.org/draft/2020-12/json-schema-core.html>.

[I-D.liu-oauth-authorization-evidence]

Liu, D., Zhu, J., Krishnan, S., and A. Parecki, "Authorization Evidence and Audit Trail for OAuth 2.0 Access Tokens", Work in Progress, Internet-Draft, draft-liu-oauth-authorization-evidence-01, 22 June 2026, <https://datatracker.ietf.org/doc/html/draft-liu-oauth-authorization-evidence-01>.

[I-D.parecki-oauth-jwt-grant-interaction-response]

Parecki, A., Campbell, B., and D. Liu, "JWT Authorization Grant Interaction Response", Work in Progress, Internet-Draft, draft-parecki-oauth-jwt-grant-interaction-response-00, 24 March 2026, <https://datatracker.ietf.org/doc/html/draft-parecki-oauth-jwt-grant-interaction-response-00>.

[RFC8414]

Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, <https://www.rfc-editor.org/info/rfc8414>.

[RFC7591]

Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, July 2015, <https://www.rfc-editor.org/info/rfc7591>.

[I-D.zehavi-oauth-authority-metadata]

Zehavi, Y., "OAuth 2.0 Authority Metadata", Work in Progress, Internet-Draft, draft-zehavi-oauth-authority-metadata-00, 11 October 2026, <https://datatracker.ietf.org/doc/html/draft-zehavi-oauth-authority-metadata-00>.

Machine-Readable Constraint Semantics Beyond JSON Schema

Clients require semantics such as deny-by-default, cross-field relationships, and cumulative-constraint evaluation in a machine-readable form to construct conforming instances autonomously. Candidate approaches include (a) a closed declarative constraint-operator vocabulary, (b) signed server-side policy attachments evaluated in trusted environments, and (c) policy languages such as Rego, used inside the Authorization Server to implement its review of submitted instances. Approach (c) must be reconciled with the No Executable Content principle of this specification (Section 10.2). Guardrail instances (Section 3.5) cover the hard-constraint cases; policy languages offer increment only where approval policies need complex cross-field derivation. Whether policy languages can also be carried in reverse-guided responses (Section 5) has been discussed, but no conclusion has been reached. Working group guidance is sought.¶

URI-Valued Type Identifiers

This specification allows authorization details type values that are HTTPS URIs (Section 3.1). The RAR metadata mechanisms of [I-D.ietf-oauth-rar-metadata-remediation] key type metadata by type name; carrying URI values in those keys is structurally compatible with the JSON map, but the assumption that type names are simple strings is widespread in that document and its implementations. Coordination on the interoperability of URI-valued types is expected; see Section 5.3.¶

Per-Instance Subset Policy Switch

This specification makes subset verification unconditional in Token Exchange (Section 9). Deployments requiring relaxation semantics may request guidance from the working group.¶