[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
- [OAUTH-WG] Comments on draft-ietf-oauth-increment… Glen Mazza
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-incre… William Denniss