>> Yes, the example I provided is a very lightweight one which does take the >> form of CSRF, but it is only the simplest example of a family of automated >> authorization flow attacks. Indeed, a nonce (or hidden token, both serve the >> same purpose in this case) would be enough here. > > Great. So we need to add explicit text about preventing CSRF attacks at the > authorization endpoint.
General comment, not for this issue alone (and not specifically to the folks conversing here): There are a great many things we can say about threats and attacks, which is why we have the threats document by Torsten, et al. I'm generally in favour of putting more security considerations into the base document to describe threats that implementors need to be concerned about, and well-crafted text that the editors can drop in is a good thing. That said, the reason we decided to put "highlights" into the base doc's Security Considerations section, and then refer to the larger document for more details and a more complete threat analysis is that we wanted to strike a balance, keep the base doc for protocol details, and leave the threat descriptions in the base doc as general threat *classes*. As we debate the various attack descriptions and mitigations that we might like to add, please keep that balance in mind, and think carefully about whether the details of *this specific* attack should go into this document, or whether we just need to cover the general class of threats here and put the details of this attack into draft-ietf-oauth-v2-threatmodel. Otherwise, we might eventually merge the entire threat analysis document into the base, one paragraph at a time. Barry, as chair _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
