Skip to main content

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