Thanks Nat, on 5: Server authentication was kind of assumed throughout the draft due to HTTPS being required but I think you're right that it might be good to add something more explicit about it. I'll add something towards that end in the next revision. on 3/4: I kind of liked the one line "cnf" in those examples but can change the formatting to indented to maybe show it more clearly on 2/1: DPoP doesn't change how the client id is conveyed to the AS. And the AS binds tokens directly to the DPoP key rather than the client id. So I'm not sure I understand or know how to answer or address these comments, to be honest.
On Thu, Apr 7, 2022 at 8:37 PM Nat Sakimura <sakim...@gmail.com> wrote: > Thanks for an excellent work. > I am happy that the public key confirmation method in JPOP [1] presented > at IETF OAuth WG in 2017 somewhat morphed into DPOP after 5 years. Also, I > was very happy to see the > > [1] https://datatracker.ietf.org/doc/html/draft-sakimura-oauth-jpop-00 > > I also apologize that due to circumstances, I was not able to contribute > much to the work during the time. It is almost the first read for me so > perhaps I could be completely off, but it may also provide the questions > that a new reader may pose. > > Here is a set of comments that came to my mind while reading the draft. > > 1. It was not immediately clear how the client_id is found from the > DPoP token request. In the case of JWT Client Authentication, it has `iss` > in it showing the client_id. In DPoP, it does not, so I am wondering how. > Some explanatory text would help. > 2. It was not immediately clear how the binding between the key > material presented in the DPoP header in the token request and the > client_id is checked. This is critical from the security point of view so > if it could be explained early on, perhaps in the first paragraph of > section 5, it would be great. > 3. In Figure 8, it would be great if "cnf" member is formatted as an > indented JSON member rather than an inline one as it stands. > 4. In Figure 10, it would be great if "cnf" member is formatted as an > indented JSON member rather than an inline one as it stands. > 5. DPoP Proof Replay described in 11.1 talks about limiting the > validity period as the mitigation. However, in the case of DPoP Proof > Phishing via MITM adversary, it is entirely possible that it is only used > once, in time, by the adversary. So, adding some guidance on server > authentication might be good to add. > > I might come up with some additional ones by the deadline, but for now, > the above is what I have. > > Cheers, > > Nat Sakimura > > > On Mon, Mar 28, 2022 at 9:01 PM Rifaat Shekh-Yusef < > rifaat.s.i...@gmail.com> wrote: > >> All, >> >> As discussed during the IETF meeting in *Vienna* last week, this is a *WG >> Last Call *for the *DPoP* document: >> https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ >> >> Please, provide your feedback on the mailing list by April 11th. >> >> Regards, >> Rifaat & Hannes >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > _______________________________________________ > 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
