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]
