Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-incremental-authz-00.txt

Torsten Lodderstedt <torsten@lodderstedt.net> Tue, 17 July 2018 14:57 UTC

Return-Path: <torsten@lodderstedt.net>
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 23504130FA3 for <oauth@ietfa.amsl.com>; Tue, 17 Jul 2018 07:57:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 3olJ95KRMBTC for <oauth@ietfa.amsl.com>; Tue, 17 Jul 2018 07:57:26 -0700 (PDT)
Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.103]) (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 64BED130F18 for <oauth@ietf.org>; Tue, 17 Jul 2018 07:57:19 -0700 (PDT)
Received: from [84.158.233.58] (helo=[192.168.71.123]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from <torsten@lodderstedt.net>) id 1ffRPg-0000PZ-EA; Tue, 17 Jul 2018 16:57:16 +0200
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Message-Id: <F399049B-C36E-4014-8717-B82270A2EBF8@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_8AE21BD8-6EA5-4E77-9D27-00ACA47FC537"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Tue, 17 Jul 2018 16:57:13 +0200
In-Reply-To: <153021689405.18540.5214482725778765448@ietfa.amsl.com>
Cc: oauth <oauth@ietf.org>
To: William Denniss <wdenniss@google.com>
References: <153021689405.18540.5214482725778765448@ietfa.amsl.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/vAhoFUti72f4ypN2tSlH4Me9Aig>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-incremental-authz-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.27
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: Tue, 17 Jul 2018 14:57:48 -0000

Hi William, 

please find below my review feedback.

First of all, I think you managed to come up with the minimal extension needed to address a very relevant use case. Thanks!

- Section 5, last paragraph. 

"the new refresh token issued in the Access Token Response (Section 4.1.4 of ) SHOULD include authorization for the scopes in the previous grant.“

Wouldn’t it be better to make that a MUST? Otherwise the client must assume the AS decides to not include all previously granted scopes, which in turn means the client must keep older grants (and hope the AS dd not automatically revolve it).

- Section 6.1.1

The section describes how a client should handle denial for incremental authorizations. How is the AS supposed to handle it? From the text one could deduce the AS should not discard any pre-existing granted scopes. Is that correct? Would it make sense to explicitly state that?

kind regards,
Torsten. 


> Am 28.06.2018 um 22:14 schrieb internet-drafts@ietf.org:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Web Authorization Protocol WG of the IETF.
> 
>        Title           : OAuth 2.0 Incremental Authorization
>        Author          : William Denniss
> 	Filename        : draft-ietf-oauth-incremental-authz-00.txt
> 	Pages           : 8
> 	Date            : 2018-06-28
> 
> Abstract:
>   OAuth 2.0 authorization requests that include every scope the client
>   might ever need can result in over-scoped authorization and a sub-
>   optimal end-user consent experience.  This specification enhances the
>   OAuth 2.0 authorization protocol by adding incremental authorization,
>   the ability to request specific authorization scopes as needed, when
>   they're needed, removing the requirement to request every possible
>   scope that might be needed upfront.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-incremental-authz/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-incremental-authz-00
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-incremental-authz-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth