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]> 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]> > 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]> 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] >> To unsubscribe send an email to [email protected] >> > >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
