[art] Artart last call review of draft-ietf-oauth-step-up-authn-challenge-12

Robert Sparks via Datatracker <noreply@ietf.org> Thu, 02 March 2023 18:41 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: art@ietf.org
Delivered-To: art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B413C13A358; Thu, 2 Mar 2023 10:41:34 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Sparks via Datatracker <noreply@ietf.org>
To: art@ietf.org
Cc: draft-ietf-oauth-step-up-authn-challenge.all@ietf.org, last-call@ietf.org, oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 9.12.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <167778249416.23678.7058306125542432959@ietfa.amsl.com>
Reply-To: Robert Sparks <rjsparks@nostrum.com>
Date: Thu, 02 Mar 2023 10:41:34 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/Wh15ll_DAa4TOP3zaZ0sdYw6YNY>
Subject: [art] Artart last call review of draft-ietf-oauth-step-up-authn-challenge-12
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Mar 2023 18:41:34 -0000

Reviewer: Robert Sparks
Review result: Ready with Issues

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.