Last Call Review of draft-ietf-oauth-step-up-authn-challenge-12
review-ietf-oauth-step-up-authn-challenge-12-artart-lc-sparks-2023-03-02-00
Request | Review of | draft-ietf-oauth-step-up-authn-challenge |
---|---|---|
Requested revision | No specific revision (document currently at 17) | |
Type | IETF Last Call Review | |
Team | ART Area Review Team (artart) | |
Deadline | 2023-03-03 | |
Requested | 2023-02-17 | |
Authors | Vittorio Bertocci , Brian Campbell | |
I-D last updated | 2023-09-08 (Latest revision 2023-06-26) | |
Completed reviews |
Secdir IETF Last Call review of -12
by Valery Smyslov
(diff)
Artart IETF Last Call review of -12 by Robert Sparks (diff) Genart IETF 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 | Robert Sparks |
State | Completed | |
Request | IETF Last Call review on draft-ietf-oauth-step-up-authn-challenge by ART Area Review Team Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/art/Wh15ll_DAa4TOP3zaZ0sdYw6YNY | |
Reviewed revision | 12 (document currently at 17) | |
Result | Ready w/issues | |
Completed | 2023-03-02 |
review-ietf-oauth-step-up-authn-challenge-12-artart-lc-sparks-2023-03-02-00
Summary: essentially ready but with issues to consider before being published as a proposed standard RFC. Issues: I expected to find some discussion of considerations of avoiding "step down" given the intuitive appeal to "step up". Can the client or Authorization server notice if the resource server has through whatever fault asserted that it will only accept the use of an authentication context class that is blatantly inferior to what has already been provided? And if they notice, what is expected to happen? Or is it expected that this is allowed, particularly when a short max_age is also supplied? The document also suggests that the client hold on to, and possibly re-use in the future, access tokens that have been challenged as having insufficient user authorization. Is this behavior something that follows a well-known and well-implemented pattern documented elsewhere? If so, a pointer would be useful. If not, this seems like something that deserves more discussion if not more definition. Nits: The reference to abr-twitter-reply will go away with the changelog when the RFC Editor removes it. It would be kind to acknowledge that in the note to the RFC Editor so that they know it's expected and don't have to ask.