Re: [OAUTH-WG] Comments on draft-ietf-oauth-incremental-authz-01

William Denniss <> Thu, 07 November 2019 01:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 34F7D12008F for <>; Wed, 6 Nov 2019 17:36:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FbKWpmeDb6iv for <>; Wed, 6 Nov 2019 17:36:42 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CD7A8120045 for <>; Wed, 6 Nov 2019 17:36:42 -0800 (PST)
Received: by with SMTP id d5so595032otp.4 for <>; Wed, 06 Nov 2019 17:36:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gh/BXr8hCBMpdH1JiMybEnEUyKcSkzICJpRzk/O5UXo=; b=kWwqM+nZhLD6CMm4Fsx+cRT4xmIltXDUgJA79dujdGdC34cRfrb5An1FPRqopxBsty nyXIArYP16Fa/9Vni0qj8+EtHhRf2wPER7To1kUaHyiIYH6nnri8xxDpew6/AfYHWx0M 7o9+dFy4OOdzN58o/pzh4Nn+TckPWpXpRKOBsJAlqyX9q4mYZpS6l9gP2laens7R2P9J tKhrgxDbGDcamWi3GcWfj/SzKLQavFYxbqkXepfGjMTwHNCnIMBSC6yCZa/5vcbNEANF HIPOkPJn97iET7teSjXa9p7oPtRCyF5L/ihafpFqQ7sX7UA2FgG+Itzq+JUuxTo5DZCK qxXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gh/BXr8hCBMpdH1JiMybEnEUyKcSkzICJpRzk/O5UXo=; b=I4B0ug4Qw6uF0/l2q8SsRbCryVBz4dn1+V7O8OG4jty3pxiza+odnV51ihkQbNGfba DsklLlZ05ed4cPH3bCPsd0ngC4WXmUfxlG9NaYsJOtLYnunPY0xwmpbaTKIfUDK+LYh2 +CEIehdzu5tmuG5qJa0oXkY42lov8//Ffh3CjZkIeTToXsdw/JXkkh/M9iT6CKEpIMl9 n4AKDW0pcAOt00nx5Fk5agQ86VqDCv8DFLRZ9cX0mrslFZH6krI7KLNcQsq9Q9iF/C3c Ij/xQDRsKvLUdELKJrDZFOCSPEbHPERtZ7qYhn8gmjs5skqA23QmJf/7dMaUgvPclOZA 2IJw==
X-Gm-Message-State: APjAAAWCfa7/HPBp44lT6a5vw+L0azx4Y2H7Xci6Z4MENUfc8kv1RZse Q7O2dt+3YRHuRx8SuKJg22j0MpHd8STNQ90X1Nep5g==
X-Google-Smtp-Source: APXvYqz1dyMY/WnisXDHdqvNZwdC8zLxnnPdhecD57+yHB32oZsa9q1vIgiHZ/KqyXJE2DHy8GbetDjReRxNatIqUfc=
X-Received: by 2002:a9d:bb6:: with SMTP id 51mr694125oth.158.1573090601565; Wed, 06 Nov 2019 17:36:41 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: William Denniss <>
Date: Wed, 06 Nov 2019 17:36:30 -0800
Message-ID: <>
To: Glen Mazza <>
Cc: oauth <>
Content-Type: multipart/alternative; boundary="00000000000081fecf0596b7b21d"
Archived-At: <>
Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-incremental-authz-01
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Nov 2019 01:36:45 -0000

Hi Glen,

Thank you for reviewing the draft. Replies inline:

On Wed, Sep 11, 2019 at 5:35 AM Glen Mazza <> wrote:

> In Section 6.1, Handling Denials of incremental authorization requests, I
> wonder if the resource owner should be provided the ability by the
> Authorization Server to reject not just the additional scope(s) but also
> all previously granted ones.  This would be to guard against the client
> withholding dubious permission requests at the outset that might indicate
> to the resource owner that the client isn't particularly reliable, scopes
> that if they were provided all at once at the beginning would have resulted
> in the user never approving any of them.  In the user is inclined to deny
> an additional permission request due to a newfound lack of trust, he may
> also want to immediately decline previously granted permissions as well.

It is definitely always the authorization server's prerogative to take such
an action. In my experience, this boils down to UX decisions made by the
authorization server. One way to implement this would be to remind the user
of previously granted scopes, and give them the opportunity to revoke them.
Or, you could do your suggestion of instantly revoking all scopes on the
denial of any one, however this may go against the user's wishes (they
might be happy to grant contacts, but not calendar, for instance, in much
the same way today on a mobile phone you may grant notifications, but
withhold location).

I don't think we need to change the spec normatively to enable such
behavior, since the server can already revoke tokens it issues. Clients
should detect this revocation during the next request to the resource
server, and handle it accordingly.

Perhaps we could add a discussion about these implementation choices for
Authorization Server

In Section 7.2, it seems odd for the Authorization Server to rely on the
> client to tell it what scopes has already been approved for it.  I would
> think there would need to be a mechanism for the Auth Server to verify that
> information, but given that, why not rely on that information directly
> instead of what the client would be informing it?

This section documents an alternative approach that clients can take today
(i.e. without needing this new specification). I'll illustrate with an
example. Let's say a website needs Contacts on day 1, and both Contacts and
Calendar on day 2, here's how you might implement that with pure RFC 6749:

Day 1. User performs an action that requires contacts access. The website
does an OAuth requests for contacts, which the user approves. Now the app
has one authorization (with its associated access token) for contacts.
Day 2. User performs an action that requires both calendar and contacts
access. The website knows that it already has contacts access, so it does a
new OAuth request only for calendar, which the user approves. Now the app
has two different authorizations, one for contacts, and one for calendar
(and 2 access tokens, and potentially 2 refresh tokens to keep track of).

When the app makes a request to the resource server, it needs to know which
authorization's access tokens to include on the request. This is what I
mean by the app "keep[s] a running record of all granted scope", basically
it needs to have an internal list of which token includes which scope,
something that is burdensome. The other option of course is to just ask for
all scopes up front (even the ones it may not need right then), which is
not an ideal user experience (as the user is asked to grant permission to
scopes unrelated to their current activity), and this is the problem we're
trying to solve with incremental authz.

This spec makes life easier for the confidential client to do incremental
authorization. An incremental authz flow instead looks like the following:

Day 1. User performs an action that requires contacts access. The app does
an OAuth requests for contacts, which the user approves. Now the app has
one authorization for contacts.
Day 2. User performs an action that requires both calendar and contacts
access. The app simply makes a request that includes both scopes. The
authorization server can see that contacts was already approved, so only
displays the new scope - calendar. The user approves, and a new
authorization grant is issued that includes *both* scopes. The app still
has one authorization, but now it includes the contacts and calendar scope.