Re: [OAUTH-WG] Refresh tokens in Security BCP -15

[Aaron Parecki <[e-mail]>]

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 <[e-mail]> 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>