AuthZEN Binding for OAuth 2.0 Token Exchange

1.1. What This Document Adds

The framework maps a generic issuance request onto AuthZEN's mandatory five-tuple. Token exchange adds one structural element the framework does not have: a second party. Every other issuance flow decides what a subject may obtain. A token exchange decides what a requesting party may obtain as, or on behalf of, a subject.¶

That second party is not decoration. [RFC8693] introduces may_act precisely because the authority to become another party's actor is a distinct privilege, and Section 4.4 identifies the party whose authority is in question as "the client (or party identified in the actor_token)". This document's central normative content is that this second privilege is evaluated as its own tuple, so that any conforming PDP - including a relationship-based engine in the style of [ZANZIBAR], which reads it directly as an edge between two named entities - can adjudicate it (Section 4.3.2).¶

The remainder is the derivation of the framework's inputs from each specification's parameters, and the small number of invariants that each specification places beyond a PDP's reach.¶

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

The exchange subject is derived from subject_token, interpreted according to subject_token_type:¶

subject.type MUST be user where the exchange subject is a natural person and workload where it is a non-human software identity, per the registry established by [ISSUANCE].¶

subject.id MUST be the identifier the AS intends to place in the issued token's subject claim, as [ISSUANCE] requires. In token exchange this ordering constraint has teeth, because the subject identifier frequently changes during the exchange: an AS receiving a token from a peer trust domain resolves the foreign subject to a local account, and an AS issuing pairwise identifiers computes one per audience. Any such resolution MUST be performed before the evaluation request is constructed.¶

An AS that evaluated against the incoming identifier and then issued a token bearing a resolved one would obtain a decision about a subject that does not appear in the token it mints.¶

4.2. Requesting Party

The requesting party is:¶

1. the party identified by actor_token, interpreted according to actor_token_type, where an actor_token is present; otherwise¶

2. the authenticated client.¶

subject.type for the requesting party MUST be client where it is an OAuth client identified by a client identifier, and workload where it is a software identity presenting a credential such as an X.509 certificate ([RFC8705]) or a workload identity document.¶

The requesting party is derived in both delegation and impersonation. It is in the impersonation case - where the issued token carries no act claim and the requesting party is therefore invisible in the result - that evaluating its authority matters most, because nothing downstream can recover it.¶

4.3. Actions

A token exchange request produces gate tuples and scope tuples as defined in [ISSUANCE], which requires a gate tuple on every request. This binding produces two, because a token exchange has two parties whose authority is in question.¶

Both carry the same action.name, of the form issue:<token-type>:token_exchange, where the token type short name is the one registered for the value of requested_token_type (Section 11.1). The grant segment is token_exchange throughout, since that is the grant this binding applies to; it is what distinguishes these tuples from those a direct request by the same party for the same target would produce.¶

Where requested_token_type is absent, [RFC8693] directs the AS to its default, and the short name for that default type is used.¶

4.4. Resource

resource.type MUST be audience and resource.id MUST be the issuance target, as in [ISSUANCE]. Where the request carries an audience parameter, or a resource parameter in the sense of [RFC8707], that value determines the issuance target.¶

Where the request names more than one target, the AS MUST fan the tuples out across targets: each gate tuple and each scope tuple is evaluated once per named target.¶

4.5. Context

In addition to the keys defined by [ISSUANCE], an AS implementing this binding SHOULD convey the following in the request context. All are advisory: a PDP MUST be able to render a decision from the five-tuple alone.¶

Each key has one JSON type, as [ISSUANCE] requires of context keys defined by a binding.¶

requested_token_type is not among them. It determines the token type segment of the gate action name, so it is already in the five-tuple, and repeating it in context would give a PDP two places to read the same fact and a way for them to disagree. subject_token_type and actor_token_type describe the credentials presented, not the token requested, and remain advisory.¶

An AS MUST NOT place raw token strings in context. Only claims the AS has already validated are conveyed, and only those a deployment's policies consume. The subject token may carry claims about a party that has not authorized their disclosure to the PDP.¶

4.6. Batch Composition

Except where a request names no scopes and the two gate tuples coincide (Section 4.3.2), the AS uses the Access Evaluations API of [AUTHZEN] as [ISSUANCE] specifies, with options.evaluations_semantic set to execute_all.¶

[ISSUANCE] requires gate tuples to occupy the leading indices of the evaluations array. Here that ordinarily means indices 0 and 1, in the order given in Section 4.3: the subject gate first, then the requesting party gate. Scope tuples follow. The AS MUST fail the request without issuing a token if either gate is denied.¶

Narrowing is the ordinary outcome of a scope denial, and matches [I-D.ietf-oauth-identity-assertion-authz-grant], which states that granted scopes may be a subset of those requested. Where a deployment instead intends the requested privileges to be granted whole, it does not vary the evaluations semantic to obtain that: it fails the request when any scope tuple is denied.¶

A short-circuiting semantic is not used, because it may return a truncated evaluations array while the aggregation rules of [ISSUANCE] are defined over the complete set of per-item results. Composing those results is the AS's work here in any case: [AUTHZEN] selects the semantic per request rather than per item, so the fatality of a gate denial is enforced by the AS and not by the PDP. Retaining every per-item result also preserves the record of which privilege was refused, which is what an operator needs when a request fails.¶

5.1. Access Tokens and Refresh Tokens

No additional derivation is required. The mapping of [ISSUANCE] and the preceding sections is complete for an exchange whose requested_token_type is urn:ietf:params:oauth:token-type:access_token or urn:ietf:params:oauth:token-type:refresh_token.¶

5.2. Identity Chaining

[I-D.ietf-oauth-identity-chaining] composes two token endpoint requests: an exchange at the authorization server of trust domain A yielding an authorization grant for trust domain B, and the redemption of that grant at B's authorization server.¶

Each leg is an independent issuance decision and is evaluated independently, against the PDP of the trust domain whose authorization server is performing it. Neither AS relies on the other's evaluation. This follows from the specification's own model, in which each domain remains authoritative for its own policy, and it is what the profile is for: the first leg decides whether authority may leave domain A, the second decides what authority it acquires in domain B.¶

The first leg is a two-level evaluation under Section 4.4.1 where the request names [RFC8707] resources. The second leg is an ordinary single-level evaluation whose exchange subject is the local account the foreign subject resolved to, per Section 4.1.¶

[I-D.ietf-oauth-identity-chaining] notes that a request may be denied due to policy, for instance where a trust relationship is not established. Under this binding, the existence of the trust relationship remains a precondition the AS validates; the PDP decides what is permitted across a relationship that already exists.¶

5.3. Identity Assertion Authorization Grant

An ID-JAG is issued by an identity provider's authorization server and redeemed at an application's authorization server.¶

Issuance. The requested_token_type is urn:ietf:params:oauth:token-type:id-jag, so the gate tuples carry action.name of issue:id_jag:token_exchange. The issued grant's audience is the resource authorization server, while [I-D.ietf-oauth-identity-assertion-authz-grant] makes the [RFC8707] resource subset a policy decision in its own right. The AS MUST therefore perform a two-level evaluation under Section 4.4.1.¶

scope is OPTIONAL in an ID-JAG request. Where it is absent, the request produces gate tuples and no scope tuples, and a PDP that wishes to grant a specific set returns granted_scope in the response context, as [ISSUANCE] defines. This is the case the framework's gate tuple exists for: without it, a scopeless ID-JAG request would produce no evaluation at all.¶

The specification permits the authorization server to modify, filter, or omit the requested authorization details. Under this binding those operations have distinct sources: filtering follows from denied scope tuples, omission from an entry all of whose tuples are denied, and modification from the authorization_details shaping key of [ISSUANCE], subject to that key's structural narrowing checks.¶

Redemption. The application's authorization server presents the ID-JAG as an assertion grant. This is an ordinary single-level evaluation. Its exchange subject is the local account produced by the subject resolution that [I-D.ietf-oauth-identity-assertion-authz-grant] requires, and its requesting party is the client authenticated at that endpoint - which is a different party from the client that obtained the grant. Evaluating it is the point: redemption is where an application's own authorization server decides what the asserted identity may do locally.¶

Where a deployment is multi-tenant, the AS SHOULD convey the tenant identifier in context. A deployment whose decisions genuinely depend on tenancy SHOULD instead encode the tenant in resource.id, so that the dependency is visible in the five-tuple.¶

5.4. Transaction Tokens

[I-D.ietf-oauth-transaction-tokens] defines a Transaction Token Service (TTS) that mints short-lived tokens carrying a call chain's originating context. Its issuance decision is the one this profile addresses, and the specification states directly that the authorization policy determining issuance is out of scope for it.¶

Txn-Tokens differ from the rest of the family in four ways that the binding must account for.¶

There is no actor_token. The requesting party is the workload that authenticated to the TTS, typically with a credential under [RFC8705] or a workload identity document. It is derived under rule 2 of Section 4.2 with subject.type of workload.¶

The requesting workload's authority is scope-dependent. The specification requires the TTS to determine whether the requesting workload is authorized to obtain a Txn-Token with the requested values, not merely whether it may obtain one. For requested_token_type of urn:ietf:params:oauth:token-type:txn_token, the AS MUST therefore include scope tuples for the requesting party in addition to those for the exchange subject. Both sets MUST be permitted for the corresponding scope to be granted. This is the one place in this document where the requesting party is evaluated for access authority rather than only for issuance authority, and it is required because the governing specification asks for it.¶

Subject derivation is ambiguous for self-signed and unsigned subject tokens. Where subject_token_type is urn:ietf:params:oauth:token-type:self_signed or urn:ietf:params:oauth:token-type:unsigned_json, the presented token is not an authority on identity. The AS MUST determine whether the request is on behalf of a user, in which case the exchange subject is that user and the AS MUST have an independent basis for believing the assertion, or on the workload's own behalf, in which case the exchange subject is the requesting workload itself and the two gate tuples coincide. An AS MUST NOT accept a user identity from an unsigned subject token without such a basis. The PDP cannot detect this error, because it sees only the identifier it is given.¶

Transaction context may originate at the PDP. The specification makes the TTS authoritative for the transaction context of the token it mints, and permits that context to be derived from the request details. A PDP is a legitimate source for that derivation. Where a deployment uses one, the transaction context is carried as a member of the claims shaping key of [ISSUANCE], and the TTS remains authoritative: it MUST validate the returned value before minting, and its own determination prevails.¶

A PDP that asserts a quantitative ceiling in transaction context is asserting a constraint that a downstream enforcement point is expected to apply, and dropping it would broaden what the token effectively authorizes. A PDP asserting such a value MUST name the claim in crit, per [ISSUANCE].¶

Requests for replacement Txn-Tokens are a second issuance moment with the same tuple shape and require no additional machinery. The invariants that [I-D.ietf-oauth-transaction-tokens] places on a replacement - that it MUST NOT expand scope, and MUST NOT modify the transaction identifier, subject, or audience - are preconditions the TTS enforces. A PDP cannot waive them. A permit authorizes a replacement within those bounds; it does not authorize one outside them.¶

9.1. Delegation With an Actor Token

A gateway workload exchanges a user's access token for a token aimed at a partner API, acting on the user's behalf. Two gate tuples and one scope tuple result.¶

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

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token=eyJ...
&subject_token_type=urn:ietf:params:oauth:token-type:access_token
&actor_token=eyJ...
&actor_token_type=urn:ietf:params:oauth:token-type:jwt
&requested_token_type=urn:ietf:params:oauth:token-type:access_token
&audience=https%3A%2F%2Fapi.partner.example
&scope=read%3Adocs

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

{
  "resource": {
    "type": "audience",
    "id": "https://api.partner.example"
  },
  "context": {
    "client_id": "gateway-client",
    "may_act": { "sub": "spiffe://cluster/ns/prod/sa/gateway" },
    "issuance": {
      "capabilities": [
        "urn:ietf:params:authzen:token-issuance"
      ]
    }
  },
  "evaluations": [
    {
      "subject": { "type": "user", "id": "alice@example.com" },
      "action":  {
        "name": "issue:access_token:token_exchange"
      }
    },
    {
      "subject": {
        "type": "workload",
        "id": "spiffe://cluster/ns/prod/sa/gateway"
      },
      "action":  {
        "name": "issue:access_token:token_exchange"
      }
    },
    {
      "subject": { "type": "user", "id": "alice@example.com" },
      "action":  { "name": "read:docs" }
    }
  ],
  "options": { "evaluations_semantic": "execute_all" }
}

A relationship-based PDP reads the second tuple as an edge between workload:spiffe://cluster/ns/prod/sa/gateway and audience:https://api.partner.example under the relation issue_access_token_token_exchange. No property bag is consulted, and the relation is distinct from the one that would govern the gateway obtaining a token for itself under the client credentials grant.¶

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

{
  "evaluations": [
    { "decision": true },
    { "decision": true },
    {
      "decision": true,
      "context": {
        "issuance": {
          "token_lifetime": 300,
          "claims": { "groups": ["eng", "sre"] }
        }
      }
    }
  ]
}

The AS issues an access token for https://api.partner.example bearing scope of read:docs, an act claim naming the gateway, a groups claim, and a lifetime no greater than 300 seconds.¶

9.2. Scopeless ID-JAG, Two Levels

An ID-JAG request naming a resource but no scopes. Two gate tuples at level 1, no scope tuples anywhere, and the PDP supplies the grantable set.¶

{
  "context": {
    "client_id": "chatterbox-idp-7f3a",
    "issuance": {
      "capabilities": [
        "urn:ietf:params:authzen:token-issuance"
      ]
    }
  },
  "evaluations": [
    {
      "subject":  { "type": "user", "id": "U0405936" },
      "action":   { "name": "issue:id_jag:token_exchange" },
      "resource": {
        "type": "audience",
        "id": "https://as.app.example"
      }
    },
    {
      "subject":  { "type": "client", "id": "chatterbox-idp-7f3a" },
      "action":   { "name": "issue:id_jag:token_exchange" },
      "resource": {
        "type": "audience",
        "id": "https://as.app.example"
      }
    }
  ],
  "options": { "evaluations_semantic": "execute_all" }
}

{
  "evaluations": [
    {
      "decision": true,
      "context": {
        "issuance": {
          "granted_scope": "files.read",
          "token_lifetime": 300
        }
      }
    },
    { "decision": true }
  ]
}

The AS mints an ID-JAG naming files.read and the requested resource. Had the PDP returned a bare permit, the AS would have fallen back to its own default scope set for that client and target, which is a safe degradation: a PDP unable to enumerate a grantable set is not thereby able to broaden one.¶

10.1. Impersonation Is the Dangerous Case

An impersonation exchange produces a token indistinguishable from one issued to the subject directly. Nothing downstream can determine that a different party obtained it, which means no downstream enforcement point can apply policy to the requesting party's involvement. The requesting party gate tuple of Section 4.3.2 is the only point at which that party's authority is evaluated at all.¶

An implementation that omitted it - reasoning that the client was already authenticated, or that may_act was present in the subject token - would externalize the delegation decision in name only. Client authentication establishes who is asking; it does not establish that they may ask for this.¶

10.2. Chain Depth and Repeated Exchange

A token obtained by exchange may itself be exchanged. Each exchange is an independent decision under this binding, so authority cannot be broadened by iteration: every step is gated, and the scope tuples at each step are bounded by what the AS would otherwise grant.¶

What repetition can accumulate is lifetime. A chain of exchanges, each issuing a token whose lifetime is permitted at that moment, can keep authority alive well past the point at which the original grant would have expired. Deployments SHOULD convey the existing act chain in context so that policy can act on chain depth, and SHOULD bound the lifetime of an exchanged token by the remaining lifetime of the subject token. The second is an AS responsibility: a token_lifetime shaping value is a ceiling and never a floor, so a PDP cannot repair an AS that fails to apply it.¶

10.3. Trust in the Subject Token Issuer

In cross-domain flows the subject token is issued by a party in another trust domain, and the claims conveyed to the PDP as context originate there. A PDP whose policy depends on those claims has extended trust to that issuer. This is a further reason for the five-tuple rule: a decision that depends only on the resolved local subject identifier, the requesting party, the action, and the target depends on values the local AS established itself.¶

10.4. Denial Information Disclosure

Both the error mapping above and [ISSUANCE]'s prohibition on relaying PDP reason strings exist to keep the requesting party from learning the shape of a policy that governs a subject it is merely acting for. Deployments adding diagnostics to token endpoint error responses should preserve this.¶

11.1. Issuance Authorization Action Names

IANA is requested to register the following token type short names in the "OAuth Token Issuance Authorization Action Names" registry established by [ISSUANCE], whose registration policy is Specification Required [RFC8126]:¶

The short names for access_token, refresh_token, and id_token, and the token_exchange grant type short name that pairs with all of the above, are registered by [ISSUANCE].¶

id_jag uses an underscore where the token type URI uses a hyphen, as [ISSUANCE] requires of every registered short name.¶

• Editor's note. These registrations depend on the corresponding token types being registered in the "OAuth URI" registry by their own specifications. id-jag and txn_token are requested by documents still in progress, and the short names above should be confirmed against the values those documents ultimately register.¶

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

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

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

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

12.2. Informative References

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

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

[RFC8705]

Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, February 2020, <https://www.rfc-editor.org/rfc/rfc8705>.

[RFC9449]

Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, <https://www.rfc-editor.org/rfc/rfc9449>.

[ZANZIBAR]

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