Andy Newton has entered the following ballot position for draft-ietf-oauth-browser-based-apps-24: Discuss
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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/ ---------------------------------------------------------------------- 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? UPDATE: based on the conversation of the telechat on 24 April this is no longer a discuss item. This document does not need to update 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? 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)? ### 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? ---------------------------------------------------------------------- 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? ## 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". _______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
