OAuth Transaction Authorization Challenge

1.1. Human Approval for Agent-Mediated Actions

Software agents, automated workflows, and delegated services can perform operations on behalf of users. Some operations are sufficiently sensitive that a protected resource might require explicit approval before processing them. Examples include sending a payment, publishing content, deleting data, modifying access policy, or disclosing sensitive information.¶

Local confirmation mechanisms within an agent framework can reduce risk, but they are not always visible to the protected resource and do not necessarily produce authorization evidence that the protected resource can validate. A transaction authorization challenge allows the protected resource to require explicit authorization for the concrete operation and to receive an access token representing that authorization.¶

1.2. Authorization by a Different Resource Owner

The party that initiated an operation is not always the party authorized to approve it. For example, an agent acting on behalf of one user might request access to a resource owned or controlled by another user. The protected resource can determine that approval from the resource owner, or from another party authorized to act for that resource owner, is required before the operation can proceed.¶

In this case, the transaction authorization challenge allows the protected resource to describe the requested operation and the authorization server to determine the appropriate approving party. The resulting access token represents authorization of the challenged operation by the party selected according to authorization server policy.¶

1.3. Organizational Approval

Some operations require approval by an organizational authority rather than by an individual end user. Examples include approving access to regulated data, authorizing a production deployment, granting elevated administrative access, or permitting data transfer to an external party.¶

A transaction authorization challenge allows the protected resource to request authorization evidence from an authorization server or associated policy infrastructure. The authorization server validates the challenge, applies organizational policy, obtains any required approval, and issues an access token only when the required authorization has been obtained.¶

4.1. Challenge Capability Signal

An agent indicates that it supports the transaction authorization challenge mechanism by sending the Accept-Txn-Challenge header field with a true value in requests to a protected resource.¶

The Accept-Txn-Challenge header field is an Item Structured Field; see Section 3.3 of [STRUCTURED-FIELDS]. Its value MUST be a Boolean. Any other value type MUST be handled by recipients as if the field were not present. For example, if this field is included multiple times, its type will become a List and the field will be ignored.¶

This document does not define any parameters for the Accept-Txn-Challenge header field value, but future documents might define parameters. Receivers MUST ignore unknown parameters.¶

The following example indicates support for transaction authorization challenges:¶

Accept-Txn-Challenge: ?1

An Accept-Txn-Challenge header field with a false value has the same semantics as when the header field is not present.¶

An agent MUST NOT include the Accept-Txn-Challenge header field unless it has a client interaction path capable of relaying the challenge to a client that can validate the challenge and present it to an authorization server.¶

A protected resource MUST NOT return a transaction authorization challenge, or a response requesting establishment of a binding key as defined in Section 4.4.2, unless the request includes an Accept-Txn-Challenge header field with a true value, or the protected resource has out-of-band knowledge that the client supports this specification.¶

4.2. Challenge Response

When a protected resource requires transaction-specific authorization, it returns an HTTP error response indicating that transaction authorization is required. This document defines the OAuth error code transaction_authorization_required for this purpose.¶

For example, in response to a request with a DPoP-bound access token:¶

HTTP/1.1 401 Unauthorized
WWW-Authenticate: DPoP error="transaction_authorization_required",
  error_description="Transaction-specific authorization is required",
  algs="ES256",
  transaction_challenge="eyJhbGciOiJFUzI1NiIsInR5cCI6InR4bi1hdXRoei1jaGFsbGVuZ2Urand0..."

The challenge uses the authentication scheme of the access token in the request (Section 7.2 of [DPOP]) or, if there is none, a scheme that the protected resource accepts.¶

The transaction_challenge parameter contains a transaction authorization challenge encoded as a JWS Compact Serialization object as specified in [JWS]. The challenge MUST be signed by the protected resource. The parameter is absent only when the operation requires a binding key that the request does not provide (Section 4.4.2).¶

The error_description parameter MAY be included to provide a human-readable diagnostic description. The error_description parameter MUST NOT be used as the basis for an authorization decision.¶

A protected resource SHOULD use status code 401 when the request was understood but requires additional transaction-specific authorization. Other status codes MAY be used when appropriate for the application protocol.¶

{
  "iss": "https://resource.example.com",
  "aud": "https://as.example.com",
  "iat": 1710000000,
  "exp": 1710000300,
  "jti": "f1f7c8c4-2f8c-4c6a-83d1-example",
  "txn": "97053963-771d-49cc-a4e3-20aad399c312",
  "cnf": {
    "jkt": "0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I"
  },
  "authorization_details": [
    {
      "type": "payment",
      "actions": ["initiate"],
      "locations": ["https://payments.example.com/accounts/123"],
      "instructedAmount": {
        "currency": "GBP",
        "amount": "5000.00"
      },
      "creditorName": "Example Ltd"
    }
  ],
  "reason": "Approval is required before initiating this payment.",
  "reason_uri": "https://resource.example.com/transactions/97053963-771d-49cc-a4e3-20aad399c312",
  "act": {
    "sub": "spiffe://example.com/aiagent/6526f880-1895-400b-a929-11a7eecf9753"
  }
}

4.3. Challenge Signing and Key Discovery

A protected resource that issues transaction authorization challenges MUST sign each challenge using an asymmetric signing key. The client and authorization server MUST validate the challenge signature before using any claim from the challenge for an authorization decision or for display to the user.¶

A protected resource that issues transaction authorization challenges MUST make the public keys needed to validate those challenges available to clients and authorization servers. This document defines protected resource metadata parameters, using the OAuth 2.0 Protected Resource Metadata mechanism described in [OAUTH-PROT-METADATA]. Deployments MAY also use preconfigured trust relationships or other mechanisms to establish the same keying information.¶

This document defines the following protected resource metadata parameters:¶

txn_challenge_jwks_uri:

URL of the protected resource's JSON Web Key Set containing public keys used to validate transaction authorization challenges.¶

txn_challenge_signing_alg_values_supported:

JSON array containing the JWS alg values supported by the protected resource for transaction authorization challenges.¶

If a protected resource uses the same JWK Set for transaction authorization challenges and for other protected resource signing keys, the value of txn_challenge_jwks_uri MAY be the same as another JWK Set URI published by the protected resource.¶

When the challenge-signing key is published in the JWK Set identified by txn_challenge_jwks_uri, the kid value in the JOSE header of a transaction authorization challenge MUST identify the signing key in that JWK Set.¶

If the challenge cannot be validated, the client or authorization server MUST NOT treat the challenge as authentic.¶

4.4. Access Token Key Binding

A protected resource can request that the access token issued for a challenge be bound to a key by including in the challenge a cnf claim that identifies that key (the binding key). The binding key is a key that the sender of the triggering request demonstrated possession of when sending that request. The triggering request is the request to the protected resource that caused the challenge to be issued; it can be sent by an agent or by a client. The authorization server binds the issued access token to the binding key (Section 4.7). The binding key comes from a sender-constrained access token in the triggering request (Section 4.4.1) or, otherwise, from a DPoP proof or client certificate sent with that request (Section 4.4.2).¶

The protected resource MUST validate the access token, including any sender constraint, and if validation fails, returns the error response specified for that access token (Section 3.1 of [BEARER], Section 7.1 of [DPOP], Section 3 of [MTLS]).¶

A protected resource SHOULD include a binding key in the challenge whenever the access token in the triggering request is sender-constrained, and for high-impact or non-idempotent operations. It MUST NOT do so unless it knows, for example by configuration, that the authorization server supports binding keys in challenges with the confirmation method used.¶

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer error="binding_key_required", algs="ES256"

POST /payments HTTP/1.1
Host: resource.example.com
Authorization: Bearer mF_9.B5f-4.1JqM
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7...
Accept-Txn-Challenge: ?1
Content-Type: application/json

{"amount": "5000.00", "currency": "GBP", "recipient": "Example Ltd"}

4.5. Agent Relay

After receiving a transaction authorization challenge from a protected resource, the agent relays the challenge to the client using a deployment-specific client-agent protocol.¶

The agent MUST relay the transaction authorization challenge without modifying it and MUST NOT replace it with an agent-generated description of the requested operation. The client MUST treat any agent-supplied description as advisory. Any authorization decision, user display, or disclosure decision MUST be based on the validated challenge or on protected resource state identified by the validated challenge.¶

A client-agent protocol that carries transaction authorization challenges SHOULD distinguish a transaction authorization challenge from ordinary agent messages or natural-language content. For example, such a protocol can carry the challenge using a field named transaction_challenge whose value is the JWS Compact Serialization of the transaction authorization challenge.¶

In deployments where one agent delegates work to another agent, a transaction authorization challenge MAY be relayed through one or more intermediate agents before reaching the client. Each agent that relays the challenge MUST relay it without modification. An intermediate agent MUST NOT replace the challenge with a new challenge unless it is itself acting as a protected resource for a distinct operation and generates a new signed transaction authorization challenge for that operation.¶

4.6. Client Processing

Before presenting the challenge to the authorization server, the client MUST validate the challenge signature, issuer, audience, and expiration. The client MUST verify that the aud claim identifies the authorization server to which the client intends to present the challenge.¶

The client MAY display the challenge contents to the user before sending the challenge to the authorization server. This allows the user to decide whether to continue and whether to disclose the challenged transaction to the authorization server.¶

When displaying challenge information, the client MUST use information obtained from the validated challenge or from protected resource state identified by the validated challenge. The client MUST NOT rely on an unprotected description supplied by the agent.¶

If the user declines to continue, or if the client cannot validate the challenge, the client MUST NOT present the challenge to the authorization server.¶

4.7. Authorization Server Processing

The authorization server MUST validate the transaction authorization challenge before accepting it for processing or issuing an access token.¶

At a minimum, the authorization server MUST verify that:¶

• the challenge signature is valid;¶

• the challenge was issued by a protected resource recognized by the authorization server;¶

• the challenge has not expired;¶

• no challenge with the same iss and jti values has previously been accepted for processing, unless the same client resubmits it, in which case the authorization server continues the original transaction authorization request; the authorization server retains this state until the challenge expires;¶

• the aud claim identifies the authorization server;¶

• the authorization server is willing to issue access tokens for the protected resource identified by the iss claim and for the requested operation;¶

• the access token issued in response to the challenge will use the protected resource identified by the iss claim as its audience, unless an application profile defines a different audience binding;¶

• the txn claim is present, is a string, and is acceptable;¶

• the requested operation is sufficiently described;¶

• the client is permitted to request transaction authorization for the challenged operation;¶

• if the challenge contains a cnf claim, that claim contains exactly one confirmation method, jkt or x5t#S256, with a well-formed value, and the authorization server supports it (Section 4.4).¶

When requester context, such as the act claim, is present in the challenge, the authorization server MUST consider that context when determining whether the challenged operation can be approved. The authorization server MUST NOT treat cnf as identifying or authenticating the requester.¶

The authorization server determines the approving party according to local policy. The approving party can be the subject associated with the original request, a different resource owner, an administrator, an organizational approval workflow, or another policy authority.¶

The authorization server MUST obtain any required approval before issuing an access token. The authorization server SHOULD present the approving party with sufficient information to understand the operation being authorized. The authorization server MUST NOT rely on an unprotected description supplied by the agent as the basis for the authorization decision.¶

If the authorization server accepts the challenge for processing, the client obtains the result using the transaction authorization flow described in Section 5. If the authorization server rejects the challenge, cannot validate the challenge, or cannot obtain the required approval, it MUST NOT issue an access token for the challenged operation.¶

When the challenge contains a cnf claim, the authorization server MUST bind the access token to the key identified by cnf as specified in Section 6 of [DPOP] or Section 3 of [MTLS], with token_type DPoP for jkt (Section 5 of [DPOP]) or Bearer for x5t#S256, and MUST NOT bind it to any other key. It MUST NOT issue a refresh token, because a refreshed access token would be bound to a key that the client proves (Section 5 of [DPOP]).¶

The authorization server does not verify possession of the binding key and does not require the client to demonstrate it; it relies on the protected resource identified by the iss claim, which verified possession on the triggering request and asserts the key in the signed challenge (Section 4.4). Client authentication still applies. As an exception to Section 5.2 of [DPOP], the authorization server does not require a DPoP proof on a transaction authorization request whose challenge contains a cnf claim, or on a poll for that request, even if the client's dpop_bound_access_tokens metadata is true.¶

5.1. Transaction Authorization Grant

This document defines the grant type urn:ietf:params:oauth:grant-type:txn-authz-challenge. The client presents a validated challenge (relayed to it by the agent) by making a token request to the token endpoint with the following parameters in the application/x-www-form-urlencoded request body:¶

grant_type:

REQUIRED. MUST be urn:ietf:params:oauth:grant-type:txn-authz-challenge.¶

transaction_challenge:

REQUIRED. The transaction authorization challenge received from the protected resource.¶

completion_mode:

OPTIONAL. Including the value deferred, as defined by [DEFERRED], signals that the client accepts a deferred token response. Because the approval that satisfies a challenge is typically asynchronous, a client SHOULD include deferred. An authorization server MUST NOT return a deferred response to a client that has not signaled deferred. If the authorization server cannot approve the operation synchronously for such a client, it MUST return the access_denied error (Section 3.5 of [OAUTH-DEVICE]); the client can then repeat the request with deferred included in completion_mode.¶

client_id:

REQUIRED if the client is not authenticating with the authorization server as described in Section 3.2.1 of [OAUTH-FRAMEWORK].¶

The client authentication requirements of Section 3.2.1 of [OAUTH-FRAMEWORK] apply, and requests MUST use TLS following the best practices of [BCP-195]. The authorization server MUST validate the challenge as described in Section 4.7 before accepting the request. If the challenge fails validation, the error code is invalid_grant (Section 5.2 of [OAUTH-FRAMEWORK]) unless a more specific code applies, such as unauthorized_client for a client that is not permitted to request transaction authorization for the operation.¶

For example, a public client, which [DEFERRED] requires to present a DPoP proof ([DPOP]) on this request, sends the following request:¶

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

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

5.2. Deferred Processing and Polling

If the authorization server can approve the challenged operation without further interaction, it returns a token response as described in Section 5.4.¶

Otherwise, if the client signaled completion_mode=deferred, the authorization server returns a deferred token response as defined in [DEFERRED]: an HTTP 400 response whose body carries the authorization_pending or interaction_required error code, a deferral_code, an expires_in, and an interval. The client then polls the token endpoint using the deferred grant of [DEFERRED] (grant_type=urn:ietf:params:oauth:grant-type:deferred with the deferral_code) until it receives a token response or a terminal error. The polling cadence, the interaction_required, slow_down, expired_token, and access_denied errors, optional completion-callback notifications, and cancellation via the revocation endpoint are all as defined in [DEFERRED].¶

When approval requires interaction that the client can facilitate, the authorization server returns interaction_required with an interaction_uri, on the deferred response or on a later polling response, as defined in [DEFERRED]. The client presents the interaction_uri to the user or other approving party, or opens it in a user agent, and continues polling.¶

The deferral_code is sender-constrained as defined in [DEFERRED]; this protects the polling credential. If the challenge contains a cnf claim, the access token issued on a polling request is bound to the key identified by cnf (Section 4.7), even if [DEFERRED] binds the deferral_code to the client's DPoP key. Otherwise, if the client presents a DPoP proof on the transaction authorization grant request, as [DEFERRED] requires of a public client, [DEFERRED] binds both the deferral_code and the access token later issued on a polling request to the client's DPoP key; if it does not, the format and binding of the issued access token are as described in Section 5.4. The txn value correlates the challenge, the issued token, and any re-evaluation.¶

• Editor's note: When the client presents a DPoP proof, binding the access token to the key identified by cnf conflicts with [DEFERRED], which requires the access token to be bound to the client's DPoP key in both its sender-constraint requirements and its sender-constraining continuity guarantee. Resolving this requires [DEFERRED] to let the originating grant define how the issued access token is bound, separately from the binding of the deferral_code.¶

For example, the authorization server returns a deferred response, and the client then polls:¶

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
}

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

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adeferred
&client_id=s6BhdRkqt3
&deferral_code=LRGidcSAeVs_xYpEDt5pNx0A0TBr7qPHbh_Se6pfdf4

5.3. Discovery

An authorization server indicates support for this mechanism by including urn:ietf:params:oauth:grant-type:txn-authz-challenge in the grant_types_supported value of its metadata [OAUTH-AS-METADATA], and by setting the deferred_token_response_supported metadata parameter defined in [DEFERRED] to true.¶

5.4. Successful Access Token Response

If the transaction authorization request is approved, the authorization server returns an access token response.¶

The response uses the access token response format defined in Section 5.1 of [OAUTH-FRAMEWORK] and the authorization_details response parameter defined in Section 7 of [OAUTH-RAR]. The granted authorization_details value MUST describe the operation approved for the challenged transaction and MUST be derived from the authorization_details claim of the transaction authorization challenge. The authorization server MAY normalize, narrow, or otherwise constrain the granted authorization details relative to those requested by the challenge, but MUST NOT broaden them.¶

The authorization_details parameter in the token response is returned by the authorization server as required by Section 7 of [OAUTH-RAR] and conveys the authorization details as granted, which MAY differ from those requested in the challenge. This response parameter is informational for the client. The protected resource MUST determine authorization from the granted authorization details bound to the access token (see Section 6), and MUST NOT rely on the token response parameter.¶

The access token MUST contain the txn value from the transaction authorization challenge, MUST be bound to the granted authorization details, and MUST use the iss value from the transaction authorization challenge as its audience unless an application profile defines a different audience binding. The authorization server MAY issue this access token in any access token format negotiated with the protected resource; when JWT access tokens defined in [JWT-AT] are used, the txn and authorization_details claims are included as defined in [SET] and Section 9 of [OAUTH-RAR] respectively.¶

The access token issued in response to a transaction authorization challenge is scoped to the challenged operation and MUST NOT be accepted as authorization for any operation that is not described by its granted authorization details.¶

For example:¶

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
  "access_token": "eyJhbGciOiJFUzI1NiIsInR5cCI6ImF0K2p3dCJ9...",
  "token_type": "DPoP",
  "expires_in": 120,
  "authorization_details": [
    {
      "type": "payment",
      "actions": ["initiate"],
      "locations": ["https://payments.example.com/accounts/123"],
      "instructedAmount": {
        "currency": "GBP",
        "amount": "5000.00"
      },
      "creditorName": "Example Ltd"
    }
  ]
}

The access token MUST have a limited lifetime. The authorization server SHOULD issue the access token with a short lifetime because it represents authorization for a specific operation. When the challenge contains a cnf claim, the access token is sender-constrained to the key identified by cnf, using DPoP [DPOP] or mutual-TLS [MTLS] (Section 4.7). Otherwise, the authorization server MAY sender-constrain the access token to a key that the client proves; only the client can then present it. A client that relays the access token to an agent also relays its token_type. The client need not possess the binding key or generate DPoP proofs; the agent presents the access token using the indicated token type.¶

6.1. Token Presentation

The client provides the access token to the agent. The agent presents the access token to the protected resource together with the request for the challenged operation.¶

In deployments where one agent delegates work to another agent, the access token MAY be relayed through one or more intermediate agents before being presented to the protected resource. Each agent that relays the access token MUST relay it without modification. An agent MUST NOT use the access token for a different transaction, different protected resource, or different requester context.¶

When the challenge contains a cnf claim, only the holder of the key identified by cnf can present the access token; an agent acting for another agent can obtain its own challenge.¶

When HTTP is used, the access token MUST be presented to the protected resource as defined by [OAUTH-FRAMEWORK]. Bearer access tokens are presented using the Authorization request header field as specified in [BEARER]. Sender-constrained access tokens are presented using the mechanism defined by the corresponding access token format, for example [DPOP] or [MTLS].¶

For example:¶

POST /payments HTTP/1.1
Host: resource.example.com
Authorization: DPoP eyJhbGciOiJFUzI1NiIsInR5cCI6ImF0K2p3dCJ9...
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6IkVDIiwiY3J2IjoiUC0yNTYi...
Content-Type: application/json

{
  "amount": "5000.00",
  "currency": "GBP",
  "recipient": "Example Ltd"
}

The agent MUST NOT modify the access token. If the agent cannot present the access token to the protected resource, the challenged operation cannot be completed using this mechanism.¶

6.2. Protected Resource Validation

Before accepting the access token as authorization for a challenged operation, the protected resource MUST validate the access token according to [OAUTH-FRAMEWORK], the access token format in use, and the requirements of this document.¶

At a minimum, the protected resource MUST verify that:¶

• the access token was issued by the authorization server identified by the aud claim of the transaction authorization challenge;¶

• the access token audience identifies the protected resource, unless an application profile defines a different audience binding;¶

• the access token has not expired;¶

• the access token is bound to the same txn value as the transaction authorization challenge;¶

• if the challenge, as recorded by the protected resource, contains a cnf claim, the access token is sender-constrained with the confirmation method and value in that claim, and the request satisfies that constraint (Section 7.1 of [DPOP], Section 3 of [MTLS]);¶

• the granted authorization details associated with the access token authorize the requested operation and are consistent with the authorization_details claim of the transaction authorization challenge;¶

• any requester context required by the transaction authorization challenge is present and matches the challenged transaction;¶

• no access token for the same txn value has previously been accepted, if the protected resource requires single use for the challenged operation.¶

A protected resource MUST reject an access token that does not correspond to the transaction authorization challenge for the requested operation.¶

A protected resource SHOULD treat access tokens issued in response to a transaction authorization challenge as single-use when the challenged operation is non-idempotent or high impact. If single-use semantics are required, the protected resource MUST maintain sufficient state to detect replay of the transaction identifier.¶

The protected resource MUST NOT accept an access token issued in response to a transaction authorization challenge as general authorization for operations other than the challenged operation. In particular, the protected resource MUST NOT honour the granted authorization details of such an access token for any operation that is not the challenged operation described by those authorization details.¶

8.1. HTTP Field Name Registration

IANA is requested to register the following field name in the "HTTP Field Name" registry [IANA.HTTP.FieldNames] as a structured Header Field:¶

Field Name:

Accept-Txn-Challenge¶

Status:

permanent¶

Structured Type:

Item¶

Reference:

this document¶

8.2. OAuth Extensions Error Registration

IANA is requested to register the following error values in the "OAuth Extensions Error" registry [IANA.OAuth.Parameters]:¶

Error name:

transaction_authorization_required¶

Usage location:

resource access error response¶

Protocol extension:

OAuth Transaction Authorization Challenge¶

Change controller:

IETF¶

Reference:

this document¶

Error name:

binding_key_required¶

Usage location:

resource access error response¶

Protocol extension:

OAuth Transaction Authorization Challenge¶

Change controller:

IETF¶

Reference:

Section 4.4.2 of this document¶

8.3. OAuth Parameter Registration

IANA is requested to register the following parameters in the "OAuth Parameters" registry [IANA.OAuth.Parameters]:¶

Name:

transaction_challenge¶

Parameter Usage Location:

WWW-Authenticate response, token request¶

Change controller:

IETF¶

Reference:

this document¶

8.4. OAuth Protected Resource Metadata Registration

IANA is requested to register the following values in the "OAuth Protected Resource Metadata" registry [IANA.OAuth.Parameters].¶

Metadata name:

txn_challenge_jwks_uri¶

Metadata description:

URL of the protected resource's JSON Web Key Set containing public keys used to validate transaction authorization challenges.¶

Change controller:

IETF¶

Reference:

this document¶

Metadata name:

txn_challenge_signing_alg_values_supported¶

Metadata description:

JSON array containing the JWS alg values supported by the protected resource for transaction authorization challenges.¶

Change controller:

IETF¶

Reference:

this document¶

8.5. OAuth URI Registration

IANA is requested to register the following value in the "OAuth URI" registry [IANA.OAuth.Parameters], in accordance with [OAUTH-URI].¶

URN:

urn:ietf:params:oauth:grant-type:txn-authz-challenge¶

Common Name:

Grant type URI for presenting an OAuth transaction authorization challenge to the token endpoint.¶

Change controller:

IETF¶

Reference:

this document¶

8.6. JSON Web Token Claims Registration

IANA is requested to register the following claims in the "JSON Web Token Claims" registry [IANA.JSON.Web.Token].¶

Claim Name:

reason¶

Claim Description:

Human-readable explanation of why authorization, confirmation, or other processing is required.¶

Change Controller:

IETF¶

Reference:

this document¶

Claim Name:

reason_uri¶

Claim Description:

URI identifying additional information about why authorization, confirmation, or other processing is required.¶

Change Controller:

IETF¶

Reference:

this document¶

9.1. Normative References

[BCP-195]

Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/rfc/rfc7525>.

[BEARER]

Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, <https://www.rfc-editor.org/rfc/rfc6750>.

[DEFERRED]

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

[DPOP]

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

[JWS]

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

[JWT]

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

[MTLS]

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

[OAUTH-AS-METADATA]

Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, <https://www.rfc-editor.org/rfc/rfc8414>.

[OAUTH-FRAMEWORK]

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

[OAUTH-PROT-METADATA]

Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0 Protected Resource Metadata", RFC 9728, DOI 10.17487/RFC9728, April 2025, <https://www.rfc-editor.org/rfc/rfc9728>.

[OAUTH-RAR]

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

[OAUTH-TOKEN-EXCHANGE]

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

[OAUTH-URI]

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

[POP-KEY]

Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, April 2016, <https://www.rfc-editor.org/rfc/rfc7800>.

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

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

[SET]

Hunt, P., Ed., Jones, M., Denniss, W., and M. Ansari, "Security Event Token (SET)", RFC 8417, DOI 10.17487/RFC8417, July 2018, <https://www.rfc-editor.org/rfc/rfc8417>.

[STRUCTURED-FIELDS]

Nottingham, M. and P. Kamp, "Structured Field Values for HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024, <https://www.rfc-editor.org/rfc/rfc9651>.

9.2. Informative References

[FSB-AI]

Financial Stability Board, "Sound Practices for Responsible Adoption of Artificial Intelligence (AI): Final report", 15 October 2026, <https://www.fsb.org/uploads/P151026-1.pdf>.

[IANA.HTTP.FieldNames]

"Hypertext Transfer Protocol (HTTP) Field Name Registry", n.d., <https://www.iana.org/assignments/http-fields/>.

[IANA.JSON.Web.Token]

"JSON Web Token (JWT)", n.d., <https://www.iana.org/assignments/jwt/>.

[IANA.OAuth.Parameters]

"OAuth Parameters", n.d., <https://www.iana.org/assignments/oauth-parameters/>.

[JWT-AT]

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

[OAUTH-DEVICE]

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

[OAUTH-STEP-UP]

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