Skip to main content

Last Call Review of draft-ietf-oauth-step-up-authn-challenge-11
review-ietf-oauth-step-up-authn-challenge-11-genart-lc-holmberg-2023-02-23-00

Request Review of draft-ietf-oauth-step-up-authn-challenge
Requested revision No specific revision (document currently at 17)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2023-03-03
Requested 2023-02-17
Authors Vittorio Bertocci , Brian Campbell
I-D last updated 2023-02-23
Completed reviews Secdir Last Call review of -12 by Valery Smyslov (diff)
Artart Last Call review of -12 by Robert Sparks (diff)
Genart Last Call review of -11 by Christer Holmberg (diff)
Artart Telechat review of -13 by Robert Sparks (diff)
Httpdir Telechat review of -13 by Mark Nottingham (diff)
Assignment Reviewer Christer Holmberg
State Completed
Request Last Call review on draft-ietf-oauth-step-up-authn-challenge by General Area Review Team (Gen-ART) Assigned
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/oLXp-vndky-rjnfs7kkHjH8acSg
Reviewed revision 11 (document currently at 17)
Result Ready w/issues
Completed 2023-02-23
review-ietf-oauth-step-up-authn-challenge-11-genart-lc-holmberg-2023-02-23-00
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-oauth-step-up-authn-challenge-11
Reviewer: Christer Holmberg
Review Date: 2023-02-23
IETF LC End Date: 2023-03-03
IESG Telechat date: Not scheduled for a telechat

Summary: The document is well written, and easy to read. However, I have found
some issues that I would like the authors to address.

Major issues:

  QMa1: General

    As the document defines a new error code, and define new WWW-Authenticate
    parameters, should the document not be an Update to RFC 6750?

----

  QMa2: Section 4

    The text defines the procedures for the client.

    But, what if the client does not support the new error code and the new
    WWW-A parameters? I think there should be some backward compatibility text
    (or reference, if defined elsewhere).

    Especially it should be clear that the server will not receive the WWW-A
    parameters in the new request if the client does not support them.

----

Minor issues:

  QMi1: Section 3

    Can the new WWW-Authenticate parameters only be used with the new error
    code? If so, please indicate it.

---

  QMi2: Section 3

    Is the max_age value required to be given as a string value (as in the
    example)? If so, please indicate it.

---

Nits/editorial comments:

  QNi1: General

    Throughout the document uses "doesn't", "isn't" and "it's". I suggest
    replacing those with "does not", "is not" and "it is".

----

  QNi2: Abstract

    The text starts by talking about resource servers, requests etc. Eventhough
    the document title mentions OAuth 2.0, I think it would also be good to
    mention it in the beginning of the Abstract.

    E.g.,

    "When OAuth 2.0 is used, it is not uncommon for..."

----

  QNi3: Introduction

    Similar to the Abstract, I think it would be good to mention OAuth 2.0 in
    the beginning.

    Also, I am not sure what "API authorization scenario" means.

    Could you say "OAuth 2.0 authorization scenario"?

----

  QNi4: Introduction

    The text says: "An API might also determine"

    Should it say "authorization server" instead of "API"?