Strongly in favour of 2. I think history shows that successful standards make security checks hard to get wrong rather than merely easy to get right.
— Neil > On 2 Dec 2020, at 22:28, Brian Campbell > <bcampbell=40pingidentity....@dmarc.ietf.org> wrote: > > There were a few items discussed somewhat during the recent interim > <https://datatracker.ietf.org/meeting/interim-2020-oauth-16/session/oauth> > that I committed to bringing back to the list. The slide below (also > available with some typos and omitted words as slide #18 from the interim > presentation > <https://datatracker.ietf.org/meeting/interim-2020-oauth-16/materials/slides-interim-2020-oauth-16-sessa-dpop-01.pdf>) > is the second one. To summarize (by basically repeating the content of the > slide): It’s been suggested that, for resource access, having the JWK in the > header of the DPoP proof JWT makes it too easy to just use that key to > validate the signature and miss checking the binding to the AT’s cnf/jkt > hash, which undermines the value of doing the binding in the first place. As > I see it, there are two options here and I'd like to gauge WG consensus on > which to move forward with. > It’s fine as is (AS/RS symmetry is nice, it's the same way confirmation works > in MTLS/TB, and the binding check is kinda fundamental to the whole thing so > it's not unreasonable to expect implementers to do it) > For resource access, put the full JWK in the AT’s confirmation and omit it > from the proof (less error prone, no hash function needed for confirmation, > somewhat less data overall between the two artifacts) > > > <Slide18.jpg> > > > > > 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 -- ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
