AuthZEN Profile for OAuth 2.0 Token Issuance

1.1. 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 (Section 10) 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. [AUTHZEN] 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 [ZANZIBAR] 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 (Section 6.3).¶

1.2. 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 (Section 6), 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.¶

1.3. Requirements Language

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

4.1. 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. [AUTHZEN] 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 Section 3 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 Section 3 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 [AUTHZEN] 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 Section 5 is assembled from values the AS already holds, and this profile implies no additional lookup to construct it.¶

4.2. 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. [I-D.gerber-oauth-deferred-token-response] 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 Section 6 to the token it eventually issues. Delay does not relax Section 6.3: a decision that arrives late constrains the issued token exactly as one that arrives promptly would.¶

4.3. The Seam Inside the Authorization Server

Section 3 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 Section 5 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.¶

5.1. Subject

subject identifies the party the issued token will represent.¶

subject.type MUST be one of the registered values in Section 12.3:¶

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

5.2. Resource

For the gate and scope tuples of Section 5.3, resource.type MUST be audience and each resource.id MUST be an issuance target. Authorization detail tuples name their resource differently, as Section 5.3.4 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 [RFC8707], 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.¶

5.3. 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. [RFC8693] 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 ([RFC9396]) asks the second question in a richer vocabulary than a scope string, and gets a third tuple shape (Section 5.3.4) rather than a reinterpretation of the second.¶

issue:<token-type>:<grant-type>

<action>
<action>:<datatype>

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

The single-type rule of Section 6.1 applies here as well: each key above has one JSON type, and bindings defining further context keys MUST state a type for each.¶

Per Section 1.1, 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 (Section 5.3.1) and does not appear in context at all.¶

5.5. Batching and Result Composition

6.1. The issuance Envelope

All keys defined by this profile appear within a single issuance member of the response context:¶

{
  "decision": true,
  "context": {
    "reason_admin": { "200": "matched policy P-4471" },
    "issuance": {
      "token_lifetime": 300,
      "claims": { "groups": ["engineering"] }
    }
  }
}

An AS implementing this profile MUST process context.issuance and MUST ignore unrecognized members outside it, preserving the advisory character that [AUTHZEN] gives response context generally.¶

The examples of Section 9 carry the envelope on live responses: token_lifetime in Section 9.1, claims in Section 9.2, and granted_scope in Section 9.3.¶

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

6.2. Mandatory-to-Understand

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

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

6.4. Constraining Keys

The keys in this section are mandatory-to-understand under Section 6.2.¶

{
  "decision": true,
  "context": {
    "issuance": {
      "claims": { "max_transfer_eur": 500 },
      "crit": [ "max_transfer_eur" ]
    }
  }
}

6.5. Decorating Keys

6.6. Aggregation Across a Batch

An Access Evaluations response in [AUTHZEN] 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:¶

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

9.1. Client Credentials, One Scope

One scope is requested, so the request is one gate tuple (Section 5.3.1) and one scope tuple (Section 5.3.3). 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 Section 5.2.2 provides.¶

POST /access/v1/evaluations HTTP/1.1
Host: pdp.example.com
Content-Type: application/json
Authorization: Bearer <token>

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

HTTP/1.1 200 OK
Content-Type: application/json

{
  "evaluations": [
    {
      "decision": true,
      "context": { "issuance": { "token_lifetime": 900 } }
    },
    { "decision": true }
  ]
}

9.2. 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 Section 5.5.5.¶

{
  "subject":  { "type": "user", "id": "U0405936" },
  "resource": {
    "type": "audience",
    "id": "https://api.example/files"
  },
  "context": {
    "client_id": "chatterbox",
    "acr": "urn:example:loa:2"
  },
  "evaluations": [
    {
      "action": {
        "name": "issue:access_token:authorization_code"
      }
    },
    { "action": { "name": "files.read"   } },
    { "action": { "name": "files.write"  } },
    { "action": { "name": "files.delete" } }
  ],
  "options": { "evaluations_semantic": "execute_all" }
}

{
  "evaluations": [
    { "decision": true },
    {
      "decision": true,
      "context": {
        "issuance": { "claims": { "groups": ["engineering"] } }
      }
    },
    { "decision": true },
    {
      "decision": false,
      "context": { "reason_admin": { "403": "policy P-118" } }
    }
  ]
}

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

9.3. No Scopes Requested

No scopes and no default set, so the gate tuple stands alone (Section 5.5.1). 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.¶

{
  "subject":  { "type": "client", "id": "svc-reporting" },
  "action":   {
    "name": "issue:access_token:client_credentials"
  },
  "resource": {
    "type": "audience",
    "id": "https://telemetry.example"
  },
  "context": { "client_id": "svc-reporting" }
}

{
  "decision": true,
  "context": {
    "issuance": {
      "granted_scope": "telemetry.write",
      "token_lifetime": 900
    }
  }
}

9.4. 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 ([RFC9396] Section 2.1); it is shown decoded in the block that follows.¶

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

grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&resource=https%3A%2F%2Fexample.com%2Fcustomers
&authorization_details=...

[
  {
    "type": "customer_information",
    "locations": [ "https://example.com/customers" ],
    "actions": [ "read" ],
    "datatypes": [ "contacts" ]
  }
]

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

{
  "subject": { "type": "user", "id": "U0405936" },
  "context": {
    "client_id": "chatterbox"
  },
  "evaluations": [
    {
      "action": {
        "name": "issue:access_token:authorization_code"
      },
      "resource": {
        "type": "audience",
        "id": "https://example.com/customers"
      }
    },
    {
      "action": { "name": "read:contacts" },
      "resource": {
        "type": "customer_information",
        "id": "https://example.com/customers"
      }
    }
  ],
  "options": { "evaluations_semantic": "execute_all" }
}

{
  "evaluations": [
    { "decision": true },
    { "decision": true }
  ]
}

Every cell was permitted, so the entry reassembles to itself and the AS issues a token carrying the requested authorization_details unchanged.¶

9.5. 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 Section 5.5.1.¶

[
  {
    "type": "customer_information",
    "locations": [
      "https://example.com/customers",
      "https://eu.example.com/customers"
    ],
    "actions": [ "read" ],
    "datatypes": [ "contacts", "photos" ]
  }
]

No top-level resource is shown, because no one resource is shared: each evaluation carries its own.¶

{
  "subject": { "type": "user", "id": "U0405936" },
  "context": {
    "client_id": "chatterbox"
  },
  "evaluations": [
    {
      "action": {
        "name": "issue:access_token:authorization_code"
      },
      "resource": {
        "type": "audience",
        "id": "https://example.com/customers"
      }
    },
    {
      "action": {
        "name": "issue:access_token:authorization_code"
      },
      "resource": {
        "type": "audience",
        "id": "https://eu.example.com/customers"
      }
    },
    {
      "action": { "name": "read:contacts" },
      "resource": {
        "type": "customer_information",
        "id": "https://example.com/customers"
      }
    },
    {
      "action": { "name": "read:photos" },
      "resource": {
        "type": "customer_information",
        "id": "https://example.com/customers"
      }
    },
    {
      "action": { "name": "read:contacts" },
      "resource": {
        "type": "customer_information",
        "id": "https://eu.example.com/customers"
      }
    },
    {
      "action": { "name": "read:photos" },
      "resource": {
        "type": "customer_information",
        "id": "https://eu.example.com/customers"
      }
    }
  ],
  "options": { "evaluations_semantic": "execute_all" }
}

The PDP permits both gates and denies one cell, photos at the European location.¶

{
  "evaluations": [
    { "decision": true },
    { "decision": true },
    { "decision": true },
    { "decision": true },
    { "decision": true },
    {
      "decision": false,
      "context": { "reason_admin": { "403": "residency R-4" } }
    }
  ]
}

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 Section 5.5.6 requires:¶

[
  {
    "type": "customer_information",
    "locations": [ "https://example.com/customers" ],
    "actions": [ "read" ],
    "datatypes": [ "contacts", "photos" ]
  },
  {
    "type": "customer_information",
    "locations": [ "https://eu.example.com/customers" ],
    "actions": [ "read" ],
    "datatypes": [ "contacts" ]
  }
]

Both gates permitted, so both targets remain in the audience. Had the second gate been denied instead, Section 5.5.4 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.¶

10.1. Related Work

Two other efforts place an AuthZEN Policy Decision Point behind an authorization server.¶

[I-D.brossard-oauth-rar-authzen] 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. Section 5.3.4 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.¶

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

[GRANTMGMT] 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 Section 6 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 Section 5.3.3 produces. Section 8.2 of that document records that the addressibility of individual grant components is unresolved, and the decomposition of Section 5.3.4 bears on it, since a cell of an authorization details entry is addressable by construction.¶

11.1. Fail Closed

Every failure of the profile - an unreachable PDP, a malformed response, a shaping value that violates Section 6.3, 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.¶

11.2. 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 Section 5.3.4 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.¶

Section 5.5.2 and Section 5.5.3 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.¶

[AUTHZEN] 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 (Section 11.1), so leaning on them converts an amplification attack into an outage.¶

11.3. 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 Section 6.5.1 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.¶

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

11.5. 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 (Section 5.1) 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 Section 1.1 already bounds how much that ought to be.¶

12.1. Registration Dependencies

The capability registration in Section 12.2 is an entry in a registry established by another body's specification, and inherits that registry's state. The two registries created in Section 12.3 and Section 12.4 are new registries created by this document, and have no such dependency.¶

[AUTHZEN] Section 12 asks IANA for two things: an authzen sub-namespace of urn:ietf:params under [RFC3553], 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 [RFC6924], 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 [RFC3553] registration of the authzen sub-namespace, satisfying IETF Review. The capability name then takes the form given in Section 12.2.¶

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. [ARAP] 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 [RFC6755], 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 [AUTHZEN] asks for without entries. Option 3 is the fallback if neither is available.¶

12.2. AuthZEN Policy Decision Point Capability

IANA is requested to register the following in the "AuthZEN Policy Decision Point Capabilities" registry established by [AUTHZEN], subject to Section 12.1:¶

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

12.3. 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 [RFC8126], containing the following initial entries:¶

12.4. 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 [RFC8126], 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. Section 5.3.2 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:¶

Grant type short names, initially:¶

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 Section 5.3.4 are carried verbatim and are not registered vocabularies.¶

This document reserves one further name outside the issue: prefix: authorization_detail, which Section 5.3.4 substitutes for the action of an authorization details entry that names none.¶

13.1. Normative References

[AUTHZEN]

OpenID Foundation AuthZEN Working Group, "Authorization API 1.0", 11 January 2026, <https://openid.net/specs/authorization-api-1_0-final.html>.

[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/rfc/rfc2119>.

[RFC6749]

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

[RFC7519]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/rfc/rfc7519>.

[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/rfc/rfc8174>.

[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/rfc/rfc8693>.

[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/rfc/rfc9396>.

13.2. Informative References

[ARAP]

McGuinness, K., "AuthZEN Access Request and Approval Profile 1.0", 27 July 2026, <https://openid.github.io/authzen/authzen-access-request-approval-profile-1_0>.

[GRANTMGMT]

Lodderstedt, T., Low, S., and D. Postnikov, "Grant Management for OAuth 2.0", 26 June 2026, <https://openid.bitbucket.io/fapi/oauth-v2-grant-management.html>.

[I-D.brossard-oauth-rar-authzen]

Brossard, D., Gazitt, O., and A. Babeanu, "AuthZEN Request/Response Profile for OAuth 2.0 Rich Authorization Requests", Work in Progress, Internet-Draft, draft-brossard-oauth-rar-authzen-03, 8 July 2024, <https://datatracker.ietf.org/doc/html/draft-brossard-oauth-rar-authzen-03>.

[I-D.gerber-oauth-deferred-token-response]

Jacobsen, F. K., de Oliveira Niero, G., and M. Gerber, "Deferred Token Response", Work in Progress, Internet-Draft, draft-gerber-oauth-deferred-token-response-00, 23 June 2026, <https://datatracker.ietf.org/doc/html/draft-gerber-oauth-deferred-token-response-00>.

[I-D.ietf-oauth-identity-assertion-authz-grant]

Parecki, A., McGuinness, K., and B. Campbell, "Identity Assertion JWT Authorization Grant", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-assertion-authz-grant-04, 21 May 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-identity-assertion-authz-grant-04>.

[I-D.ietf-oauth-identity-chaining]

Schwenkschuster, A., Kasselman, P., Burgin, K., Jenkins, M. J., Campbell, B., and A. Parecki, "OAuth Identity and Authorization Chaining Across Domains", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-chaining-17, 19 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-identity-chaining-17>.

[I-D.ietf-oauth-transaction-tokens]

Tulshibagwale, A., Fletcher, G., and P. Kasselman, "Transaction Tokens", Work in Progress, Internet-Draft, draft-ietf-oauth-transaction-tokens-11, 30 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-11>.

[RFC3553]

Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 2003, <https://www.rfc-editor.org/rfc/rfc3553>.

[RFC6755]

Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace for OAuth", RFC 6755, DOI 10.17487/RFC6755, October 2012, <https://www.rfc-editor.org/rfc/rfc6755>.

[RFC6924]

Leiba, B., "Registration of Second-Level URN Namespaces under "ietf"", RFC 6924, DOI 10.17487/RFC6924, April 2013, <https://www.rfc-editor.org/rfc/rfc6924>.

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/rfc/rfc7515>.

[RFC7643]

Hunt, P., Ed., Grizzle, K., Wahlstroem, E., and C. Mortimore, "System for Cross-domain Identity Management: Core Schema", RFC 7643, DOI 10.17487/RFC7643, September 2015, <https://www.rfc-editor.org/rfc/rfc7643>.

[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/rfc/rfc8126>.

[RFC8176]

Jones, M., Hunt, P., and A. Nadalin, "Authentication Method Reference Values", RFC 8176, DOI 10.17487/RFC8176, June 2017, <https://www.rfc-editor.org/rfc/rfc8176>.

[RFC8707]

Campbell, B., Bradley, J., and H. Tschofenig, "Resource Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707, February 2020, <https://www.rfc-editor.org/rfc/rfc8707>.

[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/rfc/rfc9068>.

[RFC9126]

Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", RFC 9126, DOI 10.17487/RFC9126, September 2021, <https://www.rfc-editor.org/rfc/rfc9126>.

[RFC9470]

Bertocci, V. and B. Campbell, "OAuth 2.0 Step Up Authentication Challenge Protocol", RFC 9470, DOI 10.17487/RFC9470, September 2023, <https://www.rfc-editor.org/rfc/rfc9470>.

[RFC9700]

Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, "Best Current Practice for OAuth 2.0 Security", BCP 240, RFC 9700, DOI 10.17487/RFC9700, January 2025, <https://www.rfc-editor.org/rfc/rfc9700>.

[ZANZIBAR]

Pang, R., Caceres, R., and M. Burrows, "Zanzibar: Google's Consistent, Global Authorization System", 2019, <https://www.usenix.org/conference/atc19/presentation/pang>.

Since -00

• A request may now name several issuance targets. The single-target MUST in Section 5.2 becomes a SHOULD inherited from [RFC8707] Section 5 and [RFC9700] Section 4.10.2, and Section 5.2.2 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. Section 5.3.4 decomposes an entry along the product of [RFC9396] Section 2.2 into one evaluation per location, action, and datatype, with the datatype carried as a trailing segment of action.name.¶

• Section 5.5.2 orders the AS's own reductions before the PDP call, so the batch carries only what the AS would otherwise grant.¶

• Section 5.5.3 requires an AS to bound the size of the batch without naming a bound, and Section 11.2 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 Section 6.4.4 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 [GRANTMGMT].¶