[OAUTH-WG] New I-D: draft-winmagic-oauth-condition-bound-keys-00

[Thi Nguyen-Huu <[e-mail]>]

Subject: New I-D: draft-winmagic-oauth-condition-bound-keys-00 (was: Re: Request for Review: Delegated Refresh Tokens for OAuth 2.0 Token Exchange (-04))

Larry, and Yaron and all,

Thank you for the review, and for asking for this — it is what got it written. The draft is submitted:

draft-winmagic-oauth-condition-bound-keys-00
Condition-Bound Keys for Mutual-TLS Client Authentication and DPoP
https://datatracker.ietf.org/doc/draft-winmagic-oauth-condition-bound-keys/

Your three questions. What each party can verify is Section 8: the authorization server in 8.1, which observes the handshake directly, and the resource server in 8.2, which concludes less because it is usually not the TLS peer. The effect on tokens already issued is Section 9, including the part the document does not claim to fix — a bearer token already issued is unaffected and runs to its expiry. The delegated case is Section 10.

Two of your own points are in there as yours. Your observation that the loss of the key makes subsequent token exchange and refresh requests fail without a revocation message being delivered is Section 9, with the general principle in Section 11. The interval between refresh requests that you named is what the document addresses, in your description of it rather than mine. And your reading that a condition-bound credential is complementary to your profile is the frame the whole document takes.

The draft turned out to hold considerably more than the delegated case. We had meant to get feedback on the narrow part first and bring the rest later. We decided instead to put in what we brought to the IETF in 2025, which went nowhere — largely because we did not understand the process then, and still do not fully understand it now.

That material is this. Login and session protection are treated as two problems and solved in two markets, but they perform one function: verify identity before giving access. Online, the unit of access is the transaction, and a key that exists only while the actor, the platform, and local policy hold can carry that verification at every transaction, without asking the user to act. There is then no login to perform and no session to protect. Not a better login, and not a longer-lived session — neither one is needed.

The same key is also not specific to OAuth. It is the same construction underneath a device-bound browser session and underneath a WebAuthn credential. It changes what continuous access evaluation has to carry, because that architecture assumes the party that observes a change and the party that enforces it are different parties — which is exactly what stops being true when the key and the condition are in the same place.

So the applicability sits across this group, the W3C, the FIDO Alliance, and the OpenID Foundation, and I do not know where the work belongs. We have a draft in WIMSE as well, draft-winmagic-wimse-condition-bounded-credentials-01, written there because mutual TLS is native to that group. The endpoint and the person using it is where our own depth is, which is why this one is separate rather than folded in.

Advice on where this belongs, and on how to bring it there, would be more useful to me than agreement.

Review welcome, particularly anywhere it overreaches.

Cheers

Thi Nguyen-Huu | CEO

Tel: [phone] x 3288  |  Toll Free: 888.879.5879
[e-mail]<mailto:[e-mail]> |  www.winmagic.com<http://www.winmagic.com/>

WinMagic Corp. | 11-80 Galaxy Blvd.
Toronto, ON  |  M9W 4Y8 |  Canada | www.winmagic.com<http://www.winmagic.com/>
From: Thi Nguyen-Huu <thi.nh=[e-mail]>
Sent: Wednesday, August 5, 2026 7:01 AM
To: Larry Zhu <[e-mail]>; Yaron ZEHAVI <yaron.zehavi=[e-mail]>; oauth <[e-mail]>
Cc: Henrik KROLL <[e-mail]>; Grese HYSENI <[e-mail]>; Frederik Krogsdal Jacobsen <[e-mail]>
Subject: [OAUTH-WG] Re: Request for Review: Delegated Refresh Tokens for OAuth 2.0 Token Exchange (-04)

CAUTION:This email originated from outside of the organization. Do not click links, open attachments or respond unless you recognize the sender and know that the content is safe.

Hi Larry,

Thanks. I'll do the write-up as an Internet-Draft and post it here; and address the issues you wrote if not covered there.

You are right that the mechanism does nothing for an access token already issued. But the access now relies — in addition to the token — on the key the client governs itself. We need a mechanism like mTLS, or similar control like DPoP; RFC 8705 seems closest, whereby the client can use this condition-bound key. Note that a client can always stop talking. What it cannot do is stop someone else from talking as it. The key in mTLS does that.

Yes, for current implementations we can shorten access token lifetime to improve security. Where the condition-bound key is applicable, the access token lifetime is mainly back to AuthZ and not needed for AuthN.

Cheers

Thi Nguyen-Huu | CEO

Tel: [phone] x 3288  |  Toll Free: 888.879.5879
[e-mail]<mailto:[e-mail]> |  www.winmagic.com<http://www.winmagic.com/>

WinMagic Corp. | 11-80 Galaxy Blvd.
Toronto, ON  |  M9W 4Y8 |  Canada | www.winmagic.com<http://www.winmagic.com/>

From: Larry Zhu <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, August 4, 2026 2:23 PM
To: Thi Nguyen-Huu <[e-mail]<mailto:[e-mail]>>; Yaron ZEHAVI <yaron.zehavi=[e-mail]<mailto:yaron.zehavi=[e-mail]>>; oauth <[e-mail]<mailto:[e-mail]>>
Cc: Henrik KROLL <[e-mail]<mailto:[e-mail]>>; Grese HYSENI <[e-mail]<mailto:[e-mail]>>; Frederik Krogsdal Jacobsen <[e-mail]<mailto:[e-mail]>>
Subject: Re: [OAUTH-WG] Re: Request for Review: Delegated Refresh Tokens for OAuth 2.0 Token Exchange (-04)

CAUTION:This email originated from outside of the organization. Do not click links, open attachments or respond unless you recognize the sender and know that the content is safe.


One thing your construction gives you that you did not claim for it: a stable actor identifier. If the actor is https://agents.acme.com/booking_agent, the AS can revoke by actor instead of hunting for token families.

[Larry Zhu] Yes, with one qualification. Under the draft -05 now, the current actor is derived from the authenticated acting client, or from an identity securely mapped to that client; it is not derived from the delegation handle's aud claim alone. The audience may identify the acting client directly or a resource-server identity mapped to it.

That stable client-to-actor mapping can allow the authorization server to find and revoke all delegated refresh-token families associated with an actor when its credential is lost or revoked, or when policy no longer permits continuation. The draft already identifies those events as family-revocation triggers. It does not, however, define a protocol operation by which the original client, user, or another party requests actor-wide revocation. RFC 7009 revocation under this profile remains token-based and is normally performed by the acting client.

What still isn't reached is the question underneath: is this the authentic actor, on the authorized platform, with its conditions still holding, right at this moment? I understand in OAuth vocabulary identity is treated as the actor. We take it to be the actor, the platform, and the conditions together — one identity, not three checks. The platform's software builds the credential from all three; that is what we call a condition-bound credential.

That is the gap our work addresses. The credential stops working when any one of the three fails — no message to deliver, nothing for the user to do.

[Larry Zhu] I agree that this is a stronger property than the one defined by the draft. The draft establishes that the presenter controls a credential accepted for the authenticated acting client and that the delegation handle is addressed to that client, including enforcement of any applicable sender constraint. It does not standardize how the authorization server determines that the credential is executing on a particular authorized platform or that user and device conditions continue to hold at the moment of each use.

The draft re-evaluates authorization-server policy and relevant subject, client, session, and workflow state on every refresh request. A condition visible to the authorization server can therefore prevent issuance of subsequent access tokens and revoke the refresh-token family. That still leaves an interval between refresh requests, and an access token already issued can remain usable until it expires unless the deployment supports immediate invalidation. This is why the draft also requires an appropriately short access-token lifetime when immediate invalidation is unavailable.

A condition-bound credential appears complementary to this profile. If it can serve as, or securely bind, the acting client's authentication or proof-of-possession key, loss of the credential would cause subsequent Token Exchange and refresh requests to fail without requiring delivery of a revocation message. Defining how such a credential is created, validated, and bound to platform and user conditions is outside this draft's current scope. A write-up of the delegated case would be useful, particularly to show what the authorization server and resource server can verify and how the mechanism affects access tokens that have already been issued.
Thanks Thi.

From: Thi Nguyen-Huu <[e-mail]<mailto:[e-mail]>>
Date: Saturday, August 1, 2026 at 5:47 AM
To: Yaron ZEHAVI <yaron.zehavi=[e-mail]<mailto:yaron.zehavi=[e-mail]>>; Larry Zhu <[e-mail]<mailto:[e-mail]>>; oauth <[e-mail]<mailto:[e-mail]>>
Cc: Henrik KROLL <[e-mail]<mailto:[e-mail]>>; Grese HYSENI <[e-mail]<mailto:[e-mail]>>; Frederik Krogsdal Jacobsen <[e-mail]<mailto:[e-mail]>>
Subject: RE: [OAUTH-WG] Re: Request for Review: Delegated Refresh Tokens for OAuth 2.0 Token Exchange (-04)
Hi Yaron,

To your question, 8693 anticipated something close to your construction: may_act in §4.4 lets the subject token name the party eligible to act for the subject. You got there through the audience claim instead. What CIMD adds is the part 8693 left out — how the AS learns the keys of an actor it never enrolled.

Which is most of the answer to your mystery, I think. Read 8693 as assuming pre-registration. The actor is an OAuth client, known to the AS, authenticating the ordinary way: client_secret, private_key_jwt from RFC 7523 in 2015, or mTLS from RFC 8705, published a month after 8693. Inside one administrative domain with a handful of enrolled services, that is interoperable and secure enough. Delegation was between things you had deployed yourself. This is me reading the RFC's assumptions rather than claiming to know what its authors intended.

So what was added is the population. An actor used to be a service you enrolled. Now it is an instance that may not exist tomorrow, and pre-registration does not reach it. Hence CIMD.

One thing your construction gives you that you did not claim for it: a stable actor identifier. If the actor is https://agents.acme.com/booking_agent, the AS can revoke by actor instead of hunting for token families. That answers part of my earlier point better than I gave you credit for.

What still isn't reached is the question underneath: is this the authentic actor, on the authorized platform, with its conditions still holding, right at this moment? I understand in OAuth vocabulary identity is treated as the actor. We take it to be the actor, the platform, and the conditions together — one identity, not three checks. The platform's software builds the credential from all three; that is what we call a condition-bound credential.

That is the gap our work addresses. The credential stops working when any one of the three fails — no message to deliver, nothing for the user to do. I'll write it up for the delegated case; happy to go into it here if it's useful to your review.

Cheers

Thi Nguyen-Huu

From: Yaron ZEHAVI <yaron.zehavi=[e-mail]<mailto:yaron.zehavi=[e-mail]>>
Sent: Friday, July 31, 2026 1:57 PM
To: Thi Nguyen-Huu <[e-mail]<mailto:[e-mail]>>; Larry Zhu <[e-mail]<mailto:[e-mail]>>; oauth <[e-mail]<mailto:[e-mail]>>
Cc: Henrik KROLL <[e-mail]<mailto:[e-mail]>>; Grese HYSENI <[e-mail]<mailto:[e-mail]>>; Frederik Krogsdal Jacobsen <[e-mail]<mailto:[e-mail]>>
Subject: RE: [OAUTH-WG] Re: Request for Review: Delegated Refresh Tokens for OAuth 2.0 Token Exchange (-04)

CAUTION:This email originated from outside of the organization. Do not click links, open attachments or respond unless you recognize the sender and know that the content is safe.

Dear Thi,
Thanks for your detailed response.

I’m no expert on delegation, was rather trying to work it out step by step, to understand and review Larry’s draft.
However, I think with actor-initiated delegated token exchange an AS can ensure the request is coming from a legitimate holder:

  *   If the token is audienced to the actor, e.g “aud”: “https://agents.acme.com/booking_agent”
  *   And the actor uses CIMD with a published jwks or jwks_uri and provides a signed actor_token or client_assertion with client identifier matching token’s aud claim (“https://agents.acme.com/booking_agent”)
  *   Then AS can validate the call is coming from the token’s audience

But there’s a mystery here…
Since RFC 8693 supported delegation flows since 2020 but DPoP came out in 2023 and CIMD is still in draft status…
How did those who envisioned token exchange for delegation intended it to work interoperably and securely?

Regards,
Yaron



Classification: GENERAL
From: Thi Nguyen-Huu <thi.nh=[e-mail]<mailto:thi.nh=[e-mail]>>
Sent: Friday, July 31, 2026 1:01 PM
To: Yaron ZEHAVI <[e-mail]<mailto:[e-mail]>>; Larry Zhu <[e-mail]<mailto:[e-mail]>>; oauth <[e-mail]<mailto:[e-mail]>>
Cc: Henrik KROLL <[e-mail]<mailto:[e-mail]>>; Grese HYSENI <[e-mail]<mailto:[e-mail]>>; Frederik Krogsdal Jacobsen <[e-mail]<mailto:[e-mail]>>
Subject: RE: [OAUTH-WG] Re: Request for Review: Delegated Refresh Tokens for OAuth 2.0 Token Exchange (-04)

This message is from an external sender - be cautious, particularly with links and attachments.

Yaron, Larry,
I described this key in the Call for topics thread on 19 July, and on 15 July, in the agent-authorization use-cases thread, pointed at your exchange as the live form of the lifetime problem. In short, and as a property of the client key under DPoP or 8705 rather than a new way of proving possession: the key carries the user verification and the device conditions, requires no user interaction at the moment of use, and exists only while those conditions hold — when they lapse it is gone, so nothing has to expire and no message has to be sent.

Yaron's revocation question is the part I have not covered, and it is Larry's review question 4 as well. Larry, your draft gives the AS a refresh-token family to revoke and a terminal state to revoke it in, and that works at the next refresh. Between refreshes there is nothing. The actor holds a credential whose validity is a matter of record at the authorization server, not of anything observable where the action is actually running. Yaron's question is the same point from the other side: the token sits in the actor's sole possession, so the party who would want it stopped is not the party holding it, and has no identifier for it.

Yaron, both of your delegation options break in the same place. Client-initiated needs something standing in for the actor's key, and a key under the actor's sole control is exactly what cannot be handed over. Actor-initiated leaves the AS unable to tell that the presenter is the legitimate holder. What is being transferred is authority; what should be transferred is permission to mint.
Mint consumes the user's approval once, and the actor's key is built at that moment. The actor then exercises it per use with no user involved, which covers the long-running offline case in your first bullet. Any one condition failing erases it. (Mint / exercise / erase is Morgan LR's naming, from the WIMSE discussion.)

Revocation then has nothing to look for, and nothing to wait for. The user stops the task, or logs out, or the device leaves an allowed posture: the key is erased where it lives, every access depending on it ends at that moment, and no message is in transit to go stale. An externally decided revocation is one signal to one platform instead of notifications to every relying party holding state, and an offline endpoint fails closed. What it does not cover is a bearer token already issued, which runs to its expiry — where a short lifetime still earns its keep.

This is also why the extension disagreement in this thread need not be settled on lifetime terms. Subject, actor, audience and scope stay with the authorization server at every refresh, exactly as you have them, Larry; what moves off the timer is whether the actor's standing survived the interval.

draft-winmagic-wimse-condition-bounded-credentials has the detail. If it helps the draft, I can write up the delegated case.

Thi Nguyen-Huu
WinMagic

From: Yaron ZEHAVI <yaron.zehavi=[e-mail]<mailto:yaron.zehavi=[e-mail]>>
Sent: Friday, July 31, 2026 2:33 AM
To: Larry Zhu <lzhu3=[e-mail]<mailto:lzhu3=[e-mail]>>; oauth <[e-mail]<mailto:[e-mail]>>
Cc: Henrik KROLL <[e-mail]<mailto:[e-mail]>>; Grese HYSENI <[e-mail]<mailto:[e-mail]>>; Frederik Krogsdal Jacobsen <[e-mail]<mailto:[e-mail]>>
Subject: [OAUTH-WG] Re: Request for Review: Delegated Refresh Tokens for OAuth 2.0 Token Exchange (-04)

You don't often get email from yaron.zehavi=[e-mail]<mailto:yaron.zehavi=[e-mail]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
CAUTION:This email originated from outside of the organization. Do not click links, open attachments or respond unless you recognize the sender and know that the content is safe.

Dear Larry,
I think I understand better and acknowledge the challenge your draft tries to solve.

Initially I proposed that the AS determines grant lifetime based on the requested authority, thus support long running tasks.
But the dynamic nature of tasks which may require longer time to complete than anticipated, makes it valuable to allow requesting to extend token lifetimes.

A few comments on that theme:

  *   Your draft focuses on delegated RFC 8693 Token Exchange, but I think it’s applicable also when the client does not delegate to other actors. For example the user asked an application to do something which requires more time, meanwhile the user is offline.
  *   Regarding delegated flows, I think the draft would benefit from concrete examples of step-by-step delegation and how the proposed token exchange profile is used and by whom.
  *   I’m raising this point because I encountered some questions when thinking about the draft, regarding how delegation works in general and how it reconciles other security concerns and mechanisms. This impacts how the mechanism proposed in the draft will be used. I see 2 options for how an actor is delegated work, perhaps there are more:

     *   Client-initiated delegated token exchange:

        *   The client performs the token exchange before providing the resulting token to the actor. In the token exchange request client provides subject_token and actor token. The resulting token includes the act claim for the actor (e.g., a worker or agent). The client securely provisions this token to the actor, which then uses it to act.
        *   Challenges arise when client and actor are separate systems:

           *   How does the client obtain an actor_token? Considering such tokens are not just strings but private key JWTs or another token securely identifying the actor?
           *   How to sender-constrain client-issued tokens to be used by actor, without compromising keys that should be under the sole control of the actor?

     *   Actor-initiated delegated token exchange:

        *   Client calls the actor using an access token.
        *   Actor performs token exchange, presenting the subject_token it received from the client and an actor_token it issues.
        *   The challenge here is when the subject_token is sender constrained to the client and not to the actor. How does the AS ensure the actor is the legitimate holder of the token?
        *   One way could be audience restriction – the subject_token’s audience could explicitly name the actor, who then uses client authentication or actor_token to prove the request is coming from subject_token’s audience.

  *   For both of these options, I don’t see how RFC 7009 token revocation will be used. Can you please explain, who would call the revocation and using which token? The challenge I see is that delegated actors will obtain refresh tokens which stem from an original grant but only they possess them. Without some global identifier, how is revocation possible and by whom?
  *   Delegation concerns set aside, the draft’s core mechanism provides grant lifetime negotiation and extension. In this framing:

     *   I’m not sure new AS metadata and token exchange request parameter are needed. Perhaps this could be profiled on a scope, such as OpenID’s “offline_access” to signal wish to extend grant lifetime.
     *   You write “If current authorization-server policy requires fresh user authentication, step-up, or additional approval for a requested resource or operation, the refresh request must fail”. But perhaps it would be better to use in such cases the deferred token response draft? This would allow human-in-the loop decisions when new tasks are spawned or when task is extended. This is especially valuable in long-running offline tasks as the user’s original intent or mission may no longer be relevant and should therefore be terminated.
     *   You write “refresh-token rotation without extending the absolute delegation lifetime” I think that defeats the draft’s purpose. If the user’s task requires long running offline processing, the delegation lifetime may need to be extended. This is okay so long as the authorization server is engaged whenever extending is required, can apply policies and reach out to the user or other approvers for consent.
     *   You write “allows an already-authorized task to continue without expanding its authority”. Why limit the scope of the draft? Imagine a delegated actor needs additional authority, it can request it and AS may employ policies and if necessary, use DTR to asynchronously obtain approval.
     *   You write in the draft “the same acting client uses the RFC 6749 refresh token grant”. Refresh tokens can also be used as subject tokens for rfc 8693 token exchange. Is this also an option in your view or do you mandate using the refresh token grant only? If so, why?

Yaron




Classification: GENERAL
From: Larry Zhu <lzhu3=[e-mail]<mailto:lzhu3=[e-mail]>>
Sent: Friday, July 24, 2026 11:27 AM
To: oauth <[e-mail]<mailto:[e-mail]>>
Subject: [OAUTH-WG] Request for Review: Delegated Refresh Tokens for OAuth 2.0 Token Exchange (-04)

This message is from an external sender - be cautious, particularly with links and attachments.


Hi OAuth WG,

We have published draft-zhu-oauth-async-delegation-04, which is the reviewable version of the proposal. I also ran into Yaron in the hallway here in Vienna and gave him a quick heads-up on the current design.

I would like to thank Arndt Schwenkschuster for his valuable feedback. In particular, his observation that RFC 8693 already permits refresh-token issuance for offline Token Exchange scenarios helped us frame this work as a profile of existing refresh tokens rather than a new continuation credential.

The draft addresses a specific interoperability gap: although RFC 8693 permits an authorization server to return a refresh token from Token Exchange, it does not define how delegated authorization state—particularly the subject, complete actor chain, client binding, permitted resources, and scope restrictions—is preserved and enforced when that refresh token is subsequently used.

The proposal profiles an RFC 8693-issued refresh token for asynchronous and long-running delegated workflows. In brief, it defines:

  *   RFC 8414 authorization-server metadata for discovering support for the profile;
  *   an explicit Token Exchange request signal for requesting delegated asynchronous continuation;
  *   preservation of the original subject and complete actor chain;
  *   binding of the refresh token to the acting client and current actor;
  *   confinement to the originally authorized resources;
  *   scope that can remain unchanged or narrow, but cannot expand;
  *   authorization re-evaluation on every refresh;
  *   refresh-token rotation without extending the absolute delegation lifetime; and
  *   a one-to-one association between a refresh-token family and an asynchronous task, with RFC 7009 revocation when the task completes, is cancelled, or otherwise reaches a terminal state.

Step-up authentication and new user authorization remain separate concerns. This profile allows an already-authorized task to continue without expanding its authority; it does not allow a refresh token to bypass authentication-context or step-up requirements. If current authorization-server policy requires fresh user authentication, step-up, or additional approval for a requested resource or operation, the refresh request must fail and that requirement must be satisfied through an appropriate, separate interaction.

The profile uses the existing refresh_token response parameter, refresh-token grant, and resource parameter. It defines no new token format, token type, grant type, or token-response parameter. It also does not make refresh tokens portable across authorization servers; each refresh token remains bound to and usable only at its issuing authorization server.

Under the clustering proposal presented at IETF 126, we suggest categorizing the draft as follows:

Requested cluster: Same-Domain Chaining
Related clusters: Token Lifecycle and Discovery

We would greatly appreciate review of -04, particularly on:

  1.  Whether the interoperability gap is clear and sufficiently narrow.
  2.  Whether profiling RFC 8693-issued refresh tokens is the right approach.
  3.  Whether the discovery and request signals are appropriate.
  4.  Whether the subject and actor preservation, resource and scope confinement, bounded lifetime, rotation, authorization re-evaluation, and task-scoped revocation requirements are complete and implementable.
  5.  Whether the boundary between delegated continuation and separate step-up or user-authorization mechanisms is sufficiently clear.
  6.  Whether any part of this work should instead be incorporated into an existing OAuth specification.

Draft -04:
https://www.ietf.org/archive/id/draft-zhu-oauth-async-delegation-04.html

Datatracker:
https://datatracker.ietf.org/doc/draft-zhu-oauth-async-delegation/

Thank you,

Larry Zhu
This message and any attachment ("the Message") are confidential. If you have received the Message in error, please notify the sender immediately and delete the Message from your system, any use of the Message is forbidden. Correspondence via e-mail is primarily for information purposes. RBI neither makes nor accepts legally binding statements via e-mail unless explicitly agreed otherwise. Information pursuant to § 14 Austrian Companies Code: Raiffeisen Bank International AG; Registered Office: Am Stadtpark 9, 1030 Vienna, Austria; Company Register Number: FN 122119m at the Commercial Court of Vienna (Handelsgericht Wien).
This message and any attachment ("the Message") are confidential. If you have received the Message in error, please notify the sender immediately and delete the Message from your system, any use of the Message is forbidden. Correspondence via e-mail is primarily for information purposes. RBI neither makes nor accepts legally binding statements via e-mail unless explicitly agreed otherwise. Information pursuant to § 14 Austrian Companies Code: Raiffeisen Bank International AG; Registered Office: Am Stadtpark 9, 1030 Vienna, Austria; Company Register Number: FN 122119m at the Commercial Court of Vienna (Handelsgericht Wien).