Javascript disabled? Like other modern websites, the IETF Datatracker relies on Javascript. Please enable Javascript for full functionality.

Domain-Specific Authorization Schemas for OAuth 2.0
draft-liu-oauth-authorization-schemas-00

Versions:

This document is an Internet-Draft (I-D). Anyone may submit an I-D to the IETF. This I-D is not endorsed by the IETF and has no formal standing in the IETF standards process.

Document	Type	Active Internet-Draft (individual)
	Author	Dapeng Liu
	Last updated	2026-10-12
	RFC stream	(None)
	Intended RFC status	(None)
	Formats	txt html xml htmlized bibtex bibxml
Stream	Stream state	(No stream defined)
	Consensus boilerplate	Unknown
	RFC Editor Note	(None)
IESG	IESG state	I-D Exists
	Telechat date	(None)
	Responsible AD	(None)
	Send notices to	(None)

Email authors IPR References Referenced by Nits Nits v3 Search email archive

draft-liu-oauth-authorization-schemas-00

Web Authorization Protocol D. Liu
Internet-Draft Alibaba
Intended status: Standards Track 12 October 2026
Expires: 15 April 2027

Domain-Specific Authorization Schemas for OAuth 2.0
draft-liu-oauth-authorization-schemas-00

Abstract

This specification defines a framework for constructing fine-grained
authorization requests in OAuth 2.0 using domain-specific
authorization schemas: structured definitions of behavioral
boundaries for a particular application domain. Schema instances are
carried in authorization requests via authorization_details; upon
approval, the instance governs the authorization associated with the
issued access token. Approved instances have a lifecycle: they
become active upon approval and end, with defined protocol
consequences for token issuance, refresh, and resource access.
Resource servers verify client behaviors against the approved schema
instance at runtime through deterministic constraint evaluation.
Authorization servers review requested schema instances against
server-side authorization policies. This specification also defines
a negotiation pattern, reverse-guided authorization, allowing
resource servers to reference a schema profile in error responses,
guiding clients toward the authorization required for their next
action.

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on 15 April 2027.

Liu Expires 15 April 2027 [Page 1]
Internet-Draft Authorization Schemas October 2026

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Domain-Specific Authorization Schema . . . . . . . . . . . . 6
3.1. Type Identifiers . . . . . . . . . . . . . . . . . . . . 6
3.2. Framework Requirements . . . . . . . . . . . . . . . . . 7
3.3. Framework Fields . . . . . . . . . . . . . . . . . . . . 8
3.4. Bounded Work and Task Requests . . . . . . . . . . . . . 9
3.5. Guardrail Instances . . . . . . . . . . . . . . . . . . . 9
3.6. schema_ref Claim . . . . . . . . . . . . . . . . . . . . 11
4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Reverse-Guided Authorization . . . . . . . . . . . . . . . . 13
5.1. Error Response Format . . . . . . . . . . . . . . . . . . 13
5.2. Relationship to insufficient_scope . . . . . . . . . . . 15
5.3. Relationship to RAR Metadata and Error Remediation . . . 15
5.4. Schema Profile Structure . . . . . . . . . . . . . . . . 16
5.5. Profile-to-Instance Example . . . . . . . . . . . . . . . 17
5.6. Client Adaptive Behavior . . . . . . . . . . . . . . . . 18
5.7. Denial Semantics . . . . . . . . . . . . . . . . . . . . 18
6. Authorization Server Processing . . . . . . . . . . . . . . . 19
6.1. Instance Validation . . . . . . . . . . . . . . . . . . . 19
6.2. Instance Registration . . . . . . . . . . . . . . . . . . 20
6.3. Error Responses . . . . . . . . . . . . . . . . . . . . . 20
6.4. Approval Basis . . . . . . . . . . . . . . . . . . . . . 22
6.5. Refresh Token Handling . . . . . . . . . . . . . . . . . 23
7. Resource Server Enforcement . . . . . . . . . . . . . . . . . 23
7.1. Instance Retrieval . . . . . . . . . . . . . . . . . . . 24
7.2. Constraint Evaluation . . . . . . . . . . . . . . . . . . 24
7.3. Enforcement Decision . . . . . . . . . . . . . . . . . . 25
8. Instance Lifecycle . . . . . . . . . . . . . . . . . . . . . 25
9. Token Exchange (RFC 8693) . . . . . . . . . . . . . . . . . . 28
10. Security Considerations . . . . . . . . . . . . . . . . . . . 29

Liu Expires 15 April 2027 [Page 2]
Internet-Draft Authorization Schemas October 2026

10.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . 29
10.2. No Executable Content . . . . . . . . . . . . . . . . . 30
10.3. Instance Integrity . . . . . . . . . . . . . . . . . . . 30
10.4. Instance Size Limits . . . . . . . . . . . . . . . . . . 30
10.5. Reverse-Guided Authorization . . . . . . . . . . . . . . 31
10.6. Guardrails . . . . . . . . . . . . . . . . . . . . . . . 31
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 32
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
12.1. Domain-Specific Authorization Schema Types Registry . . 33
12.2. JWT Access Token Claims Registration . . . . . . . . . . 34
12.3. WWW-Authenticate Parameter Definition . . . . . . . . . 34
12.4. OAuth Protected Resource Metadata Registration . . . . . 35
12.5. Error Code Usage . . . . . . . . . . . . . . . . . . . . 35
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
13.1. Normative References . . . . . . . . . . . . . . . . . . 35
13.2. Informative References . . . . . . . . . . . . . . . . . 37
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 38
Example: transaction_authority . . . . . . . . . . . . . . . . . 38
Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Machine-Readable Constraint Semantics Beyond JSON Schema . . . 41
URI-Valued Type Identifiers . . . . . . . . . . . . . . . . . . 41
Per-Instance Subset Policy Switch . . . . . . . . . . . . . . . 41
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 41

1. Introduction

When a client performs a delegated task such as "help me find and buy
a laptop", the sequence of operations (product search, price
checking, coupon search, cart management, payment, shipping
selection) is determined at runtime. Scopes cannot express the
constraints a deployment actually wants to approve for such work: an
overly broad scope grants unchecked power (violating least
privilege), while an overly narrow scope causes frequent
authorization failures that interrupt task execution.

This specification builds on OAuth 2.0 and Rich Authorization
Requests (RAR) [RFC9396] by defining a profile based on _domain-
specific authorization schemas_. A domain-specific authorization
schema is a structured description of behavioral boundaries for a
particular application domain, such as transaction boundaries for
e-commerce operations. A client requests authorization by submitting
a schema instance in authorization_details; the Authorization Server
reviews it against server-side authorization policies, and upon
approval the instance governs the authorization associated with the
issued access token. At runtime, the Resource Server verifies each
client behavior directly against the approved schema instance through
deterministic constraint evaluation; when a behavior exceeds the

Liu Expires 15 April 2027 [Page 3]
Internet-Draft Authorization Schemas October 2026

approved boundaries, the Resource Server returns structured schema
requirements guiding the client toward the required authorization
(Section 5).

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.

2. Terminology

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, as shown here.

Domain-Specific Authorization Schema: A structured definition of
task and authorization boundaries for a particular application
domain, identified by an authorization details type (a short name
or an HTTPS URI, Section 3.1) and usable by clients to construct
authorization requests. A schema defines constraint fields whose
values are machine-verifiable at runtime through deterministic
evaluation.

Schema Instance: A concrete authorization details object conforming

Liu Expires 15 April 2027 [Page 4]
Internet-Draft Authorization Schemas October 2026

to a domain-specific authorization schema, carried in
authorization_details. When approved by the Authorization Server,
the schema instance is bound to the access token and verified by
the Resource Server against each client behavior at runtime.

Bounded Work: The overall objective for which a client requests
authorization, such as "help me find and buy a laptop". The
work_id assigned by the AS upon approval is the identity of the
approved work. A work authorization is a schema instance approved
for the overall work; task requests performed under the work are
verified against its boundaries (Section 3.4).

Task: A unit of activity performed by a client in pursuit of a
bounded work. A task-level authorization request references the
work it serves via the work_id field.

Task-in-Work Evaluation: The deterministic verification, performed
by the Resource Server, that a requested task is consistent with
the boundary constraints of the approved work instance.

Guardrail Instance: A schema instance used as an upper bound on
other instances of the same type (Section 3.5).

Approver: The party whose authorization decision establishes a
governing authorization for requested work. The approver is
authenticated, is entitled to approve the bounds in question, and
is recorded on the approved instance as the party accountable for
the decision.

Subject: The user on whose behalf the work is performed. The
subject and the approver are often the same person but need not
be; for example, a manager can approve work performed on an
employee's behalf.

AS Review Policy: Server-side authorization policies used by the
Authorization Server to review requested schema instances before
approval. Review policies are managed by the Authorization
Server.

Policy Enforcement Point (PEP): The entity that enforces
authorization decisions, allowing, denying, or adapting the
client's request. In this specification, the Resource Server acts
as the PEP, verifying each behavior against the approved schema
instance.

Rich Authorization Requests (RAR): A framework defined in [RFC9396]
for expressing fine-grained authorization requirements through the
authorization_details parameter.

Liu Expires 15 April 2027 [Page 5]
Internet-Draft Authorization Schemas October 2026

3. Domain-Specific Authorization Schema

This specification defines a profile for domain-specific
authorization schemas used with Rich Authorization Requests (RAR).
Schema instances carried in authorization_details are structured
data; when approved by the Authorization Server, the instance is
bound to the access token and verified by the Resource Server at
runtime through deterministic constraint evaluation.

Schema instances are carried within the authorization_details
parameter [RFC9396] as the primary mechanism. This specification
standardizes the binding of the approved instance to the access
token, not the specific input channel by which the instance reaches
the Authorization Server; schemas can accordingly be used with any
authorization flow that supports authorization_details.
Implementations MAY combine domain-specific authorization schemas
with other RAR types in a single request. Resource servers MAY
advertise the authorization details types they support via
authorization_details_types_supported ([RFC9728]); the relationship
to per-type metadata is described in Section 5.3.

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

Liu Expires 15 April 2027 [Page 6]
Internet-Draft Authorization Schemas October 2026

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.

Liu Expires 15 April 2027 [Page 7]
Internet-Draft Authorization Schemas October 2026

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

Liu Expires 15 April 2027 [Page 8]
Internet-Draft Authorization Schemas October 2026

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

Liu Expires 15 April 2027 [Page 9]
Internet-Draft Authorization Schemas October 2026

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.

Liu Expires 15 April 2027 [Page 10]
Internet-Draft Authorization Schemas October 2026

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"]
}
}

Figure 1: Example administrative guardrail

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

Liu Expires 15 April 2027 [Page 11]
Internet-Draft Authorization Schemas October 2026

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"
}

Figure 2: schema_ref in a JWT access token

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

4. Protocol Flow

The end-to-end schema binding flow proceeds as follows. The client
proposes a domain-specific schema instance in the authorization
request; the Authorization Server reviews and approves it; and the
Resource Server verifies each client behavior against the approved
instance through deterministic constraint evaluation.

1. Authorization Request: The authorization request includes
authorization_details containing a schema instance (e.g., of type
transaction_authority, Appendix "Example: transaction_authority",
with the boundary constraints), using RAR ([RFC9396]) 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, token
binding context, and any effective guardrails (see Section 6).
The AS does not perform per-behavior verification (which occurs
at the Resource Server).

Liu Expires 15 April 2027 [Page 12]
Internet-Draft Authorization Schemas October 2026

4. Token Binding: AS issues an access token with enriched
authorization_details array per Section 7.1 of [RFC9396], binding
the approved schema instance to the token. The AS MAY include
additional metadata in the authorization_details object (e.g.,
server-assigned identifiers such as work_id or work_ref, or
normalized instance content) but MUST NOT alter the semantic
meaning of the instance without client consent.

5. Behavior Execution: The client 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 client's current
behavior (action, target resource) against the boundary
constraints of the approved instance through deterministic
constraint evaluation.

8. Enforcement: RS enforces the per-behavior decision, allowing or
denying the client's action.

9. Response: RS returns the result to the client.

5. Reverse-Guided Authorization

Traditional OAuth error responses indicate authorization failure
without providing guidance on how to obtain valid authorization.
This specification defines a negotiation pattern in which the
resource server guides the client toward the authorization required
for its next action: when the client's next planned behavior falls
outside the approved schema instance (_behavioral drift_), the client
needs structured guidance to recover autonomously. Resource servers
provide this guidance through structured error responses that enable
clients to construct authorization requests with updated behavioral
constraints.

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.

Liu Expires 15 April 2027 [Page 13]
Internet-Draft Authorization Schemas October 2026

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"
}

Figure 3: Reverse-guided authorization error response

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"
}

Figure 4: Schema profile document

Liu Expires 15 April 2027 [Page 14]
Internet-Draft Authorization Schemas October 2026

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:

Liu Expires 15 April 2027 [Page 15]
Internet-Draft Authorization Schemas October 2026

* 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

Liu Expires 15 April 2027 [Page 16]
Internet-Draft Authorization Schemas October 2026

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"]
}
]
}

Figure 5: Instance constructed from a schema profile

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.

Liu Expires 15 April 2027 [Page 17]
Internet-Draft Authorization Schemas October 2026

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.

Liu Expires 15 April 2027 [Page 18]
Internet-Draft Authorization Schemas October 2026

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. Authorization Server Processing

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

Liu Expires 15 April 2027 [Page 19]
Internet-Draft Authorization Schemas October 2026

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:

Liu Expires 15 April 2027 [Page 20]
Internet-Draft Authorization Schemas October 2026

Table 1: AS error taxonomy for schema binding

Liu Expires 15 April 2027 [Page 21]
Internet-Draft Authorization Schemas October 2026

Example error response:

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

Figure 6: Schema instance error response

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

Liu Expires 15 April 2027 [Page 22]
Internet-Draft Authorization Schemas October 2026

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. Resource Server Enforcement

The Resource Server acts as the Policy Enforcement Point (PEP) in
this framework. When a behavior is presented with a token, the
operative question is not merely "is this token valid?" It is the
two-part question:

Liu Expires 15 April 2027 [Page 23]
Internet-Draft Authorization Schemas October 2026

_Is the authorization bound to this token still active, and is this
operation within its bounds?_

The two parts fail independently: the lifecycle part fails for a
valid token whose authorization has ended (Section 8); the bounds
part fails for a valid token on live work that reaches outside what
was approved. The Resource Server extracts the approved schema
instance from the access token, verifies each client behavior against
the boundary constraints through deterministic constraint evaluation,
and enforces the resulting decision (allow or deny). When the
behavior is a task performed under an approved work (identified by
work_id), this verification is a task-in-work evaluation: the task is
checked against the work's approved boundaries (Section 3.4).

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:

Liu Expires 15 April 2027 [Page 24]
Internet-Draft Authorization Schemas October 2026

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

8. Instance Lifecycle

An approved schema instance has a lifecycle. The lifecycle has two
states and four ending reasons; the requested instance before
approval is an object (a proposal), not a state: a rejected proposal
never enters the lifecycle.

active: The instance has been approved and bound. Tokens issued for

Liu Expires 15 April 2027 [Page 25]
Internet-Draft Authorization Schemas October 2026

it carry its authority; the AS accepts new task requests
referencing its work_id, and refresh re-binds the same instance.

ended: The instance no longer permits anything. Ended is terminal:
an ended instance does not support new issuance, refresh, or
derivation, and widening requires a fresh authorization through
the AS (the monotonic narrowing principle, Section 9).

An active instance ends in one of four ways, and the distinction
among them matters for accountability: *completed* (the termination
criterion is satisfied, e.g., the report is filed), *withdrawn* (the
approver withdraws the work), *terminated* (an administrator or
governance process ends it), or *expired* (the maximum lifetime
elapses, e.g., a time_window constraint).

The framework maps these concepts onto OAuth mechanisms as follows:

Liu Expires 15 April 2027 [Page 26]
Internet-Draft Authorization Schemas October 2026

Table 2

Guardrail instances follow the same lifecycle, with the tightening,
removal, and relaxation semantics defined in Section 3.5.

Because the ending of an authorization is a state change to one
object with consequences for everything bound to it, the denial
semantics of Section 5.7 apply: a valid credential does not authorize
further operations for work that has ended. Deployments MUST place a
finite bound on how long a Resource Server continues to accept a
token after the authorization it was issued for has ended; token
lifetimes and introspection are the mechanisms this specification
relies on, and the bound they define is the worst-case exposure
window between an ending and its observation.

Liu Expires 15 April 2027 [Page 27]
Internet-Draft Authorization Schemas October 2026

The work_id and any evidence_ref of an ended instance remain
meaningful as record locators: approval evidence records what was
decided and remains available for accountability after the work is
over, but its existence does not establish current permission
(Section 3.3). Privacy considerations for authorization identifiers
spanning multiple resource servers, including per-audience schema_ref
variants, are discussed in Section 11.

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

Figure 7: Token exchange with schema instance

The resulting access token MUST include the new approved schema
instance. Because schema instances are structured data, subset
verification is 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). The AS MUST verify that the
derived instance is a subset of the original instance and reject the
exchange otherwise; Token Exchange in this framework is narrowing-
only, by construction. 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 the framework requirements (Section 3.2). If the client
requires broader behavioral boundaries, it MUST obtain a new
authorization through the AS (for example, via the reverse-guided
mechanism in Section 5, with resource owner consent where required),
rather than widening an approved instance through exchange.

Token Exchange is a common trigger for _behavioral drift_: when a
client's next planned behavior falls outside the approved schema
constraints, the Resource Server can return an
insufficient_authorization error with a schema_profile_uri (as
defined in Section 5), guiding the client toward constructing an
appropriate Token Exchange request with an updated schema instance.

Liu Expires 15 April 2027 [Page 28]
Internet-Draft Authorization Schemas October 2026

10. Security Considerations

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.

Liu Expires 15 April 2027 [Page 29]
Internet-Draft Authorization Schemas October 2026

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.

Liu Expires 15 April 2027 [Page 30]
Internet-Draft Authorization Schemas October 2026

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.

Liu Expires 15 April 2027 [Page 31]
Internet-Draft Authorization Schemas October 2026

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

11. Privacy Considerations

Implementations of this specification MUST consider the following
privacy aspects per BCP 188 [RFC6973]:

* *Instance Content Privacy:* Schema instances embedded in
authorization_details may carry identifying data (e.g., merchant
and category values in the boundary). When instances are carried
in JWT access tokens, this data is visible to any party that can
decode the token. Implementations SHOULD avoid embedding
personally identifiable information (PII) directly in instance
content and instead use correlation identifiers (e.g.,
transaction_id) that the Resource Server or an audit service
resolves when needed.

* *Constraint Disclosure:* The schema profile document returned via
schema_profile_uri reveals the required boundary constraints to
the requesting client. While this disclosure is necessary for the
reverse-guided authorization flow, resource servers SHOULD limit
the information to what is strictly needed for the client to
construct a valid authorization request, and MUST NOT include
internal implementation details, database schemas, or
infrastructure information.

* *Endpoint Exposure:* The auth_server field in the schema profile
document reveals the Authorization Server's identifier.
Deployments SHOULD use well-known identifiers rather than exposing
internal service URLs.

Liu Expires 15 April 2027 [Page 32]
Internet-Draft Authorization Schemas October 2026

* *Behavioral Profiling:* The sequence of schema instances submitted
by a client may reveal the client's intent, capabilities, or
decision-making patterns. Authorization Servers SHOULD treat
schema instances with the same confidentiality as other
authorization request parameters and MUST NOT use them for
purposes beyond authorization decision-making without explicit
consent.

* *Cross-Resource Correlation:* Authorization identifiers such as
work_id, schema_ref, and evidence_ref can correlate a user's
activity across resource servers when the same value is observed
by multiple RSs. Deployments for which this correlation is a
concern MAY use audience-specific schema_ref and work_ref values
per resource server, so that each RS observes a distinct
identifier for the same authorization; the AS maintains the
mapping. This is a deployment option and does not change the
mechanisms defined in this specification.

12. IANA Considerations

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;

Liu Expires 15 April 2027 [Page 33]
Internet-Draft Authorization Schemas October 2026

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,

Liu Expires 15 April 2027 [Page 34]
Internet-Draft Authorization Schemas October 2026

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

13.1. Normative References

Liu Expires 15 April 2027 [Page 35]
Internet-Draft Authorization Schemas October 2026

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

Liu Expires 15 April 2027 [Page 36]
Internet-Draft Authorization Schemas October 2026

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

Liu Expires 15 April 2027 [Page 37]
Internet-Draft Authorization Schemas October 2026

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

Contributors

The following individuals contributed to the IETF 126 presentation
and discussions from which this specification grew:

Jeff Lombardo AWS

Karl McGuinness Independent

Yaron Zehavi Raiffeisen Bank International

Yaron Sheffer Intuit

Suresh Krishnan Cisco

Acknowledgments

The author would like to thank Brian Campbell, Aaron Parecki, Hongru
Zhu, and Hui Xue for their valuable input during the development of
this specification; their contributions helped shape key design
decisions.

Example: transaction_authority

_This appendix is non-normative._ It defines transaction_authority, a
worked example of a domain-specific authorization schema that
illustrates the framework requirements of Section 3.2. It is not
registered in the Domain-Specific Authorization Schema Types registry
(Section 12.1); deployments that wish to standardize it or other
schemas are expected to do so in follow-up specifications. Nothing
in the framework is specific to payments: schemas for other domains,
such as calendaring (time windows and attendee scope), document
management (access and sharing scope), or service usage (quotas and
rate windows), satisfy the same requirements.

Liu Expires 15 April 2027 [Page 38]
Internet-Draft Authorization Schemas October 2026

The transaction_authority authorization data type defines transaction
boundaries within which the client is permitted to operate, carried
within authorization_details. The example type name is local to this
specification and is unrelated to the authority metadata concept
discussed in [I-D.zehavi-oauth-authority-metadata].

Type Name: transaction_authority

Data Type: Object

Usage: authorization_details ([RFC9396])

The following example shows the authorization_details request
parameter containing a transaction_authority instance for an
e-commerce transaction:

{
"authorization_details": [
{
"type": "transaction_authority",
"domain": "ecommerce",
"transaction_id": "urn:uuid:txn-abc-123",
"boundary": {
"total_amount_limit": { "value": 50, "currency": "USD" },
"operations": ["ecommerce.search", "ecommerce.cart.add"],
"category": ["apparel"],
"merchant": ["https://shop.example"],
"time_window": {
"start": "2026-08-20T00:00:00Z",
"end": "2026-08-21T00:00:00Z"
}
},
"actions": ["search", "cart.add"],
"locations": ["https://api.shop.example"]
}
]
}

Figure 8: transaction_authority in authorization_details

In addition to the common fields defined in Section 2 of [RFC9396]
(such as actions, locations, datatypes, and identifier) and the
framework fields of Section 3.3, the transaction_authority example
defines the following type-specific fields:

domain: REQUIRED. A string identifying the application domain the
schema instance applies to (e.g., "ecommerce").

Liu Expires 15 April 2027 [Page 39]
Internet-Draft Authorization Schemas October 2026

transaction_id: OPTIONAL. An identifier for the transaction the
instance governs. When used together with the authorization
evidence mechanism ([I-D.liu-oauth-authorization-evidence]), the
transaction_id correlates the approved instance with the
corresponding consent record.

boundary: REQUIRED. An object containing the transaction boundary
constraints. All fields are OPTIONAL; only behaviors consistent
with every present constraint are permitted:

total_amount_limit: An object with value (number) and currency
(string) members. The aggregate amount of the client's
transactions MUST NOT exceed value in the given currency.

operations: An array of namespaced operation identifiers (e.g.,
"ecommerce.cart.add"). Only the listed operations are
permitted.

category: An array of product category identifiers the client is
permitted to operate on.

merchant: An array of merchant URIs the client is permitted to
interact with.

time_window: An object with start and end members, each a
timestamp per [RFC3339]. Only behaviors occurring within the
window are permitted.

The common RAR fields and the boundary constraints serve different
consumers at different stages of the authorization flow. The common
fields (actions, locations) provide a declarative upper bound on the
requested operations and resources, enabling the Authorization Server
to approve or reject the request without interpreting the boundary
constraints. The boundary constraints define the behavioral limits
that the Resource Server verifies against each client behavior at
runtime. This layered design allows Authorization Server
implementations to review requests declaratively, while the Resource
Server performs per-behavior verification through deterministic
constraint evaluation.

The AS SHOULD verify that the boundary constraints are consistent
with the common fields (Section 6). The Resource Server bears
responsibility for ensuring each verified behavior is consistent with
the approved schema instance at runtime.

Liu Expires 15 April 2027 [Page 40]
Internet-Draft Authorization Schemas October 2026

Open Issues

_This appendix is non-normative; it records questions on which
working group guidance is sought._

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.

Author's Address

Dapeng Liu
Alibaba
Email: max.ldp@alibaba-inc.com

Liu Expires 15 April 2027 [Page 41]

Domain-Specific Authorization Schemas for OAuth 2.0 draft-liu-oauth-authorization-schemas-00

Domain-Specific Authorization Schemas for OAuth 2.0
draft-liu-oauth-authorization-schemas-00