On Mon, Apr 11, 2022 at 11:13 AM Daniel Fett <m...@danielfett.de> wrote:
> Hi Rifaat, > Am 14.02.22 um 22:26 schrieb Rifaat Shekh-Yusef: > > As part of the preparation for the shepherd write-up, I reviewed the > document and have the following comments: > > https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-19.html > > > General comment > > The document refers to a number of drafts that are not active anymore, > e.g., token binding, pop key distribution, signing http requests, etc. > > What is the reason behind including these in this document? > > The reason is to provide a general idea of other approaches that have been > conceived and to discuss various approaches to specific problems. It may be > helpful to the reader to see that sometimes, a certain solution has been > discussed already, even when it was not pursued further. > > > I agree that including these might be useful to some people. But as a developer working on following this specification, this does not add much value and just adds more noise to the document. I think that all these, options considered but not pursued, could be captured in an appendix at the end of the document and you could refer to the appendix when needed. > Section 4.5.4 > > I am not clear on how the attacker can do that. Let’s take the > code_challenge example. Wouldn’t the AS be able to detect this attack > because it gets the *code verifier* associated with the *original code > challenge* from the Client? > > Yes, but this can be circumvented if the attacker can modify the > authorization request from the client to the AS before it reaches the AS. > In this case, the attacker can define the code_challenge in the request > such that it works with the code_verifier that will be sent later on. > > > But such an attack is not a limitation of this specific case. If an attacker is able to control the Client or mount a MITM attack between the Client and the AS, then all bets are off. I am looking at this from a developer perspective; what would a developer need to do in this case? Regards, Rifaat > Nits > > Section 2.1, 3rd paragraph, 3rd sentence: “MAY rely the” to “, MAY rely on > the” > > Section 2.3, second paragraph: replace ietf-oauth-resource-indicators with > RFC8707 > > Section 4.1.3. Last paragraph: replace the jwsreq and PAR draft references > with rfc9101 and rfc9126 respectively. > > Who might want to sweep through the document and update the various > references, as there seem to be too many old references > > Thanks, we will fix this for the next revision and update the references. > > -Daniel > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
