The discussion during the interim wasn't really about replay protection but rather about precomputation and exfiltration. Something like a server contributed nonce can potentially work to address both though so discussing such things gets fuzzy quickly.
The approach to reply protection in DPoP is a bit different than what ACME's done. It's arguably somewhat less robust but I think it is appreciably simpler and is appropriately so because the replay of a DPoP proof itself isn't of primary interest. To the extent possible/reasonable, simplicity was and still is a goal of the DPoP design. On Tue, Mar 16, 2021 at 5:21 PM Benjamin Kaduk <ka...@mit.edu> wrote: > On Tue, Mar 16, 2021 at 05:45:46PM -0400, Rifaat Shekh-Yusef wrote: > > Brian, > > > > For a nonce-based replay protection you. might want to look at the ACME > > protocol here: > > https://tools.ietf.org/html/rfc8555#section-6.5 > > Yes, that one is really solid for the sort of thing it does, and I find > myself recommending it over and over again. > Of course, that workflow is not universally applicable, so sometimes it's > not the right thing to do (and I don't remember enough about DPoP to say if > it works there). > > -Ben > -- _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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
