[OAUTH-WG] rfc9449

[Bhasker Allam <[e-mail]>]

Hello OAuth Working Group,
I am trying to use DPOP RFC by I am running into issues with htu/htm claims in the RFC. Towards this end, I’ve written a proposal arguing for relaxing these claims so that the RFC can be used varying deployment architectures. I’d appreciate your input w.r.t to my proposal.

Bhasker Allam


================================================================
Proposed Modification to RFC 9449
OAuth 2.0 Demonstrating Proof of Possession (DPoP)
Making htm and htu Optional to Enable Wider Adoption

June 2026
================================================================


Abstract
--------

RFC 9449 defines DPoP (Demonstrating Proof of Possession), a
mechanism for sender-constraining OAuth 2.0 access tokens at the
application layer.  The core value of DPoP is its ability to
cryptographically bind an access token to a client keypair,
ensuring that only the entity holding the corresponding private
key can legitimately use the token.  This property directly
addresses the bearer token problem -- that any party in possession
of a token string can use it.

However, RFC 9449 mandates that every DPoP proof include htm
(HTTP method) and htu (HTTP target URI) claims, binding each
proof to a specific request.  This requirement, while addressing
a narrow secondary threat, fails to account for a fundamental
architectural reality of HTTP deployments: requests routinely
traverse intermediaries -- reverse proxies, load balancers,
Application Programming Interface (API) gateways, and service
meshes -- that are not passive conduits
but active participants in request routing.  These intermediaries
frequently rewrite URIs as a core function of their operation,
translating the external URI a client signs in its DPoP proof
to an internal URI the backend resource server receives.  The
result is a proof validation failure that is not a security
event but an architectural inevitability.  This proposal argues
that htm and htu should be reclassified from MUST to OPTIONAL,
that the core possession proof properties are fully preserved
without them, and that this change would significantly broaden
DPoP adoption without meaningful security regression.


----------------------------------------------------------------
1.  Background and Motivation
----------------------------------------------------------------

1.1  The Bearer Token Problem DPoP Solves

OAuth 2.0 access tokens, as defined by RFC 6750, are bearer
tokens: any party in possession of the token string can present
it to a resource server and receive access.  This creates a
fundamental vulnerability -- a token intercepted in transit,
leaked through a log, or exfiltrated from storage is immediately
usable by an attacker.  The legitimate holder of the token has
no exclusive claim to it.

DPoP addresses this by binding the token to a public/private
keypair at issuance time.  The Authorization Server (AS) embeds
the JSON Web Key (JWK) thumbprint of the client's public key
into the access token as the cnf.jkt claim.  To use the
token, the client must produce a fresh DPoP proof -- a
JSON Web Token (JWT) signed with the corresponding private
key.  A verifier confirms that the public key in the
proof matches cnf.jkt in the token, and that the signature is valid.

This elegantly solves the core problem: a stolen token string is
useless without the private key.  The private key never leaves
the client.  The token is bound to its legitimate holder.


1.2  The Fundamental Verification Chain

The security guarantee DPoP provides rests on a four-step
verification chain, all of which are self-contained and require
no call back to the AS:

  o  The AS signs the access token, embedding cnf.jkt -- the
     SHA-256 thumbprint of the client's public key.

  o  The client presents the token alongside a fresh DPoP proof
     JWT, which carries the full public key in its jwk header
     and is signed with the corresponding private key.

  o  The verifier (resource server or intermediary) extracts the
     public key from the DPoP proof header.

  o  The verifier computes the SHA-256 thumbprint of that public
     key and compares it against cnf.jkt in the token.  If they
     match, and the proof signature is valid, possession is
     proven.

This chain is complete, stateless, and cryptographically sound.
It proves, beyond reasonable doubt, that the entity presenting
the token controls the private key the AS associated with the
token at issuance.


1.3  What htm and htu Add -- and at What Cost

What they add:  htm (HTTP method) and htu (HTTP target URI) bind
a DPoP proof to a specific request.  This prevents a proof
received by a malicious or compromised resource server from being
replayed to a different resource server within the proof's
validity window.  The threat model is: a server that legitimately
receives a client's proof attempts to relay it in real time to a
different server where the token is also valid.

What they cost:  Any reverse proxy that rewrites the URI or
changes the HTTP method between the client-facing layer and the
backend resource server will cause DPoP proof validation to fail.
The proof the client signed references the external URI; the
backend resource server sees a different URI.  The htm/htu check
fails, and the request is rejected.

This is not an edge case.  URI path rewriting at reverse proxies
is standard practice in production deployments across the
industry.


----------------------------------------------------------------
2.  The Proxy Incompatibility Problem
----------------------------------------------------------------

2.1  URI Rewriting is Ubiquitous

Reverse proxies performing path translation are among the most
common deployment patterns in production HTTP architectures.
Examples covering API versioning, microservice routing, Content
Delivery Networks (CDNs), security gateways, and multi-tenant
Software-as-a-Service (SaaS) platforms are pervasive:

  Pattern               External URI           Internal URI
  -------------------   --------------------   -------------------
  API versioning        /api/orders            /v2/internal/orders
  Microservice routing  /app/checkout          /checkout-svc/process
  CDN / edge routing    /static/assets/x.js    /origin/cdn/x.js
  Security gateway      /payments/transfer     /internal/pay/v1/xfr
  Multi-tenant SaaS     /tenant-a/api/data     /api/data?tenant=a

In each of these cases, the htu the client signed -- based on the
URI it was given -- does not match the URI the backend resource
server receives.  DPoP proof validation fails.  The client has no
way to know the internal URI; it cannot pre-sign for a URI it was
never told about.


2.2  Security Intermediaries

Security gateways, Web Application Firewalls (WAFs), and API
security products sit in the request path specifically to
perform deep inspection.  Their core function is to
validate tokens, enforce policy, and detect anomalous
usage -- precisely the entities that should be enforcing
DPoP.  Yet these products routinely operate in environments where
URI rewriting occurs.

An intermediary that wants to validate DPoP possession -- to
confirm that the token is being used by the entity it was issued
to -- cannot do so if URI rewriting causes the htu check to fail.
The RFC as written forces a binary choice: either perform DPoP
validation (and break URI-rewriting deployments) or pass the
proof through transparently (and skip possession verification).
Neither is acceptable.


2.3  The RFC's Own Scope Statement

RFC 9449 Section 7.1 explicitly states:

   This authentication scheme is for origin-server authentication
   only.  Therefore, this authentication scheme MUST NOT be used
   with the Proxy-Authenticate or Proxy-Authorization header
   fields.

This statement acknowledges that DPoP is an end-to-end
application layer mechanism between client and origin server.
It does not mandate that the path between them be free of
proxies -- it mandates that proxies not themselves challenge
using DPoP.  Transparent proxies are expected.  URI-rewriting
proxies are common.  The RFC's htm/htu requirement is in tension
with this reality.


----------------------------------------------------------------
3.  Analysis of the htm/htu Threat Model
----------------------------------------------------------------

3.1  The Threat htm/htu Addresses

The specific threat htm and htu defend against is described in
RFC 9449 Section 2:

   The attacker model describes cases where a protected resource
   might be counterfeit, malicious, or compromised and plays
   received tokens against other protected resources to gain
   unauthorized access.

In concrete terms: a Resource Server (RS-A) that legitimately
receives a valid DPoP proof from a client could, within the
proof's validity window (typically 30-60 seconds), relay that
proof to a different resource server (RS-B) where the same token
is also valid.  Without URI binding, RS-A's forwarded proof would
pass validation at RS-B.


3.2  TLS Server Authentication Already Addresses This Threat

The malicious RS relay attack requires the client to connect to a
malicious server in the first place.  Transport Layer Security
(TLS) server certificate validation -- mandatory for all
DPoP deployments, as the RFC states DPoP MUST always be
used in conjunction with HTTPS -- prevents this in the standard case:

  o  The client connects to api.example.com.

  o  TLS presents the server certificate for api.example.com.

  o  The client validates the certificate.  If it is fraudulent
     or the domain does not match, the TLS handshake fails.

  o  No DPoP proof is ever sent.

The malicious RS scenario only becomes relevant when TLS
validation has already failed -- either through a compromised
Certificate Authority, a client that ignores certificate errors,
or a legitimate RS that is fully compromised (in which case it
already has the access token and scope, making proof replay a
marginal additional concern).


3.3  Other Mechanisms Already Bound the Token to a Resource

Even without htm/htu in the proof, the token itself carries
resource binding through standard JWT claims:

  o  aud (audience):  Restricts the token to specific resource
     servers.  A proof replayed to an out-of-scope RS fails aud
     validation regardless of the proof contents.

  o  scope:  Limits what operations are permitted.  Cross-
     resource replay is constrained by the scope the token was
     issued for.

  o  ath (access token hash):  Binds the proof to the specific
     token value.  A proof cannot be used with a different token.

  o  jti (JWT ID) + iat (issued at):  The proof's unique
     identifier and timestamp.  Servers maintain a jti cache to
     prevent replay within the validity window.

These mechanisms collectively constrain the attack surface to:
same token, same aud, same scope, same jti not yet seen, within
iat window.  The htm/htu binding adds marginal defense on top of
this existing stack, specifically for the malicious-RS relay
attack that TLS already defends against.


3.4  Transaction Tokens: Architectural Complexity as Evidence
     of the Problem

The OAuth Working Group (WG)'s own
draft-ietf-oauth-transaction-tokens (Txn-Tokens) provides
compelling evidence that the htm/htu constraint is a
recognized deployment barrier -- one that required a
significant architectural workaround rather than a fix to
the root cause.

Txn-Tokens address the URI rewriting problem by introducing a
Transaction Token Service (TTS) at each trust domain boundary.
When an external request arrives at a boundary workload, that
workload exchanges the inbound OAuth access token for a freshly
issued Txn-Token scoped to the internal transaction.  Internal
workloads use the Txn-Token rather than the original OAuth
token.  Because the Txn-Token is issued after the external DPoP
proof has been validated -- and before any URI rewriting occurs
-- the htm/htu constraint is bypassed: the DPoP proof only needs
to survive the one external hop where the URI is still unchanged.

This is an architecturally sound solution for deployments that
can install a TTS at every trust boundary.  However it introduces
substantial infrastructure requirements and has its own
limitations:

  o  Chained URI rewrites across multiple proxy layers before the
     TTS boundary is reached still break DPoP proof validation.

  o  Federated agentic architectures spanning organizational
     boundaries require a TTS at every domain boundary,
     multiplying operational complexity.

  o  The TTS itself becomes a high-value target and single point
     of failure within each trust domain.

  o  Deployments without the infrastructure to run a TTS --
     which includes the majority of existing API deployments --
     cannot benefit from this workaround.

The existence of Txn-Tokens as a workaround is an implicit
acknowledgement by the WG that the current htm/htu requirement
creates real deployment barriers.  A targeted relaxation of that
requirement in RFC 9449 addresses the root cause directly,
without requiring new infrastructure at every trust boundary.


3.5  Rich Authorization Requests (RAR) Renders htm/htu
     Redundant in Modern Deployments

RFC 9396 (Rich Authorization Requests) allows the AS to encode,
at token issuance time, precisely what resource, action, and
parameters the token authorizes.  The authorization_details
claim carries structured, AS-signed assertions of the specific
resources and locations the token is valid for:

   "authorization_details": [
     {
       "type": "payment_initiation",
       "locations": ["https://payments.example.com/v1/transfer"],
       "instructed_amount": {
         "currency": "EUR", "amount": "123.50"
       }
     }
   ]

Where RAR is used with location-bound authorization_details, the
AS has already cryptographically constrained the token to
specific resource locations.  This AS-signed assertion is
structurally stronger than htu in the DPoP proof for several
reasons:

  o  It is made at token issuance time by the AS -- the ultimate
     authority -- not at request time by the client.

  o  It is embedded in the access token and protected by the AS's
     signature.  It cannot be forged or modified.

  o  It is validated independently of the DPoP proof by any
     verifier that trusts the AS signature.

  o  It constrains the token to specific locations regardless of
     what URI appears in any proof.

The malicious RS relay attack that htm/htu defend against is
already blocked at the token layer by RAR location binding.  A
proof replayed to an unauthorized RS fails not because of htu
validation but because the token's authorization_details.
locations does not include that RS.  The htu check becomes a
redundant verification of something the token already constrains
more strongly.

It should be noted that RAR's locations field is optional and
not all authorization_details types include it.  The argument
for optionality is therefore precise: for deployments using RAR
with location-bound authorization_details, htm/htu are
redundant; for deployments without RAR, htm/htu remain valuable
as defense-in-depth.  Mandating htm/htu universally fails to
account for the layered defenses already available in modern RAR
deployments, and imposes a proxy-incompatible constraint where
stronger alternatives already exist.


3.6  The Cumulative Redundancy Argument

Taken together, the defenses available without htm/htu form a
comprehensive stack against the threats htm/htu were introduced
to address:

  Defense                  Threat Covered              URI-safe?
  -----------------------  --------------------------  ---------
  TLS server cert          Malicious RS impersonation  Yes
  aud claim                Cross-service token replay  Yes
  scope claim              Cross-operation abuse       Yes
  ath claim                Proof/token substitution    Yes
  jti + iat                Verbatim proof replay       Yes
  RAR locations (RFC 9396) Resource location binding   Yes
  htu / htm                Residual margin above all   No

By the time htm/htu are reached in this stack, every meaningful
attack vector has already been addressed by mechanisms that are
both stronger and proxy-transparent.  The marginal security gain
of htm/htu is real but small.  The deployment cost is large.


3.7  The Disproportionate Trade-off

The marginal security benefit of htm/htu -- defense against a
malicious RS relay attack already addressed by TLS, RAR, and
existing token claims -- is outweighed by the deployment cost:
incompatibility with the most common production proxy
architecture, and the architectural complexity required to work
around it as evidenced by Txn-Tokens.  The RFC has optimized for
a narrow threat model at the expense of broad applicability.


----------------------------------------------------------------
4.  Proposed Modification
----------------------------------------------------------------

4.1  Reclassify htm and htu from MUST to OPTIONAL

The proposed change is narrow and surgical.  In RFC 9449
Section 4.2, reclassify htm and htu from MUST to OPTIONAL claims
in the DPoP proof payload.

Current specification (Section 4.2):

   htm:  The value of the HTTP method of the request to which
         the JWT is attached. [REQUIRED]

   htu:  The HTTP target URI of the request to which the JWT is
         attached, without query and fragment parts. [REQUIRED]

Proposed specification:

   htm:  The value of the HTTP method of the request to which
         the JWT is attached. [OPTIONAL]  When present,
         verifiers MUST validate it matches the current request
         method.

   htu:  The HTTP target URI of the request to which the JWT is
         attached, without query and fragment parts. [OPTIONAL]
         When present, verifiers MUST validate it matches the
         current request URI.


4.2  The Core Security Properties Are Preserved

The following table demonstrates that the fundamental DPoP
guarantee -- proving the presenter holds the private key the AS
bound the token to -- is fully preserved without htm/htu:

  Security Property                     Preserved?  Mechanism
  ------------------------------------  ----------  --------------------
  Token is authentic (AS-issued)        Yes         AS signature on JWT
  Presenter holds the bound private key Yes         cnf.jkt match +
                                                    proof signature
  Proof not reused with different token Yes         ath claim
  Proof not replayed verbatim           Yes         jti cache + iat
  Token scoped to correct audience      Yes         aud claim in token
  Token scoped to correct operations    Yes         scope claim in token
  Malicious RS relay (same aud/scope)   Partial     TLS (primary);
                                                    jti cache limits
                                                    window
  Proof bound to specific URI/method    No          Removed -- this is
                                                    the trade-off


4.3  Preserve htm/htu as a Defense-in-Depth Option

Deployments with direct client-to-RS communication (no URI
rewriting) should continue to include htm and htu.  Deployments
behind URI-rewriting proxies should be able to omit them without
forfeiting the core possession guarantee.  The RFC should
explicitly address both deployment topologies rather than
mandating behavior that breaks one of them.

A deployment profile approach is appropriate: the AS could
indicate, via authorization server metadata, whether it requires
htm/htu in proofs -- allowing clients and proxies to adapt to
deployment context.


----------------------------------------------------------------
5.  Impact on Intermediaries and Security Products
----------------------------------------------------------------

5.1  The Security Intermediary Use Case

Security gateways, API security products, and reverse proxies
with deep inspection capabilities represent a critical deployment
scenario for DPoP.  These products sit in the request path
specifically to validate tokens and detect misuse.  Their ability
to enforce DPoP possession verification benefits the entire
ecosystem.

Under the current RFC, an intermediary that performs URI rewriting
cannot validate htm/htu without causing legitimate requests to
fail.  Its choices are:

  o  Skip DPoP proof validation entirely (defeats the security
     purpose).

  o  Validate the proof against the external URI before rewriting
     (requires the proxy to be the terminal DPoP verifier,
     breaking end-to-end semantics).

  o  Perform token exchange (RFC 8693) to re-bind the token to
     the proxy's own key (significant complexity, AS dependency).

None of these options is satisfactory for a security product
whose purpose is transparent inspection.  With htm/htu as
optional, the intermediary can validate the core possession proof
-- cnf.jkt match, signature validity, ath, jti, iat -- without
being blocked by URI translation.


5.2  Enabling Stateless Verification at Any Point in the
     Request Path

One of DPoP's most valuable properties is that possession
verification is stateless and self-contained.  The AS signature
on the token, combined with the proof's self-describing public
key, allows any party in the request path to independently verify
possession using only locally cached AS public keys.

This property is only fully realized when htm/htu are not
blockers.  With them as optional, a security intermediary, an
audit logging system, or a policy enforcement point can inspect
the DPoP binding at any hop without being broken by the URI
transformations that occur naturally in production infrastructure.


----------------------------------------------------------------
6.  The Agentic AI Imperative
----------------------------------------------------------------

6.1  The Emerging Agentic Architecture

The rapid proliferation of AI agent frameworks -- where software
agents act autonomously on behalf of human users, orchestrating
sub-agents across multiple backend services -- represents a
fundamental shift in how OAuth tokens are used in practice.
Agentic commerce protocols being developed by Skyfire, Visa,
Google, and others are building delegated identity frameworks on
top of OAuth 2.0 and JWT tokens, precisely because these are the
established standards for authorization.

In a typical agentic architecture, the identity chain that was
once short and direct becomes long and multi-hop:

                        Human User
                             |
                       delegates to
                             |
                    Orchestrator Agent
                (holds token bound to user identity)
                             |
                          spawns
                   __________|__________
                  |           |         |
             Sub-agent A  Sub-agent B  Sub-agent C
                  |           |         |
             Payment API  Data Service  Commerce API

Each hop in this chain may involve a JWT token carrying the
original human user's identity in the sub claim.  The question
at the heart of DPoP -- is the entity presenting this token the
one it was issued for -- becomes exponentially more important in
this context, and exponentially harder to answer without
sender-constraining mechanisms.


6.2  Why Agentic Architectures Demand Strong Token Binding

Several properties of agentic systems make bearer token theft a
more severe risk than in traditional human-driven flows:

  o  Larger attack surface:  Agents are software processes
     running in cloud environments with tokens frequently cached
     in memory, passed between orchestrator and sub-agents over
     internal networks, and potentially logged by agent
     frameworks.  The number of points at which a token can be
     intercepted or exfiltrated is far greater than in a browser
     session.

  o  Autonomous operation:  Agents operate without real-time
     human oversight.  A stolen token used by a malicious actor
     may go undetected far longer than in an interactive human
     session, allowing more damage before revocation.

  o  High-value operations:  Agentic commerce protocols are
     specifically designed for consequential transactions --
     payments, purchases, data access at scale.  The value of a
     stolen token in this context is substantially higher than in
     typical API access scenarios.

  o  Delegated identity amplification:  An agent acting on
     behalf of a user carries the user's full delegated authority
     within the token's scope.  A rogue agent or compromised
     sub-agent presenting a stolen token can act with the user's
     identity across every service the token authorizes.

These factors collectively make the case that sender-constraining
tokens -- ensuring the token is usable only by the specific agent
instance holding the bound private key -- is not merely desirable
in agentic architectures but essential.


6.3  Agents Are Naturally Suited for DPoP

Unlike human users, for whom key management introduces UX
friction, software agents are ideally positioned to implement
DPoP.  Key generation at agent initialization, secure private key
storage in agent runtime memory or hardware security modules, and
automated proof generation on every request are all natural
operations for automated processes.  There is no UX argument
against DPoP in agentic contexts -- the only barriers are
deployment infrastructure constraints, chief among them URI
rewriting at intermediary layers.


6.4  Agentic Infrastructure is Built on URI-Rewriting Proxies

This is where the htm/htu constraint becomes a critical blocker
for agentic adoption.  Agentic commerce platforms route agent
requests through layered infrastructure:

  o  Payment orchestration layers (Visa, Stripe, etc.) that
     translate external payment URIs to internal processing
     endpoints.

  o  Agent execution platforms (cloud-hosted agent runtimes)
     that proxy requests through service meshes with internal
     URI schemes.

  o  API gateways fronting microservice backends, where the
     agent-visible URI bears no resemblance to the internal
     service path.

  o  Multi-tenant SaaS platforms where tenant routing prefixes
     are stripped or rewritten at the gateway layer.

In every one of these cases, the htu the agent signed -- based
on the URI it was given -- does not match the URI the backend
resource server receives.  Under the current RFC, DPoP is
incompatible with the infrastructure that agentic commerce is
being built on.  This is not a theoretical concern -- it is a
structural incompatibility between the RFC's mandatory request
binding and the layered proxy architecture that production
agentic systems require.


6.5  The Authorization Boundary in Multi-Agent Systems

A further concern specific to agentic architectures is the need
to enforce authorization boundaries between agents.  When an
orchestrator agent delegates a sub-task to a sub-agent, the
sub-agent should be constrained to act only within the scope of
its specific delegation -- not with the full authority of the
original token.

The cnf claim family provides the right primitive for this.  Each
agent instance can hold its own keypair.  The token issued to a
sub-agent can be bound to the sub-agent's specific key via
cnf.jkt, with scope restricted to the delegated operation.  Any
verifier -- API gateway, security intermediary, or backend
service -- can independently confirm that the presenting agent is
the specific instance the token was bound to, without any call
back to the AS or orchestrator.

This is the cnf-based binding model operating exactly as
designed.  But it only works if the proof those sub-agents
generate can traverse the URI-rewriting infrastructure of agentic
platforms.  The mandatory htm/htu requirement prevents this.
Making these claims optional removes the infrastructure barrier
while preserving the cryptographic binding that makes sub-agent
authorization enforceable.


6.6  A Prerequisite for the Next Generation of Delegated
     Identity

The modification proposed here is not merely a pragmatic
fix for existing proxy deployments.  It is a prerequisite for
DPoP to fulfill its role as the token binding standard for the
next generation of delegated identity architectures.  Agentic
commerce protocols are being designed now.  The standards they
adopt will shape the security posture of AI-driven commerce for
years.  If DPoP cannot operate through the infrastructure these
platforms are built on, the ecosystem will adopt weaker
alternatives -- or build fragmented, non-interoperable binding
mechanisms that undermine the goal of a universal standard.

The RFC authors designed DPoP to solve the bearer token problem
at the application layer.  That problem is nowhere more acute
than in agentic systems where tokens carry human identity through
automated, multi-hop, high-value workflows.  This proposal asks
that the standard be made compatible with the infrastructure
those systems run on -- so that DPoP can deliver its security
guarantee precisely where it is most needed.


----------------------------------------------------------------
7.  Addressing Anticipated Objections
----------------------------------------------------------------

7.1  "Removing htm/htu weakens DPoP security"

The core security guarantee of DPoP -- that the token is bound
to a keypair and the presenter must prove private key possession
-- is entirely independent of htm/htu.  As demonstrated in
Section 4.2, every property directly relevant to the fundamental
question ("is this the entity the token was issued to?") is
preserved.  htm/htu address a secondary, narrower threat that is
already substantially mitigated by TLS and existing token claims.


7.2  "The malicious RS relay attack is a real threat"

It is.  But it requires a specific precondition: TLS validation
has failed or been bypassed.  The RFC explicitly requires DPoP
to be used exclusively over HTTPS.  A deployment where TLS is
properly enforced -- which is the only deployment the RFC
contemplates -- is already defended against this attack by the
TLS layer.  htm/htu provide defense-in-depth for a degraded
security posture that the RFC's own requirements prohibit.


7.3  "Deployments can just preserve URIs through their proxies"

This is true for some deployments.  But it requires URI rewriting
to be avoided as a design constraint, which conflicts with
legitimate and common architectural patterns.  Requiring all
deployments to forego URI rewriting in order to use DPoP is an
unreasonable architectural constraint to impose on adopters.  The
RFC should accommodate real-world deployment patterns, not demand
they be restructured.


7.4  "RFC 9421 (HTTP Message Signatures) can handle request
     binding"

Correct -- and this supports the proposed modification.  Request
integrity, including URI and method binding, is the domain of
RFC 9421.  DPoP should own the narrower problem of token
possession proof.  Keeping htm/htu as optional in DPoP and
deferring request integrity to RFC 9421 results in a cleaner
separation of concerns, where each RFC solves its intended
problem without overreaching into the other's domain.


7.5  "Agentic systems should use token exchange per RFC 8693"

Token exchange (RFC 8693) is a valid architectural pattern for
agentic delegation -- an orchestrator exchanging a user token for
a sub-agent-scoped token at the AS.  However, token exchange
addresses the delegation problem, not the possession problem.  A
token obtained via token exchange is still a bearer token unless
it is also DPoP-bound.  The two mechanisms are complementary.
But token exchange requires an AS call on every delegation event,
adds latency, and requires AS support for the exchange grant
type.  It cannot substitute for a possession proof mechanism that
works transparently through the infrastructure.  DPoP with
optional htm/htu solves the possession half of the agentic
security problem in a way that token exchange alone cannot.


----------------------------------------------------------------
8.  Summary of Proposed Changes
----------------------------------------------------------------

The following changes to RFC 9449 are proposed:

  1.  Section 4.2 -- DPoP Proof JWT Syntax:  Reclassify htm and
      htu from MUST to OPTIONAL payload claims.  Add language
      stating: when present, verifiers MUST validate these
      claims; when absent, verifiers MUST NOT reject the proof
      on this basis alone.

  2.  Section 4.3 -- Checking DPoP Proofs:  Update validation
      rules 8 and 9 to be conditional on the presence of htm and
      htu respectively.

  3.  Section 5.1 -- Authorization Server Metadata:  Introduce
      a new metadata field dpop_request_binding_required
      (boolean, default false) allowing an AS to signal that it
      requires htm/htu in proofs issued for its tokens.

  4.  Section 11 -- Security Considerations:  Add a subsection
      documenting the malicious RS relay threat, the role of TLS
      as primary mitigation, and guidance for deployments that
      wish to include htm/htu as defense-in-depth.

  5.  New Section -- Deployment Profiles:  Define two deployment
      profiles: (a) full binding profile (htm + htu present, for
      direct client-to-RS deployments), (b) possession-only
      profile (htm + htu omitted, for proxy-intermediated
      deployments).  Guidance for each topology.


----------------------------------------------------------------
9.  Conclusion
----------------------------------------------------------------

DPoP represents a significant and well-designed advance over
bearer tokens.  Its core mechanism -- binding an access token to
a client keypair via cnf.jkt and requiring a signed proof on
every request -- directly solves the bearer token problem in a
stateless, proxy-transparent, and widely deployable way.

The mandatory htm and htu claims, while addressing a legitimate
secondary threat, impose a deployment constraint that conflicts
with the most common production proxy architecture.  The threat
they address is already substantially mitigated by TLS, existing
token claims, and -- in modern deployments using RFC 9396 -- by
AS-signed RAR location binding that is structurally stronger
than htu in a DPoP proof.  The working group's own Transaction
Tokens draft (draft-ietf-oauth-transaction-tokens) implicitly
acknowledges this barrier by introducing significant
architectural complexity to route around it, rather than
addressing the root cause.

This incompatibility is not merely a concern for existing
infrastructure.  The emergence of agentic AI architectures and
agentic commerce protocols -- where software agents act on behalf
of human users across layered, URI-rewriting service meshes --
makes the proposed modification urgent.  These are precisely the
deployments where sender-constraining tokens matter most, and
precisely the deployments where mandatory htm/htu makes DPoP
unworkable.  If the standard is not amended, the ecosystem
building agentic commerce infrastructure will be forced to adopt
weaker alternatives or fragmented non-interoperable solutions.

Reclassifying htm and htu as optional claims, with their
inclusion remaining recommended for direct-connection deployments
without RAR, would preserve all meaningful security properties
of DPoP while removing an unnecessary barrier to adoption.  The
result would be a standard that works across the full spectrum
of production deployment patterns -- from existing API
architectures to the next generation of agentic delegated
identity systems -- enabling the ecosystem of security tools,
API gateways, and intermediaries to enforce DPoP possession
verification universally.

The authors of RFC 9449 are to be commended for the elegance of
the core DPoP design.  This proposal asks only that the
standard's applicability match the ambition of its security
goals.


----------------------------------------------------------------
References
----------------------------------------------------------------

[RFC 9449]  Fett, D., Campbell, B., Bradley, J., Lodderstedt,
            T., Jones, M., Waite, D., "OAuth 2.0 Demonstrating
            Proof of Possession (DPoP)", RFC 9449,
            September 2023.

[RFC 7800]  Jones, M., Bradley, J., Sakimura, N., "Proof-of-
            Possession Key Semantics for JSON Web Tokens
            (JWTs)", RFC 7800, April 2016.

[RFC 8705]  Campbell, B., Bradley, J., Sakimura, N.,
            Lodderstedt, T., "OAuth 2.0 Mutual-TLS Client
            Authentication and Certificate-Bound Access
            Tokens", RFC 8705, February 2020.

[RFC 9396]  Lodderstedt, T., Richer, J., Campbell, B.,
            "OAuth 2.0 Rich Authorization Requests",
            RFC 9396, May 2023.

[RFC 9421]  Backman, A., Richer, J., Sporny, M., "HTTP Message
            Signatures", RFC 9421, February 2024.

[RFC 8693]  Jones, M., Nadalin, A., Campbell, B., Bradley, J.,
            Mortimore, C., "OAuth 2.0 Token Exchange",
            RFC 8693, January 2020.

[RFC 6749]  Hardt, D., "The OAuth 2.0 Authorization
            Framework", RFC 6749, October 2012.

[RFC 6750]  Jones, M., Hardt, D., "The OAuth 2.0 Authorization
            Framework: Bearer Token Usage", RFC 6750,
            October 2012.

[TXN-TOKENS] Tulshibagwale, A., Fletcher, G., Kasselman, P.,
            "Transaction Tokens",
            draft-ietf-oauth-transaction-tokens-08,
            March 2026.

================================================================