[OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02

Roman Danyliw <rdd@cert.org> Tue, 16 July 2019 23:23 UTC

Return-Path: <rdd@cert.org>
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 D852D12002F for <oauth@ietfa.amsl.com>; Tue, 16 Jul 2019 16:23:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (1024-bit key) header.d=cert.org
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 iw9f9Ow_du7F for <oauth@ietfa.amsl.com>; Tue, 16 Jul 2019 16:23:33 -0700 (PDT)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 79D2A12002E for <oauth@ietf.org>; Tue, 16 Jul 2019 16:23:33 -0700 (PDT)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6GNNWlC027017 for <oauth@ietf.org>; Tue, 16 Jul 2019 19:23:32 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x6GNNWlC027017
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1563319412; bh=obx+rmOgpYoHlF7SIZsw04ovfE+a5lmu33ZZVHzo/2U=; h=From:To:Subject:Date:From; b=WKYEEVkIKdU0SHulBQQ4rYhpxLSgQ7fOOcKfO/K6NXzOsau23iZeemVYODri0nM3i ZZUBFJNoXPFrU8nOiMxiD6pxadI63kxifPT5rZE9HI7OcvKenfPlANufKgmahkUizi iptDmYtUs3Q5zaeHdSQpfyhKHeW7V4H9CNGLRGlA=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6GNNUbo025410 for <oauth@ietf.org>; Tue, 16 Jul 2019 19:23:30 -0400
Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0439.000; Tue, 16 Jul 2019 19:23:30 -0400
From: Roman Danyliw <rdd@cert.org>
To: "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: AD Review: draft-ietf-oauth-resource-indicators-02
Thread-Index: AdU8LNOah0VUVvCrRz+gltwjhgJkfg==
Date: Tue, 16 Jul 2019 23:23:29 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B33D6046@marchand>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.22.6]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/zS4HzoS_pyrTnEqBPeDynEdbbbQ>
Subject: [OAUTH-WG] AD Review: draft-ietf-oauth-resource-indicators-02
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: Tue, 16 Jul 2019 23:23:35 -0000

Hi!

The following is my AD review of draft-ietf-oauth-resource-indicators-02.  The document is in good shape.

(1) Section 2. Per "The parameter can carry the location of a protected resource, typically as an https URL, or a more abstract identifier", is this "abstract identifier" still an absolute URI per Section 4.3 of RFC3986?

(2) Section 2.2.  in the sentence "To the extent possible, when issuing access tokens, the authorization server should adapt the scope value associated with an access token to the value the respective resource is able to process and needs to know":

--  is this language suggesting that the authorization server is modifying the scope value based on the resource it sees?  I'm trying to understand what "adapt" means, especially in relation to the improved security and privacy the subsequent sentence suggests.

-- (Depending on the above) Is there a security consideration here for the server relative to confidential scope values and how they might be modified?

(3) Editorial
** Section 1 and 2.1.  Multiple Typo.  s/the the/the/g

** Section 2.  Editorial. s/resource at which/resource to which/

** Section 2.  Editorial.  
s/ And can also be used to inform the client that it has requested an invalid combination of resource and scope./
It can also be used to inform the client that it has requested an invalid combination of resource and scope./

** Section 2.1. Multiple Typo. s/an an/an/g

** Section 2.2.  Editorial. s/token request and response/token request (Figure 3) and response (Figure 4)/

** Section 3.  Typo.  s/a invalid/an invalid/

** Section 3.  Missing words.  "A bearer token that has multiple intended recipients (audiences) can be used by any one of those recipients at any other."  Is it protected resource?