Thi, Using a key to form an "identity" is something that the Drone Remote ID Protocol (DRIP) WG worked towards for UAS RID. This resulted in the creation of the DRIP Entity Tag (DET, RFC9374) which is an instantiation of an Overlay Routable Cryptographic Hash Identifier (ORCHID, RFC7343). All of this was influenced and builds upon existing work from the Host Identity Protocol (HIP, RFC9063). Near the end of that work I started architecting a system for keys to be registered and later have additional private data lookup. This was to use COSE/JOSE over HTTPS (at minimum) for registration and use either OAuth or mTLS to query using RDAP (since the public lookup was part of DNS per RFC9886).
This meta-problem you are describing is the exact same one I ran into when designing something for multiple organizations/agencies to be able to perform lookups with disparate user and authentication systems already deployed while transporting sensitive data. I am curious where such a conversation goes and look forward to others opinions on this. On Wed, Sep 23, 2026 at 3:42 PM Thi Nguyen-Huu <thi.nh= [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* > > winmagic.com > > 11-80 Galaxy Blvd. > <https://www.google.com/maps/search/80+Galaxy+Blvd.++%7C+Toronto,+ON++%7C+M9W+4Y8++%7C+Canada?entry=gmail&source=g> > | > <https://www.google.com/maps/search/80+Galaxy+Blvd.++%7C+Toronto,+ON++%7C+M9W+4Y8++%7C+Canada?entry=gmail&source=g> > Toronto, ON > <https://www.google.com/maps/search/80+Galaxy+Blvd.++%7C+Toronto,+ON++%7C+M9W+4Y8++%7C+Canada?entry=gmail&source=g> > | > <https://www.google.com/maps/search/80+Galaxy+Blvd.++%7C+Toronto,+ON++%7C+M9W+4Y8++%7C+Canada?entry=gmail&source=g> > M9W 4Y8 > <https://www.google.com/maps/search/80+Galaxy+Blvd.++%7C+Toronto,+ON++%7C+M9W+4Y8++%7C+Canada?entry=gmail&source=g> > | > <https://www.google.com/maps/search/80+Galaxy+Blvd.++%7C+Toronto,+ON++%7C+M9W+4Y8++%7C+Canada?entry=gmail&source=g> > Canada > <https://www.google.com/maps/search/80+Galaxy+Blvd.++%7C+Toronto,+ON++%7C+M9W+4Y8++%7C+Canada?entry=gmail&source=g> > > > > > > > > > > > > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- 73 // Adam Wiethuechter // System & Protocol Engineer
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
