Hi Brian, everyone The option 2 makes sense to me, because I think the DPoP Proof to AS and the one to RS play different roles. Maybe they should even have different names. However, AS/RS symmetry of option 1 is also attractive from the viewpoint of an implementer.
I think this topic is related to the question of "followup I: freshness and coverage of signature". The option 2 for the followup I will also break AS/RS symmetry. If we choose the option 2 for followup I, I think we might as well choose the option 2 for followup II, too. Toshio Ito From: OAuth <[email protected]> On Behalf Of Brian Campbell Sent: Thursday, December 3, 2020 7:29 AM To: oauth <[email protected]> Subject: [OAUTH-WG] DPoP followup II: confirmation style 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. 1. 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) 2. 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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
