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]<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]
