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

From: Aaron Parecki <[email-masked]>
Date: Sun, 5 Apr 2020 12:24:43 -0700

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.

----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>

---

From: Aaron Parecki <[email-masked]>
Date: Mon, 6 Apr 2020 06:59:28 -0700

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 <[email-masked]> wrote:

> Hi Aaron,
>
> Am 05.04.20 um 21:24 schrieb Aaron Parecki:
>
> 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

---

From: Daniel Fett <[email-masked]>
Date: Mon, 6 Apr 2020 22:08:20 +0200

Am 06.04.20 um 15:59 schrieb Aaron Parecki:
> 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?

Sounds good to me. I will do that for the next version.

-Daniel