Hi Justin, As discussed before, Paul & I are definitely interested in the topic and were exploring similar ideas. We also had a session at OSW on how to best proceed with guaranteeing http message integrity for PoPs (e.g., add message digest to DPoP proof), but my takeaway was that people were more in favour of a construction fully based on http message signatures.
Definitely interested in the topic and also in helping to move this forward. Best Regards, Christian > On 1. Jul 2026, at 22:49, Justin Richer <[email protected]> wrote: > > Hi chairs et al, > > I’ve just uploaded an updated version of the draft, as promised: > https://www.ietf.org/archive/id/draft-richer-oauth-httpsig-01.html > > A handful of people have reached out off-list expressing a desire to help > bring this forward, but I’ll let them chime in if they like. > > — Justin > >> On Jun 30, 2026, at 12:25 PM, Justin Richer <[email protected]> wrote: >> >> Chairs, >> >> I would like to request a slot to discuss an update to >> https://datatracker.ietf.org/doc/draft-richer-oauth-httpsig/ as this has >> come up in a few places recently. At this point we’ve got several standards >> and profiles that describe how to bind HTTPSig to OAuth tokens, and several >> more communities that would like to do so in an interoperable way, so I >> think it’s time we brought it forward. >> >> I’m working on an update of the draft text ahead of the publication deadline >> for the meeting, but the core is basically straightforward: >> >> 1: How do you tie a key to an HTTPSig-bound access token? (I can predict >> pre-registered keys and DPoP style inline introduction, there might be >> others we want to cover) >> >> 2: How do you present an HTTPSig-bound access token? (Includes required >> components and parameters for the signature) >> >> 3: How do you verify an HTTPSig-bound access token? (Includes key >> resolution, coverage verification, and signature verification) >> >> We probably also want to talk about things like entity binding (via digest), >> response non-repudiation (from the FAPI profile), and possibly others. >> >> HTTPSig could ALSO be applied as a client authentication method, since it’s >> presenting proof of a key to the target, but I am not planning on running >> that idea down apart from a mention in this document. >> >> To be clear, my goal with this is to have it live as a deployment option >> alongside DPoP and MTLS, which each have their own niches and strengths. To >> that end, the WG is the best place to make sure we have good guidance to >> developers choosing a solution, and I would like to start that discussion. >> >> — Justin >> >>> On Jun 20, 2026, at 6:42 PM, Rifaat Shekh-Yusef <[email protected]> >>> wrote: >>> >>> All, >>> >>> As per the preliminary agenda, we have two OAuth sessions at: >>> Thursday, 2:00-4:00pm >>> Friday, 9:00-11:00am >>> >>> If you have not done so already, let us know, as soon as possible, if you >>> have a topic that you would like to present and discuss in Vienna. >>> >>> Regards, >>> Rifaat & Hannes >>> _______________________________________________ >>> 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] > > _______________________________________________ > 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]
