AuthZEN Profile for Authorization Claims in JWT Access Tokens

Internet-Draft	AuthZEN Authorization Claims	August 2026
Gazitt	Expires 15 February 2027	[Page]

Abstract

RFC 9068 recommends that an authorization server placing group memberships, roles, or entitlements in a JWT access token draw those claims from the SCIM user schema. It says what the claims are named and how their values are encoded, and it does not say where an authorization server obtains them. In deployments today they come from a directory, a database, or a vendor-specific hook, and the question they answer is an authorization question asked of something that is not the authorization system.¶

This document profiles the Resource Search API of the OpenID AuthZEN Authorization API for that purpose. It binds each authorization claim to a search, defines how a search result set becomes a claim value, and requires that a search result never influence whether a token is issued or what authority it conveys. It may be applied on its own, by an authorization server that externalizes claim enrichment but not its issuance decision, or alongside the companion framework document that externalizes the decision.¶

1. Introduction

[RFC9068] Section 2.2.3.1 describes the authorization attributes an authorization server (AS) commonly places in a JWT access token beyond the delegated authority the grant itself conveys: the group memberships, roles, and entitlements a resource server is expected to consult. It recommends the groups, roles, and entitlements attributes of the user schema of [RFC7643] as the claim types, and registers all three as JWT claims.¶

What it does not describe is where the values come from. An AS populating groups is answering the question "which groups does this subject belong to." That is an authorization question, and in most deployments it is answered by a directory query, a database join, or a proprietary extension point rather than by the system that holds the deployment's authorization policy.¶

[AUTHZEN] answers questions of exactly that shape. Its Resource Search API returns the resources of a given type on which a given subject may perform a given action. Given a subject and a member action, the resources of type group it returns are the groups the subject is a member of.¶

This document defines the bindings that make that correspondence interoperable, and the rules an AS follows to turn a search result into a claim.¶

1.1. Why a Search

[AUTHZEN] defines a Search API for enumerating one leg of a tuple given the other two, and enumerating what a subject holds is that operation exactly.¶

The alternative would be to obtain these claims as a side effect of an evaluation, attaching the enumeration to the response context of a decision the AS was making anyway. [ISSUANCE] defines a claims key that could be used that way, and declines to route these claims through it. An evaluation response is the answer to the question the request asked, and an AS asking whether a token may be issued has not asked what its subject belongs to. A purpose-built operation exists for the second question, so the second question is asked with it.¶

So the AS makes each call for what it is for, and composes the results. The consequence is worth stating at the outset: this document asks nothing of a PDP that [AUTHZEN] does not already require. The searches it specifies are ordinary Resource Search requests carrying registered type and action names, and a PDP answering them is not required to know that their results will reach a token. Everything specified here is a rule for the authorization server.¶

1.2. Composition with the Issuance Framework

This document is independent of [ISSUANCE]. An AS that does not externalize its issuance decision may still externalize claim enrichment, and for such an AS everything in this document applies unchanged; the decision to issue is simply its own.¶

Where both are used, they compose as follows:¶

The decision governs. A token is minted only if the gate of [ISSUANCE] permits it, and no search result contributes to that decision (Section 7).¶
Enrichment is discardable. Where the gate denies, any search results the AS has obtained are discarded and no claim is rendered from them.¶

[ISSUANCE] defines no vocabulary this document extends, and this document defines none of its own, so the two interact only through that ordering.¶

Where the grant is a member of the token exchange family, [I-D.gazitt-oauth-authzen-token-exchange] determines the subject, and the searches of this document follow it (Section 6.1).¶

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

2. Terminology

This document uses the terms Authorization Server, Client, Resource Server, access token, and scope from [RFC6749]; Policy Decision Point (PDP), Policy Enforcement Point (PEP), Subject, Action, Resource, and Context from [AUTHZEN]; and gate tuple and scope tuple from [ISSUANCE].¶

Authorization claim:: One of the claims of [RFC9068] Section 2.2.3.1 - groups, roles, and entitlements - or any other claim whose value enumerates what a subject holds.¶
Claim binding:: The association of an authorization claim with an AuthZEN resource type and action name, such that a Resource Search over that type and action enumerates the claim's members. See Section 5.¶
Bound claim:: An authorization claim for which the AS has a claim binding configured, and which it will therefore attempt to populate on the token it is about to issue.¶

4. Architecture

+--------+           +----------------------+        +-------+
| Client |           | Authorization Server |        |  PDP  |
+---+----+           |        (PEP)         |        +---+---+
    |                +----------+-----------+            |
    | 1. token req              |                        |
    +-------------------------->|                        |
    |                           | 2. evaluate (ISSUANCE) |
    |                           +----------------------->|
    |                           |                        |
    |                           | 3. search: groups      |
    |                           +----------------------->|
    |                           | 4. search: roles       |
    |                           +----------------------->|
    |                           |                        |
    |                           | 5. decision            |
    |                           |<-----------------------+
    |                           | 6. result sets         |
    |                           |<-----------------------+
    |                           |                        |
    |                           | 7. if permitted, mint  |
    |                           |    and render claims   |
    | 8. token response         |                        |
    |<--------------------------+                        |

Steps 3 and 4 are drawn as concurrent with step 2 because Section 7 permits it. They are semantically after it: their results are discarded if step 5 denies.¶

Step 2 is one request under [ISSUANCE], ordinarily a batch. Each bound claim is a separate search, because a Resource Search names one resource type and [AUTHZEN] defines no batch form for searches.¶

5. Claim Bindings

5.1. Membership as an Action

A claim binding names an AuthZEN action. The names this document registers - member, assignee, holder - describe how a subject relates to a resource rather than an operation the subject performs on it.¶

Nothing in [AUTHZEN] requires otherwise. An action names something asserted of a subject and a resource together, and "Alice is a member of engineering" fills the three positions of a tuple as readily as "Alice may read document 7" does. How a deployment's PDP arrives at either answer is its own affair.¶

The names are consequently meaningful in an evaluation as well as in a search, which is what makes a search result checkable. [AUTHZEN] Section 8.1 states that a search result, used in a subsequent evaluation, SHOULD yield a permit; an AS or an auditor can verify any member of a rendered claim by evaluating the corresponding tuple.¶

5.2. Registered Bindings

This document registers the following bindings in the registry established in Section 15.2:¶

Table 1
Claim	resource.type	action.name
`groups`	`group`	`member`
`roles`	`role`	`assignee`
`entitlements`	`entitlement`	`holder`

Reading the first row: the members of the groups claim are the identifiers of the resources of type group on which the subject may perform the action member.¶

Each action name matches the grammar [ISSUANCE] defines for registered action names, [a-z][a-z0-9_]{0,30}. They are not composed with the issue: prefix, which [ISSUANCE] reserves for gate actions.¶

Editor's note. member is the settled choice of the three. It is the name [RFC7643] uses, and it is what schema languages call this association in their own examples. assignee and holder are less settled: a role or an entitlement is variously said to be assigned to, granted to, or held by a subject, and a single name could serve for both claims, with the resource type carrying the distinction. Distinct names are registered here on the theory that policy is easier to read when names differ where the concepts do. Implementer feedback is invited.¶

5.3. Deployment Configuration

A deployment that uses action names other than the registered ones configures the AS with the names it uses. The registered bindings are defaults, not constraints on a deployment's policy vocabulary.¶

They earn their place by being defaults. An AS and a PDP from different implementers, neither configured for the other, interoperate on these three claims only because both arrive at group/member without being told. A deployment that overrides a binding has taken on the configuration burden knowingly, which is a reasonable trade and a poor default.¶

A deployment MAY also bind a claim this document does not register, using a binding registered under Section 15.2 or one local to the deployment. A local binding is not interoperable and SHOULD NOT use a claim name registered in the JSON Web Token Claims registry for some other purpose.¶

6. Forming the Search Request

For each bound claim, the AS forms one Resource Search request as defined in Section 8.5 of [AUTHZEN].¶

6.1. Subject

The subject of every search MUST be the same entity as the subject of the gate tuple of [ISSUANCE]: the same type and the same id, the latter being the identifier the AS intends to place in the issued token's subject claim.¶

The requirement is not merely for tidiness. A claim enumerating what a subject holds is only true of the subject the token names, and any identifier transformation the AS applies - pairwise identifiers, resolution of a foreign identity to a local account - MUST therefore be applied before the search is formed, exactly as [ISSUANCE] requires of the evaluation.¶

Where [I-D.gazitt-oauth-authzen-token-exchange] applies, the subject is the exchange subject and never the requesting party. The token represents the subject, and a claim enumerating the requesting party's holdings would assert of the subject something that is not true of it.¶

6.2. Action and Resource

action.name MUST be the action name of the claim binding, and resource.type MUST be its resource type. The resource object carries no id; Section 8.5.1 of [AUTHZEN] states that the identifier of the entity being searched for is omitted, and is ignored if present.¶

6.3. Context

An AS SHOULD convey in the search context the same values it conveys on the evaluation request under [ISSUANCE], other than the capability declaration of that document, which concerns response shaping and has no meaning on a search. It MAY additionally convey:¶

Table 2
Key	Type	Value
`audience`	array of strings	The issuance targets of the token being minted

The type is an array for the same reason [ISSUANCE] makes its audience shaping key an array: the value is a set, and a set has one JSON rendering here.¶

This key exists because [RFC9068] scopes its authorization claims to the target, describing roles and groups "relevant to the resource being accessed" and entitlements "for the targeted resource," while a Resource Search has no slot to say so. Its mandatory entities are the subject, the action, and the type of the resource being enumerated; the resource identifier position is the answer, not an input. There is no second resource.¶

The consequence is that this is advisory input, and this document does not pretend otherwise. A PDP MAY use it to scope the result set and MAY ignore it, so an AS MUST NOT assume the returned set has been filtered by target, and MUST NOT represent the resulting claim to itself as target-scoped. A deployment that requires the scoping to be honored registers a binding whose resource type distinguishes the target, which puts the distinction in the type slot where a PDP must read it.¶

6.4. Endpoint Selection

Where the HTTPS binding of [AUTHZEN] is in use, the request is sent to the search_resource_endpoint published in the PDP's metadata, or to /access/v1/search/resource where metadata provides no value.¶

Section 9.1.1 of [AUTHZEN] states that the absence of an endpoint parameter is sufficient for a PEP to determine that the PDP does not support the corresponding API. An AS whose PDP publishes metadata without search_resource_endpoint, and which has not been configured with an endpoint out of band, MUST NOT attempt the searches; every bound claim then fails under Section 10. This is a deployment error rather than a request error, and an AS SHOULD detect it at configuration time rather than at the token endpoint.¶

7. Ordering

An AS MUST NOT include an enrichment claim in a token it does not issue, and MUST NOT treat a search result as authorizing anything. In particular, an AS MUST NOT derive the scope claim, the audience, or authorization_details from search results, and MUST NOT allow a search result to affect whether it issues a token or what authority that token conveys. Where [ISSUANCE] is in use, this means a search result never affects the gate or scope decisions.¶

An AS MAY nonetheless issue the searches concurrently with whatever it does to decide, discarding their results if it decides not to issue.¶

The two statements are compatible, and it is worth being precise about why, because they look like a contradiction. The ordering is semantic: search results are inputs to claim construction and to nothing else, so no ordering of the calls in time can make one an input to the decision. The concurrency is a performance affordance: the calls are independent, and running them in sequence would add their latencies together on the token endpoint's critical path.¶

Two consequences follow for a deployment that takes the affordance. It performs work it may discard, so the cost of a denied request rises by the cost of the searches. And its PDP receives searches for subjects who never receive a token, so search volume at the PDP is not a measure of tokens issued, and neither logs nor rate limits should be read as though it were.¶

8. Rendering the Claim

A Search API response, per Section 8.3 of [AUTHZEN], carries a results array of entities of the type searched for, each an object with a type and an id. A claim value is a JSON array. This section defines the mapping between them.¶

8.1. From Results to Claim Members

The value of a bound claim MUST be a JSON array of strings, each member being the id of one result object, and every result contributing exactly one member.¶

[RFC9068] recommends encoding these claims according to the guidance of [RFC7643], whose corresponding attributes are multi-valued and complex: each value is an object with a value sub-attribute carrying the identifier, and, depending on the attribute, $ref, display, type, and primary sub-attributes carrying a reference, a human-readable label, and classification.¶

An AuthZEN search result supplies exactly one of those: the identifier, in id. The type field of a result is invariant across the response by construction, since the search named it and Section 8.3 of [AUTHZEN] requires results to be of that type alone, so it carries no per-member information. The remaining sub-attributes have no source in a search result and could only be fabricated or fetched from a system this profile does not define. A conforming complex rendering would therefore be an array of single-member objects, conveying what an array of strings conveys, in a claim that is carried on every request the token is presented with.¶

This document accordingly renders the array of identifiers directly. The recommendation in [RFC9068] is a SHOULD, and this document deviates from it: the profile emits the value sub-attribute of each SCIM value and omits an enclosing object that would have nothing else in it. An AS that must produce the complex form for a resource server that requires it is not prevented from doing so, but it is then rendering something this profile does not define, and a resource server cannot infer which form to expect from the presence of this profile.¶

8.2. Type Mismatch

An AS MUST reject a result whose type does not equal the resource.type it searched for, and MUST treat the response as a failed search under Section 10 rather than filtering the offending results and proceeding.¶

8.3. Duplicates and Order

A result set is a set. An AS MUST remove duplicates, comparing id values as JSON strings for exact equality, before rendering the claim. Duplicates are expected rather than exceptional: [AUTHZEN] recommends that searches be performed transitively, so a subject holding the same group through two paths may be returned twice, and pagination admits repetition on its own account (Section 9).¶

A JSON array is ordered and a set is not, so the order of the members carries no meaning. A resource server MUST NOT attribute any to it.¶

An AS SHOULD nonetheless render members in an order that is stable across issuances, so that two tokens issued for the same subject against unchanged policy data differ only where the underlying facts differ. Sorting ascending by Unicode code point is one way; preserving the PDP's response order is another where the PDP's order is itself stable.¶

8.4. Empty Result Sets

Where a bound claim's search succeeds and returns no results, the AS MUST include the claim with an empty array as its value. It MUST NOT omit the claim.¶

The choice is observable, so it has to be made deliberately. Under this rule the presence of a bound claim means the enumeration was performed, and its absence means the claim was not populated. Had an empty result set also been rendered as absence, a resource server could not distinguish "this subject holds nothing" from "the enumeration did not happen."¶

10. Failure Handling

A bound claim's search fails if the PDP returns an error status, if the response is malformed or contains a result of the wrong type (Section 8.2), if the page bound is exceeded (Section 9), if the request times out, or if the PDP cannot be reached.¶

Where a bound claim's search fails, the AS MUST NOT render the claim, and MUST NOT substitute a default, a placeholder, or an empty array for it. An empty array asserts that the subject holds nothing (Section 8.4), which a failed search does not establish.¶

Whether the AS then issues a token without the claim, or issues none, is a deployment decision, and this document specifies no default. An AS SHOULD allow the choice to be configured per claim binding and per client, because the correct answer differs by claim and by consumer: the absence of a claim a resource server reads before granting access is a different event from the absence of one used for display or personalization, and only the deployment knows which it has.¶

Implementer's note. Issuing the token without the claim is the common behavior in authorization servers that support enrichment today, and it is a defensible default: an enrichment dependency that is briefly unreachable should not take down every token issuance that names the claim. The case that argues the other way is a resource server that reads the claim as an input to an access decision and treats its absence as a value rather than as an absence. An AS cannot detect that from the request, so the choice belongs with the operator, stated rather than assumed, and the two behaviors should be nameable in configuration rather than implied by the product's default.¶

An AS MAY serve a bound claim from a cache of an earlier successful search. A cache hit is not a failure. Cached results are subject to the staleness discussed in Section 14.2, and a deployment that caches SHOULD bound the cache lifetime by the lifetime of the tokens the results are rendered into.¶

11. Discovery

This document registers no capability URN.¶

[ISSUANCE] draws the line at response vocabulary: an extension that adds keys an AS must understand and enforce registers a URN, and one that does not relies on the mechanisms already in place. This document adds no response vocabulary at all, and, as Section 1.1 notes, requires nothing of a PDP that [AUTHZEN] does not already require. What an AS needs to discover is therefore already discoverable:¶

whether the PDP supports Resource Search at all is answered by the presence of search_resource_endpoint in its metadata, which Section 9.1.1 of [AUTHZEN] defines for exactly this purpose;¶
what the bindings mean is answered by the registry of Section 15.2, which is what makes an unconfigured pairing interoperate.¶

What remains is a question about the content of a deployment's policy: does this PDP actually recognize member as an action on resources of type group, or will a correctly formed search return nothing forever? As [ISSUANCE] argues for the analogous question about gate actions, that belongs on the authenticated evaluation surface rather than in an unauthenticated metadata document, and the Action Search API of [AUTHZEN] answers it: a search for the actions a representative subject may perform on a representative resource of type group returns member where the binding is live. This is a deployment-time check, and nothing in this document requires it.¶

Table 3
Condition	Authorization server behavior
Gate evaluation denied ([ISSUANCE])	Fail per [ISSUANCE]; discard results
Result of the wrong type	Treat as a failed search
Page bound exceeded	Treat as a failed search
Search endpoint not published	Treat as a failed search
Search failed	Do not render the claim; issue or fail per configuration

13. Example

An authorization code request for two scopes, at a deployment that binds all three registered claims. Only the JSON payloads are shown; as [ISSUANCE] notes, the transport is a property of the deployment.¶

The token request:¶

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

grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient.example%2Fcb
&scope=files.read+files.write

The AS forms the evaluation of [ISSUANCE] and the three searches, and MAY send them concurrently. The evaluation:¶

{
  "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" } }
  ],
  "options": { "evaluations_semantic": "execute_all" }
}

The groups search, sent to the PDP's search_resource_endpoint:¶

{
  "subject":  { "type": "user", "id": "U0405936" },
  "action":   { "name": "member" },
  "resource": { "type": "group" },
  "context": {
    "client_id": "chatterbox",
    "acr": "urn:example:loa:2",
    "audience": ["https://api.example/files"]
  }
}

{
  "results": [
    { "type": "group", "id": "engineering" },
    { "type": "group", "id": "release-managers" }
  ]
}

The roles search differs only in its action and resource type:¶

{
  "subject":  { "type": "user", "id": "U0405936" },
  "action":   { "name": "assignee" },
  "resource": { "type": "role" },
  "context": {
    "client_id": "chatterbox",
    "acr": "urn:example:loa:2",
    "audience": ["https://api.example/files"]
  }
}

{
  "results": [
    { "type": "role", "id": "deployer" }
  ]
}

The entitlements search is formed the same way, with action holder and resource type entitlement, and returns no results:¶

{
  "results": []
}

The evaluation permits the gate and both scopes:¶

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

The AS mints the access token. Its payload:¶

{
  "iss": "https://as.example",
  "sub": "U0405936",
  "aud": "https://api.example/files",
  "client_id": "chatterbox",
  "iat": 1791000000,
  "exp": 1791003600,
  "scope": "files.read files.write",
  "groups": ["engineering", "release-managers"],
  "roles": ["deployer"],
  "entitlements": []
}

entitlements is present and empty because its search succeeded and returned nothing (Section 8.4). Had it instead failed, the claim would be absent rather than empty, and whether a token was issued at all would depend on how the deployment has configured that binding (Section 10).¶

Had the gate been denied, the searches would have been performed and their results discarded, and no token would have been issued (Section 7).¶

14. Security Considerations

Where [ISSUANCE] is also in use, its considerations apply in full.¶

14.1. Enrichment Is Not Authorization

The rule of Section 7 is the security property this document rests on. Section 8.1 of [AUTHZEN] is careful to say that a search result SHOULD, not MUST, correspond to a permit, because a search and an evaluation may be computed differently and may consider different variables. An AS that treated a non-empty result set as a reason to issue would be relying on a guarantee [AUTHZEN] declines to make, and would have replaced a decision with an enumeration.¶

The concurrency permitted by Section 7 makes this easier to get wrong in an implementation than in a specification. Search results become available before the decision does, and an implementation that assembles a token as results arrive can find itself with a nearly complete token and no decision. The results are inputs to claim construction alone.¶

14.2. No Consistency Across Calls

The decision and the searches are separate requests against data that may change between them, so a token can carry a decision made against one state and claims computed against another. An AS keeps the window narrow by issuing the calls concurrently (Section 7) and by bounding any cache lifetime to the lifetime of the tokens the results are rendered into.¶

14.3. Token Size

A claim with thousands of members produces a token that may exceed the header size limits of intermediaries on the path to the resource server, at which point the failure moves from the AS to the network and becomes much harder to diagnose. A deployment discovering that an enumeration is too large to carry has learned that the claim is the wrong mechanism for that data, not that it needs a larger token. The alternative is available and is the ordinary AuthZEN deployment: the resource server consults the PDP directly at request time, with the resource in hand, and asks a question whose answer is one decision rather than an enumeration. Issuance-time claims and request-time evaluation are complementary surfaces, and a claim that will not fit in a token is a signal about which surface the deployment needs.¶

14.4. Privacy

An authorization claim discloses to every party that receives the token the complete enumeration of what the subject holds of that kind, including memberships that have nothing to do with the audience the token is aimed at. A group name can itself be sensitive, and a resource server needs only the groups relevant to its own decisions.¶

Section 6.3 allows an AS to convey the issuance target so that a PDP may scope the result set, but that input is advisory and a PDP may ignore it. A deployment for which target scoping is a privacy requirement rather than an optimization SHOULD bind claims whose resource type distinguishes the target, so that the scoping is expressed where the PDP must honor it, and SHOULD consider whether the claim belongs in the token at all.¶

The searches themselves also disclose to the PDP that a token is being minted for a subject, on every issuance and, where the affordance of Section 7 is taken, on issuances that never complete. [ISSUANCE] discusses the disclosure of authentication and access patterns to a PDP operated by another party; binding claims multiplies the number of requests that disclosure travels in, without adding a new category of disclosed information.¶

15. IANA Considerations

15.1. Issuance Authorization Entity Types

IANA is requested to register the following in the "OAuth Token Issuance Authorization Entity Types" registry established by [ISSUANCE], whose registration policy is Specification Required [RFC8126]:¶

Table 4
Type	Applies to	Description
`group`	resource	A group whose members are subjects
`role`	resource	A role assignable to subjects
`entitlement`	resource	An entitlement held by subjects

15.2. Authorization Claim Bindings Registry

IANA is requested to establish the "OAuth Authorization Claim Bindings" registry, with a registration policy of Specification Required [RFC8126], recording for each authorization claim the AuthZEN Resource Search that enumerates its members.¶

The registry has the following fields:¶

Table 5
Field	Description
Claim Name	The JWT claim name being bound
Resource Type	The `resource.type` of the search
Action Name	The `action.name` of the search
Change Controller	As in [RFC8126]
Specification Document(s)	Where the binding is defined

Registrations MUST use a Claim Name already registered in the "JSON Web Token Claims" registry established by [RFC7519], MUST use an Action Name matching [a-z][a-z0-9_]{0,30}, and MUST use a Resource Type registered in the registry of Section 15.1. The grammar is the one [ISSUANCE] imposes on the names it expects to be usable as relation identifiers, and Section 15.2.1 gives the reason it applies here too.¶

Initial entries:¶

Table 6
Claim Name	Resource Type	Action Name
`groups`	`group`	`member`
`roles`	`role`	`assignee`
`entitlements`	`entitlement`	`holder`

The Change Controller for all three is the IETF and the Specification Document is this document, alongside Section 4.1.2 of [RFC7643] and Section 2.2.3.1 of [RFC9068], which define the claims themselves.¶

[AUTHZEN]: OpenID Foundation AuthZEN Working Group, "Authorization API 1.0", 11 January 2026, <https://openid.net/specs/authorization-api-1_0-final.html>.
[ISSUANCE]: Gazitt, O., "AuthZEN Profile for OAuth 2.0 Token Issuance", Work in Progress, Internet-Draft, draft-gazitt-oauth-authzen-issuance-00, 4 August 2026, <https://datatracker.ietf.org/doc/html/draft-gazitt-oauth-authzen-issuance-00>.
[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>.
[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>.
[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>.
[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>.

16.2. Informative References

[I-D.gazitt-oauth-authzen-token-exchange]: Gazitt, O., "AuthZEN Binding for OAuth 2.0 Token Exchange", Work in Progress, Internet-Draft, draft-gazitt-oauth-authzen-token-exchange-00, 4 August 2026, <https://datatracker.ietf.org/doc/html/draft-gazitt-oauth-authzen-token-exchange-00>.
[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>.
[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>.
[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>.