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

Benjamin Kaduk <> Wed, 04 September 2019 23:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 503B7120815; Wed, 4 Sep 2019 16:55:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Gy6OB1LF0K0D; Wed, 4 Sep 2019 16:55:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 477BC12007A; Wed, 4 Sep 2019 16:55:38 -0700 (PDT)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id x84NtXbW019089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 4 Sep 2019 19:55:35 -0400
Date: Wed, 04 Sep 2019 18:55:32 -0500
From: Benjamin Kaduk <>
To: Brian Campbell <>
Cc: The IESG <>,, oauth <>,
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
Subject: Re: [OAUTH-WG] Benjamin Kaduk's No Objection on draft-ietf-oauth-resource-indicators-05: (with COMMENT)
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: Wed, 04 Sep 2019 23:55:41 -0000

On Wed, Sep 04, 2019 at 05:19:27PM -0600, Brian Campbell wrote:
> Thanks Ben, for the review and non-objectional ballot.
> On Wed, Sep 4, 2019 at 3:13 PM Benjamin Kaduk via Datatracker <
>> wrote:
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-oauth-resource-indicators-05: No Objection
> ----------------------------------------------------------------------
> > ----------------------------------------------------------------------
> >
> > Abstract
> >
> > This seems to be a sentence fragment (maybe preface with "This document
> > specifies"?).
> >
> Hrm. Yeah, I suppose so. I guess I was trying to be efficient with the
> words but to the point of not having a complete sentence. I'll add that
> preface.
> > Section 2.1
> >
> >    For authorization requests sent as a JWTs, such as when using JWT
> >    Secured Authorization Request [I-D.ietf-oauth-jwsreq], a single
> >    "resource" parameter value is represented as a JSON string while
> >    multiple values are represented as an array of strings.
> >
> > jwsreq includes an example with "aud" in the request, yet this new
> > "resource" request parameter is also intended to influence the audience
> > of the resulting token.  I'm not sure whether we need to say anything
> > specifically about this in the document, but I'd like to have a better
> > understanding of how "aud" and "resource" would interact when both
> > present in the reqeust.
> > (This is presumably related to why the request parameter is called
> > "resource" and not "aud" or "audience", but unfortunately I seem to have
> > zoned out for that part of the WG discussion.)
> >
> In the context of a jwsreq request the "aud" indicates the intended
> recipient/audience of the singed authorization request itself, which will
> be the authorization server to whom the request is being made. This
> prevents a singed request meant for AS1 from being used successfully at
> AS2, for example. That "aud" does not do anything to influence the audience
> of the resulting token - it's really just metadata of the signed request
> that will be discarded once the singed request is validated. The "resource"
> parameter of this document indicates where the client intends to use the
> token its requesting, which can and will influence the audience of the
> resulting token. So "aud" and "resource" do not interact when both present
> in a signed authorization request.

Ah, of course; thanks for the refresher, and that makes perfect sense.

> And yes, this is related to why the request parameter is called "resource"
> and not "aud" and also I think related to the outstanding discuss you have
> on jwsreq. If this parameter were to have been called "aud" then there
> would be a name collision when used in conjunction with jwsreq where "aud"
> would have had two distinct and irreconcilable meanings at the same time.
> There are a few other reasons the WG landed on "resource" as the name but
> what you've alluded to up here was a big part of it.


>    If the client omits the "resource" parameter when requesting
> >    authorization, the authorization server MAY process the request with
> >    no specific resource or by using a pre-defined default resource
> >    value.  [...]
> >
> > Would/could this default value be global or on a per-scope basis or some
> > other finer granularity than global?
> >
> Yes, it could be any of those. Though I think most likely it'd be global or
> influenced by scope. Really, it'd be whatever that AS was doing in the
> absence of such a parameter before this document came along.

Very true :)

> >                                                                      The
> >    authorization server might use this data to inform the user about the
> >    resources the client is going to access on her behalf, to meet policy
> >    decision (e.g. refuse the request due to unknown resources), and
> >    determine the set of resources that can be used in subsequent access
> >    token requests.
> >
> > nits: comma after "e.g.", and maybe s/meet policy decision/apply policy/
> > (or similar), and "to" before "determine" for parallelism.
> >
> Okay, will do.
> > In Figure 1 we URL-encode the '.'s in "" but not in
> > "" in the request URL; should we be consistent?  (This
> > seems to be recurring throughout the examples.)
> >
> Shoot. I really do aim to be tighter with that kind of thing well before
> getting to the IESG evaluation phase. I suspect some copy/paste/change work
> along with not looking closely enough got the better of me here. I'll fix
> to use not-encoded '.'s throughout.
> > Section 2.2
> >
> >    needs to know.  This further improves privacy as scope values give an
> >    indication of what services the resource owner uses and downscoping a
> >    token to only that which is needed for a particular service can limit
> >    the extent to which such information is revealed across different
> >    services.  As specified in Section 5.1 of [RFC6749], the
> >
> > (nit?) I suggest to s/scope values give an indication of what services
> > the resource owner uses and/a list of scope values is an indication that
> > the
> > resource owner uses the multiple various services listed;/ since I
> > misparsed it the first time as-is.
> >
> Sure. Striving to avoid the ol' misparse is always good.
> > Section 3
> >
> >    An access token that is audience restricted to a protected resource
> >    that obtains that token legitimately cannot be used to access
> >    resources on behalf of the resource owner at other protected
> >    resources.  The "resource" parameter enables a client to indicate the
> >
> > nit: This sentence has a pretty strange construction.  I think the
> > intent is to say that that a token, legitimately presented to a
> > resource, cannot then be taken by that resource server and
> > illegitimately present it somewhere else for access to other resources.
> > But with the current wording we seem to be missing part of the part
> > where some entity obtains the token with intent for illegitimate access.
> >
> Yes, despite the pretty strange construction, you have the correct intent.
> I'll work on improving that sentence (borrowing heavily from your words
> there).
> >    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.  This will cause any access token issued
> >    for accessing the user controlled resource to have an invalid
> >    audience if replayed against the legitimate resource API.
> >
> > I'm not entirely sure what this is trying to say.  What is the
> > "legitimate resource API"?  Why would a token be issued for accessing a
> > user-controlled resource if that's something we're trying to avoid
> > having confused clients access?
> >
> Um... so on rereading that I might say that it's also "pretty strange".
> What it was trying to somehow say is similar to the previous nit about
> audience-restricted not being usable at the resource for whom the weren't
> intended. But saying so in the context of a multi-tenant environment.
> Basically it's trying to say that, in a multi-tenant environment, the
> resource URI and subsequent token audience need to have something that
> identifies the tenant so as to prevent the token from being used by one
> tenant to illegitimately access resources at a different tenant. I'll work
> on trying to improve that text to better explain all that.

Ah, yes, that's a very good point to make.  I'm happy to look at some draft
text if you want.

>    Although multiple occurrences of the "resource" parameter may be
> >    included in a request, using only a single "resource" parameter is
> >    encouraged.  A bearer token that has multiple intended recipients
> >    (audiences) indicating that the token is valid at more than one
> >    protected resource can be used by any one of those protected
> >    resources to access any of the other protected resources.  Thus, a
> >    high degree of trust between the involved parties is needed when
> >    using access tokens with multiple audiences.  Furthermore an
> >    authorization server may be unwilling or unable to fulfill a token
> >    request with multiple resources.
> >
> > Do we want to contrast this with an authorization code/refresh token,
> > which may be more likely to be issued with a multiple-resource/audience
> > property?
> >
> Yeah, it's perhaps worth making the distinction. Though I don't know that
> it needs to be explicitly contrasted per se. I think just qualifying the
> text above to more specifically say "... parameter may be included in a
> token request" (as apposed to authorization request) would be enough to
> indicate that the suggestion is only applicable to the access token and not
> authorization code/refresh token.

Sure; we don't need to overemphasize it.