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

Denis <denis.ietf@free.fr> Fri, 10 August 2018 09:35 UTC

Return-Path: <denis.ietf@free.fr>
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 58A6C130ECA for <oauth@ietfa.amsl.com>; Fri, 10 Aug 2018 02:35:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 0wX897mmRwaL for <oauth@ietfa.amsl.com>; Fri, 10 Aug 2018 02:35:30 -0700 (PDT)
Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [212.27.42.6]) (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 F07A7130E8D for <oauth@ietf.org>; Fri, 10 Aug 2018 02:35:29 -0700 (PDT)
Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 40AD07803BF for <oauth@ietf.org>; Fri, 10 Aug 2018 11:35:28 +0200 (CEST)
To: oauth@ietf.org
References: <153021689405.18540.5214482725778765448@ietfa.amsl.com> <F399049B-C36E-4014-8717-B82270A2EBF8@lodderstedt.net> <CAAP42hCDH3bGiiyLX47SyKha1PnwhMLws=_25bTYj1pEz6at4g@mail.gmail.com> <629FEF02-7853-4FA5-8895-0851809C8BA0@lodderstedt.net>
From: Denis <denis.ietf@free.fr>
Message-ID: <aa74936a-ea2d-8798-0de3-5715504d80cc@free.fr>
Date: Fri, 10 Aug 2018 11:35:29 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <629FEF02-7853-4FA5-8895-0851809C8BA0@lodderstedt.net>
Content-Type: multipart/alternative; boundary="------------AA0FE179FCCFDCBB808FFC3C"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/JAPdHfNFYvwSitL-T6BWkX02IN0>
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: Fri, 10 Aug 2018 09:35:33 -0000

Hi William,

The draft states:

The goal of incremental authorization is to enhance end-user privacy
by allowing clients to request only the authorization scopes needed
in the context of a particular user action, rather than asking for
ever possible scope upfront.

Removing the requirement to request every possible scope that might be 
needed upfront would indeed be a nice feature.

Authorization scopes will thus be used in the context of a particular 
action. Servers should determine whether the authorization scope
matches with a particular action. However, the principle of minimum 
attributes should be used: only the authorization scope needed
to perform the particular action should be requested and then sent. In 
other words, authorization scopes should not be incremental.

A diagram of the exchanges should be added.

One of the approaches would be to allow the client to send an action 
(without sufficient authorization), so that the server can reply
by indicating the authorization scope needed for that particular action 
(if the current authorization scope is insufficient). Sending that
authorization scope in the next exchange would then allow to get an 
appropriate response from the server.

This means that the reply from the server to indicate the authorization 
scope needed for that particular action should also be normalized.

I would think that the wording 'user action authorization' should be 
used instead of 'incremental authorization'.
The next draft should better be named: 
draft-ietf-oauth-user-action-authz-00.

Denis

> Hi William,
>
> I think it would make sense to add AS metadata fields, which the AS can use to advertise support for include_granted_scopes and existing_grant.
>
> kind regards,
> Torsten.
>
>> Am 17.07.2018 um 19:33 schrieb William Denniss <wdenniss@google.com>:
>>
>> Hi Torsten,
>>
>> On Tue, Jul 17, 2018 at 7:57 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>> 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!
>>
>> Glad you like it! Thanks for reviewing.
>>   
>> - 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).
>>
>> I was torn about this. From a protocol perspective you're not implementing the protocol if you don't do that, so it should be a MUST. However, we need to be careful that we defer to the provider when it comes to what authorization is included as this is always their discretion.  I'll think of a better way to word this so that it can be a MUST while still not limiting the provider's discretion.
>>   
>>
>> - 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?
>>
>> Good point. That section is mostly talking about the client, I'll add a section for the server. I agree, the normal behavior would not be to revoke previously granted scopes (which is how Google implements it).
>>
>> Best,
>> William
>>
>>
>>> 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
>>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth