Yaron and all, Thank you. You put the premise perhaps better than I have: the token records that at some point the user was authenticated and the authority granted.
One principle before the threats, since the threats are the ones we name today but there can be more, in particular now that AI-enabled attacks will exploit more than currently known. Principle first also lets me explain the why better. Everything on your list is reaching for the same answer: not what was true when the token was minted, but what is true now. An answer to that is accurate only if it comes from somewhere that can see what it reports. Thank you also for pointing me at Mohamad's messages, because his draft states the requirement better than I have. From the abstract of draft-yossif-psea-01: "Sessions preserve the memory of authentication but not the certainty of authority," and what he asks for is "cryptographic proof of real human presence, device trust, and execution authority at the exact moment a sensitive action is approved — independent of prior authentication or session state." That is what I want too, and the word I would underline is certainty. Of the three things he requires, execution authority belongs where it is now, with the authorization server. The other two do not. Certainty about presence and about the device cannot be produced by asking: a gesture costs the user every time, and a moment after it is a record again. And of your six, introspection is the strongest and genuinely real-time, but the authorization server can answer accurately only the authorization questions — suspension, consent withdrawal. It cannot say the user is at the device, or that the device is still sound. The endpoint can. And it does not explicitly check: it knows when the user logs off, and when the device leaves an allowed location. No ledger needed or involved, no polling. Jeff is correct in the other mail that nothing is really real-time, but this is probably as real-time as we want it here. The threat, in one line, is access that continues after what it was granted on has stopped being true: the person has left the device, or the device is no longer compliant. Note that in most deployments nothing was established about the device in the first place. A note on my own shorthand, since I have been saying "user, device and conditions" to keep things short, and it understates it. The conditions are gated by the platform, in software, with hardware where hardware adds something — the key ideally sits in the TPM, which makes the endpoint itself very hard to fake. They are not all worth the same: a condition the hardware enforces is stronger than one that rests on the operating system's word about which user is present. So what belongs in a specification is not a list of condition names, but that a verifier be told how each condition is enforced. And what I could list today is only a few named conditions. If the approach is supported, many more meaningful ones can emerge, sooner than later. This applies as well when the actor is not the user, though that case is more complex and we can discuss it when needed. I would welcome brainstorming it with the group, and with Mohamad, since the proof he asks for is stronger if the key that produces it cannot exist unless the conditions hold. On the ledger, since it is in the archive: §3 of draft-winmagic-wimse-condition-bounded-credentials-01 defines the Verifier Contract as "the set of checks a verifier performs before accepting a credential use" — checks a verifier runs. Nothing is stored, published or looked up, and nothing calls home. And DBSC does not show that a request comes from the chip that logged in: the DBSC key is created by the browser at or after sign-in, bound to the device rather than the user, and it is not the key that authenticated anyone. Cheers Thi Nguyen-Huu CEO [cid:[email protected]] winmagic.com<https://winmagic.com/> [cid:[email protected]] 11-80 Galaxy Blvd. | Toronto, ON | M9W 4Y8 | Canada From: Yaron ZEHAVI <[email protected]> Sent: Friday, September 25, 2026 4:57 PM To: Lombardo, Jeff <[email protected]>; Thi Nguyen-Huu <[email protected]>; Neil Madden <[email protected]>; Mohamad Khalil Yossif <[email protected]> Cc: [email protected] Subject: RE: [OAUTH-WG] Re: Beyond the DPoP / HTTPSig choice: login and session as one problem You don't often get email from [email protected]<mailto:[email protected]>. 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. 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]<mailto:[email protected]>> Sent: Thursday, September 24, 2026 3:57 PM To: Thi Nguyen-Huu <[email protected]<mailto:[email protected]>>; Neil Madden <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[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]
