OAuth 2.0 Step Up Authentication Challenge Protocol
draft-ietf-oauth-step-up-authn-challenge-17
Yes
Roman Danyliw
No Objection
Erik Kline
Jim Guichard
John Scudder
Warren Kumari
Zaheduzzaman Sarker
(Andrew Alston)
(Robert Wilton)
Note: This ballot was opened for revision 13 and is now closed.
Paul Wouters
Yes
Comment
(2023-04-12 for -14)
Not sent
Thanks for the clear specification and for resolving the issues raised in the http and secdir directorate reviews
Roman Danyliw
Yes
Éric Vyncke
Yes
Comment
(2023-04-09 for -14)
Sent
Interesting acknowledgment section ;-)
Erik Kline
No Objection
Jim Guichard
No Objection
John Scudder
No Objection
Murray Kucherawy
No Objection
Comment
(2023-04-12 for -14)
Sent
Thanks to Robert Sparks for the ARTART reviews and Mark Nottingham for the HTTPDIR review. Please make sure the former was fully addressed before proceeding. The SHOULD at the top of Section 4 is bare. What happens if I don't do that? Or should this really be a MUST? Same question for the first SHOULD in Section 5. Is there ever a legitimate reason not to do what it says? I feel that claim names such as "acr" should be quoted. They look like misspelled words otherwise.
Warren Kumari
No Objection
Zaheduzzaman Sarker
No Objection
Andrew Alston Former IESG member
No Objection
No Objection
(for -14)
Not sent
Lars Eggert Former IESG member
No Objection
No Objection
(2023-04-12 for -14)
Sent
# GEN AD review of draft-ietf-oauth-step-up-authn-challenge-14 CC @larseggert Thanks to Christer Holmberg for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/oLXp-vndky-rjnfs7kkHjH8acSg). ## Comments ### Inclusive language Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance: * 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` ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### URLs These URLs in the document can probably be converted to HTTPS: * http://openid.net/specs/openid-connect-core-1_0.html ### Grammar/style #### Section 2, paragraph 12 ``` hentication level, and the new one- selecting the appropriate token for each ^^^^^^^^^^^^^^ ``` This word seems to be formatted incorrectly. Consider fixing the spacing or removing the hyphen completely. #### Section 4, paragraph 1 ``` Subsequent to the challenge in Figure 3, a cl ^^^^^^^^^^^^^ ``` Consider using "after". #### Section 5, paragraph 1 ``` requirements, the resource servers needs a way of accessing information abou ^^^^^ ``` The verb form "needs" does not seem to match the subject "servers". #### Section 6.2, paragraph 6 ``` ation server as a result of the requirements propagation method described he ^^^^^^^^^^^^ ``` An apostrophe may be missing. ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool
Robert Wilton Former IESG member
No Objection
No Objection
(for -14)
Not sent