[OAUTH-WG] Artart last call review of draft-ietf-oauth-security-topics-25

[Russ Housley via Datatracker <[e-mail]>]

Reviewer: Russ Housley
Review result: Almost Ready

I am the assigned ART-ART reviewer for this draft. Please treat these
comments just like any other last call comments.


Document: draft-ietf-oauth-security-topics-25
Reviewer: Russ Housley
Review Date: 2024-02-18
IETF LC End Date: 2024-02-22
IESG Telechat date: Unknown


Summary: Almost Ready

Major Concerns:

Section 4: Some of the subsections contain MUST, MUST NOT, SHOULD, and
MAY statements.  Given the structure of the document, I expected all of
the words that are defined in RFC 2119 to appear is Section 2, with
discussion of attacks in Section 4.  Please consider lower case words.


Minor Concerns:

Section 1: I recognize that the term "Anti-patterns" is gaining favor,
but I still think that you should provide a brif introduction to the
concept.  Perhaps: Anti-patterns are patterns in software development
that are considered bad programming practices, but they seem to happen
over and over.

Section 2.3: It says:

   ...  If not, the resource server must refuse to
   serve the respective request. ...

The "If not" is ambiguous.  Which aspects of the previous sentence
does this cover?  Part is implemented by the access server and part is
implemented by the resource server.  Can the resource server always
determin whether the "the authorization server associates the access
token with the respective resource and actions"?  Please clarify.

Section 2.5: When is client authentication not possible?  In other
words, under what circumstances does an authorization server
implementer ignore this SHOULD statement?

Section 4.1.1: The text says: "First, the attacker ..."  However, there
is not "Second" or "Then" to go wit the "First".  Please reword.
Perhaps: s/First/To begin/

Section 4.1.2: The text says: "First, the attacker ..."  However, there
is not "Second" or "Then" to go wit the "First".  Please reword.
Perhaps: s/First/To begin/


Nits:

Abstract: Because the Abstract is not allowed to contain references:
          s/[RFC6749], [RFC6750], and [RFC6819]/
           /RFC 6749, RFC 6750, and RFC 6819/
           
Section 1: s/client talks to/client is talking to/

Section 1: s/when feasible/as soon as feasible/

Section 2.5: s/authentication if possible./authentication./

Section 3: s/attacker model/threat model/ (multiple places)

Section 3: s/(wifi)/(Wi-Fi)/

Section 4.4.1: I do not think the bolding in the Variants bullets is
helpful to the reader, especially in the plaintext document.

Section 4.10.1: I do not think the bolding at the send of the section is
helpful to the reader, especially in the plaintext document.