Update draft to cover latest changes of the security BCP

[kmzs]

PR #7:

• [x] Mix-up mitigations
• [x] Updated references to security BCP

Todo:

• [x] Implicit grant: Is not forbidden in security BCP. Security BCP: clients SHOULD NOT use the implicit grant Draft: Authorization servers MUST NOT issue access tokens in the authorization response (Section )

• [x] Refresh tokens: Different guidance on expiration. Security BCP: Refresh tokens SHOULD expire if the client has been inactive for some time, i.e., the refresh token has not been used to obtain fresh access tokens for some time. The expiration time is at the discretion of the authorization server. Draft: [AS] MUST either set a maximum lifetime on refresh tokens OR expire if the refresh token has not been used within some amount of time Also the security BCP does not say anything about this part: MUST NOT extend the lifetime of the new refresh token beyond the lifetime of the initial refresh token

• [x] Refresh token rotation: Security BCP requires PoP RTs or using RT rotation. Draft recommends RT rotation. Security BCP: Authorization server MUST utilize one of these methods [...] Sender-constrained refresh tokens [...] Refresh token rotation Draft: SHOULD rotate refresh tokens on each use

• [x] Update Overview section after all other updates are finished

• [x] Update Server Support Checklist in appendix after all other updates are finished

Maybe the first three points should be discussed on the mailing list.

[kmzs]

For sender-constraining refresh tokens the security BCP only mentions mTLS and Token Binding in Section 4.13.2. It should also mention DPoP there as DPoP is mentioned in Section 4.9.1.1.2 for sender-constraining for access and refresh tokens.

This draft should mention sender-constraining RTs using DPoP as an alternative for RT rotation.

[aaronpk]

I went ahead and updated the refresh token rotation issue to match the security BCP. For some reason draft 07 changed it from "MUST" to "SHOULD", but I can't find any notes in the meeting minutes or mailing list that motivated that change. So instead I updated it to match the current security BCP text: MUST either use refresh token rotation or sender-constrained refresh tokens.

[aaronpk]

I believe it was intentional to have the refresh token expiration be more strict in this draft compared to the security BCP. I've added the sentence about not extending the refresh token lifetime.

[aaronpk]

Same with the implicit grant, it was intentional that the browser-based app spec is more strict than the Security BCP in that instance.

[aaronpk]

This should be caught up now. Will probably have to do one more pass once the Security BCP is finished but I'll close this for now.