Keeping the details in section 4 makes sense. I think why I was confused is that there isn't a subheader in section 2 for refresh tokens so it's not immediately obvious until you get to section 4. What about adding a new subhead in section 2 with just that short summary and referring to section 4 for details?
Aaron On Mon, Apr 6, 2020 at 12:24 AM Daniel Fett <f...@danielfett.de> wrote: > Hi Aaron, > > Am 05.04.20 um 21:24 schrieb Aaron Parecki: > > I believe the document would flow better if section 4.12 about Refresh > Tokens were moved into section 2. The Refresh Token section contains > descriptions of some pretty significant normative behavior, and I worry > that it will get lost in the long list of attacks and mitigations. > > Section 2 starts with a description: "This section describes the set of > security mechanisms the OAuth working group recommends to OAuth > implementers.", and the whole section on refresh tokens seems like a pretty > significant recommendation. > > So far the approach was to keep the recommendations in Section 2 rather > brief and to have the details in Section 4. I would like to keep it that > way. > > The Refresh Token section in Section 4 has a lot of discussion that puts > the recommendations in context. Section 2 refers to that section with the > sentence "Refresh tokens MUST be sender-constrained or use refresh token > rotation as described in Section 4.12.". It catches the main normative > change and refers Section 4 for details. > > I propose to just highlight that sentence a little bit more (make it its > own paragraph). > > -Daniel > -- ---- Aaron Parecki aaronparecki.com @aaronpk <http://twitter.com/aaronpk>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
