Thanks for your detailed review and comments Andy! Responses are inline.
On Wed, Apr 16, 2025 at 3:40 PM Andy Newton via Datatracker < nore...@ietf.org> wrote: > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > # Andy Newton, ART AD, comments for draft-ietf-oauth-browser-based-apps-24 > CC @anewton1998 > > * line numbers: > - > > https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-24.txt&submitcheck=True > > * comment syntax: > - https://github.com/mnot/ietf-comments/blob/main/format.md > > * "Handling Ballot Positions": > - > https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > > ## Discuss > > Many thanks to authors and working group for putting this document > together. > And thanks to all the reviewers who have provided very good feedback. > > ### Update RFC 9700 > > 166 Many of these recommendations are derived from the Best Current > 167 Practice for OAuth 2.0 Security [RFC9700], as browser-based > 168 applications are expected to follow those recommendations as > well. > 169 This document expands on and further restricts various > 170 recommendations given in [RFC9700]. > > Given the above text which states that it further restricts RFC 9700, > should this document be listed as updating RFC 9700? > I am not 100% sure of the criteria for marking an RFC as updating another, but I don't think that is the case here. The recommendations in this draft are meant to be complementary to RFC 9700. > > ### Consistency of Terms > > 188 "Browser-based application": An application that is dynamically > 189 downloaded and executed in a web browser, usually written in > 190 JavaScript. Also sometimes referred to as a "single-page > 191 application", or "SPA". > > This draft introduces the term "Browser-based application" which is used > in some places, but it also uses the term "Javascript application" in > many more places. Here is an example where the two terms are used > together and to mean the same thing (I think). > > 1436 The token-mediating backend counters the first two attack > scenarios > 1437 by not exposing the refresh token to the browser-based > application. > 1438 Even when the attacker gains full control over the JavaScript > 1439 application, there are simply no refresh tokens to be stolen. > > Is a JavaScript application the same thing as a browser-based application > in this document? I also noticed a few places where the term SPA or single > page application were used. If these are all the same term, can one term > be used instead of many? And if they are separate terms, can their > definitions > all be given even if quoting from a reference? > Yes, these are all intended to refer to the same thing. I've just gone through and updated all the uses of "JavaScript application" to "browser-based application" or "application" where appropriate. The few references that remain to "JavaScript" should only be where we are talking about JavaScript APIs specifically. > > 1737 In this scenario, the application sends JavaScript-based > requests to > 1738 the authorization server and the resource server. Given the > nature > > What is a Javascript-based request? Is this a request for data in JSON > format > or is it a request being made by code of the JavaScript application (or > browser-based application)? > I've rephrased this to be more clear: "...the application uses a browser API to send requests..." > > ### BFF as an HTTP Proxy > > From the description of the BFF with respect to the browser-based > application > and the resource server, it appears to act as an HTTP proxy as defined in > Section 3.7 of RFC 9110. Should this document make note of this > and reference the message forwarding requirements of Section 7.6 in RFC > 9110? > > The BFF is not intended to act like an HTTP proxy. It is more like a gateway or reverse proxy, except that in this case it is considered part of the OAuth client rather than part of the resource server (API). I've swapped some of the uses of "proxies" with "forwards" to hopefully avoid this connotation. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > ## Comments > > ### BFF Operational Considerations > > As the BFF is forwarding/proxying all requests to the resource server, > I wonder if there are any operational issues to consider. If a resource > server is rate limiting requests based on IP addresses, might it start > blocking requests as it would appear many users are originating from > one or a few sources? > > Good call-out. I've added a new consideration under this pattern describing this. > > ## Nits > > ### hard drive > > 905 cookies are never written to the user's hard drive in plaintext > > Most users today probably do not use equipment with hard drives. > This is probably better said as "local, persistent storage". > > Thanks, I've updated the text accordingly. These changes are currently in the GitHub repo but not yet published to datatracker. Here are the individual commits if you'd like to see the diffs: * https://github.com/oauth-wg/oauth-browser-based-apps/commit/728c360988399d6374f02677ac6202abc447a2f3 * https://github.com/oauth-wg/oauth-browser-based-apps/commit/95f2ca974bc34fef5b8294000cbb4da5112e1d6c * https://github.com/oauth-wg/oauth-browser-based-apps/commit/b6c6f25ba949b268e4d22b57f2cae31f69b905e8 * https://github.com/oauth-wg/oauth-browser-based-apps/commit/f33b5f02b67de0aea697f4a45a5970e7df7d4b8f The current preview snapshot is here: https://drafts.oauth.net/oauth-browser-based-apps/draft-ietf-oauth-browser-based-apps.html Thanks! Aaron
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
