Re: [Ace] I-D Action: draft-ietf-ace-oauth-authz-27.txt

Benjamin Kaduk <kaduk@mit.edu> Mon, 25 November 2019 23:04 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 119331200C4 for <ace@ietfa.amsl.com>; Mon, 25 Nov 2019 15:04:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SndGVKGsPEVL for <ace@ietfa.amsl.com>; Mon, 25 Nov 2019 15:04:26 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AF6C12003E for <ace@ietf.org>; Mon, 25 Nov 2019 15:04:16 -0800 (PST)
Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xAPN4BYB006227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 25 Nov 2019 18:04:14 -0500
Date: Mon, 25 Nov 2019 15:04:11 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Ludwig Seitz <ludwig.seitz@ri.se>
Cc: ace@ietf.org
Message-ID: <20191125230411.GN32847@mit.edu>
References: <157430230677.769.6413870274615783065@ietfa.amsl.com> <b2ad5cc9-0caa-137d-79f0-2a9bfe1060e3@ri.se>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <b2ad5cc9-0caa-137d-79f0-2a9bfe1060e3@ri.se>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/zlbwzWgYJxEHyur1SxgIjOpX-rI>
Subject: Re: [Ace] I-D Action: draft-ietf-ace-oauth-authz-27.txt
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Nov 2019 23:04:28 -0000

Hi Ludwig,

On Thu, Nov 21, 2019 at 03:16:03AM +0100, Ludwig Seitz wrote:
> Hello ACE,
> 
> turns out -26 didn't cover one of the items in Ben's review, namely the 
> question of using Client introspection to determine token expiration as 
> a lower bound for key expiration. Since the whole issue of Client 
> introspection was contentious between OAuth experts, we decided to 
> remove the text describing that option.  This still leaves us with the 
> two other options, so the problem is still covered.

Thanks for all the updates!  I'm just about ready to push the "request Last
Call" button, but wanted to check one thing first:

Section 5.6.3 seems to limit the error responses to 4.00 and 4.01, but
Section 5.8.2 also talks about 4.03 and 4.05.  I noticed because I was
checking Section 5.1.1's note about "unauthorized_client" error response against the
various options in 5.8.2, to see if we're internally consistent about when
we say to send errors vs. AS request creation hints.  My recollection is
that we can have all three of a response code, error response (e.g.,
"unauthorized_client"), and (our custom format of) response payload present
in the same response, so any potential conflict would be limited to just
the response code, but please correct me if I'm wrong about that.

Also, a few nits that could be treated as LC comments:

There's a stray 'W' in Figure 7

In Section 6.8: s/obsole/obsolete/, and s/profile/ace_profile/

In Section 8.16 we removed the entire "Specifications are required for the
standards track range of point assignment[...]" bullet point.  I think that
only the first two sentences of that bullet point were redundant with RFC
8126, and the last two ("Specifications are needed for the first-come,
first-serve range if they are expected [...]") reflected new requirements.


Thanks,

Ben