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

Glen Mazza <glen.mazza@gmail.com> Wed, 11 September 2019 12:33 UTC

Return-Path: <glen.mazza@gmail.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 9345F1208AC for <oauth@ietfa.amsl.com>; Wed, 11 Sep 2019 05:33:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 sS9QGj2LXB2b for <oauth@ietfa.amsl.com>; Wed, 11 Sep 2019 05:33:28 -0700 (PDT)
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72EFC1208A7 for <oauth@ietf.org>; Wed, 11 Sep 2019 05:33:28 -0700 (PDT)
Received: by mail-wm1-x332.google.com with SMTP id p13so3333806wmh.1 for <oauth@ietf.org>; Wed, 11 Sep 2019 05:33:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=x6oUCxHqqUgCpNkMuQL30MF9JL7Iypw0Zp4pyOaa7EI=; b=ahuPs107AizGK0P55LeMoQ+FJqqwU+xJwGzLD98injeboqH60yAq7l1Zq+SNMCNCY/ rLLoChWR0DPh94g9YDKi8Y/9ChRD+o76DlujNejEboTB7JpXwIHmK4gK1aytW6UqFIvx BwJP+58MlZis2j6p80/zsCaz2BpyFZ6mJFBqTPT9bGjDYSPwZV3TQEIApa/YtPgffo/A 0Il3vmDMLi7+Ls5Sn2MXTV24Zng2+1TmAbgmxm3xo5Epz3fAOZSPAszhT8Gf6yqVNJ1T w1UGjedFQlAzfTJrHZLf4r5ti43LyH5B7KxxFGpghcAD2Z6xpO5oCV/LrdlEssAvPDd8 xFHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=x6oUCxHqqUgCpNkMuQL30MF9JL7Iypw0Zp4pyOaa7EI=; b=nLdP2TS6LdSDceVzUd474WrNzfhxyyLbH4BcuKezwxcjstzn5Cj2e62g1fQadKL+hF W1p+wlwdkCFYyXXHQtCMTnE748ARHEVgGkih5P8ys4OLZeJVhYuqhFz0rZWTnb+mm3jA B/OAXg/ewRr8MpAdkN10IPIcY8i4J+T2krHecGEGBih9tkwHMIIIrGq5JJttNd52Cfaa IVfqxQFMJpD7VUzUxmDWhc0inIl5qQn4NmhjVq0brilWByohRaTxgVfGZe44HAgYvDz5 H/wgRyNdH+fwxSyrnWWmjcOi7iNGH2YIKCBnC5h6sGf1gP8dwYh+fZmF+3XFmXW4Qsd1 suIA==
X-Gm-Message-State: APjAAAUie6m9WKY5d7AGMldcxu9O1Lkji+dHH6sO1rrBlEgku27r6EZI 6XcS7GvVWkiAAozhmigWtMrAIj/tqUe7wKmiuBCe00Zwew0=
X-Google-Smtp-Source: APXvYqykERCF21xByhtNh/z4BY4vSf4tRF3baHc6M/BBXIBuuvUSJwslJweDDMnJLhvWHxrqVO5g7JmYJY7rfMU5dIc=
X-Received: by 2002:a1c:7407:: with SMTP id p7mr4041720wmc.31.1568205206517; Wed, 11 Sep 2019 05:33:26 -0700 (PDT)
MIME-Version: 1.0
From: Glen Mazza <glen.mazza@gmail.com>
Date: Wed, 11 Sep 2019 08:33:15 -0400
Message-ID: <CAC_m_FFcVWtU_cgV_OyZtJA3uirt5YiyJE+tz8DkPKkT8brCXg@mail.gmail.com>
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="00000000000044fbaf0592463a11"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/dUtQEYOC1LfeR0tMUOgf4khYSfw>
Subject: [OAUTH-WG] Comments on draft-ietf-oauth-incremental-authz-01
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 11 Sep 2019 12:34:56 -0000

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.

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?

Regards,
Glen