[Last-Call] Genart last call review of draft-ietf-oauth-step-up-authn-challenge-11

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Reviewer: Christer Holmberg
Review result: Ready with Issues

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"?



-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux