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

resource.type MUST be audience. resource.id MUST be the issuance target.¶

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

Where the request carries an explicit target - an audience parameter, or a resource parameter in the sense of [RFC8707] - that value determines resource.id. Where it does not, the AS's default audience for the grant determines it.¶

5.3. Actions: Gate Tuples and Scope 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.¶

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

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

Where a request yields more than one tuple, the AS MUST use the Access Evaluations API of [AUTHZEN] 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.¶

A request reduces to a single evaluation only when it names no scopes, in which case the gate tuple stands alone.¶

This document produces exactly one gate tuple. 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.¶

execute_all is required because scope denials must be able to narrow the grant rather than fail it: an AS that requested three scopes and received two permits issues a token bearing two scopes, and reports the reduced set in the scope response parameter as [RFC6749] already requires.¶

A gate denial, by contrast, is fatal. If any leading gate tuple has a decision of false, the AS MUST fail the request and MUST NOT issue a token, irrespective of the other results.¶

[AUTHZEN] evaluation semantics are selected per request and cannot mark an individual batch item as a precondition, so this composition rule is enforced by the AS. This is well within the PEP's role - the AS is already interpreting per-item results in order to downscope.¶

Where the request named scopes and every scope tuple is denied, the AS MUST fail the request rather than issue a token with an empty scope set, even though the gate permitted it. A permitted gate authorizes a token of that kind to exist; it does not authorize an empty one.¶

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

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

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

7.1. Policy Decision Point Capabilities

A PDP supporting this profile MUST advertise the capability URN registered in Section 12.2 in the capabilities member of its metadata document, retrievable at /.well-known/authzen-configuration:¶

{
  "policy_decision_point": "https://pdp.example.com",
  "access_evaluation_endpoint":
      "https://pdp.example.com/access/v1/evaluation",
  "access_evaluations_endpoint":
      "https://pdp.example.com/access/v1/evaluations",
  "capabilities": [
    "urn:ietf:params:authzen:token-issuance"
  ]
}

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 [I-D.ietf-oauth-identity-assertion-authz-grant] 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 Section 12.4, 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 (Section 5.5).¶

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; [AUTHZEN] notes that an unauthenticated PDP can be probed for the shape of its policy. The Action Search API of [AUTHZEN] 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.¶

7.2. Policy Enforcement Point Capabilities

An AS MAY declare the capabilities it understands in the request context, using the same URNs:¶

{
  "subject":  { "type": "user", "id": "U0405936" },
  "action":   { "name": "issue:access_token:authorization_code" },
  "resource": {
    "type": "audience",
    "id": "https://api.example/files"
  },
  "context": {
    "issuance": {
      "capabilities": [
        "urn:ietf:params:authzen:token-issuance"
      ]
    }
  }
}

Capability URNs are reused on both legs rather than introducing a list of key names, so that extensions obtain granularity from the registry rather than from a second, parallel mechanism.¶

The declaration is an optimization, not a safety mechanism, and this is why it is OPTIONAL. Safety is already unilateral: a PDP that marks a key crit obliges any AS implementing this profile to fail closed if it does not understand it (Section 6.2), and an AS that does not implement this profile ignores the issuance envelope entirely, crit included. Withholding crit from an undeclared AS therefore protects nothing. What the declaration buys a PDP is the ability to choose a decision the AS can actually enforce - denying, say, rather than permitting subject to a constraint it knows will be discarded. That is worth having as extensions add vocabulary, and worth nothing in a deployment using only the keys defined here.¶

An AS is not otherwise required to announce itself. The behaviors this profile depends on - treating a gate denial as fatal, narrowing to the permitted scope subset - are constitutive of implementing it rather than features an AS might separately lack, and [AUTHZEN] already assumes a PDP trusts its PEP to enforce what it decides.¶

The declaration describes the AS's implementation and MUST NOT be treated as an authorization input. A PDP that varied its decision based on it would be allowing a property of the enforcement point to influence policy.¶

9.1. Client Credentials, One Scope

One scope is requested, so the request is the gate tuple and one scope tuple. This is the floor: two evaluations, so the Access Evaluations API.¶

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",
    "issuance": {
      "capabilities": [
        "urn:ietf:params:authzen:token-issuance"
      ]
    }
  },
  "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.¶

{
  "subject":  { "type": "user", "id": "U0405936" },
  "resource": {
    "type": "audience",
    "id": "https://api.example/files"
  },
  "context": {
    "client_id": "chatterbox",
    "acr": "urn:example:loa:2",
    "issuance": {
      "capabilities": [
        "urn:ietf:params:authzen:token-issuance"
      ]
    }
  },
  "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. 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": {
    "issuance": {
      "capabilities": [
        "urn:ietf:params:authzen:token-issuance"
      ]
    }
  }
}

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

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

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

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. 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.3. 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.4. 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 are carried verbatim and are not a registered vocabulary.¶

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

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

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

[ZANZIBAR]

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