Skip to main content

OAuth 2.0 Security Best Current Practice
draft-ietf-oauth-security-topics-29

Note: This ballot was opened for revision 26 and is now closed.

Paul Wouters
Yes
Comment (2024-05-16 for -27) Not sent
Thanks for this very useful document.
Roman Danyliw
Yes
Erik Kline
No Objection
Comment (2024-05-05 for -26) Not sent
# Internet AD comments for draft-ietf-oauth-security-topics-26
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Nits

### S3

* "as good as practically possible" ->
  "as well as practically possible", perhaps?
Francesca Palombini
No Objection
Gunter Van de Velde
No Objection
Comment (2024-05-08 for -27) Not sent
# Gunter Van de Velde, RTG AD, comments for draft-ietf-oauth-security-topics-27.txt

Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/ documenting the handling of ballots.

#GENERIC COMMENTS
#================
## There are a bunch of idnits identified when running the tool
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-27.txt
Jim Guichard
No Objection
John Scudder
No Objection
Comment (2024-05-16 for -27) Sent
I read Section 3 before Section 2 (c.f. Éric’s comment) and that worked for me. 

One nit, “see #iuv_countermeasures” is presumably a broken xref.
Mahesh Jethanandani
No Objection
Comment (2024-05-11 for -27) Sent
Thank you for writing this document. Just a couple of comments.

Using lowercase "not" together with an uppercase RFC2119 keyword is not
acceptable usage. Found: "not RECOMMENDED"

The IANA review of this document seems to not have concluded yet.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "masterthesis"; alternatives might be "active", "central", "initiator",
   "leader", "main", "orchestrator", "parent", "primary", "server"
 * Term "man"; alternatives might be "individual", "people", "person"
 * Term "he"; alternatives might be "they", "them", "their"
 * Term "traditional"; alternatives might be "classic", "classical", "common",
   "conventional", "customary", "fixed", "habitual", "historic",
   "long-established", "popular", "prescribed", "regular", "rooted",
   "time-honored", "universal", "widely used", "widespread"
 * Term "native"; alternatives might be "built-in", "fundamental", "ingrained",
   "intrinsic", "original"
Murray Kucherawy
No Objection
Comment (2024-05-16 for -27) Sent
I quite agree with Eric's comments and suggestions about document flow.
Zaheduzzaman Sarker
No Objection
Comment (2024-05-14 for -27) Sent
Thanks for working on this specification. 

One observation, does it add any value to mention the OAuth working group in the following sentence after publication? 

  Section 2 says - This section describes the core set of security mechanisms and measures the OAuth working group considers to be best practices at the time of writing.

If there is no significant value add factor here, the it might be better to omit the working group name from sentence.
Éric Vyncke
No Objection
Comment (2024-05-14 for -27) Sent
Thank you for the work put into this document.

Special thanks to Hannes Tschofenig for the shepherd's detailed write-up including the WG consensus *BUT* the justification of the intended status is rather light.

My only comment is more on the flow: for the non-expert reader, reading sections 3+4 (threat) before will make it easier to undestanding the reasoning behind section 2.

I am trusting the SEC and APP ADs for the technical correctness of the document.