[OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT)

Adam Roach via Datatracker <noreply@ietf.org> Wed, 04 September 2019 06:06 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E2D12003E; Tue, 3 Sep 2019 23:06:43 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Adam Roach via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-oauth-resource-indicators@ietf.org, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, oauth-chairs@ietf.org, rifaat.ietf@gmail.com, oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.100.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Adam Roach <adam@nostrum.com>
Message-ID: <156757720342.20663.3055037033818226992.idtracker@ietfa.amsl.com>
Date: Tue, 03 Sep 2019 23:06:43 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/-YcUbKWejGmKd6qYNR9cSEUydUg>
Subject: [OAUTH-WG] Adam Roach's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
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, 04 Sep 2019 06:06:44 -0000

Adam Roach has entered the following ballot position for
draft-ietf-oauth-resource-indicators-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-resource-indicators/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Many thanks to everyone who worked on this refinement to OAuth.
It seems like it will be a significant improvement over today's
ad-hoc system.

I agree with Barry and Alexey about the need for some language discussing
the privacy implications of explicitly signaling audience resources to
OAuth servers.

---------------------------------------------------------------------------

§2:

>  The client SHOULD use the base URI of the API
>  as the "resource" parameter value unless specific knowledge of the
>  resource dictates otherwise.  For example, the value
>  "https://api.example.com/" would be used for a resource that is the
>  exclusive application on that host, however, if the resource is one
>  of many applications on that host, something like
>  "https://api.example.com/app/" would be used as a more specific
>  value.  Another example, for an API like SCIM [RFC7644] that has
>  multiple endpoints such as "https://apps.example.com/scim/Users",
>  "https://apps.example.com/scim/Groups", and
>  "https://apps.example.com/scim/Schemas" The client would use
>  "https://apps.example.com/scim/" as the resource so that the issued
>  access token is valid for all the endpoints of the SCIM API.

This seems pretty intuitive in the examples given. It may be a little
less clear when applications are indicated by query parameter instead
of path prefixes. For example, if an endpoint is running two applications
distinguished thus:

https://example.com/apps/?app=app1
https://example.com/apps/?app=app2

...and in a form that allows for additional parameters:

https://example.com/apps/?darkmode=true&version=1.2&app=app2

...then the notion of the "most specific API" isn't quite as clear.
Intuitively, I think the idea would be that the resource for app2
would be <https://example.com/apps/?app=app2>;. It may be useful
to include an example along these lines as an illustration.

---------------------------------------------------------------------------

§2.2:

>    &resource=https%3A%2F%2Fcontacts.example.com%2Fapp%2F
...
>        "access_token":"eyJhbGciOiJFUzI1NiIsImtpZCI6Ijc3In0.eyJpc3MiOi
>         JodHRwOi8vYXV0aG9yaXphdGlvbi1zZXJ2ZXIuZXhhbXBsZS5jb20iLCJzdWI
>         iOiJfX2JfYyIsImV4cCI6MTU4ODQyMDgyNiwic2NvcGUiOiJjb250YWN0cyIs
>         ImF1ZCI6Imh0dHBzOi8vY29udGFjdHMuZXhhbXBsZS5jb20vIn0.5f4yhqazc
>         OSlJw4y94KPeWNEFQqj2cfeO8x4hr3YbHtIl3nQXnBMw5wREY5O1YbZED-GfH
>         UowfmtNaA5EikYAw",

The "aud" value here is "https://contacts.example.com/" rather than the
"https://contacts.example.com/app/" that I would expect -- that is, I would
expect them to match. Am I misunderstanding the intended relationship between
"resouce" and "aud"?

---------------------------------------------------------------------------

§3:

>  Some servers may host user content or be multi-tenant.  In order to
>  avoid attacks that might confuse a client into sending an access
>  token to a resource that is user controlled or is owned by a
>  different tenant, it is important to use a specific resource URI
>  including a path component.

Related to my comment about §2 above, "path component" isn't quite sufficient.
What you want is "including any portion of the URI that identifies the
resource, such as a path component."