[OAUTH-WG] Re: Beyond the DPoP / HTTPSig choice: login and session as one problem

[Neil Madden]

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 <thi.nh=40winmagic....@dmarc.ietf.org> 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 <image002.png> 11-80 Galaxy Blvd.  |  Toronto, ON  |  M9W 4Y8  |  Canada       _______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org

_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org