I was at that OSW session and discussed some afterwards with you and Paul. My takeaway was rather different. The purported need for message content integrity from the PoP mechanism seems to stem from inappropriately wanting the oauth layer to address perceived infrastructure and deployment layer concerns. People in the room were more in favour of a construction fully based on http message signatures but my sense was that very few had actual skin in the game, so to speak, and a greenfield approach almost always sounds more appealing in the abstract.
On Wed, Jul 1, 2026 at 3:38 PM Christian Bormann <chris.bormann= [email protected]> wrote: > 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] > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
