Presenter Rebinding for OAuth 2.0 Proof-of-Possession Tokens

Internet-Draft	OAuth Presenter Rebinding	August 2026
McGuinness	Expires 8 February 2027	[Page]

Abstract

A proof-of-possession (PoP) token can normally be presented only by a party that holds the token's confirmation key. This prevents an intended recipient from presenting the token when a token handoff is authorized but transferring the confirmation private key is unacceptable. This document defines a one-hop presenter-rebinding mechanism for OAuth 2.0 Token Exchange. The holder of a JWT Source Token's confirmation key signs a Presenter Rebinding Assertion (PRA) that authorizes a recipient key to present that exact token at a named authorization server. The recipient presents the Source Token and PRA with a DPoP proof of its own key. After applying normal authorization policy, the authorization server issues an access token sender-constrained to the recipient key, and no refresh token. Further presenter changes use another exchange rather than an offline delegation chain.¶

1. Introduction

Proof-of-possession (PoP) binding transforms a bearer security token into one that only its intended holder can use. A JWT can carry a confirmation (cnf) claim [RFC7800] identifying a key, and the presenter proves possession of that key when using the token. OpenID Connect Key Binding [OpenID.KeyBinding] applies this model to ID Tokens, and JWT access tokens [RFC9068] and Token Exchange [RFC8693] outputs can carry cnf as well.¶

PoP binding creates a gap whenever the party that should present a token is not the party the token is bound to. This arises in more than one place:¶

In cross-client delegation [I-D.mcguinness-oauth-cross-client-delegation], a Delegate presents an Identity Assertion issued to and key-bound to an Initiator. The Delegate does not hold the Initiator's key.¶
In presenter-transition and rebind flows under the OAuth Actor Profile [I-D.mcguinness-oauth-actor-profile], a token bound to one presenter has to be continued by another.¶
More generally, any Token Exchange in which the requesting party differs from the party a key-bound subject_token is bound to faces the same gap, whatever profile governs the exchange.¶

Two unsatisfactory options are common today. Removing the binding turns the token into a replayable bearer credential and discards the protection PoP binding provides. Sharing the confirmation private key defeats key isolation and is often impossible. This document defines a third option that requires neither.¶

This document defines a one-hop cryptographic authorization for changing the presenter. The holder of the Source Token's confirmation key signs a Presenter Rebinding Assertion (PRA) that binds together the exact Source Token, a recipient key, and one authorization server. The recipient submits the Source Token and PRA in a Token Exchange request and proves possession of the recipient key with DPoP [RFC9449]. The authorization server validates both signatures and applies all ordinary Token Exchange, client, actor, and deployment policy before issuing a token bound to the recipient key.¶

The PRA answers one question: did the Source Token's confirmation-key holder authorize this recipient key to present this token at this authorization server? It does not identify the party controlling either key, grant scopes or resources, or establish that an actor is authorized to act for a subject. Those decisions remain with the applicable OAuth profile and authorization-server policy.¶

Presenter rebinding is deliberately one hop. If the recipient later needs to authorize another presenter, it first obtains a new token bound to its own key and creates a new PRA for that token. This keeps each proof path constant in size and ensures that the authorization server evaluates policy at every presenter transition. Offline, recursively signed delegation chains are out of scope.¶

1.1. Requirements and Scope

This specification applies to a Source Token that:¶

is a JWT whose exact encoded value is available to both the confirmation-key holder and the authorization server;¶
is accepted as a subject_token in OAuth 2.0 Token Exchange; and¶
carries an RFC 7800 cnf claim that resolves to exactly one asymmetric signing key as specified in Section 4.4.¶

The recipient proves possession with DPoP, and the recipient key is the key proven by the request's single DPoP proof, as specified in Section 6.1. The exchange issues a DPoP-bound OAuth access token, as specified in Section 6.2. Symmetric confirmation keys, bearer Source Tokens, non-JWT Source Tokens, mutual-TLS presenter rebinding, issued token types other than an access token, refresh tokens, use outside Token Exchange, and offline multi-hop delegation are out of scope. A future specification can define another profile without changing the one-hop security invariant defined here.¶

This document changes nothing for direct presentation. A party that holds the Source Token's confirmation key presents the token under its existing profile and does not use a PRA.¶

Presenter rebinding is opt-in. An authorization server MUST accept a PRA only under an applicable profile and local policy that explicitly permit presenter rebinding for the Source Token type and request context.¶

The following are also out of scope:¶

how the confirmation-key holder decides to authorize the handoff, including user interaction or consent;¶
how the confirmation-key holder authenticates the intended recipient key, except for the requirements in Section 9.3;¶
establishing trust in the Source Token issuer; and¶
the policy for authenticating or authorizing the clients, actors, subject, requested resources, or requested scopes.¶

4. Presenter Rebinding Assertion

A Presenter Rebinding Assertion is a JWT [RFC7519] secured as a JWS [RFC7515].¶

4.1. JOSE Header

The protected JOSE header MUST contain:¶

typ: the explicit type pra+jwt (Section 11.1). As permitted by [RFC7515], Section 4.1.9, the application/ prefix is omitted. An authorization server MUST reject a JWT presented as a PRA whose typ is not pra+jwt.¶
alg: an asymmetric digital-signature algorithm accepted by the authorization server and appropriate for the key in jwk. An authorization server MUST reject none, symmetric algorithms, algorithms outside its allowlist, and an algorithm inconsistent with the key type. An authorization server advertises the algorithms it accepts as specified in Section 6.4.¶
jwk: the public Source Confirmation Key, represented as an asymmetric JWK [RFC7517] containing only public parameters. An authorization server MUST reject a jwk containing private-key material.¶

The jwk is not trusted merely because it appears in the header. Its JWK SHA-256 Thumbprint MUST match the key identifier derived from the validated Source Token as specified in Section 5.¶

An authorization server MUST resolve the PRA signing key only from the jwk header parameter. It MUST NOT dereference a jku or x5u header parameter and MUST NOT resolve the signing key from x5c or kid. Dereferencing a presenter-supplied URI exposes the authorization server to request forgery and serves no purpose here, because the signing key is fully determined by the validated Source Token's cnf claim.¶

4.2. Claims

A PRA MUST contain:¶

sth (Source Token hash): the base64url encoding without padding of the SHA-256 digest of the ASCII octets of the exact encoded Source Token value. This is the construction used by the DPoP ath claim ([RFC9449], Section 4.2), applied to the Source Token. The value is computed before transport encoding. For Token Exchange, it is computed over the subject_token value before application/x-www-form-urlencoded encoding, and the authorization server computes it after form decoding. It MUST NOT be computed over decoded claims, reserialized JSON, or a canonicalized representation.¶
stt (Source Token type): the token type identifier the Recipient Presenter will send as subject_token_type. Its value MUST be one case-sensitive string. sth binds the Source Token's octets but not the profile under which they are interpreted, and one JWT can be acceptable under more than one token type identifier. Without stt a Recipient Presenter could present the authorized token under a token type the Original Presenter did not intend, and have it validated under different rules. This is carried as a claim rather than folded into the sth digest so that it remains independently inspectable and sth remains the construction defined by [RFC9449], Section 4.2.¶
cnf: the Recipient Presenter key. It MUST be a JSON object containing a single member, jkt, whose value is the JWK SHA-256 Thumbprint [RFC7638] of the Recipient Presenter's asymmetric DPoP public key. An authorization server MUST reject a PRA whose cnf contains any other member.¶
aud: the authorization server issuer identifier. Its value MUST be one case-sensitive string, not an array. The value MUST exactly equal the issuer identifier by which the authorization server identifies itself. It is distinct from the Token Exchange audience request parameter and the DPoP htu claim.¶
iat: the time at which the PRA was issued, as a NumericDate [RFC7519].¶
exp: the expiration time, as a NumericDate [RFC7519]. A PRA SHOULD be short-lived. exp bounds when the exchange may occur; it does not bound the lifetime of the token the exchange issues, as discussed in Section 9.5.¶

A PRA MAY contain:¶

jti: an identifier for audit, profile-defined one-time use, or profile-defined revocation. Reuse of a PRA jti is not by itself a replay because a PRA authorizes a key and can be used more than once during its validity interval unless a profile says otherwise.¶
presenter_limits: a JSON object restricting the Token Exchange result as specified in Section 4.3. It has one defined member, audience, which an authorization server supporting presenter rebinding MUST implement. An authorization server MUST reject a PRA whose presenter_limits carries any other member.¶

Other claims MUST NOT be interpreted as identifying the Original Presenter or granting authority unless an applicable profile explicitly defines that meaning and its validation rules.¶

An authorization server MUST configure a maximum PRA lifetime. Writing now for its current time and skew for the clock skew it permits, it MUST reject a PRA unless all of the following hold:¶

iat <= now + skew
exp >  now - skew
exp >  iat
exp - iat <= maximum lifetime

Stating these comparisons explicitly avoids the interoperability differences that "satisfies temporal-validity policy" would otherwise leave to each implementation.¶

4.3. Presenter Limits

presenter_limits is an optional restriction on the result of the one Token Exchange request. It is an upper bound, not a grant. Successful PRA validation never overrides the Source Token's authorization rules, an administered relationship, a may_act claim, client or actor authentication, user authorization, or authorization-server policy.¶

The object can contain:¶

audience: an array of case-sensitive Token Exchange audience strings. A requested or issued audience is within this limit when it is a member of the array.¶

When audience is absent, the PRA places no restriction on the audiences the exchange may produce.¶

When audience is present, the Token Exchange audience request parameter MUST be present in the request, and every value it carries MUST be within the limit. An authorization server MUST reject a request that omits audience when the PRA limits it. Requiring the requester to state what it wants removes the case in which an authorization-server default, rather than the request, determines the result for a limited dimension. A Recipient Presenter holds the PRA and can therefore read each limit it must request within.¶

The authorization server MAY issue a result narrower than both the request and the Presenter Limits. It MUST NOT issue a result broader than either.¶

Together these rules confine the issued token by construction: the request is explicit for every limited dimension, the request is within the limit, and the issued authorization is within the request. An authorization server whose issuance cannot produce an audience outside the request therefore satisfies this section by comparing the request against the limit, at the point where it already validates audience. Section 9.8 states the requirement that remains on the issued authorization.¶

audience is the only dimension this specification bounds. It was chosen because it names where the issued token can be used, which is the constraint an Original Presenter is best placed to decide for a particular handoff, and because a single dimension cannot combine with another to authorize more than it appears to. [RFC8693], Section 2.1.1 makes the requested rights of a token "the Cartesian product of all the scopes at all the target services", so a limit spanning several dimensions permits every combination of their values rather than the pairing its author had in mind.¶

Resources, scopes, and authorization_details are therefore bounded by the authorization server's own policy for the exchange, not by the PRA. A profile that needs the Original Presenter to bound one of them cryptographically has to define the containment rule for that dimension, the comparison it uses, and its behavior when containment cannot be determined, and in doing so updates this document (Section 8). Section 9.8 states why this specification does not attempt a generic rule.¶

4.4. Confirmation-Key Identification

The authorization server reduces the validated Source Token's cnf claim to one expected JWK SHA-256 Thumbprint. A cnf containing jkt supplies that value directly. A cnf containing a public asymmetric jwk supplies the value obtained by applying [RFC7638] with SHA-256.¶

The authorization server MUST reject presenter rebinding when the Source Token's cnf identifies a symmetric key, identifies more than one key, cannot be reduced to exactly one asymmetric public signing key or SHA-256 thumbprint, or uses an unsupported confirmation method. The authorization server MUST NOT resolve the Source Confirmation Key from untrusted material supplied by the Recipient Presenter except for a public jwk whose thumbprint is compared with a trusted jkt from the validated Source Token.¶

4.5. Example

The following abbreviated PRA authorizes K_recipient to present one Source Token at https://idp.example and limits the exchange result to one target audience.¶

{
  "typ": "pra+jwt",
  "alg": "ES256",
  "jwk": { "kty": "EC", "crv": "P-256", "x": "...", "y": "..." }
}

Figure 1: PRA protected header

{
  "sth": "0Ei...source-token-hash...",
  "stt": "urn:ietf:params:oauth:token-type:id_token",
  "cnf": { "jkt": "0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I" },
  "aud": "https://idp.example",
  "presenter_limits": {
    "audience": ["https://gateway.example"]
  },
  "iat": 1785974400,
  "exp": 1785974700,
  "jti": "b1f0c8a2-9d3e-4a2b-9f1c-8e7d6c5b4a30"
}

Figure 2: PRA claims

5. Presentation and Validation

The Recipient Presenter sends the Source Token as the Token Exchange subject_token, the compact PRA in the presenter_rebinding parameter, and a DPoP proof in the DPoP HTTP header on the same request.¶

The authorization server MUST perform the following checks. Failure of any required check means that presenter rebinding is not authorized. Every check MUST be performed against a single request: the Source Token, PRA, DPoP proof, and Token Exchange parameters MUST all be taken from the same HTTP request, and the authorization server MUST NOT combine artifacts drawn from different requests.¶

Confirm that an applicable profile and local policy permit presenter rebinding for the Source Token type and request context.¶
Validate the Source Token according to its token type and profile, including its cryptographic protection, issuer, audience, temporal validity, and every check not explicitly replaced by the applicable profile. Reduce its cnf to exactly one expected Source Confirmation Key thumbprint per Section 4.4.¶
Parse the PRA without accepting duplicate JSON member names. Confirm that the protected header contains typ, alg, and a public jwk as required by Section 4.1. Compute the header key's JWK SHA-256 Thumbprint and confirm that it equals the expected Source Confirmation Key thumbprint. Verify the PRA signature with that header key and accepted alg.¶
Confirm that sth equals the value defined in Section 4.2, computed over the subject_token parameter after form decoding, that stt exactly equals the request's subject_token_type, that aud exactly identifies the authorization server, and that iat and exp satisfy temporal-validity, clock-skew, and maximum-lifetime policy. Apply jti replay or revocation state only when required by an applicable profile or local policy.¶
Confirm that the PRA cnf contains only jkt and that its value is syntactically valid. Validate the DPoP proof carried on this request according to [RFC9449], including its signature, typ, alg, jwk, jti, htm, htu, iat, and nonce when required. Confirm that the DPoP public key's JWK SHA-256 Thumbprint exactly equals the PRA cnf.jkt.¶
Validate the Token Exchange request, client and actor authentication, delegation relationship, and requested authorization under [RFC8693], the applicable profile, and local policy. Confirm that the request carries a parameter for every dimension the PRA limits, and apply Presenter Limits per Section 4.3 to those request values and to the resulting authorization.¶

Step 2 validates the Source Token under the token type the requester declared, because the PRA is not parsed until step 3. Step 4 then confirms that the Original Presenter authorized that type. A request whose subject_token_type does not equal stt therefore fails at step 4 even though the Source Token validated under the declared type, and the exchange is not authorized.¶

On success, the Source Token's proof-of-possession requirement for this Token Exchange presentation is satisfied by the holder of the PRA Recipient Presenter key. This result establishes control of an authorized presentation key. It does not establish the presenter's application-level identity or independently authorize the exchange.¶

6. Use with OAuth 2.0 Token Exchange

6.1. Request

This specification defines the following Token Exchange parameter:¶

presenter_rebinding:: The compact JWS serialization of one PRA rooted in the subject_token's confirmation key. Its presence is what invokes this mechanism. It MUST NOT occur more than once, and an authorization server MUST reject a request carrying it more than once rather than selecting one occurrence.¶

The subject_token is the Source Token, and the request's subject_token_type MUST equal the PRA stt claim. The PRA aud MUST be the authorization server's issuer identifier; it is not the token endpoint URI, the DPoP htu, or the requested token audience.¶

The requester MUST send a DPoP proof on the same request, and the key proven by that DPoP proof MUST be the key identified by the PRA cnf.jkt. [RFC9449] permits at most one DPoP proof per request, and at the token endpoint that proof also determines the key to which the authorization server sender-constrains the issued token. A requester using this mechanism therefore uses the Recipient Presenter key as its DPoP key for this request; it cannot present one key as the Recipient Presenter and a different key for sender-constraining. An authorization server MUST reject a request whose DPoP proof is for a key other than the PRA cnf.jkt.¶

This constrains only key control on this request. It does not merge the Recipient Presenter and OAuth client roles, and client authentication remains an independent input per Section 9.2.¶

6.2. Processing and Output

The authorization server validates the request according to Section 5. If it issues a token, the authorization carried by that token MUST be within both normal authorization policy and any Presenter Limits.¶

The token issued by a presenter-rebinding exchange MUST be an OAuth 2.0 access token, and the response MUST carry token_type of DPoP as specified in [RFC9449], Section 5. [RFC8693] permits other issued token types, and [RFC9449] defines an interoperable sender-constrained output only for access tokens; this document therefore defines the base case only. An authorization server MUST reject a request whose requested_token_type it would satisfy with any other token type, unless an applicable profile defines how the Recipient Presenter key binding is represented in that token type and how a verifier checks it. [RFC8693] makes requested_token_type OPTIONAL and leaves the default to the authorization server; when it is absent from a presenter-rebinding request, the authorization server MUST treat the request as one for an access token.¶

The authorization server MUST sender-constrain that access token to the PRA Recipient Presenter key. Because that key is also the key proven by the request's DPoP proof (Section 6.1), this is the binding ordinary DPoP token-endpoint processing produces for an access token. Sender-constraining completes the presenter transition: the issued token has one current confirmation key, and a subsequent transition requires a new PRA signed by that key over the new token.¶

An authorization server MUST NOT issue a bearer token in response to a request that uses presenter rebinding. Doing so would convert a key-bound Source Token into an unbound credential and defeat both the Source Token's confirmation requirement and the one-hop invariant in Section 9.9. If the authorization server is unwilling to sender-constrain the token it would issue, it MUST reject the request rather than issue an unbound token.¶

An authorization server MUST NOT issue a refresh token in response to a request that uses presenter rebinding. [RFC9449], Section 5 does not bind a refresh token issued to a confidential client to the DPoP proof public key, because such a refresh token is already sender-constrained by client authentication. A Recipient Presenter that authenticates as a confidential client would therefore hold a credential derived from the Source Token that is controlled by its client credentials rather than by the Recipient Presenter key, and could obtain further tokens after the PRA expired without any presenter-key transition having been authorized; see Section 9.5. A profile that needs refreshable output has to define how refresh preserves the key transition.¶

An applicable delegation profile MAY allow the authorization server to record the Original Presenter as a prior actor in the issued token's act claim [RFC8693]. It can do so only when the profile independently maps the Source Confirmation Key to an authenticated actor identity and authorizes that actor relationship. A key thumbprint is not an actor identity, and a valid PRA alone is insufficient to create an act entry.¶

6.3. Errors

Errors are returned according to [RFC8693], Section 2.2.2 and [RFC6749], Section 5.2. A missing or invalid DPoP proof is a DPoP error, not a presenter-rebinding error, and takes the code [RFC9449] assigns it. When presenter rebinding is required, the error codes are:¶

Table 1
Condition	Error code
Missing, malformed, or otherwise invalid DPoP proof	`invalid_dpop_proof` ([RFC9449], Section 5)
DPoP nonce required or stale	`use_dpop_nonce`, per [RFC9449], Section 8
Valid DPoP proof whose key is not the PRA `cnf.jkt`	`invalid_request`
Missing or invalid `presenter_rebinding`, or more than one occurrence	`invalid_request`
PRA validation failure under Section 5	`invalid_request`
`stt` not equal to `subject_token_type`	`invalid_request`
Request omits a parameter for which the PRA carries a limit (Section 4.3)	`invalid_request`
Requested `scope` or granted scope outside a `scope` limit	`invalid_request`
Requested or issued `audience` or `resource` outside its limit	`invalid_target`
`requested_token_type` the authorization server will not sender-constrain (Section 6.2)	`invalid_request`

Error descriptions SHOULD NOT disclose which key, relationship, or policy input caused rejection.¶

The error codes themselves can also disclose. invalid_target is returned only for a request that could otherwise have succeeded, so distinguishing it from invalid_request tells the requester that the presented tokens and the underlying relationship were acceptable. An applicable profile MAY therefore require an authorization server to return invalid_request in place of invalid_target where that distinction would disclose the existence of an administered relationship or other confidential policy state. A profile doing so accepts reduced target diagnostics in exchange for non-disclosure. The table above applies where no such requirement is in force.¶

6.4. Authorization Server Metadata

An authorization server advertises support in its metadata [RFC8414] with the following OPTIONAL members:¶

presenter_rebinding_supported:: Boolean value indicating support for the presenter_rebinding Token Exchange parameter and the validation rules in this document. The value is true when supported. If omitted, support is not indicated. This metadata does not guarantee that any particular Source Token, algorithm, client, actor, or request will be accepted.¶
presenter_rebinding_signing_alg_values_supported:: JSON array containing a list of the JWS alg values supported by the authorization server for the PRA signature. The array MUST NOT contain none or a symmetric algorithm. An authorization server that supports presenter rebinding SHOULD include this member, because Section 4.1 requires it to reject algorithms outside its allowlist and Section 6.3 discourages disclosing the reason for rejection. If omitted, an Original Presenter has no discovery mechanism for the accepted algorithms and must obtain them out of band.¶

8. Design Invariants

This document defines no extension points. Every part of the mechanism is fixed: the Source Token is a JWT, the confirmation method is jkt, the proof mechanism is DPoP, aud is an authorization server issuer identifier, the output is a DPoP-bound access token, presenter_limits bounds audience and nothing else, and the only binding is the Token Exchange binding of Section 6. Widening any of them means overriding a normative requirement here, so a specification that does so updates this document rather than extending it. Section 1.1 places those cases outside this document's scope; it does not reserve them against a future specification that takes them on deliberately.¶

Fixing the mechanism this narrowly is a deliberate trade. An implementer can build the whole of it without deciding which optional pieces to support, and two independent implementations have nothing to negotiate. The cost is that growth requires revising this document, which is the right cost while no second deployment exists to tell us which way it should grow.¶

Any specification that revises this document MUST preserve each of the following invariants. A specification that changes one of them is a different protocol and requires its own validation, revocation, privacy, and resource-exhaustion analysis. Each invariant is stated normatively in the section referenced beside it; the list below summarizes those requirements and does not restate them, and the referenced section governs.¶

One hop. A PRA authorizes one presenter transition, and is never nested, chained, or read as authorizing another PRA (Section 9.9).¶
One authorization server. A PRA names exactly one authorization server in aud, as one case-sensitive string, and is valid only there (Section 4.2).¶
Exact token binding. A PRA authorizes presentation of the one Source Token whose encoded octets sth covers, read under the one token type stt names, and of no other token and no other type (Section 4.2).¶
No presenter-chosen signing key. The PRA signing key is determined by the validated Source Token's cnf claim, and a Recipient Presenter cannot influence which key verifies the PRA (Section 4.4).¶
One Recipient Presenter key, proven on the request. A PRA identifies exactly one asymmetric Recipient Presenter key, and control of that key is proven on the same request that carries the PRA (Section 6.1).¶
Limits narrow only. Presenter Limits and any extension to them are upper bounds; they never grant authority, and their omission is never permission (Section 9.8).¶

9. Security Considerations

The OAuth 2.0 Security Best Current Practice [RFC9700] and JWT Best Current Practices [RFC8725] apply in addition to this section.¶

9.1. Explicit Acceptance of Rebinding

Key binding ordinarily assures a verifier that the presenter controls the key selected when the token was issued. Presenter rebinding deliberately permits a different key to satisfy that requirement for one Token Exchange presentation. This is an authorization-semantic change, not a generic consequence of RFC 7800. Authorization servers MUST opt in for each applicable Source Token profile and request context and MUST continue to enforce issuer and deployment policy.¶

9.2. Separation of Key Control, Identity, and Authority

The Source Token authenticates its issuer and establishes the Source Confirmation Key. The PRA proves authorization from that key to the Recipient Presenter key. DPoP proves control of the Recipient Presenter key on the request. None of those facts alone identifies the party controlling a key or authorizes an OAuth delegation relationship. Client authentication, actor authentication, administered relationships, may_act, consent, and authorization-server policy remain independent and conjunctive inputs.¶

9.3. Recipient Key Authentication

Before signing a PRA, the Original Presenter MUST obtain the intended Recipient Presenter's JWK or thumbprint through an authenticated, integrity-protected process providing the assurance required by the application. If an attacker substitutes its own key before signature, the resulting PRA validly authorizes that attacker key. A consuming profile MUST define the key-distribution and authentication process or identify the deployment mechanism that supplies it.¶

9.4. Replay and Freshness

A captured Source Token and PRA cannot be used without control of the Recipient Presenter key. Binding the PRA to the exact Source Token, one authorization server, one Recipient Presenter key, and a short validity interval limits replay. DPoP provides per-request replay protection through its jti, iat, request target, method, and nonce when used.¶

A PRA is not one-time-use by default. A deployment that requires one-time use needs atomic replay-cache processing and retry semantics keyed by jti; such a deployment requires jti by policy. Offline revocation of a PRA is unavailable unless a profile defines a lookup mechanism, so short lifetimes are the primary control.¶

This has an aggregate consequence that Original Presenters need to account for. Presenter Limits bound the result of one Token Exchange request, not the total authorization obtainable from one PRA. Until the PRA expires, the Recipient Presenter can repeat the exchange without limit, and each exchange can select any nonempty subset of the permitted audiences and request whatever scopes and resources the authorization server's own policy allows. One PRA limited to three audiences therefore authorizes an unbounded number of tokens across those three audiences, not one token and not three.¶

Presenter Limits cannot express a single-use restriction, and no authorization server check derives one from them. A deployment that needs exactly one exchange requires the profile-defined one-time-use processing described above. Absent that, an Original Presenter SHOULD keep the PRA lifetime close to the time the Recipient Presenter needs to make its request.¶

9.5. Derived Tokens and PRA Lifetime

A PRA authorizes one exchange; it does not govern what the resulting credential can do afterwards. exp bounds the interval during which the exchange may occur and has no relationship to the lifetime of the token the exchange issues. A five-minute PRA can produce an access token valid for far longer. The lifetime of that token is determined by authorization-server policy and the applicable profile, which SHOULD account for the fact that the token continues to carry authorization derived from the Source Token after both the PRA and the Source Token have expired.¶

The prohibition on refresh tokens in Section 6.2 follows from the same concern in a sharper form. [RFC9449], Section 5 deliberately does not bind a refresh token issued to a confidential client to the DPoP proof public key, because it is already sender-constrained by that client's credentials. A Recipient Presenter authenticating with a client assertion is such a client. Were a refresh token issued here, the Recipient Presenter would hold a long-lived credential derived from another party's key-bound token whose control rests on its own client credentials rather than on the Recipient Presenter key, and it could keep minting tokens after the PRA expired. No presenter-key transition would have been authorized for any of them, and the authorization server would never re-evaluate the handoff. This is the one-hop invariant of Section 9.9 failing by a route that adds no assertion at all.¶

9.6. Request Binding

PRA aud and DPoP request binding provide different protections. aud expresses authorization for one authorization server. DPoP htu and htm bind proof of the Recipient Presenter key to one HTTP target and method. Both MUST be checked.¶

DPoP does not cover the HTTP request body. The authorization server MUST process the Source Token, PRA, and Token Exchange parameters from the same TLS-protected request on which it validates DPoP. Presenter Limits cryptographically express upper bounds selected by the Original Presenter, but normal TLS and request processing remain necessary to prevent parameter mixing.¶

9.7. Token and Key Substitution

The sth claim prevents a PRA created for one Source Token from being combined with another. Matching the PRA header jwk thumbprint to the validated Source Token cnf prevents a Recipient Presenter from choosing the PRA signing key. Matching PRA cnf.jkt to the DPoP key prevents substitution of the current presenter proof.¶

Original Presenters SHOULD use confirmation keys dedicated to key-bound tokens. Signing APIs MUST bind the pra+jwt type and intended operation so that an attacker cannot use a generic signing oracle to obtain a PRA.¶

9.8. Presenter Limits Are Not Grants

Presenter Limits only narrow authorization. An authorization server MUST apply all other authorization inputs independently and MUST NOT treat omission of a limit as permission.¶

A present limit is an input to the computation that produces the granted authorization, alongside the request, the Source Token's authorization, and local policy. It is not a check appended after issuance. This is why Section 4.3 rejects a request that omits a parameter for a limited dimension rather than defaulting it: a default computed without the limit as an input can exceed it, and a server that discovers this only by inspecting the finished token has already done the work twice. The authorization placed in the issued token MUST NOT exceed a present limit, whatever other input would otherwise have produced a broader result.¶

An unrecognized member fails closed rather than open. Section 4.2 requires an authorization server to reject a PRA whose presenter_limits carries any member other than audience, so a limit an authorization server cannot enforce is never silently ignored.¶

This specification bounds one dimension because a bound is only safe when the comparison that enforces it is fully defined. Resource indicators, scope values, and authorization_details types do not share one such comparison: [RFC8707] URIs admit more than one plausible containment rule, and arbitrary authorization-detail types share none at all. A specification adding a dimension must define its comparison and must fail closed when containment cannot be determined, which is why Section 8 treats such an addition as an update to this document rather than an extension of it.¶

9.9. Subsequent Presenter Transitions

One hop is a security boundary, not a simplification. Every presenter transition past the first would occur offline, between parties, with no authorization server in the path: authority granted for one handoff would propagate to parties the authorization server never evaluated, at a time it could not observe, under a policy that may have changed or been revoked since. Requiring each transition to be an exchange means the authorization server decides every time who may present what, and can refuse.¶

The Recipient Presenter cannot extend a PRA or sign a PRA for the original Source Token because it does not hold the Source Confirmation Key. A later transition requires a successful exchange yielding a new token bound to the current presenter's key. Keeping the proof path to one hop also keeps it constant in size and avoids recursive parsing and cycle handling, but those are consequences of the boundary rather than the reason for it.¶

The proof path is bounded; the actor history is not. Each transition that a profile authorizes can add one act entry to the issued token per Section 6.2, so repeated presenter transitions grow that nesting one level at a time even though no PRA is ever nested. This specification does not bound act depth, detect cycles among prior actors, or define disclosure rules for actor history. A profile that authorizes actor recording MUST specify those limits; see also the OAuth Actor Profile for Delegation [I-D.mcguinness-oauth-actor-profile].¶

Implementations MUST NOT accept a nested PRA or interpret a PRA as authorizing another PRA. A specification that defines offline multi-hop delegation is a different protocol and requires separate validation, revocation, privacy, and resource-exhaustion analysis.¶

9.10. Downgrade and Confusion

An authorization server MUST NOT accept bearer presentation of a key-bound Source Token because a PRA is absent or invalid. The Source Token requires either direct proof of its confirmation key under its own profile or a valid PRA and a matching Recipient Presenter DPoP proof under this specification.¶

The output side requires the same discipline. Issuing a bearer token from a successful presenter-rebinding exchange downgrades the Source Token's key binding one step later: the Recipient Presenter obtains a replayable credential derived from a token that could only ever be presented with a key. Section 6.2 therefore requires the issued token to be sender-constrained to the Recipient Presenter key and requires the authorization server to reject the request rather than issue an unbound token.¶

The explicit pra+jwt type and mutually exclusive validation rules distinguish a PRA from a Source Token, access token, ID Token, client assertion, and DPoP proof. An authorization server MUST validate each artifact only under the rules for its protocol position.¶

9.11. Trust Domains

The authorization server can validate a PRA only if it can validate the Source Token and obtain its confirmation-key identifier without trusting presenter-supplied key resolution. Across trust domains, the authorization server must trust the Source Token issuer, token profile, and confirmation method. Establishing that trust is outside this specification.¶

11. IANA Considerations

11.1. Media Type Registration

This document requests registration of the following media type in the "Media Types" registry, following the procedures of [RFC6838], for use as the typ JOSE header value of a Presenter Rebinding Assertion. As permitted by [RFC7515], Section 4.1.9, the application/ prefix is omitted in the typ value.¶

Type name: application¶
Subtype name: pra+jwt¶
Required parameters: N/A¶
Optional parameters: N/A¶
Encoding considerations: binary; a PRA is a JWT represented as base64url-encoded values separated by periods¶
Security considerations: See Section 9 and Section 11 of [RFC7519]¶
Interoperability considerations: N/A¶
Published specification: this document¶
Applications that use this media type: OAuth applications rebinding presentation of proof-of-possession tokens¶
Fragment identifier considerations: N/A¶
Additional information: Magic number(s): N/A; File extension(s): N/A; Macintosh file type code(s): N/A¶
Person and email address to contact for further information: Karl McGuinness, public@karlmcguinness.com¶
Intended usage: COMMON¶
Restrictions on usage: N/A¶
Author: Karl McGuinness¶
Change controller: IETF¶
Provisional registration: No¶

11.2. JSON Web Token Claims Registration

This document requests registration of the following claims in the "JSON Web Token Claims" registry established by [RFC7519]. The cnf, aud, iat, exp, and jti claims are already registered and are used without new registration.¶

Claim Name: sth¶
Claim Description: Source Token Hash; base64url-encoded SHA-256 digest of the token whose presenter is being rebound¶
Change Controller: IESG¶
Specification Document: Section 4.2 of this document¶

and:¶

Claim Name: stt¶
Claim Description: Source Token Type; token type identifier under which the token whose presenter is being rebound is presented¶
Change Controller: IESG¶
Specification Document: Section 4.2 of this document¶

and:¶

Claim Name: presenter_limits¶
Claim Description: Upper bounds on authorization resulting from a presenter-rebound Token Exchange¶
Change Controller: IESG¶
Specification Document: Section 4.2 and Section 4.3 of this document¶

11.3. OAuth Parameters Registration

This document requests registration of the following value in the "OAuth Parameters" registry established by [RFC6749].¶

Parameter name: presenter_rebinding¶
Parameter usage location: token request¶
Change Controller: IESG¶
Specification Document: Section 6.1 of this document¶

11.4. OAuth Authorization Server Metadata Registration

This document requests registration of the following values in the "OAuth Authorization Server Metadata" registry established by [RFC8414].¶

Metadata Name: presenter_rebinding_supported¶
Metadata Description: Boolean indicating authorization server support for presenter rebinding in OAuth 2.0 Token Exchange¶
Change Controller: IESG¶
Specification Document: Section 6.4 of this document¶

and:¶

Metadata Name: presenter_rebinding_signing_alg_values_supported¶
Metadata Description: JSON array of JWS alg values supported by the authorization server for Presenter Rebinding Assertion signatures¶
Change Controller: IESG¶
Specification Document: Section 6.4 of this document¶

12. References

12.1. Normative References

[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC6749]: Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/rfc/rfc6749>.
[RFC6838]: Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/rfc/rfc6838>.
[RFC7515]: Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/rfc/rfc7515>.
[RFC7517]: Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, <https://www.rfc-editor.org/rfc/rfc7517>.
[RFC7519]: Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/rfc/rfc7519>.
[RFC7638]: Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, <https://www.rfc-editor.org/rfc/rfc7638>.
[RFC7800]: 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>.
[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>.
[RFC8414]: 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>.
[RFC8693]: Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, <https://www.rfc-editor.org/rfc/rfc8693>.
[RFC8707]: Campbell, B., Bradley, J., and H. Tschofenig, "Resource Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707, February 2020, <https://www.rfc-editor.org/rfc/rfc8707>.
[RFC8725]: Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, <https://www.rfc-editor.org/rfc/rfc8725>.
[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>.

12.2. Informative References

[I-D.mcguinness-oauth-actor-profile]: McGuinness, K., "OAuth Actor Profile for Delegation", 30 April 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-actor-profile-00>.
[I-D.mcguinness-oauth-cross-client-delegation]: McGuinness, K., "Cross-Client Delegation Profile for OAuth 2.0 Token Exchange", 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-cross-client-delegation>.
[OpenID.KeyBinding]: Hardt, D. and E. Heilman, "OpenID Connect Key Binding 1.0 - draft 02", 24 June 2026, <https://openid.net/specs/openid-connect-key-binding-1_0.html>.
[RFC9068]: Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021, <https://www.rfc-editor.org/rfc/rfc9068>.
[RFC9700]: Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, "Best Current Practice for OAuth 2.0 Security", BCP 240, RFC 9700, DOI 10.17487/RFC9700, January 2025, <https://www.rfc-editor.org/rfc/rfc9700>.

Appendix A. Worked Example: Cross-Client Delegation

This informative example shows presenter rebinding used with the Cross-Client Delegation profile [I-D.mcguinness-oauth-cross-client-delegation] so that a Delegate can present a key-bound ID Token issued to an Initiator.¶

The Initiator holds an ID Token bound to K_init. The Delegate conveys the public JWK or thumbprint for K_del to the Initiator over the authenticated, integrity-protected mechanism defined by the deployment profile. The Initiator verifies that the key belongs to the intended Delegate and signs a PRA with K_init. The PRA binds the exact ID Token to K_del, names the IdP as the authorization server, limits the result to https://gateway.example, and expires after five minutes. The Initiator conveys the exact encoded ID Token and PRA to the Delegate.¶

The Delegate performs Token Exchange at the IdP:¶

POST /token HTTP/1.1
Host: idp.example
Content-Type: application/x-www-form-urlencoded
DPoP: <proof of possession of K_del>

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token=<key-bound Initiator ID Token>
&subject_token_type=urn:ietf:params:oauth:token-type:id_token
&actor_token=<Delegate actor token>
&actor_token_type=urn:ietf:params:oauth:token-type:jwt
&audience=https://gateway.example
&presenter_rebinding=<PRA signed by K_init for K_del>
&client_assertion_type=<jwt-bearer-client-assertion-type>
&client_assertion=<Delegate client assertion>

The IdP validates the ID Token under the composed profile, reduces its cnf to jkt(K_init), confirms that the PRA is signed by K_init, verifies the Source Token hash, confirms that the PRA stt equals the request's subject_token_type, verifies the IdP audience, and verifies the Delegate's DPoP proof of K_del. Because the PRA carries an audience limit, the request must carry an audience parameter, and the IdP checks the requested value against that limit rather than defaulting it. It separately authenticates the Delegate as client and actor, validates the administered cross-client relationship and may_act when present, and applies exchange-time policy.¶

The single K_del proof serves both roles required by Section 6.1: it satisfies the PRA cnf.jkt and it sender-constrains the token the IdP issues. Note that the Delegate authenticates as a client with a separate client assertion, so client authentication remains independent of key control.¶

On success, the IdP issues an access token sender-constrained to K_del, with token_type of DPoP, and no refresh token (Section 6.2). The applicable profile can authorize it to record the Delegate as the current actor and the Initiator as a prior actor:¶

{
  "iss": "https://idp.example",
  "sub": "<user identifier for the gateway>",
  "aud": "https://gateway.example",
  "cnf": { "jkt": "0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I" },
  "act": {
    "iss": "https://idp.example",
    "sub": "delegate-client",
    "act": {
      "iss": "https://idp.example",
      "sub": "initiator-client"
    }
  }
}

The PRA expires five minutes after it is signed, which bounds when the Delegate may perform this exchange. It does not bound how long the issued access token remains valid; that is IdP policy (Section 9.5).¶

An attacker that captures the Initiator's ID Token and PRA cannot perform the exchange without K_del. If the Delegate later hands authority to another presenter, it uses the newly issued K_del-bound token as the Source Token in a new exchange; it does not extend the original PRA.¶