Re: [OAUTH-WG] Artart last call review of draft-ietf-oauth-step-up-authn-challenge-12
Robert Sparks <rjsparks@nostrum.com> Mon, 20 March 2023 19:23 UTC
Return-Path: <rjsparks@nostrum.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F23C17B32C; Mon, 20 Mar 2023 12:23:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.676
X-Spam-Level:
X-Spam-Status: No, score=-6.676 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id js_H7rVsNXkr; Mon, 20 Mar 2023 12:23:34 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95880C14F74E; Mon, 20 Mar 2023 12:22:18 -0700 (PDT)
Received: from [192.168.1.102] ([47.186.48.51]) (authenticated bits=0) by nostrum.com (8.17.1/8.17.1) with ESMTPSA id 32KJMEJQ027216 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 20 Mar 2023 14:22:14 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1679340135; bh=M4tur3YckdpKuBt5jHNTyzAzHEfqK2obp14rObp75hA=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=R4D5U0g6p9XxTw5u8yyKVs+0N8Fbl0ydi7BwRMxT4I0K0DufZfF3sGaNlPCNzh977 cExlwCvFJBfYghgjE4TAseZcP8w6p0xQOfDRgQOZ7Djcw8WZzw6FMZgD3sfUubks1h xxDnqVvejnlwbtxOl/0Dov5LCwfAXBV55PuFMuHo=
X-Authentication-Warning: raven.nostrum.com: Host [47.186.48.51] claimed to be [192.168.1.102]
Content-Type: multipart/alternative; boundary="------------iCGJyxPZSjoIq48qVzcnNhYb"
Message-ID: <9a0f1e9c-33de-f828-ff64-407bd527e5df@nostrum.com>
Date: Mon, 20 Mar 2023 14:22:08 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.9.0
Content-Language: en-US
To: Vittorio Bertocci <vittorio@auth0.com>
Cc: art@ietf.org, draft-ietf-oauth-step-up-authn-challenge.all@ietf.org, last-call@ietf.org, oauth@ietf.org
References: <167778249416.23678.7058306125542432959@ietfa.amsl.com> <CAEFJvaqpu0JUwr-cLQaS_yqJedU1seDLXbN+_wiqv0kDmf+jPw@mail.gmail.com>
From: Robert Sparks <rjsparks@nostrum.com>
In-Reply-To: <CAEFJvaqpu0JUwr-cLQaS_yqJedU1seDLXbN+_wiqv0kDmf+jPw@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/RVfJ3Fz1TKvvaQWHqzv8Vaos2ys>
Subject: Re: [OAUTH-WG] Artart last call review of draft-ietf-oauth-step-up-authn-challenge-12
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Mar 2023 19:23:37 -0000
On 3/2/23 3:51 PM, Vittorio Bertocci wrote: > Hi Robert, > thanks for your comments! > Some of the ideas you mention here were also touched upon during the > AD review w Roman, the exchange we had might provide some context > https://mailarchive.ietf.org/arch/msg/oauth/PBDCtVB7vtou5Dlz6nPJxX_5Yyo/ > but more succinctly: Why can't much of what you had to explain to Roman and then to me be put in the draft? I think you have pretty good datapoints that the draft doesn't communicate your intent as you intend given those two points of feedback. You can _acknowledge_ the questions and let designers/implementors know what your general thinking was without trying to fully specify behavior. > > - "step down". One of the key reasons this spec exists is that the RS, > and only the RS, is the arbiter of what's good enough for a request at > a given moment. The exact same API call and exact same token that > worked few seconds earlier (and still meets the requirements of a > preceding challenge, including max_age) could be rejected later, and > trigger a completely different set of requirements, for example as the > result of black box logic executed by an anomaly detection engine on > the API side. Neither the client nor the AS can know in advance > whether a particular token will work again, all they can do is caching > tokens according to the call circumstances they know (URL, call > parameters etc) and hope it will work again, while remaining ready to > receive and process a new challenge if it doesn't. > > - Caching. Please see the discussion with Roman in the referenced > thread, it should address the question. > > - Nit: we'll remove the ref from the doc history on the next update :) > > thanks > V. > > > > > > > > On Thu, Mar 2, 2023 at 10:42 AM Robert Sparks via Datatracker > <noreply@ietf.org> wrote: > > > This message originated outside your organization. > > > 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. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
- [OAUTH-WG] Artart last call review of draft-ietf-… Robert Sparks via Datatracker
- Re: [OAUTH-WG] Artart last call review of draft-i… Vittorio Bertocci
- Re: [OAUTH-WG] Artart last call review of draft-i… Robert Sparks