One of the important differences here is the client model between OAuth and GNAP — in GNAP, clients are ephemeral-first and pretty much tied to the key in play. any kind of long-running identity for the client is managed as an optimization on top of that, run by the AS. In OAuth, clients are expected to have a long-lasting relationship with the AS first, and any kind of dynamic, runtime, or ephemeral connection or identity is built around that.
So with OAuth clients, relying on jwks and jwks_uri makes sense because it’s rooted in the client model. That’s why we don’t ever pass the jwks or jwks_uri values at runtime in the HTTPSig spec here — it would be a layering violation. Rotating those keys is a registration problem that can be solved via registration constructs. If an attacker gets a hold of your JWKS document you’ve got a world of problems anyway, and this work would honestly just inherit those problems with eyes wide open. In GNAP, it’s not the same model at play, and so managing the keys associated with various entities is built into the protocol in a different way. There’s no assumed registration step in GNAP, but registration can happen either out-of-band (in which case updates happen out of band) or as a result of a TOFU introduction (in which case, updates happen in band using the same mechanisms you’ve described). Where things start to overlap is the introduction of the token-bound key at runtime. GNAP doesn’t separate the notion of the token key and a client key, really, because it’s different set of assumptions about the client’s relationship with the AS than we have in OAuth. But in the OAuth world, we’re treating them as different items — like we have with DPoP. And it’s assumed that if you’ve got a need to rotate a runtime key, you’ll just get a start off a new token request with the new key. Could we do a key-rotating upgrade in OAuth? Maybe, but we don’t have the grant or token lifecycle APIs that GNAP has to facilitate this, and we’d need to invent something or leverage something else like refresh tokens, perhaps. I think it’s an interesting avenue, but I would personally rather see that as an additional layer of future work if folks are interested in it. I’ll make a note to add it to the future work section of the I-D, as I agree it’s something the WG should at least think about. Thanks for raising this discussion! — Justin On Aug 17, 2026, at 7:57 PM, Andrii Deinega <[email protected]> wrote: Justin, in GNAP, as I recall, when a client wants to introduce the new key to an AS, it needs not only to prove it controls the corresponding (new) private key but also to prove it possesses the old private key. In our scenario, we deal with keys in the client’s (unsigned) metadata via the jwks or jwks_uri properties + resource servers that receive those keys. These keys are used to bind access tokens to a client, which somehow concerns me. Don't get me wrong, I find this to be a great addition, and an inexpensive (and new) way to achieve sender constrained access tokens. However, is this enough? I'm not so sure. What if an attacker gets control over the metadata document and keys it exposes? Do these tokens still count as sender constrained? As for TUF and its portions, I guess, it could serve as a source of ideas in this context. TUF starts with the signing of metadata, provides a reliable way to check its freshness (via timestamps as they call them), and of course, uses different keys for different roles (keys for rotation, or root keys, other keys for signing artifacts, etc.). Lastly, in TUF, all keys have expiration dates. All the best, Andrii On Mon, Aug 17, 2026 at 9:33 AM Justin Richer <[email protected]<mailto:[email protected]>> wrote: Hi Andrii, thanks for reading through. For JWK pre-registered keys, what “use” signaling would you have in mind? We used to have the “httpsig_bound_access_token_kid” value but pulled it out to use the runtime “kid” instead, which seems more explicit and flexible for clients who want to rotate to a new key in their keyset. So key rotation is supported by the client choosing a new key after having added it to the keyset. It’s not that dissimilar to GNAP, though GNAP is more explicit about the key values throughout and allows a smoother transition between by-value and by-reference given the different client model than what OAuth has. What portions of TUF would you recommend pulling over here? — Justin On Aug 11, 2026, at 7:34 PM, Andrii Deinega <[email protected]<mailto:[email protected]>> wrote: Justin, I like this idea and draft, but I also want to raise a few questions and share some concerns for discussion. To start off, keys exposed through the client's registration (either via Dynamic Client Registration or the Client Id Metadata Document) should be explicitly marked for their intended "use", the standard "sig" value for that may not work alone. Then, how are we going to support (smooth) key rotation? As I recall, a JSON Web Key (JWK) doesn't include properties such as "exp", "iat", etc. One more... The Client Id Metadata Document is not signed so how can we validate that the client actually controls the corresponding private key? We did some exercises and addressed some of these challenges in GNAP back in the day, and all these Qs seem relevant here, right? We might also consider drawing some ideas from the The Update Framework (TUF) to address them. Regards, Andrii Deinega On Tue, Jul 28, 2026 at 10:55 AM Justin Richer <[email protected]<mailto:[email protected]>> wrote: After the meeting last Friday, a bunch of us joined up to work on the HTTP Message Signatures draft — huge thanks to Paul, Christian, and Filip for joining me and Aaron. Name: draft-richer-oauth-httpsig Revision: 03 Title: OAuth Proof of Possession Tokens with HTTP Message Signatures Date: 2026-07-28 Group: Individual Submission Pages: 23 URL: https://www.ietf.org/archive/id/draft-richer-oauth-httpsig-03.txt Status: https://datatracker.ietf.org/doc/draft-richer-oauth-httpsig/ HTML: https://www.ietf.org/archive/id/draft-richer-oauth-httpsig-03.html HTMLized: https://datatracker.ietf.org/doc/html/draft-richer-oauth-httpsig Diff: https://author-tools.ietf.org/iddiff?url2=draft-richer-oauth-httpsig-03 This new version changes how we present inline public keys, and adds the first step of considerations for RS-side validation of bound tokens. Please read through this when you can, and implement it if you can, and give us your comments on here or on GitHub. We've asked the chairs to schedule and interim to discuss this work and we'd like to bring this forward for adoption modulo the interim discussion. * Justin _______________________________________________ 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]
