I do not recall any agreement that “bearer + cnf” is the acceptable or preferred pattern. DPoP uses the “dpop" scheme today, which is the closest precedent. To this day I believe the MTLS spec’s re-use of “bearer” auth scheme is a mistake. In any case, this is not a bearer token and should not be accepted in any place that a bearer token would be accepted — that kind of downgrade would be a huge flaw in the system.
On key rotation, I think that’s going to be use case specific in a lot of ways, but it would be great to have additional privacy and security considerations — in the doc you can see that they’re basically stubs right now (along with IANA). — Justin On Jul 2, 2026, at 11:39 AM, Neil Madden <[email protected]> wrote: Hi Justin, Thanks for sharing this. A couple of initial thoughts: Why HTTPSig vs Bearer? What happens if a httpsig token gets sent in a bearer auth header? I thought we’d basically settled on using Bearer + cnf for everything. There probably needs to be a privacy considerations section about the impact of client requests being signed/non-repudiable, especially when the content is being signed. Perhaps clients should be encouraged to regularly rotate and publish their old private keys as suggested here (for DKIM), unless non-repudiation is specifically needed: https://blog.cryptographyengineering.com/2020/11/16/ok-google-please-publish-your-dkim-secret-keys/ — Neil On 2 Jul 2026, at 15:54, Justin Richer <[email protected]> wrote: Starting a new thread on this one: As you may have seen, I’ve updated the draft for applying HTTP Message Signatures to OAuth Access Tokens, and Aaron has joined as co-author. A pull for this work has come from a few different places lately and we’d like to see this move forward in the WG. https://www.ietf.org/archive/id/draft-richer-oauth-httpsig-02.html Please read the draft, it’s not that long and I’ve left a bunch of editor’s notes in places that I think we’d want to address more directly or would need WG debate to come to a satisfying answer. — 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]
