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]>
Sent: September 24, 2026 9:26 AM
To: Lombardo, Jeff <[email protected]>; Neil Madden <[email protected]>
Cc: [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]
