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

[Benjamin Kaduk <[e-mail]>]

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 <
> [e-mail]> wrote:
> 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-oauth-resource-indicators-05: No Objection
> 
> ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > 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.

Agreed.

> 
> 
>    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 "client.example.org" but not in
> > "api.example.com" 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.

Thanks,

Ben