+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]> Sent: September 23, 2026 4:05 PM To: Thi Nguyen-Huu <[email protected]> Cc: [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]
