AuthZEN Access Request OAuth Profile - Draft 1

7.1. Resolution outcomes

A client engages exactly one binding, selected by the entry point and opt-in it used; the evaluating party never converts a request made under one binding into another. The evaluating party resolves an asynchronous authorization request as follows:¶

• Allow. The transport's normal success response is returned synchronously (a token, for the request mechanisms that issue one directly).¶

• Deny, not requestable. A synchronous error is returned in the transport's error form: at the token endpoint, invalid_authorization_details ([RFC9396]) when the denial concerns the requested authorization_details, invalid_scope when it concerns requested scope, and otherwise invalid_grant. The pending and terminal-denial codes (authorization_pending, interaction_required, interaction_pending, access_denied, expired_token, slow_down) are reserved for the deferred path and MUST NOT be returned here. The transaction authorization grant is the one place one of them is returned synchronously; see the no-opt-in case below.¶

• Deny, requestable. The evaluating party MUST NOT issue a token. It submits an [ARAP] access request to its internal Access Request Service on the client's behalf (an internal approval submission, not an outbound OAuth request to any authorization server), binds the resulting task to this transport's continuation handle, and returns this transport's pending response (carrying the handle, expires_in, and interval).¶

• Deny, requestable, but the client did not opt into asynchronous completion. A binding that guards its deferred response behind a client signal (DTR's completion_mode=deferred) MUST NOT return that deferred response when the client did not send it, because the client may be unable to handle it. Opting in is a requirement of the deferral transport, not a precondition for approval; the internal access request and re-evaluation need no client opt-in. Rather than silently deny, the evaluating party MAY surface the requestable denial to the client as remediation so the client can proceed as it sees fit: retry while opting into a deferral transport (DTR or CIBA), reuse an existing token that already satisfies the requirement, or pursue interactive end-user approval where deferral is not needed. A requestable denial therefore does not by itself imply deferral. On the transaction authorization grant the answer is already fixed: [I-D.rosomakho-oauth-txn-challenge] has the AS return access_denied when the client did not signal deferred and approval cannot be obtained synchronously, and the client repeats the request with it. Where the requestable denial originates at a protected resource, the remediation reaches the client as a challenge (a signed Transaction Authorization Challenge, which the resource returns only to an agent that signalled Accept-Txn-Challenge, or an authorization_remediation response [I-D.ietf-oauth-rar-metadata-remediation]). A deployment MAY withhold the requestable nature where revealing that the operation is obtainable through approval is itself sensitive.¶

7.2. Idempotent submission

An asynchronous authorization request is not inherently idempotent, so a client that retries an initial request (for example after a lost response or a restart) could otherwise cause the issuer to open a second access request and issue a second continuation handle for one intent. To prevent duplicate approvals, the issuer SHOULD treat a repeated requestable-denial request from the same client for the same requested authorization (the same authorization_details and scope) as the same request and return the existing handle rather than open a new access request. This deduplication is best-effort; a client that requires exactness SHOULD send a stable request identifier where its transport provides one. The transaction challenge binding needs no best-effort rule: [I-D.rosomakho-oauth-txn-challenge] identifies a resubmitted challenge by its iss and jti and has the AS continue the original transaction authorization request rather than open a second one.¶

7.3. Continuation handle

The continuation handle is the redemption handle and binds the pending access request in the issuer's state. It is not authority: possessing a handle does not authorize anything, and a token is issued only after the issuance-time re-evaluation below. The handle is sender-constrained (see Section 12) and is redeemed at most once: once a token is issued for it, a subsequent redemption MUST fail with invalid_grant.¶

7.4. Polling and completion

The client redeems the continuation handle at the binding's completion endpoint, no faster than interval, and backs off on a slow_down response. Under DTR, authorization_pending, interaction_required, and interaction_pending are all non-terminal and the client keeps polling through them. Where a binding offers a notification channel (the DTR client callback, CIBA ping), the client MAY rely on it in addition to polling; polling remains the authoritative completion path. A binding MAY also deliver the token directly rather than by redemption (CIBA push), in which case there is no polling to be authoritative over. On resolution the evaluating party re-evaluates the original request with the approval as an input (the [ARAP] approval object, carried at context.approval in the internal evaluation) and:¶

• Approved. The issuer issues the access token. The granted authorization (authorization_details, and scope if used) carries the approved access, which MUST NOT broaden the originating request, and the access token lifetime MUST NOT exceed the recorded approval expiry.¶

  The approval bounds the credential, not a single token: no access token, refresh token, or token obtained by exchange ([RFC8693]) may outlive the recorded approval expiry (approved_until) or broaden the approved access, and a refresh or exchange after that expiry MUST fail with invalid_grant and requires a new access request.¶

  Within that bound, whether a refresh token applies depends on the completion mode and on what was approved. Under token-issuance completion, standing, time-bounded access (for example read access to a path, or a policy-granted set of privileges expressed as RAR) is served by a refresh token bounded by approved_until and re-evaluated at each refresh, which keeps the PDP in the loop within the approval window; a single-use approval (for example a single payment, or the single-use Transaction Authorization Challenge) SHOULD NOT yield a refresh token, and [I-D.rosomakho-oauth-txn-challenge] rules one out altogether where the challenge carries a cnf claim, since a refreshed token would be bound to a key the client proves instead. Where standing access should instead be re-evaluated on every call, that is re-evaluation completion ([ARAP]'s reevaluate), which needs no long-lived credential and is out of scope for this profile.¶

• Terminal denial, cancellation, or expiry. The issuer returns access_denied (or expired_token once the handle lifetime has elapsed).¶

The issued access token is the decision representation. This is the token issuance completion mode that [ARAP] defers to a downstream profile. Because completion is the issued token, this mode is not surfaced to the client as an [ARAP] result.mode value; the OAuth token response is the result.¶

7.5. Access request input

Inputs the access request needs are supplied either in the initial request (for example as authorization_details fields, or CIBA's binding_message) or out of band at the Access Request Service. Where DTR carries the wait, the AS has somewhere to send the client: an interaction_uri, returned with interaction_required or alongside a pending response, is the natural carrier for an [ARAP] form_url or request_schema_url, and deferred_interactive is how a client says it can act on one. The URI is opaque to the client, and visiting it does not by itself complete the request. CIBA has no equivalent channel, and this profile defines no in-band input mechanism of its own.¶

8.1. Where the requestable denial originates

[ARAP] allows the PEP and PDP roles to be deployed in more than one place, and this profile supports three placements:¶

• AS as PEP (DTR, CIBA). The AS evaluates the request against its PDP, derives the requestable denial itself, and defers.¶

• Resource as PEP (transaction challenge). A protected resource detects that the presented token cannot authorize the operation, asserts the requestable denial as a signed transaction_challenge, and the AS treats the validated challenge as the requestable-denial signal rather than re-deriving the decision from scratch.¶

• Both. The resource asserts the challenge and the AS additionally evaluates against its own PDP before issuing, so the decision is the conjunction of resource policy and AS policy.¶

In every placement the access request, approval, and issuance-time re-evaluation are the same; only the origin of the requestable denial differs.¶

8.2. Constructing the Access Evaluation

The evaluating party builds the Access Evaluation request from the OAuth request (or the challenge):¶

The structural mapping above is fixed. The semantic interpretation of a given authorization_details type (and of named scopes) into AuthZEN resource and action values is deployment- or vocabulary-defined, and interoperating parties MUST agree on it. The agent acting for the principal is conveyed in subject.properties.act and context.client_id.¶

A fine-grained read request (read access to one customer record) maps to an evaluation whose subject carries the user and the acting agent, with the record as resource and read as action; the worked trace in Section 10.1 shows the full Access Evaluation request and the PDP's response.¶

A request may carry several authorization_details (and scopes), which the evaluating party evaluates together; it MAY use the AuthZEN Evaluations (bulk) API for this. This profile treats the request as a unit: if any requested authorization is requestable-denied and the client opted into asynchronous completion, the whole request is deferred and the full requested set is issued on approval. Partial issuance (issuing the allowed subset immediately and deferring the rest) is not defined by this profile.¶

8.3. Requestable denial

When the PDP denies but the denial is requestable, it returns decision: false with an [ARAP] context.access_request and denial-binding material (context.evaluation_id or a binding_token):¶

{
  "decision": false,
  "context": {
    "evaluation_id": "ev_9f2c8a1b",
    "reason": "approval_required",
    "access_request": { "expires_at": "2026-06-13T12:00:00Z" }
  }
}

The example above carries context.evaluation_id, which the Access Request Service resolves against the PDP's recorded evaluation; this fits a deployment where the Access Request Service shares the PDP's state. Where the Access Request Service is a separate service from the PDP, it cannot trust the submitting party's claim that a denial occurred, so the denial instead carries a PDP-signed binding_token in context.access_request that the service verifies cryptographically; evaluation_id is then optional:¶

{
  "decision": false,
  "context": {
    "reason": "approval_required",
    "access_request": {
      "expires_at": "2026-06-13T12:00:00Z",
      "binding_token": "eyJhbGciOiJFUzI1NiIsImtpZCI6InBkcC0xIn0..."
    }
  }
}

The evaluating party submits the access request using this binding material, binds the resulting [ARAP] task to a continuation handle, and returns the transport's pending response. A decision: false with no context.access_request is a non-requestable denial and maps to the synchronous error in Section 7. In the transaction challenge binding the resource has already asserted the requestable denial as a signed challenge; the AS validates the challenge and submits the access request from it (and MAY additionally evaluate against its own PDP).¶

8.4. Re-evaluation and issuance

On approval, the evaluating party re-evaluates the same request with the [ARAP] approval object at context.approval (the re-evaluation request, the task it resolves, and the resulting decision are shown in Section 10.1). A decision: true response authorizes issuance: the issuer issues the access token whose granted authorization_details reflect the approved resource and action, with a lifetime bounded by approved_until. A decision: false at re-evaluation maps to access_denied on the next poll; obtaining access then requires a new request.¶

9.1. Deferred Token Response

The client makes an ordinary token request and signals deferred completion with completion_mode=deferred ([I-D.ietf-oauth-deferred-token-response]). The requested authorization is expressed with authorization_details ([RFC9396]), with scope, or with both. The AS maps the request to an AuthZEN Access Evaluation and resolves per Section 7. On a requestable denial it binds the access request to a deferral_code and returns the DTR deferred response (authorization_pending with deferral_code, expires_in, and interval).¶

The client polls the token endpoint with the deferred grant type (urn:ietf:params:oauth:grant-type:deferred) and the deferral_code, and completes per Section 7. This binding rides on any originating grant, including Token Exchange [RFC8693], the authorization code grant, and the refresh token grant.¶

9.2. Client-Initiated Backchannel Authentication

CIBA [OIDC-CIBA] is purpose-built for decoupled approval: the device that consumes the token (the agent) is separate from the device on which the user authenticates and approves. This profile uses that decoupling for the agentic case in which the principal approves their own agent's elevation out of band, on their own authentication device, while the agent waits.¶

In CIBA the user identified by login_hint, login_hint_token, or id_token_hint is the user the AS authenticates and whose identity the issued tokens represent; CIBA does not natively let one party approve a token that acts as a different principal. This binding therefore maps the hint to the principal the issued token acts as, and the approving party is that same principal. Deployments that need a different party (a data owner or manager) to approve should use the DTR or transaction challenge binding, where the approver is the [ARAP] workflow's resolver and is unrelated to OAuth authentication. Per [OIDC-CIBA] the request carries the openid scope; the requested authorization is carried in authorization_details (and any additional scope), and a binding_message MAY convey the operation to the user.¶

The AS maps the request to an AuthZEN Access Evaluation and resolves per Section 7. On a requestable denial it binds the access request to the CIBA auth_req_id and returns it with expires_in and (optionally) interval. In the poll and ping delivery modes the client redeems the auth_req_id at the token endpoint with the CIBA grant type (urn:openid:params:grant-type:ciba); in ping the AS first notifies the client's notification endpoint that the result is ready, and in push the AS instead delivers the tokens directly to that endpoint with no token-endpoint redemption. A client using ping or push MUST supply a client_notification_token on the backchannel authentication request ([OIDC-CIBA]). Where the client polls, polling remains the authoritative completion path as in Section 7. In every mode completion is an access token carrying the approved authorization_details, bounded by the approval expiry.¶

9.3. Transaction Authorization Challenge

In this binding the protected resource is the PEP. When the resource determines that the token presented for an operation does not authorize it, it returns HTTP 401 with a WWW-Authenticate challenge carrying a signed transaction_challenge (a JWS whose claims include txn, authorization_details, the resource as iss, the AS as aud, iat, exp, jti, and a human-readable reason, and optionally act for the requester context and cnf for a binding key), per [I-D.rosomakho-oauth-txn-challenge]. The agent signals that it understands challenges with the Accept-Txn-Challenge header, and a resource returns one only to an agent that signalled it or that it knows out of band to support the mechanism. The challenge is the resource's assertion of a requestable denial, signed so neither the agent nor the client can forge or broaden the requested operation.¶

The client itself presents the challenge to the AS named in the challenge's aud, as a token request under the transaction authorization grant (urn:ietf:params:oauth:grant-type:txn-authz-challenge) carrying the challenge in transaction_challenge and opting into deferral with completion_mode=deferred, per [I-D.rosomakho-oauth-txn-challenge]; the originating deployment does not forward anything on the client's behalf, so no server-to-server credential is crossed even when aud names an AS the client has not used before. That AS validates the challenge against the resource's signing keys, treats it as the requestable-denial signal (and MAY additionally evaluate against its own PDP), submits the [ARAP] access request to its own Access Request Service, and resolves per Section 7. On a requestable denial it returns the DTR deferred response and the client polls the token endpoint with the deferred grant, exactly as in Section 9.1. The challenge supplies the requested authorization; DTR carries the wait.¶

On approval the AS issues an access token that carries the challenge's txn and authorization_details and is audience-restricted to the resource. The client returns it to the agent, which re-presents it to the resource; the resource validates that the token's txn matches the challenge, that the audience identifies the resource, and that the granted authorization_details authorize the operation. Because the resource originates and consumes the txn, this binding is the one case where completion is not "client holds token, done": the token is evidence re-presented to the resource that originated the challenge. Resources SHOULD treat these tokens as single-use for non-idempotent or high-impact operations.¶

10.1. DTR: Token Exchange (AS as PEP)

An agent acting on behalf of a user requests fine-grained access to a single protected resource. The authorization_details (shown decoded for readability) scopes the request to one record:¶

[ { "type": "customer_records", "actions": ["read"], "locations": ["https://crm.example/customers/c-4815"] } ]

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

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&completion_mode=deferred
&authorization_details=%5B%7B%22type%22%3A%22customer_records%22%2C%22actions%22%3A%5B%22read%22%5D%2C%22locations%22%3A%5B%22https%3A%2F%2Fcrm.example%2Fcustomers%2Fc-4815%22%5D%7D%5D
&subject_token=...&subject_token_type=...

Internally, and never on the OAuth wire, the AS maps this to an AuthZEN Access Evaluation and calls its PDP:¶

{
  "subject": {
    "type": "user",
    "id": "alice@example.com",
    "properties": { "act": { "sub": "agent-7" } }
  },
  "resource": { "type": "customer_records", "id": "c-4815" },
  "action": { "name": "read" },
  "context": { "client_id": "agent-7", "dpop_jkt": "0ZcOCORZ..." }
}

The PDP returns a denied-but-requestable decision:¶

{
  "decision": false,
  "context": {
    "evaluation_id": "ev_9f2c8a1b",
    "reason": "approval_required",
    "access_request": { "expires_at": "2026-06-13T12:00:00Z" }
  }
}

Here the Access Request Service shares the PDP's state, so the denial binds by evaluation_id; a separate-service Access Request Service would instead receive a PDP-signed binding_token (Section 8). The AS submits the [ARAP] access request on the agent's behalf, echoing the denial-binding material (authentication to the Access Request Service is omitted for brevity):¶

POST /access/v1/requests HTTP/1.1
Host: pdp.example.com
Content-Type: application/json
Idempotency-Key: 7b8d0f0d-65a1-4af1-9fd3-a684f08a5d14

{
  "subject": {
    "type": "user",
    "id": "alice@example.com",
    "properties": { "act": { "sub": "agent-7" } }
  },
  "resource": { "type": "customer_records", "id": "c-4815" },
  "action": { "name": "read" },
  "denial": {
    "evaluation_id": "ev_9f2c8a1b",
    "expires_at": "2026-06-13T12:00:00Z",
    "reason": "approval_required"
  }
}

The Access Request Service accepts it and returns a pending task:¶

HTTP/1.1 202 Accepted
Content-Type: application/json
Location: https://pdp.example.com/access/v1/requests/arq_01HX4Y3AJZ

{
  "task": {
    "id": "arq_01HX4Y3AJZ",
    "status": "pending",
    "status_endpoint": "https://pdp.example.com/access/v1/requests/arq_01HX4Y3AJZ"
  }
}

The AS binds this task to a deferral_code and returns the deferred response to the client:¶

{
  "error": "authorization_pending",
  "deferral_code": "8d67dc78-7faa-4d41-aabd-67707b374255",
  "expires_in": 10800,
  "interval": 60
}

The client polls the token endpoint until the record's data owner resolves the request out of band:¶

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

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adeferred
&deferral_code=8d67dc78-7faa-4d41-aabd-67707b374255

Behind the AS, the data owner approves and the task reaches a terminal state, which the AS reads from the Task Status Endpoint:¶

GET /access/v1/requests/arq_01HX4Y3AJZ HTTP/1.1
Host: pdp.example.com

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

{
  "task": { "id": "arq_01HX4Y3AJZ", "status": "approved" },
  "result": {
    "approval": { "id": "ar_123", "approved_until": "2026-06-13T18:00:00Z" }
  }
}

The task completes with the approval. Under this profile the completion mode is token issuance, not [ARAP]'s reevaluate (see Section 11), so the result is the issued token rather than a client-facing result.mode; the AS re-evaluates the original request itself with the approval at context.approval:¶

{
  "subject": {
    "type": "user",
    "id": "alice@example.com",
    "properties": { "act": { "sub": "agent-7" } }
  },
  "resource": { "type": "customer_records", "id": "c-4815" },
  "action": { "name": "read" },
  "context": { "approval": { "id": "ar_123", "approved_until": "2026-06-13T18:00:00Z" } }
}

The PDP now allows it:¶

{ "decision": true }

The AS issues an access token carrying the approved authorization, with a lifetime bounded by the recorded approved_until:¶

{
  "access_token": "eyJ...",
  "token_type": "DPoP",
  "expires_in": 900,
  "authorization_details": [
    { "type": "customer_records", "actions": ["read"], "locations": ["https://crm.example/customers/c-4815"] }
  ]
}

If the data owner denies the request, the task reaches denied, the AS's re-evaluation returns decision: false, the poll returns access_denied, and no token is issued.¶

The flow above is independent of the originating grant and of which party gates approval. The same DTR exchange applies when the agent redeems an authorization code (the authorization_details bound to the code drive the decision), when it uses a refresh token to reach a resource outside its current scope, and when the gate sits at a resource server that issues its own tokens (contrast Section 9.3, where the resource asserts a signed challenge rather than issuing a token). In an ID-JAG [I-D.ietf-oauth-identity-assertion-authz-grant] chain there are two issuers and approval may be gated at either: the identity provider may defer when it issues the ID-JAG, or the Resource Authorization Server may defer when the agent redeems it. In every case the deferring party returns the same authorization_pending response, and the agent polls and completes as shown.¶

10.2. CIBA: decoupled self-approval (AS as PEP)

An agent acting for Alice needs to export a CRM report, an action that requires Alice's explicit approval. The agent makes a backchannel authentication request naming Alice (the principal the token will act as) with login_hint, and conveying the operation to her with binding_message; CIBA prompts Alice on her own authentication device while the agent waits:¶

POST /backchannel-authn HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
DPoP: eyJ...

scope=openid
&login_hint=alice%40example.com
&binding_message=Export+CRM+contacts
&authorization_details=%5B%7B%22type%22%3A%22crm%22%2C%22actions%22%3A%5B%22export%22%5D%2C%22locations%22%3A%5B%22https%3A%2F%2Fcrm.example%2Fcontacts%22%5D%7D%5D

The AS evaluates the request, gets a denied-but-requestable decision, submits an access request, and returns:¶

{
  "auth_req_id": "1c266114-a1be-4252-8ad1-04986c5b9ac1",
  "expires_in": 300,
  "interval": 5
}

The agent redeems the auth_req_id at the token endpoint once the owner approves out of band:¶

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

grant_type=urn%3Aopenid%3Aparams%3Agrant-type%3Aciba
&auth_req_id=1c266114-a1be-4252-8ad1-04986c5b9ac1

Before approval the token endpoint returns authorization_pending; on approval it returns an access token carrying the approved authorization, bounded by the approval expiry:¶

{
  "access_token": "eyJ...",
  "token_type": "DPoP",
  "expires_in": 900,
  "id_token": "eyJ...",
  "authorization_details": [
    { "type": "crm", "actions": ["export"], "locations": ["https://crm.example/contacts"] }
  ]
}

If Alice declines, or the request expires, the poll returns access_denied or expired_token and no token is issued.¶

10.3. Transaction challenge: resource-initiated (RS and both as PEP)

An agent already holds a token for a CRM but attempts a high-impact deletion the token does not authorize. The resource returns a signed challenge:¶

DELETE /customers/c-4815 HTTP/1.1
Host: crm.example
Authorization: DPoP eyJ...
Accept-Txn-Challenge: ?1

HTTP/1.1 401 Unauthorized
WWW-Authenticate: DPoP error="transaction_authorization_required",
  transaction_challenge="eyJ0eXAiOiJ0eG4tYXV0aHotY2hhbGxlbmdlK2p3dC... (signed JWT)"

The agent relays the challenge to its client, which presents it at the token endpoint under the transaction authorization grant:¶

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

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atxn-authz-challenge
&client_id=agent-7
&completion_mode=deferred
&transaction_challenge=eyJ0eXAiOiJ0eG4tYXV0aHotY2hhbGxlbmdlK2p3dC...

Here the binding to [AuthZEN] differs from the DTR example: the AS does not derive the requestable denial itself, it arrives as the resource-signed challenge. The AS validates the challenge's signature, treats its authorization_details and txn as the requestable-denial signal (mapping them to an AuthZEN evaluation only if it also applies its own policy, the "both" case below), submits the access request, and returns the DTR deferred response:¶

HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store

{
  "error": "authorization_pending",
  "deferral_code": "LRGidcSAeVs_xYpEDt5pNx0A0TBr7qPHbh_Se6pfdf4",
  "expires_in": 300,
  "interval": 5
}

The client polls the token endpoint with the deferred grant and the deferral_code. On approval the AS issues a transaction-scoped token carrying the challenge's txn, which it hands back to the agent to re-present on the original operation:¶

{
  "access_token": "eyJ...",
  "token_type": "DPoP",
  "expires_in": 120,
  "authorization_details": [
    { "type": "customer_records", "actions": ["delete"], "locations": ["https://crm.example/customers/c-4815"] }
  ]
}

The resource validates that the token's txn matches the challenge and that the granted authorization_details authorize the deletion before performing it.¶

In this example the resource is the sole PEP and the AS acts only on the validated challenge. A both as PEP deployment adds one step: after validating the challenge, the AS additionally evaluates the operation against its own PDP before issuing, so issuance requires both the resource's challenge and an AS allow. If the AS's own evaluation is itself a requestable denial, the same access request resolves both; if it is a non-requestable denial, the AS returns the synchronous error of Section 7 and issues nothing. The wire exchange the agent sees is unchanged.¶

17.1. Normative References

[ARAP]

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

[AuthZEN]

Gazitt, O., Brossard, D., and A. Tulshibagwale, "Authorization API 1.0", 29 April 2026, <https://openid.github.io/authzen/>.

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

de Oliveira Niero, G. and D. Liu, "Deferred Token Response", Work in Progress, Internet-Draft, draft-ietf-oauth-deferred-token-response-01, 31 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-deferred-token-response-01>.

[I-D.ietf-oauth-v2-1]

Hardt, D., Parecki, A., and T. Lodderstedt, "The OAuth 2.1 Authorization Framework", Work in Progress, Internet-Draft, draft-ietf-oauth-v2-1-17, 30 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-17>.

[I-D.rosomakho-oauth-txn-challenge]

Rosomakho, Y., Campbell, B., McGuinness, K., and P. Kasselman, "OAuth Transaction Authorization Challenge", Work in Progress, Internet-Draft, draft-rosomakho-oauth-txn-challenge-01, 2 November 2026, <https://datatracker.ietf.org/doc/html/draft-rosomakho-oauth-txn-challenge-01>.

[OIDC-CIBA]

Fernandez, G., Walter, F., Nennker, A., Tonge, D., and B. Campbell, "OpenID Connect Client-Initiated Backchannel Authentication Flow - Core 1.0", 1 September 2021, <https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.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>.

[RFC7009]

Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, August 2013, <https://www.rfc-editor.org/rfc/rfc7009>.

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

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

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

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

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

17.2. Informative References

[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.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-06, 30 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-identity-assertion-authz-grant-06>.

[I-D.ietf-oauth-rar-metadata-remediation]

Zehavi, Y., "OAuth 2.0 RAR Metadata and Error Remediation", Work in Progress, Internet-Draft, draft-ietf-oauth-rar-metadata-remediation-00, 23 August 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar-metadata-remediation-00>.

[RFC8628]

Denniss, W., Bradley, J., Jones, M., and H. Tschofenig, "OAuth 2.0 Device Authorization Grant", RFC 8628, DOI 10.17487/RFC8628, August 2019, <https://www.rfc-editor.org/rfc/rfc8628>.

[RFC9126]

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