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? _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth