Adam, Thank you for this. I should say that I did not know any of it — not DRIP, not DET or ORCHID, not HIP.
I have started reading. HIP looks closest to what I am describing, since there the identity is the key and the exchange that proves it derives the keys. The difference on my side is that the key should cease — it exists only while its conditions hold, so validity is neither asserted nor timed. I only half understand your registration-and-lookup case so far. I do not know how the querying parties are known to the registry in the first place — federated from their own organization, certificates, or a gateway per agency with the individual never visible. In short, not much at all. If you like, send me whatever you have privately and I will read it properly. I am interested, and would like to know whether what I am working on is any use to you — or not. To be clear, I focused on endpoint and encryption for 30+ years, and only 6 years on online access. 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: Adam Wiethuechter <[email protected]> Sent: Wednesday, September 23, 2026 4:05 PM To: Thi Nguyen-Huu <[email protected]> Cc: [email protected] Subject: Re: [OAUTH-WG] Beyond the DPoP / HTTPSig choice: login and session as one problem You don't often get email from [email protected]<mailto:[email protected]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> 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. 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 <[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 [cid:[email protected]] winmagic.com<https://winmagic.com/> [cid:[email protected]] 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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> -- 73 // Adam Wiethuechter // System & Protocol Engineer
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
