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

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk 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:
----------------------------------------------------------------------

Thank you for this easy-to-read-document -- reducing the risk of using
bearer tokens seems worthwhile, since they are not going away very
quickly.

Abstract

This seems to be a sentence fragment (maybe preface with "This document
specifies"?).

Section 1

                                                           When the
   authorization server is informed of the resource that will process
   the access token, it can restrict the intended audience of that token
   to the given resource such that the token cannot be used successfully
   at other resources.

(This mechanism is only effective if the other resources are
checking in some fashion, whether by direct inspection of a structured
token or by a backchannel to the AS or otherwise, but I hope that
checking 'aud' is standard practice by now!)

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.)

   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?

                                                                     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.

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.)

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.

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.

   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?

   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?