Hi, +1 to Jeff and Neil, I agree with your analysis. Specifically, any access token in JWT format represents that at some point in time end-user was authenticated and the requested authority was authorized and granted. JWT tokens inherently go stale. As time passes since they were minted, the user account or client might have been suspended, the authority removed, the consent withdrawn etc.
Solutions patterns I'm aware of for re-asserting user account’s status / authentication / authorization: 1. Single use tokens (enforced by resource servers) 2. Short expiration for tokens, shortening the staleness period and requiring a fresh mint 3. Reference tokens (non-JWTs), validated via introspection so user and client account validation are possible at every resource access 4. Resource server step-up authentication (RFC 9470), requesting a fresh mint with RS-prescribed authentication strength 5. Resource server step-up authorization (GNAP RFC 9767<https://www.rfc-editor.org/info/rfc9767/#section-3.4>, drafts OAuth 2.0 RAR Metadata and Error Remediation<https://datatracker.ietf.org/doc/draft-ietf-oauth-rar-metadata-remediation/> and OAuth Transaction Authorization Challenge<https://datatracker.ietf.org/doc/draft-rosomakho-oauth-txn-challenge/>) 6. Token revocation but that's mostly for refresh and not access tokens But @Thi Nguyen-Huu<mailto:[email protected]>’s concerns resonate with messages from @Mohamad Khalil Yossif<mailto:[email protected]> this summer. I therefore reiterate Jeff’s request for a problem statement. What do you see in terms of risks and attacks from OAuth tokens lacking a verifiable live user context? Regards, Yaron ZEHAVI Classification: GENERAL From: Lombardo, Jeff <[email protected]> Sent: Thursday, September 24, 2026 3:57 PM To: Thi Nguyen-Huu <[email protected]>; Neil Madden <[email protected]> Cc: [email protected] Subject: [OAUTH-WG] Re: Beyond the DPoP / HTTPSig choice: login and session as one problem This message is from an external sender - be cautious, particularly with links and attachments. Hi, I am talking about the AIMS draft in WIMSE: https://datatracker.ietf.org/doc/draft-ietf-wimse-aims/ On the different elements you raise: * Beyond the feeling that this is wrong, what are the threats you aim to solve with this binding? * OAuth is Open Authorization and it requires authentication to be verified ahead of issuance. The User Authentication is expected but left to OIDC to define, while the client authentication is completely part of OAuth. Still, both are bound in the issued token. * Login and Session (as in session of the access to resource) happens at different times and we need keep them separated as only two outcomes can happen: * The User will always be in the loop cause only it can unlock the key to prove the identity * The Client has a key that represents the user and therefore there is no longer the ability to differentiate the user from the client creating confusion at the resource servers. Confusion is the enemy of proper access control and automatically raise multiple new threats that would need to be covered. * mTLS provides identity assurance for all transactions * Where used. mTLS stops at TLS termination layer which is not always compatible with the architecture at stake, see CDNs. * Still, contrary argument is that it is a valid mechanism. Frameworks like FAPI recognize the two options for PoP as they both have value, cf. the initial discussion. Coming back to the Live Key: * DPoP does not forbid that the key bound to the token is the same as the key bound to the mTLS session * When you propose that the key can be constructed with the actor being the client application + the device + local posture * That is what WIMSE is asking to do: assert the posture of the compute layer (infrastructure/device, and application stack on top of it/ client) before issuing it a credentials that allow it to authenticate during authorization request * WIMSE support, but does not impose, the usage of this key to act as mTLS client authenticator and to act as the Workload Proof Token secret (a DPoP equivalent for Workload) * Then when you propose with the user's presence as a condition on it or not * That is exactly what OAuth2.0 Step Up Authentication Challenge Protocol / RFC 9470 [https://datatracker.ietf.org/doc/rfc9470/ ] is for. Allowing Resource Server to require a refreshed proof of liveness / user presence for the access to be granted based on its own authorization decision. * This what also fueled the current proposal of https://datatracker.ietf.org/doc/draft-ietf-oauth-rar-metadata-remediation/00/ to expand also to authorization_details for which the Authorization Server might also require a refreshed proof of liveness / user presence * This is also a sub use case of https://datatracker.ietf.org/doc/draft-ietf-oauth-deferred-token-response/00/ where the AS could reach out of band to the user for a refreshed proof of liveness / user presence Therefore we have (or will have soon) the complete framework to support the objectives you set through your proposal, and this in a complete respect of the current OAuth 2.0 model. Until we know better. Jeff Jean-François “Jeff” Lombardo | Amazon Web Services Principal Standards Specialist, Identity Services Montréal, Canada From: Thi Nguyen-Huu <[email protected]<mailto:[email protected]>> Sent: September 24, 2026 9:26 AM To: Lombardo, Jeff <[email protected]<mailto:[email protected]>>; Neil Madden <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: RE: [EXT] [OAUTH-WG] Re: Beyond the DPoP / HTTPSig choice: login and session as one problem CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le contenu ne présente aucun risque. Neil, Jeff, Thank you both — your comments are helpful. First, to clarify what I meant, since "client key" as I used it seems to mean something different in this group. In our best-practice case we use for mTLS the Live Key representing user + device + local posture. If the Live Key is to be used for DPoP or similar, it can be constructed with the actor being the client application + the device + local posture, with the user's presence as a condition on it or not. Constructed that way it would not be usable by other applications on the same endpoint. But what I am proposing firstly in this email is to treat login and session as one problem, and this will certainly not fit all the requirements of OAuth, or of other existing models. It feels wrong to me that one identity is verified — the user, mostly — and access is then given to another: the client, or whatever holds the token, with binding or not, but not the identity that was verified. For me the right concept is to verify the identity before giving access to it, at the point of access, meaning at every transaction. And this goes beyond OAuth: the common user authentication we have today, no exception, is a login that serves the session and its transactions some time later. The login, or the token, is in the past; the access is now. Separating login and session is suboptimal, and we had to do it because we could not verify the user without user friction. mTLS provides identity assurance for all transactions, and it already authenticates the machines as part of the key exchange. The Live Key adds the user verification to it. So, where applicable, we believe this approach is more secure and simpler. And I understand that OAuth should not cover authentication. Yet everywhere I look, the bearer token is what authentication ends up resting on. So might OAuth not be perfect in this one respect? As stated in the first email, solving login and session with one solution might not fit anywhere. But this group is perhaps the best placed to say whether it is worth pursuing. PS: Jeff, on WIMSE — I think you mean the condition-bounded credentials draft you reviewed in July. If you meant something else there, I would like to read it Cheers Thi Nguyen-Huu CEO winmagic.com<https://winmagic.com/> 11-80 Galaxy Blvd. | Toronto, ON | M9W 4Y8 | Canada From: Lombardo, Jeff <[email protected]<mailto:[email protected]>> Sent: Wednesday, September 23, 2026 5:44 PM To: Neil Madden <[email protected]<mailto:[email protected]>>; Thi Nguyen-Huu <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; Lombardo, Jeff <[email protected]<mailto:[email protected]>> Subject: RE: [OAUTH-WG] Re: Beyond the DPoP / HTTPSig choice: login and session as one problem 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. +1 to Neil We are conflating multiple things here. The key in DPoP, mTLS, HTTPSig is a key possessed by the Client to prove it is the one which got authorized through the issuance of the access token to perform a task for the scope, audience, and possible authorization_details as well as access control logic based on other claims. When a user in involved, this happens during the authorization process. This could rely to a private / public key based authentication scheme (OIDC) with a keyset owned by the user (FIDO2). This keyset could be stored on a portable or local hardware support. The action of authorizing is here to bound: the authenticity of the user delegating with the key of the client acting on its behalf. Once done the user is no longer required to be involved as it is the client key that is used when accessing resources on the basis of this authorization. The fact that the client has a key to bound authorization and that this key is only existing upon security posture checks is exactly what WIMSE is already proposing. Giving access from the client to the user bound keys is a unsecure are the client could then authorize itself for any scope, audience, and possible authorization_details as well as access control logic based on other claims without the user knowledge and capability of action. This would confuse the AS as it will impossible for it to differentiate an authorization request to act on behalf of the subject/user and an authorization request in the back of the user/subject. This would be especially bad for AI Agent architecture. There are some works on allowing the client to expand beyond the initial authorization scope, audience, authorization_details, etc. with boundaries on what could be requested. For example, Karl McGuiness proposal around Mission Based for OAuth. Jeff Jean-François “Jeff” Lombardo | Amazon Web Services Principal Standards Specialist, Identity Services Montréal, Canada From: Neil Madden <[email protected]<mailto:[email protected]>> Sent: September 23, 2026 4:05 PM To: Thi Nguyen-Huu <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: [EXT] [OAUTH-WG] Re: Beyond the DPoP / HTTPSig choice: login and session as one problem CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le contenu ne présente aucun risque. They are separate because they authenticate different things. The login authenticates the user, who then authorises a client. The client (which may or may not be acting under direct user supervision) then acts using the access token(s) - what you refer to as a session. They *could* in some circumstances use the same mechanism, but there is no need to conflate them. In particular, requiring a client to use a user’s credentials (eg key) seems to defeat the purpose for which OAuth exists in the first place - to avoid such credential sharing. Neil On 23 Sep 2026, at 20:42, Thi Nguyen-Huu <[email protected]<mailto:[email protected]>> wrote: Subject: Beyond the DPoP / HTTPSig choice: login and session as one problem Hello, As the WG is discussing mTLS, DPoP and HTTPSig, I would like to raise a question I have wanted to raise since joining the IETF this year. All three constrain who may present a token, with a proof of possession of a key. The token exists because the authentication happened earlier, somewhere else, and something has to carry it forward. What if the key represents an identity now — that is, authentication: a condition-bound key, or easier for me to say a Live Key, that exists and can sign only while the authorized user is using the authentic, authorized endpoint with a policy-compliant security posture, and disappears when any of that stops being true. With such a key, a login is no longer needed. An mTLS session using it as the client key needs no user login, and identity is proven at the moment of the request, on every request, for the session and each transaction in it. That is what I would like the group to consider. Today a login is needed to establish who is there, and mTLS, DPoP or HTTPSig protect the session that follows it: two problems, two solutions. But, one key can do both — it is the authentication, and it is what the session is bound to. Simpler and end-to-end. To be precise, this key represents "identity". Online identity, as I use the term, is a combination of actor, platform and local posture — the actor being a user, an AI agent, an application, a browser, whatever acts. The key is therefore registered per actor and endpoint. What that identity is entitled to still comes from the authorization server, or from the token. OAuth might not be about login — that is perhaps OIDC's and FIDO2's ground. But the issue is a gap in security, and more precisely in cryptography. Current user authentications, Passkeys included, end in a verdict. They do not establish a key to protect the data exchange that follows, as an encapsulated operation like an authenticated key exchange would. And so the token is not protected by the authentication. Other methods may provide alternatives, but mTLS protecting login and session in one atomic operation is stronger than covering login and then covering the session separately. What I'd like to know is whether this group sees collapsing login and session as in scope for OAuth. I have argued elsewhere that withstanding AI-enabled attacks needs end-to-end cryptography, and that separating login from session is a gap in it — one that can be closed. If it is out of scope here, I would value a pointer to where it belongs — WIMSE, W3C, or elsewhere. PS: Btw, the same condition-bound key works under all three mechanisms and can carry whatever the token is meant to assert. Cheers Thi Nguyen-Huu CEO <image001.png> winmagic.com<https://winmagic.com/> <image002.png> 11-80 Galaxy Blvd. | Toronto, ON | M9W 4Y8 | Canada _______________________________________________ OAuth mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> 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).
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
