Jeff, Thank you for the detailed reply, and for pointing me at AIMS.
On the threats, let me put the question back. Is the central difficulty of our industry not that we need to know the right identity is there now, while everything we have to work with was established in the past? DPoP, DBSC, 9470 — each is an attempt to make something from the past answer a question about the present. FIDO2 made the login unphishable; the session is still taken afterwards, which is why DBSC was built. Concretely, the threat is that access continues after what it was granted on has stopped being true. The person has left the device and the session keeps working; the posture has failed and the credential stays valid until it expires. AIMS shows the same thing, and better than I put it. Section 8 makes provisioning the assessment point — "Credential provisioning is also the assessment point to confirm that the Agent and its runtime environment satisfy the posture requirements" — and posture then determines, among other things, how long the credential remains valid. Section 7 follows: credentials "SHOULD be short-lived to minimize the risk of credential theft, MUST include an explicit expiration time after which it is no longer accepted." So posture is measured once and converted into a timer. If the posture stops holding a minute after provisioning, the credential is still valid, because expiry is what ends it. Short-lived credentials shorten that window; they cannot close it, since the credential's validity never depended on the posture, only on the clock. That is the flaw I am pointing at, and it is the same one in the user case: the check happens before, the access happens after, and nothing in between carries the check forward. A condition-bound credential inverts that. The posture is not converted into a lifetime: the credential exists while the posture holds, and access ends where the posture fails, with no message having to travel. To be clear, the Live Key — the condition-bound credential — is new as far as I know, and it will not be perfect straight away. But I think it is worth considering and supporting, because where applicable, it really solves the problem instead of going around it. And with support, it can be applicable everywhere. On two of your references, I am not sure they carry what you intend. The RAR metadata remediation draft is about discovering authorization-details metadata and remediating insufficient authorization. The deferred token response draft defers an issuance decision, and states that it supports cases where a different user, a different system, or no human at all completes it. Both concern the authorization decision rather than establishing that the user is present at the time of access. On your two outcomes. Both assume that unlocking the key is a user action, and that the key stands for the user. Neither holds here. The user is verified into the endpoint at login and that verification is held continuously, so at the moment of use there is no gesture. The key is the client's, derived per actor, and the user's presence is a condition on it existing. From the resource server's side, nothing changes in what it validates. What changes is what had to be true for the signature to exist: a verified user, at this device, with the posture holding. The identity claim still comes from the token, as today. On 9470. A refreshed proof of liveness produces a result, which is then recorded and carried forward again — the same shape at a finer interval. And we know how often a resource server will ask, because each ask costs the user. Even at every fifteen minutes, which no user would accept, it can be fourteen and a half minutes late. On mTLS and CDNs, agreed, and AIMS says it well in 9.1 — mTLS gives channel binding and proof of control of the key. Where TLS is terminated the same key works under DPoP, which is why I would not tie this to mTLS alone. So my question on AIMS. What happens when posture stops holding after the credential is issued? If that is out of scope, is it worth naming as a gap? 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: Lombardo, Jeff <[email protected]> Sent: Thursday, September 24, 2026 9:57 AM To: Thi Nguyen-Huu <[email protected]>; Neil Madden <[email protected]> Cc: [email protected]; Lombardo, Jeff <[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. 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]>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
