Skip to main content

Last Call Review of draft-ietf-oauth-step-up-authn-challenge-12

Request Review of draft-ietf-oauth-step-up-authn-challenge
Requested revision No specific revision (document currently at 17)
Type 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-03-02
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 Robert Sparks
State Completed
Request Last Call review on draft-ietf-oauth-step-up-authn-challenge by ART Area Review Team Assigned
Posted at
Reviewed revision 12 (document currently at 17)
Result Ready w/issues
Completed 2023-03-02
Summary: essentially ready but with issues to consider before being published
as a proposed standard RFC.


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.

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.