]> Independent

ogazitt@gmail.com

Security Web Authorization Protocol oauth authorization authzen policy token exchange Numerous OAuth 2.0 specifications define a moment at which an authorization server decides whether to issue a security token, and each of them declares the decision itself to be a matter of local policy that is out of scope. The result is that a decision common to every OAuth deployment has no interoperable expression. This document defines a profile for using the OpenID AuthZEN Authorization API to externalize that decision to a Policy Decision Point. It specifies how the inputs to a token issuance request map onto AuthZEN's mandatory five-tuple, how a Policy Decision Point response may shape the issued token, and how a Policy Decision Point advertises support for the profile. The mapping is complete for grants whose request names a single party, including the authorization code and client credentials grants. Companion documents bind the grant families that add structure this document does not model, the token exchange family first among them. About This Document Status information for this document may be found at . Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Consider the moment an OAuth 2.0 authorization server (AS) has authenticated a client, validated a grant, and must decide whether to mint a token - and if so, with what scopes, what audience, what lifetime, and what claims. Every specification that defines such a moment models its inputs in careful detail and then stops short of the decision. , which defines OAuth 2.0 Token Exchange, is explicit that the decision to issue is governed by policy it does not define. The specifications built on top of it inherit that seam: identity chaining (), identity assertion authorization grants (), and transaction tokens () each describe an "administrator-defined policy" or equivalent without describing how such a policy is expressed, evaluated, or externalized. Leaving the decision to local policy is the correct choice for those documents. But it means that the single most security-relevant step in token issuance is, today, an implementation detail - expressed in vendor-specific rules engines, inline hooks, and scripting extensions that do not port between authorization servers and cannot be reasoned about by anything outside the AS. defines an interoperable API between a Policy Enforcement Point (PEP) and a Policy Decision Point (PDP). This document profiles that API for the token issuance moment, casting the authorization server as a PEP.

Design Goals One mechanism, many issuance moments. The decision point is structurally identical across grant types: a party is asking for a token, naming a target and some set of privileges. This document defines that mapping once. Bindings () supply what is specific to a given grant or token type, and are expected to be short. Interoperability at the level of policy, not just wire format. makes exactly five fields mandatory in an evaluation request: subject.type, subject.id, action.name, resource.type, and resource.id. Everything else - the properties bag on each entity, and the context object - is optional. That asymmetry is deliberate. It is what allows one request shape to be understood by policy engines with very different internal models: attribute- and policy-based engines that evaluate expressions over arbitrary input, and relationship-based engines in the style of that reason over a typed graph of subjects, relations, and objects. This is not a claim that a relationship-based engine can consume nothing beyond the five-tuple. Such engines commonly accept contextual tuples supplied at query time, and a PDP may project properties or context into them. It is a claim about where a profile should put the load. The five-tuple has a shape every conforming PDP can be expected to read the same way; a free-form bag does not, and a profile that carried its decision-critical inputs there would nominally use AuthZEN while leaving each PDP to infer the semantics on its own. This document therefore adopts a design rule:

• The five-tuple is the primary information model target. Every input on which the decision depends MUST be expressed in it. properties and context carry advisory input only, and a conforming mapping MUST be implementable by a PDP that reads only the five-tuple.

The rule is applied throughout and is not re-argued at each mapping. Least surprise for the AS. The profile does not ask the AS to surrender decisions it is authoritative for. A PDP may narrow what is issued; it may not broaden it, re-subject it, or re-target it ().

Scope This document covers token issuance: the decision made by an authorization server at its token endpoint, before a token is minted. It does not address enforcement at a resource server, which is the ordinary case AuthZEN already serves and requires no profile. The framework decides an issuance gate. Where a deployment's policy depends on quantitative or transactional constraints - a payment amount, a rate limit - those flow in as advisory context and out as token shaping (), to be enforced by downstream policy enforcement points. Any conforming PDP can adjudicate the gate, because the gate is expressed entirely in the five-tuple. Whether a given PDP also adjudicates the context is a property of that deployment and is not something this profile guarantees. Stating that boundary is what keeps the design rule above from overpromising.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology This document uses the terms Authorization Server, Client, Resource Server, access token, and scope from ; Policy Decision Point (PDP), Policy Enforcement Point (PEP), Subject, Action, Resource, and Context from .

Issuance target:

The audience of the access being granted - the party the issued token authorizes its bearer to act against. Usually the value the AS intends for the token's aud claim.

Gate tuple:

An evaluation request whose action expresses issuance authority - whether the subject may obtain a token of a given type for the issuance target. See .

Scope tuple:

An evaluation request whose action is a requested scope, expressing access authority. See .

Architecture | | | | 2. authn client, | | | validate grant | | | | | | 3. evaluation request | | +----------------------->| | | | | | 4. decision + shaping | | |<-----------------------+ | | | | | 5. mint per decision | | | and shaping | | 6. token response | | |<--------------------------+ | ]]> Step 2 is unchanged from the underlying grant: the AS remains solely responsible for authenticating the client, validating the grant or subject token, and verifying any proof of possession. The PDP is consulted only after those checks succeed. A PDP permit does not substitute for any of them.

Deployment Considerations

Colocation and Latency A token endpoint can be a very high volume path. Multi-tenant authorization servers operate at request rates that leave a per-request budget in the low milliseconds, and an issuance decision that added a round trip to a remote service would not be deployable at that scale. This profile does not add one. specifies a request and response contract between a Policy Enforcement Point and a Policy Decision Point; it does not specify where the Policy Decision Point runs. The PDP of may be embedded in the authorization server's own process, loaded as a module or as a WebAssembly component, resident on the same host, or reached over a network. Conformance to this profile is a property of the messages exchanged and not of the topology that carries them, and deployments with the strictest budgets are expected to evaluate in process or on the same host. Step 3 of is drawn as an arrow because it is a request, not because it is a hop. Two properties of the issuance moment make the budget more forgiving than the volume alone suggests. The decision is made once per token rather than once per request. An access token is presented many times, over a lifetime usually measured in minutes or hours, so the cost of deciding at issuance is amortized across every later presentation. This is the reverse of the resource server deployments was first written for, where the decision recurs on every call and the budget is correspondingly tighter. The inputs are already in hand. By the time an AS reaches this decision it has authenticated the client, validated the grant, and resolved the subject. The evaluation request of is assembled from values the AS already holds, and this profile implies no additional lookup to construct it.

Decisions That Cannot Be Made Synchronously Some issuance decisions cannot complete within the time a token request will wait, at any topology. A policy may call for human review, for an out-of-band approval, or for a check against a system whose own latency is unbounded. This document defines no mechanism for those, and does not need to. defines a deferred token response, in which an authorization server that cannot answer immediately returns a deferral code and the client retrieves the outcome later. An AS implementing both may treat a decision it cannot obtain synchronously as a deferral rather than as a denial, evaluate it out of band, and apply the response of to the token it eventually issues. Delay does not relax : a decision that arrives late constrains the issued token exactly as one that arrives promptly would.

The Seam Inside the Authorization Server separates validating a grant from deciding whether to honor it, and asks a PDP only the second question. In a deployed authorization server that separation is often less clean than the figure. Credential handling, grant validation, session and consent state, and token minting are commonly one subsystem, with the inputs this profile needs distributed across it rather than exposed at any single point. The consequence is practical rather than normative. An authorization server that cannot assemble the fields of at one point in its issuance path will have to introduce such a point, and for many implementations that will be the substantive work rather than the mapping or the response handling. This profile is defined in terms of the values an AS holds when it makes the decision, not in terms of where an implementation keeps them, so it constrains neither the internal structure nor the refactoring.

Forming the Evaluation Request

Subject subject identifies the party the issued token will represent. subject.type MUST be one of the registered values in :

• user - a natural person.
• client - an OAuth client acting on its own behalf.
• workload - a non-human software identity, such as a workload with a cryptographic identity document.

subject.id MUST be the identifier the AS intends to place in the issued token's subject claim. Where the AS applies a transformation to subject identifiers - pairwise or pseudonymous identifiers, or a mapping from an external identity to a local account - that transformation MUST be applied before the evaluation request is constructed, so that the identifier the PDP authorizes is the identifier the token carries.

Resource For the gate and scope tuples of , resource.type MUST be audience and each resource.id MUST be an issuance target. Authorization detail tuples name their resource differently, as sets out. A single registered type is used rather than a type per kind of target (service, trust domain, peer authorization server) because the type names the protocol role the target plays, not a guess at its nature. Policies written against audience port across deployments; policies written against locally invented type names do not. The requested targets of a request are the values it carries in a resource parameter in the sense of , in an audience parameter where the binding defines one, or in both. Where the request carries neither, the AS's default audience for the grant is the sole requested target.

One Target Is the Preferred Shape A request SHOULD name a single target. This profile does not introduce that preference; it inherits it. Section 5 encourages using only a single resource parameter, observing that a token valid at several protected resources "can be used by any one of those resources to access any of the others", so that multiple audiences presuppose a high degree of trust among the recipients. Section 4.10.2 describes the same practice from the other direction: an access token is bound to a specific resource server, so a client reaching several obtains a token for each. An AS MAY reject a request naming more than one target. Section 5 anticipates this, noting that an authorization server may be unwilling or unable to fulfill such a request. Where the AS does reject one, the requirements of do not arise.

Several Targets A request may nonetheless name more than one: Section 2 permits the resource parameter to appear multiple times, and Section 2.1 permits the same of audience and resource in a token exchange request. An AS that accepts such a request has more than one issuance target, and whether the subject may reach each of them is a separate question. Because the information model of carries exactly one resource per evaluation, a request naming several targets MUST be expressed as several evaluations rather than as one evaluation naming a compound target. The tuples of are formed once for each requested target, and resource is carried on the individual evaluation object, overriding the top-level default as Section 7.1.1 provides. This is also what makes the audience constraining key of reachable. That key narrows a set of targets, and a set can only be narrowed if the request was able to put more than one member in it. shows a two-target request on the wire.

Actions: Gate, Scope, and Authorization Detail Tuples Token issuance asks two questions that are frequently conflated:

1. May this subject obtain a token of this kind for this target? This is issuance authority, and in delegation scenarios, delegation authority.
2. May this subject exercise this scope at this target? This is access authority.

These are distinct privileges. defines a may_act claim precisely because the authority to act on another party's behalf is not the same as the authority to access a resource. A subject may legitimately be permitted to hold an access token for an API while being forbidden from minting a delegated grant aimed at that same API. Because AuthZEN's information model provides exactly one action per evaluation, these two questions MUST be expressed as separate evaluations rather than as two interpretations of one action.name. A request carrying authorization_details () asks the second question in a richer vocabulary than a scope string, and gets a third tuple shape () rather than a reinterpretation of the second.

Gate Tuple A gate tuple is an evaluation whose action.name has three colon-separated segments: : ]]> where <token-type> and <grant-type> are short names registered in - for example issue:access_token:authorization_code, issue:id_token:authorization_code, issue:refresh_token:token_exchange. The issue: prefix is reserved. A deployment MUST NOT use a scope value beginning with issue: as a scope tuple action. shows a gate tuple in a request. The grant is part of the action because it is not recoverable from the rest of the tuple and it is not implied by the token type. The same subject, audience, and token type arise from an authorization code request and from its later refresh, and from a client requesting a token for itself and that same client exchanging for one. A policy that distinguishes those cases - requiring fresh authorization at a high-value audience, or permitting a client to hold a token but not to exchange for one - has nothing to attach to unless the grant is in the five-tuple. Neither segment subsumes the other. A single authorization code request may mint an access token, a refresh token, and an ID token, which are separately gateable; and a token exchange selects its output through requested_token_type, so its token type is a variable of the request. Together the two segments name one privilege: what may be minted, and by what means.

Action Name Portability Short names registered under MUST match [a-z][a-z0-9_]{0,30}, and a composed gate action name MUST NOT exceed 50 characters. The bounds exist for portability. Relationship-based engines commonly validate relation identifiers against a restricted grammar, admitting a small character set within a modest length limit. A PDP built on such an engine can canonicalize an action name defined by this document by replacing each : with a character the grammar admits, conventionally _. The bounds above are what make that transformation total: any registered name survives it, so a policy written against these names ports without being rewritten. Carrying a grant type URI verbatim would not survive it. The composed action name would exceed the length limits such grammars impose before any question of characters arose. The guarantee covers only the vocabulary this document defines. Scope values are carried verbatim () and routinely contain characters no such grammar admits; mapping them remains internal to the PDP.

Scope Tuple A scope tuple is an evaluation whose action.name is a single requested scope value, carried verbatim. Scope values are not transformed into policy-engine relation names by the AS. Any such mapping is internal to the PDP. This keeps action.name a stable interface: the AS reports what the client asked for, and the PDP decides what that means in its own policy vocabulary. shows three scope tuples behind a gate, one of them denied.

Authorization Detail Tuple Where the request carries authorization_details (), each entry in the array yields one or more evaluations. An entry is a product, not a single permission. Section 2.2: "When different common data fields are used in combination, the permissions the client requests are the product of all the values. The object represents a request for all actions values listed within the object to be used at all locations values listed within the object for all datatypes values listed within the object." Figure 6 of that document is the client's escape hatch: a client that does not want the whole product sends several entries instead. Asking the PDP one question per cell therefore asks exactly the questions the entry poses, and asking fewer answers a coarser question than the client asked. The AS forms one evaluation per cell:

RAR member	AuthZEN
type	resource.type
each locations value	resource.id
each actions value	action.name, leading segments
each datatypes value	action.name, final segment

action.name is the actions value alone where the entry has no datatypes, and the actions value and the datatypes value joined by a colon otherwise, the datatype last: : ]]> The datatype is recovered as the segment following the final colon. An AS MUST NOT form a compound name where the datatypes value itself contains a colon; such an entry is decomposed on locations and actions only, and its datatype axis is narrowed on the response side alone (). These names cannot be confused with the gate names of . A gate tuple always names a resource whose type is audience; an authorization detail tuple never does, because resource.type is the entry's own type. The two may name the same resource.id and remain distinct questions, which shows. shows an entry decomposing into the four cells of a two by two product, and one of them denied. Only type is REQUIRED of an entry ( Section 2), so an axis may be absent:

Absent member	Substituted
locations	Each requested target of
actions	The reserved name authorization_detail
datatypes	No compounding; action.name is the action alone

Substituting the requested targets for an absent locations continues the audience restriction the member itself performs. Section 12 describes locations as preventing unintended client authorizations "through audience restriction", and Section 9.1 recommends that an AS minting a JWT access token filter the authorization details to the specific audience. Where an entry names no location, the request's own targets are the audience it is restricted to. privileges and identifier are not decomposed. Section 2.2's product sentence names actions, locations, and datatypes, so whether privileges multiplies is unstated, and identifier is a scalar with no multiplicity. Nor does the decomposition reach a type that carries its multiplicity in type-specific members rather than in the common data fields - a consent object enumerating individual permissions, for instance. Such an entry yields one evaluation per location. This is the prevailing shape in deployed open banking profiles, so it is not a corner case. An undecomposed member is not shown to the PDP, and a PDP cannot narrow against a value it was not sent. What it can still do is narrow by policy: knowing the subject, the type, and the location, it may return an entry whose datatypes or type-specific members are the most this subject may ever reach there. Such an entry is still subject to the structural check of , so a PDP that returns more than was requested has its decision rejected rather than trimmed. Narrowing against the request itself remains the AS's own obligation under Section 6. Decomposing the entry is also what makes the structural check of derivable rather than asserted. An entry whose locations, actions, and datatypes are subsets of the request's is exactly an entry reassembled from cells the PDP permitted.

Gate Tuples Are Always Present An AS MUST include a gate tuple in every evaluation request it forms under this profile. A binding MAY require more than one (). The floor is therefore two evaluations for a single-target request naming scopes, and one for a single-target request naming none. Deployments are expected to write issuance policy for every token type and grant combination their AS can produce; a PDP that advertises support for this profile renders a decision on any registered gate action it is sent (), so an AS never has to predict which combinations a given PDP has policy for.

Context The context object carries advisory input. A conforming PDP MUST be able to render a decision without it. The following keys are defined by this document; bindings may define more:

Key	Type	Value
client_id	string	The authenticated client identifier
acr	string	Authentication context class of the subject
amr	array of strings	Authentication methods, per
auth_time	integer	Time of authentication, as in
cnf	object	Confirmation method of the presented credential
jti	string	Identifier of the token the AS intends to mint ()

The single-type rule of applies here as well: each key above has one JSON type, and bindings defining further context keys MUST state a type for each. Per , any input on which the decision genuinely depends belongs in the five-tuple, not here. The grant type is the worked example: it is decision-critical, so it is a segment of the gate action name () and does not appear in context at all.

Correlation An operator running an authorization server against a separately operated policy decision point has two decision logs and no defined way to join them. An AS MAY include in context the jti of the token it intends to mint, so that the record the PDP writes and the token the AS issues carry the same identifier. It is a MAY because of an ordering problem: at evaluation time the token does not exist, so an AS that sends a jti has allocated it in advance, and on a denial that identifier is spent on a token that is never issued. Whether to pre-allocate, and what to do with identifiers spent on denied requests, is an implementation matter for the AS and is outside the scope of this document. An AS that does not pre-allocate omits the key. Supplying jti as an input does not disturb the reservation in . The AS remains authoritative for the claim, and a PDP MUST NOT set it in the response.

Batching and Result Composition

Forming the Batch For each requested target (), the AS forms:

• a gate tuple (), and
• one scope tuple () for each requested scope,

each carrying that target as its resource. Where the request carries authorization_details, the AS also forms the authorization detail tuples of , which carry a resource of their own. This document produces one gate tuple per target. Bindings may produce more: the token exchange family evaluates the authority of the requesting party separately from that of the subject, and so produces two per target. Where a request yields more than one tuple, the AS MUST use the Access Evaluations API of with options.evaluations_semantic set to execute_all, and MUST place gate tuples at the leading indices of the evaluations array, beginning at index 0. The response lists decisions in request order ( Section 7.2), so the AS recovers which target, scope, or authorization detail cell each decision belongs to by position. A request reduces to a single evaluation only when it names one target, no scopes, and no authorization details, in which case the gate tuple stands alone. is that case, and the smallest batch. execute_all is required because a denial must be able to narrow the grant rather than fail it. evaluation semantics are selected per request and cannot mark an individual batch item as a precondition, so the composition rules below are enforced by the AS. This is well within the PEP's role - the AS is already interpreting per-item results in order to downscope.

The Batch Carries Only the Residue Before forming the batch, an AS MUST apply the reductions it is itself authoritative for, and MUST form tuples only for what survives them. Those reductions already exist. Section 3.3 permits an AS to issue a token whose scope is narrower than the one requested. Section 6 is stronger still: the AS "checks whether the underlying grant ... or the client's policy ... allows the issuance of an access token with the requested authorization details", and refuses with invalid_authorization_details where it does not. Neither is introduced here; this profile only fixes their order relative to the PDP call. The reason to fix that order is . A PDP may narrow what is issued and may not broaden it, so a permit on something the AS had already decided to refuse cannot change the outcome. Asking anyway writes a decision into the PDP's record that corresponds to no issued authority, which is worse than not asking: the two logs the profile is otherwise careful to let an operator join () stop agreeing. The batch therefore expresses the request as the AS is prepared to grant it, and the PDP narrows from there.

The Batch Is Bounded What remains after that reduction is still sized by the client. An AS MUST bound the number of evaluations it will form for a single token request, and MUST reject a request that would exceed the bound. This document does not specify the value. Section 2.3 is the precedent: it directs an AS to answer an oversized pushed request with 413 and an over-frequent client with 429, and names no number for either. The bound that is right for a deployment depends on its PDP, and a number written here would be wrong somewhere. The error is the one belonging to the parameter that overran the bound: invalid_authorization_details ( Section 6), invalid_scope (), or, for token exchange requests, invalid_target (). Where more than one contributed, any of them is correct. invalid_request is not, because it does not tell the client what to shorten.

A Denied Gate Removes a Target A gate tuple governs one target. Where its decision is false, that target is removed from the request: the AS MUST NOT name it in the audience of any token it issues, and MUST disregard the scope tuples formed for it and any authorization detail tuple naming it as resource.id. Where every target is removed, the AS MUST fail the request and MUST NOT issue a token. For token exchange requests the appropriate error is invalid_target (). An AS MAY instead fail the whole request when any gate is denied. already permits it to refuse a multi-target request outright, and an AS unwilling to issue a token for a subset of what was asked for is exercising the same discretion later. closes on what a denied gate would have removed from the batch shown there. Where one target was requested, both rules coincide: a denied gate fails the request.

A Denied Scope Must Narrow Every Target A scope tuple governs one scope at one target. A scope is carried in the issued token only where it was permitted at every surviving target. The AS reports the reduced set in the scope response parameter, as already requires. This intersection is not introduced here. Section 2.2.3 requires that "all the individual scope strings in the scope claim MUST have meaning for the resources indicated in the aud claim"; the plural is the operative part. Section 3 of the same document requires that an AS "MUST NOT issue a JWT access token if the authorization granted by the token would be ambiguous". A scope permitted at one audience and denied at another, carried in a token naming both, is that ambiguity exactly: no recipient can determine whether the scope was granted for itself or for the other. An AS that wants a scope to survive at one target and not another issues a token per target, which is the shape prefers in the first place. Where the request named scopes and none survive, and no authorization detail entry survives either, the AS MUST fail the request rather than issue an empty token, even though the gate permitted it. A permitted gate authorizes a token of that kind to exist; it does not authorize an empty one. shows a partial denial narrowing a single-target request.

A Denied Cell Narrows an Entry An authorization detail tuple governs one cell of one entry. The AS reassembles each entry from the cells that were permitted, so that a denied cell narrows the entry rather than failing it. The surviving cells of an entry need not be expressible as one entry, since an entry is a product and the survivors need not be a rectangle. Where they are not, the AS reassembles them as several entries of the same type, which is the shape Figure 6 of defines for a client wanting exactly this. An AS MUST NOT instead widen the result to the smallest single entry containing the survivors, which would return a cell the PDP denied. works through such a split. Where an entry's locations was absent and its tuples were therefore fanned across several targets, a cell survives only where it was permitted at every surviving target, for the reason given in . An entry with no surviving cells is dropped. Where the request carried authorization_details and no entry survives, the AS MUST fail the request with invalid_authorization_details, which Section 6 already defines for a token request whose authorization details the AS will not grant. Reassembly is what the AS does absent a authorization_details key in the response. Where the PDP returns one, it replaces the reassembled array and is checked against the request as requires.

Processing the Evaluation Response A PDP MAY return, in the response context, information that shapes the token the AS issues.

The issuance Envelope All keys defined by this profile appear within a single issuance member of the response context: An AS implementing this profile MUST process context.issuance and MUST ignore unrecognized members outside it, preserving the advisory character that gives response context generally. The examples of carry the envelope on live responses: token_lifetime in , claims in , and granted_scope in . Every key defined below has exactly one JSON type, and bindings that define further keys MUST do the same. Where the corresponding OAuth or JWT construct admits more than one - aud is the notable case, per Section 4.1.3 of - this profile picks one rather than carrying the polymorphism forward. An AS validates the response context before acting on it, and a union type costs more to validate, to schematize, and to project into a typed representation than the shorthand saves.

Mandatory-to-Understand , in the definitions of the decision values in its Decision section, states that where a PEP does not understand information in the response context, the PEP MAY reject the decision. That permission is appropriate for a general-purpose API in which response context is advisory. It is not sufficient here, because the consequences are asymmetric:

• Ignoring a key that narrows the grant yields a token broader than the PDP authorized - a silent privilege escalation.
• Ignoring a key that adds information yields a token narrower than intended - a functional shortfall, not a security failure.

This profile therefore adopts the following rule, from which the treatment of every key below is derived:

• A response-context key is mandatory-to-understand if and only if ignoring it would produce a token broader than the PDP authorized. For such keys, an AS that does not understand and apply the key MUST treat the permit as a denial.

No Broadening A PDP MUST NOT return a shaping value that grants access the AS would not otherwise have granted, and an AS MUST reject a decision that attempts it. The PDP decides whether and how much; it does not decide what else. Without this rule, an evaluation of files.read could return a token bearing admin, and the token would assert a privilege no evaluation ever considered.

Constraining Keys The keys in this section are mandatory-to-understand under .

granted_scope A space-delimited string in the syntax of the scope parameter of , giving the scope set the AS is authorized to grant. granted_scope MUST be a subset of the scopes the AS would otherwise have granted - the requested scopes, or for a request naming none, the AS's default set for that client and target. The AS MUST reject the decision otherwise. Its principal use is the gate-only evaluation, where there are no scope tuples and this key is how a PDP answers "permit, and grant this set." Enumerating a grantable set is a search operation rather than a check; a PDP unable to perform it returns a bare permit and the AS falls back to its own defaults, which is a safe degradation. Where scope tuples are present, the per-item decisions already express downscoping, and a PDP SHOULD NOT also return granted_scope.

token_lifetime A non-negative integer number of seconds, interpreted as a ceiling. The AS MUST issue a token whose lifetime is the lesser of this value and the lifetime it would otherwise have used. It is never a floor: a PDP cannot extend a token's life beyond the AS's own policy. A value of 0 MUST be treated as a denial rather than as an instruction to mint an already-expired token.

audience An array of strings, narrowing the set of targets for which the token may be issued. Every value MUST be the resource.id of the evaluation on which it was returned, so the array is either that single target or empty. An evaluation is a decision about one target, and this key lets a PDP withhold that target while still permitting the request; it does not let one evaluation speak for another. An empty array therefore withdraws the target that evaluation was about, with the same effect as the denied gate of . Where no target survives, the AS MUST fail the request; for token exchange requests the appropriate error is invalid_target (). The value is an array even when it names a single target, per the single-type rule above. An AS remains free to render a single-element set as a bare string in the token's own aud claim, where permits it.

authorization_details An array in the syntax of , replacing - not merged with - the authorization details of the request. Where the PDP returns nothing, the AS reassembles the entries itself from the cells its authorization detail tuples () permitted. The key exists for the narrowing the cells cannot express: within a type-specific member, or along an axis does not decompose. Replacement admits arbitrary structured narrowing, which is what a PDP filtering rich authorization requests needs, but "narrower" is not decidable for arbitrary authorization detail types. This profile therefore requires:

• Structural check, always. Every returned entry MUST be covered by a single entry of the request: there MUST exist a request entry with the same type whose locations, actions, and datatypes members are supersets of the returned entry's. Several returned entries MAY be covered by the same request entry, which is the shape produces. The AS MUST reject the decision if any returned entry is covered by no request entry, or is covered only by several of them taken together. Where a request carries read on contacts in one entry and write on photos in another, as Figure 6 of does, an entry returning read on photos is within the union of the two and within neither, and names a permission the client did not request.
• Absent members. A member absent from the covering request entry constrains nothing, and a returned entry MAY carry a member the request omitted: the client asked for the entry unrestricted along that axis, so any value the PDP supplies narrows it, which is the policy narrowing describes. locations is the exception, since substitutes the requested targets where it is absent. A returned entry MUST NOT name a location that is neither in the covering request entry nor a requested target of .
• Type-specific members. For members beyond those defined in , the AS MUST either apply a validator specific to that authorization details type or reject the decision. An AS MUST NOT pass unvalidated structure into an issued token.

crit An array of strings naming members of claims () that are themselves mandatory-to-understand. The name and semantics are taken from the crit header parameter of : an AS that does not understand and apply a named member MUST treat the permit as a denial. crit exists because the static classification in this section is incomplete. A member of claims is normally safe to drop, and is occasionally the constraint that made the permit safe. Consider a PDP that permits a payment and returns: The ceiling is enforced by the resource server, which reads it from the token. An AS that drops the claim issues a token that says nothing about a limit: the resource server has nothing to enforce, and a decision that authorized 500 euros has become an authorization for any amount. No statically classified key catches this, because the scope, lifetime, audience, and authorization details are all exactly what the PDP allowed and the claim is the only thing that made them safe. An AS may drop a claim for ordinary reasons, most often because it emits only claim names on an allowlist. The vocabulary is domain-specific, so neither party can settle the question in advance, and the AS learns at response time that it cannot carry the claim. crit is what makes that a denial rather than a silent broadening.

Decorating Keys

claims An object whose members are claim names, in the sense of , and the values to be included in the issued token. This is the mechanism by which attributes computed during the decision itself reach the token: a ceiling the policy derived while evaluating a limit, a risk tier that determined the outcome, a structured result a binding defines. It is not the mechanism for enumerating what a subject holds. For the group memberships, roles, and entitlements that describes for JWT access tokens, drawn from the schema of , the search operations of answer the question directly, and the companion profile in specifies how an AS calls them and composes the results. A PDP MAY return such a claim in claims where its policy computes one. Members of claims are advisory under : an AS that drops them issues a less capable token. A PDP that requires a member to be honored MUST name it in crit. A PDP MUST NOT set, and an AS MUST reject a response that sets, any of the following claims:

Reserved	Rationale
iss, iat, jti	Provenance, for which the AS is authoritative
sub	It is subject.id, an input to the decision
aud	It is resource.id, an input to the decision
exp, nbf	Expressed by token_lifetime
scope	Expressed by granted_scope
client_id	Established by client authentication
cnf	Derived from a proof of possession the AS verified
act	Delegation chain, constructed by the AS
authorization_details	Has its own key and narrowing rules
may_act	Confers future delegation authority; broadening by construction

The entries for sub and aud rest on stronger ground than the rest. Both are inputs to the five-tuple; a PDP that could rewrite either would cause the AS to issue a token corresponding to a decision that was never evaluated. Re-subjecting a token is a fresh issuance, not an attenuation of an existing one, and MUST be evaluated as such.

Aggregation Across a Batch An Access Evaluations response in carries no top-level context; each element of the evaluations array is a decision with its own optional context. Token shaping, however, is a property of the token: there is one lifetime, one claim set, one authorization details array for the token being minted, while this profile fans scopes, targets, and authorization detail cells out across many evaluations. An AS MUST therefore compose per-item shaping as follows:

Key	Aggregation
token_lifetime	Minimum over permitted items
granted_scope	Union over permitted items, intersected with what the AS would otherwise grant and with the surviving scopes of
audience	The surviving targets of , less any target whose item returned an empty array
authorization_details	Union of entries, then the per-entry structural check, intersected with the entries reassembled under
claims	Merge; see below
crit	Union

Shaping keys appearing in the context of a denied item MUST be ignored. Where two permitted items return different values for the same member of claims, the AS MUST reject the decision. There is no general narrowing merge for arbitrary JSON values, and choosing one arbitrarily could broaden the result. Identical values are not a conflict. A PDP SHOULD return token-level shaping on a single item to avoid the situation.

Discovery A PDP supporting this profile MUST advertise the capability URN registered in in the capabilities member of its metadata document, retrievable at /.well-known/authzen-configuration: The URN asserts support for the request mapping and response vocabulary of this document. It is not a statement about the content of the PDP's policy, and a PDP MUST NOT be read as claiming to hold rules for any particular issuance. What a deployment's policy permits is disclosed only through decisions. This is the same line draws for authorization_grant_profiles_supported, which indicates that a server implements a profile's processing rules and not that any particular issuer, client, subject, or audience will be accepted. Advertising the capability is accordingly a commitment to the request shapes this profile can produce. A PDP that advertises it MUST render a decision for a gate tuple naming any action name composable from the short names registered in , and MUST NOT reject the evaluation on the grounds that it holds no policy for that action. Denying is a decision; a protocol error is not. The same applies to a batch that mixes a gate tuple with scope tuples, which is the ordinary shape of a request naming scopes (). The obligation matters because the gate vocabulary is a product of two registries and grows as bindings register short names. An AS pairs the token type it is about to mint with the grant it received; it cannot know which pairings a given deployment's policy anticipated, and must not have to. For the same reason, this profile defines one capability URN rather than one per token type and grant combination. Finer granularity would oblige the AS to predict what the PDP has policy for, which the rule above exists to avoid, and would publish the shape of a deployment's issuance policy in an unauthenticated metadata document. Capability granularity in this profile tracks vocabulary, not policy. An extension that adds response vocabulary registers its own URN, since an AS must understand what it is asked to enforce; one that adds only advisory context keys or new registered action names does not, since a PDP ignores a context key it does not recognize and the rule above already obliges it to decide any registered gate action. An operator enabling a new grant or token type nonetheless has a real question to answer: whether the deployment's policy anticipates the gate actions the AS is about to start sending, or whether every such request will be denied. That question is about policy content, so its answer belongs on the authenticated evaluation surface rather than in metadata; notes that an unauthenticated PDP can be probed for the shape of its policy. The Action Search API of answers it directly: a search for a representative subject and an audience resource returns the action names policy would permit, and gate actions among them indicate the issuances the deployment is prepared for. This is a deployment-time check, not a per-request one, and nothing in this profile requires it.

Error Mapping

Condition	Authorization server behavior
Gate tuple denied	Fail the request; do not issue
All scope tuples denied	Fail the request; invalid_scope
Some scope tuples denied	Issue with the permitted subset; report via scope
Target denied or empty audience set	invalid_target ()
No authorization detail entry survives	invalid_authorization_details ()
Batch would exceed the bound of	The error of the parameter that overran it
Shaping key violates	Treat as denial; fail the request
Unknown crit member	Treat as denial; fail the request
PDP unreachable or malformed response	Fail closed; do not issue

Reason information returned by a PDP is diagnostic and intended for the operator of the AS. An AS MUST NOT relay PDP reason strings to the client, as they may disclose policy structure to a party that is not authorized to learn it. Where a PDP returns a denial accompanied by authentication requirements - the step-up pattern of , in which the required acr and amr values are named - an AS SHOULD surface the requirement to the client. This document does not define that mapping, and neither end of it is presently specified. illustrates the pattern in a non-normative example rather than defining the response context keys that carry it, leaving a profile nothing normative to reference; and on the OAuth side, insufficient_user_authentication in is defined for resource servers rather than for the token endpoint, where no equivalent signal exists. This is an open item, and closing it requires work in both specifications.

Examples The first example below is shown in full, framed against the HTTPS JSON binding of . The remaining examples show only the JSON payload. Each is referenced from the section that specifies the rule it exercises. The transport is a property of the deployment, not of this profile: an evaluation carrying the mapping defined here is the same evaluation whatever binding conveys it. Where the HTTPS JSON binding is in use, the request URL is the PDP's access_evaluations_endpoint, or access_evaluation_endpoint for a request that reduces to a single evaluation, as published in the PDP's metadata; the paths shown below are the defaults that apply when metadata provides no value.

Client Credentials, One Scope One scope is requested, so the request is one gate tuple () and one scope tuple (). This is the floor: two evaluations, so the Access Evaluations API. One target is shared by both, so resource is carried once at the top level; the examples below that need a resource per evaluation carry it there instead, as provides. { "subject": { "type": "client", "id": "svc-reporting" }, "resource": { "type": "audience", "id": "https://telemetry.example" }, "context": { "client_id": "svc-reporting" }, "evaluations": [ { "action": { "name": "issue:access_token:client_credentials" } }, { "action": { "name": "telemetry.write" } } ], "options": { "evaluations_semantic": "execute_all" } } ]]>

Authorization Code, Downscoping Three scopes are requested. The gate leads at index 0 and execute_all allows the AS to issue the permitted subset of the rest, per . The AS issues a token bearing files.read files.write, a groups claim, and reports the reduced scope set in the token response. Had the same subject arrived at the same audience with the same scopes on a refresh, index 0 would have read issue:access_token:refresh_token, and a policy that requires fresh authorization here could deny it while leaving the scope tuples untouched.

No Scopes Requested No scopes and no default set, so the gate tuple stands alone (). This is the only shape this document produces that is a single evaluation, and it is therefore the only one sent to the Access Evaluation API rather than the Access Evaluations API: the payload is a bare evaluation with no evaluations array, and under the HTTPS JSON binding it is a POST to /access/v1/evaluation.

Authorization Details, One Entry The token request below carries one authorization details entry naming one location, one action, and one datatype. Line breaks in the request body are for display only, and the value of authorization_details is form encoded on the wire ( Section 2.1); it is shown decoded in the block that follows. The entry has one cell, so the batch is the gate tuple and one authorization detail tuple. The two name the same URI and are still distinct evaluations: the gate asks whether a token may be issued for that audience, and the authorization detail tuple asks whether this subject may read contacts at that API. resource.type is what separates them. Every cell was permitted, so the entry reassembles to itself and the AS issues a token carrying the requested authorization_details unchanged.

Authorization Details Across Two Targets Here the request names two issuance targets, and its single entry names two locations and two datatypes. One action across two locations and two datatypes is four cells, and two targets is two gate tuples, so the batch is six evaluations. Gate tuples lead, per . No top-level resource is shown, because no one resource is shared: each evaluation carries its own. The PDP permits both gates and denies one cell, photos at the European location. Three of the four cells survive, and three cells are not a product, so the entry cannot reassemble into one. The AS returns two entries of the same type, as requires: Both gates permitted, so both targets remain in the audience. Had the second gate been denied instead, would have removed that target and the AS would have disregarded both evaluations naming it, denied or not, leaving the first entry alone and no second entry at all.

Relationship to Companion Documents This document defines the mapping and the shaping vocabulary, and registers short names for the grant types listed in . For a grant whose request names a single party, that is everything an AS needs; the client credentials and authorization code examples above are complete, and no companion document is required to implement them. A binding is required where a grant family adds structure this document does not model. The token exchange family adds two such things: a request names a second party, the requesting party, whose authority is separately at stake; and several of its members issue an artifact whose own audience differs from the audience of the access it describes. Bindings are therefore expected for that family - including identity chaining, identity assertion authorization grants, and transaction tokens - and a profile describing the use of AuthZEN search operations to populate the authorization claims of . Bindings specify the subject derivation for their grant, any additional context keys, the token type short names they register, and any invariants of their own that a PDP cannot override.

Related Work Two other efforts place an AuthZEN Policy Decision Point behind an authorization server. carries an AuthZEN request and response inside authorization_details, placing the evaluation on the OAuth wire. It has expired. This document does not adopt that approach: the evaluation stays between the authorization server and its Policy Decision Point, and the client sees only an OAuth response. covers the same territory the other way round, deriving the evaluation from the authorization details the client already sends rather than asking the client to construct one. defines what happens when a Policy Decision Point denies a request but marks the denial as requestable: the enforcement point submits an access request, an approval is obtained out of band, and a fresh evaluation is performed so that the Policy Decision Point remains authoritative at enforcement time. That profile deliberately does not bind the loop to OAuth, requiring instead that a separate profile define a completion mode appropriate to the flow. The AuthZEN Working Group's Access Request OAuth Profile supplies that completion mode, and it governs the same moment as this document. The two divide along the value of decision. The approval work specifies the deny path: a requestable denial becomes an asynchronous approval, and issuance follows the re-evaluation. This document specifies the allow path: how the evaluation request is formed, and how a permit may narrow what is issued. The approval work therefore already establishes that response context shapes issuance; it does so for approval state, where this document does so for the granted authorization. Because both must construct an evaluation request from an OAuth token request, that construction is shared surface, and its treatment in the approval profiles is deliberately brief, being incidental to their subject. Where the two overlap, this document is intended to supply the detail rather than to compete, and aligning the two is expected work. approaches the same authorization from the other end. Its grant query response reports a grant as scopes, claims, and authorization_details, which is the set of constraining keys of seen after the fact: this document specifies how a Policy Decision Point shapes those at issuance, and grant management specifies how a client reads and manages them afterwards. Its scopes member pairs each scope value with the resource indicators it applies to, which is the same per-target scoping the scope tuple of produces. Section 8.2 of that document records that the addressibility of individual grant components is unresolved, and the decomposition of bears on it, since a cell of an authorization details entry is addressable by construction.

Security Considerations

Fail Closed Every failure of the profile - an unreachable PDP, a malformed response, a shaping value that violates , an unrecognized crit member - MUST result in no token being issued. A PDP that cannot be consulted is not an authorization to proceed. Because the PDP is on the token issuance path, its availability becomes the AS's availability. Deployments should consider caching of decisions, local policy fallback that is explicitly configured rather than implicit, and the latency budget of the token endpoint.

Request Amplification One token request becomes many evaluations. A client controls the scopes it asks for, the targets it names, and the size of every authorization_details entry, and turns each entry into the product of its common data fields. That product is the legitimate meaning of a RAR entry, not an abuse of it; the feature becomes a burden only when it is used to excess. An AS that does not bound the fan-out lets an authenticated but unprivileged client impose disproportionate work on the PDP, and through the PDP on every other tenant of it. and are the two controls, and they are independent of each other. The first removes what the AS was never going to grant; the second caps what remains. An AS SHOULD also track fan-out per client over time. A per-request cap does not bound the rate at which maximum-size requests can be submitted, and a rate limit does not bound the cost of a single request; neither substitutes for the other. Section 11.7 places a matching obligation on the PDP, which "SHOULD apply reasonable protections to avoid common attacks tied to request payload size, the number of requests ... or memory consumption". An AS MUST NOT rely on it. Those protections take the form of the PDP shedding requests, and a request the PDP sheds is one the AS must fail closed on (), so leaning on them converts an amplification attack into an outage.

The Policy Decision Point as a Trust Dependency A PDP that can shape tokens can narrow every grant an AS issues, and a compromised PDP can deny service. The constraints in this document bound the damage in the other direction: because no shaping key may broaden a grant, because sub, aud, and cnf are reserved, and because the AS validates every constraining key before applying it, a compromised PDP cannot cause an AS to issue a token for a different subject, aimed at a different audience, bound to a different key, or bearing a privilege that no evaluation considered. This is why the reservations in are normative rather than advisory. An implementation that passed PDP-supplied claims into a token without checking them against that list would give the PDP the ability to mint arbitrary identities.

Integrity of the Decision Response The crit mechanism relies on the response arriving intact. An attacker able to strip crit from a response is also able to change decision to true, so crit does not extend the attack surface beyond what transport protection between the AS and the PDP must already cover. It is not a substitute for that protection, and deployments requiring non-repudiation of decisions should use the response signing mechanisms of .

Privacy Evaluation requests carry subject identifiers, client identifiers, targets, and authentication context to the PDP, and do so on every token issuance. Where the PDP is operated by a party other than the operator of the AS, this is a disclosure of authentication and access patterns for every user of the system. Requiring that identifier transformations be applied before the request is constructed () means that a PDP receiving pairwise or pseudonymous identifiers sees only the identifier the token itself will carry, rather than a durable global identifier. Deployments sensitive to this should prefer such identifiers. Where context conveys authentication context or device posture, deployments should include only what their policies actually consume. The design rule of already bounds how much that ought to be.

IANA Considerations The registrations requested by this document fall into two groups with different dependency properties, described in .

Registration Dependencies The capability registration in is an entry in a registry established by another body's specification, and inherits that registry's state. The two registries created in and are new registries created by this document, and have no such dependency. Section 12 asks IANA for two things: an authzen sub-namespace of urn:ietf:params under , and an "AuthZEN Policy Decision Point Capabilities" registry whose entries are named as URNs within that sub-namespace. At the time of writing, neither appears in the IANA registries. The urn:ietf:params sub-namespace registry has a registration policy of IETF Review , which a specification published outside the IETF stream cannot satisfy on its own. This document is on the IETF stream, and therefore can. Three resolutions are available, and the choice is for the working group:

1. This document, or a companion document, performs the registration of the authzen sub-namespace, satisfying IETF Review. The capability name then takes the form given in .
2. The capability is named in the urn:openid:authzen namespace rather than under urn:ietf:params, and no IANA action is requested for it. takes this route, naming its capability urn:openid:authzen:capability:access-request and its error conditions under urn:openid:authzen:access-request:error, so this is the scheme AuthZEN profiles use in practice. The capability name would be urn:openid:authzen:capability:token-issuance.
3. This document declines the dependency and registers its capability under urn:ietf:params:oauth, the sub-namespace established by , whose registration policy is Specification Required and is therefore not blocked. The capability name would be urn:ietf:params:oauth:authzen-capability:token-issuance.

A capability identifier is only useful if both parties compute the same string, so one naming scheme for all AuthZEN capabilities is worth more than this document's independence from any particular one. Options 1 and 2 both achieve that, and differ in which body assigns the name; option 2 has the advantage of matching what AuthZEN profiles already do, at the cost of leaving the registry asks for without entries. Option 3 is the fallback if neither is available.

AuthZEN Policy Decision Point Capability IANA is requested to register the following in the "AuthZEN Policy Decision Point Capabilities" registry established by , subject to :

Capability Name:

:token-issuance

Capability URN:

urn:ietf:params:authzen:token-issuance

Capability Description:

Support for the OAuth 2.0 token issuance profile, comprising the request mapping and the issuance response context vocabulary.

Change Controller:

IETF

Specification Document(s):

This document

• Editor's note. requires capability names to begin with a colon but gives no worked example of the resulting URN, so the rendering above is inferred. It should be confirmed against the registry as established and against the first registrations made in it.

Issuance Authorization Entity Types Registry IANA is requested to establish the "OAuth Token Issuance Authorization Entity Types" registry, with a registration policy of Specification Required , containing the following initial entries:

Type	Applies to	Description
user	subject	A natural person
client	subject	An OAuth client acting on its own behalf
workload	subject	A non-human software identity
audience	resource	The audience of the access being granted

Issuance Authorization Action Names Registry IANA is requested to establish the "OAuth Token Issuance Authorization Action Names" registry, with a registration policy of Specification Required , for the two short-name vocabularies from which action names in the reserved issue: space are composed. A gate action name is issue:<token-type>:<grant-type>, so the registry grows with the number of token types plus the number of grant types, not with their product. The combinations that are meaningful in a deployment are a matter of policy, not of registration. Every short name MUST match [a-z][a-z0-9_]{0,30}, and a composed action name MUST NOT exceed 50 characters. gives the reason: these bounds are what let the name be transformed mechanically into a relation identifier that relationship-based engines accept. Registrants should note that the hyphen is excluded deliberately, and that a short name therefore differs from the corresponding URI wherever that URI contains one. Token type short names, initially:

Short name	Token type
access_token	urn:ietf:params:oauth:token-type:access_token
refresh_token	urn:ietf:params:oauth:token-type:refresh_token
id_token	urn:ietf:params:oauth:token-type:id_token

Grant type short names, initially:

Short name	Grant type
authorization_code	authorization_code
client_credentials	client_credentials
refresh_token	refresh_token
token_exchange	urn:ietf:params:oauth:grant-type:token-exchange
device_code	urn:ietf:params:oauth:grant-type:device_code
jwt_bearer	urn:ietf:params:oauth:grant-type:jwt-bearer
saml2_bearer	urn:ietf:params:oauth:grant-type:saml2-bearer

Registrations MUST give the URI or parameter value the short name corresponds to, and MUST state which of the two vocabularies they join. Names outside the issue: prefix are not registered here, since scope values and the action names of are carried verbatim and are not registered vocabularies. This document reserves one further name outside the issue: prefix: authorization_detail, which substitutes for the action of an authorization details entry that names none.

References Normative References The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. This document specifies a new parameter authorization_details that is used to carry fine-grained authorization data in OAuth messages. OpenID Foundation In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. The System for Cross-domain Identity Management (SCIM) specifications are designed to make identity management in cloud-based applications and services easier. The specification suite builds upon experience with existing schemas and deployments, placing specific emphasis on simplicity of development and integration, while applying existing authentication, authorization, and privacy models. Its intent is to reduce the cost and complexity of user management operations by providing a common user schema and extension model as well as binding documents to provide patterns for exchanging this schema using HTTP. This document provides a platform-neutral schema and extension model for representing users and groups and other resource types in JSON format. This schema is intended for exchange and use with cloud service providers. The "amr" (Authentication Methods References) claim is defined and registered in the IANA "JSON Web Token Claims" registry, but no standard Authentication Method Reference values are currently defined. This specification establishes a registry for Authentication Method Reference values and defines an initial set of Authentication Method Reference values. This document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access. This specification defines a profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner. This document defines the pushed authorization request (PAR) endpoint, which allows clients to push the payload of an OAuth 2.0 authorization request to the authorization server via a direct request and provides them with a request URI that is used as reference to the data in a subsequent call to the authorization endpoint. It is not uncommon for resource servers to require different authentication strengths or recentness according to the characteristics of a request. This document introduces a mechanism that resource servers can use to signal to a client that the authentication event associated with the access token of the current request does not meet its authentication requirements and, further, how to meet them. This document also codifies a mechanism for a client to request that an authorization server achieve a specific authentication strength or recentness when processing an authorization request. This document describes best current security practice for OAuth 2.0. It updates and extends the threat model and security advice given in RFCs 6749, 6750, and 6819 to incorporate practical experiences gathered since OAuth 2.0 was published and covers new threats relevant due to the broader application of OAuth 2.0. Further, it deprecates some modes of operation that are deemed less secure or even insecure. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. This document describes a new sub-delegation for the 'ietf' URN namespace for registered protocol items. The 'ietf' URN namespace is defined in RFC 2648 as a root for persistent URIs that refer to IETF- defined resources. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document establishes an IETF URN Sub-namespace for use with OAuth-related specifications. This document is not an Internet Standards Track specification; it is published for informational purposes. RFC 2648 defines the "ietf" URN namespace and a number of sub- namespaces. RFC 3553 defines an additional sub-namespace, "params", and creates a registry to document allocations under that. But there is no registry that lists, in one place, all sub-namespaces of "ietf". This document creates and populates such a registry, thereby changing the mechanism defined in RFC 2648 for adding new sub- namespaces of "ietf". Axiomatics Aserto 3Edges This specification defines a profile of OAuth 2.0 Rich Authorization Requests leveraging the OpenID AuthZEN authorization request/response formats within the authorization_details JSON object. Authorization servers and resource servers from different vendors can leverage this profile to request and receive relevant authorization decisions from an AuthZEN-compatible PDP in an interoperable manner. Idura Itaú Twilio This document defines the Deferred Token Response (DTR) extension for OAuth 2.1. In existing OAuth grants, the token endpoint either issues an access token or returns an error. DTR establishes a generic asynchronous token request mechanism that any OAuth grant may plug into. In DTR-aware flows, the authorization server returns a deferral_code and a polling interval, indicating that the final token response will be available at a later time. The client retrieves the eventual response by polling the token endpoint, or by receiving a callback from the authorization server when one is configured. Defakto Security Defakto Security MITRE NSA-CCSS Ping Identity Okta This specification describes a mechanism for preserving identity and authorization information across trust domains that use the OAuth 2.0 Framework. A JSON Web Token (JWT) authorization grant, obtained through an intra-domain OAuth 2.0 Token Exchange, facilitates the cross-domain acquisition of an access token. The relevant identity and authorization information is chained throughout the flow by being conveyed in the respective artifacts exchanged at each step of the process. Chaining across multiple domains is achieved by using the same protocol every time a trust domain boundary is crossed. Okta Independent Ping Identity This specification provides a mechanism for an application to use an identity assertion to obtain an access token for a third-party API by coordinating through an identity provider that the downstream Resource Authorization Server already trusts for single sign-on (SSO), using Token Exchange [RFC8693] and JWT Profile for OAuth 2.0 Authorization Grants [RFC7523]. This pattern is informally referred to as Cross-App Access (XAA). CrowdStrike Practical Identity LLC Defakto Security Transaction Tokens (Txn-Tokens) are designed to maintain and propagate user identity, workload identity and authorization context throughout the Call Chain within a trusted domain during the processing of external requests (e.g. such as API calls) or requests initiated internally within the Trust Domain. Txn-Tokens ensure that this context is preserved throughout the Call Chain thereby enhancing security and consistency in complex, multi-service architectures. Independent yes.com Biza.io Independent

Acknowledgments This work was motivated in part by Karl McGuinness, whose initiative to bridge OAuth and AuthZEN - in and its OAuth completion mode - established that a Policy Decision Point belongs behind the token endpoint, and that the response of such a Policy Decision Point may legitimately shape what is issued. This document takes up the other half of that decision. Thanks also to the participants in the OpenID AuthZEN interoperability events, whose December 2025 identity provider scenario demonstrated AuthZEN search operations populating token claims, and to the members of the AuthZEN Working Group and the OAuth Working Group.

Document History

Since -00

• A request may now name several issuance targets. The single-target MUST in becomes a SHOULD inherited from Section 5 and Section 4.10.2, and says how tuples are formed per target, how a denied gate removes one, and why a scope survives only where it was permitted at every surviving target.
• Requested authorization_details now reach the PDP. decomposes an entry along the product of Section 2.2 into one evaluation per location, action, and datatype, with the datatype carried as a trailing segment of action.name.
• orders the AS's own reductions before the PDP call, so the batch carries only what the AS would otherwise grant.
• requires an AS to bound the size of the batch without naming a bound, and covers the attack.
• crit is unilateral. The enforcement point capability declaration and the precondition that gated crit on it are removed, so this profile no longer uses context.issuance on the request leg at all.
• The structural check of tests a returned entry against a single covering request entry rather than against the union of the same-type entries, and a member absent from the request entry no longer causes rejection.
• Added worked examples of both authorization details shapes, cross-references between the rules and the examples that exercise them, and a Related Work paragraph on .