Hi @all, I'm planning to read those I-D as they might be useful in a project, and I'm happy to provide feedback on digest usage. In general, when building protocols over HTTP it is necessary to take into account the semantics (eg. range requests, caching, ...) because reverse proxies, WAF and api gateways implement them: this is true whether you use digest or other fields.
Is there a git repo to provide feedback? I hope to do it in the next few weeks.. Have a nice day, R: Il giorno ven 19 feb 2021 alle ore 22:51 Brian Campbell <bcampbell=40pingidentity....@dmarc.ietf.org> ha scritto: > > My inclination is to keep digest[1] out of the base DPoP document. I do > believe that including it would add unneeded complexity to regular old DPoP > (there are some subtleties around digest that make it more complicated than > one might expect) and, from a design philosophy perspective, DPoP has always > aspired to be only a proof-of-possession mechanism in and of itself and not > venture into the realm of HTTP message integrity or general signatures. > > > [1] Note that the digest header is defined in RFC3230 but there's work > underway to obsolete that RFC with draft-ietf-httpbis-digest-headers-04 > > > On Wed, Feb 17, 2021 at 2:54 PM Justin Richer <jric...@mit.edu> wrote: >> >> Two different specifications (GNAP and FAPI signatures) have recently >> profiled DPoP to use its signature method to protect a different kind of >> protocol entirely. One thing these methods have in common is that they both >> define an additional field for holding a digest of the HTTP Message Body: >> >> https://bitbucket.org/openid/fapi/src/master/Financial_API_Simple_HTTP_Message_Integrity_Protocol.md#markdown-header-521-htd-the-digest-of-the-http-request-or-response-body >> >> https://www.ietf.org/archive/id/draft-ietf-gnap-core-protocol-03.html#name-demonstration-of-proof-of-p >> >> Both of these have the same semantics, and we’re changing the name in GNAP >> to align with the FAPI one. This begs the question: do we want to just >> define this field as an optional component in DPoP instead of having these >> profiles do it separately? It would save them from needing to align with >> each other, and anyone else from inventing it again. >> >> Is it worth defining this in DPoP directly, or does that complicate the spec >> too much? I’ve previously raised a similar question on including a hash of >> the access token in the DPoP request to the RS. >> >> — Justin >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
