Authors, While reviewing this document during Final Review, please resolve (as necessary) the following questions, which are also in GitHub issues (see https://github.com/rfc-editor-drafts/FinalReview-rfc10017/issues).
1) <!--[rfced] Should this document be assigned a new BCP number, or should it be part of an existing BCP such as BCP 212 or BCP 240? See the complete list of BCPs here: https://www.rfc-editor.org/bcps --> 2) <!-- [rfced] FYI: We updated [I-D.ietf-httpbis-rfc6265bis] to [PRE-RFC10025] for now. We will make the final updates in RFCXML (i.e., remove "PRE-" in "PRE-RFC10025" and"PRE-10025"). --> 3) <!-- [rfced] FYI: We updated the formats of the W3C and WHATWG references to include "this version" and "latest version" URLs. In the case of WHATWG, we added "commit snapshots" to the references to provide a snapshot of the specification as it existed at the time of publication. --> 4) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 5) <!-- [rfced] Does applications "executing in a browser" mean applications that run/operate in a browser? If so, would the perhaps text be clearer? Original: This specification describes different architectural patterns for implementing OAuth 2.0 clients in applications executing in a browser. Perhaps: This specification describes different architectural patterns for implementing OAuth 2.0 clients in browser-based applications. --> 6) <!--[rfced] We note that "resource owner" is only used within the term "Resource Owner Password Credentials Grant". Given this, should it be removed from the text below, or is it okay to leave it as is? Current: This specification uses the terms "access token", "authorization endpoint", "authorization grant", "authorization server", "client", "client identifier" (client ID), "protected resource", "refresh token", "resource owner", "resource server", and "token endpoint" as defined by OAuth 2.0 [RFC6749]. --> 7) <!--[rfced] We updated the following term descriptions for consistency (i.e., expansion first and then the description). Please let us know of any objections. Original: "PKCE": Proof Key for Code Exchange (PKCE) [RFC7636], a mechanism to prevent various attacks on OAuth authorization codes. "DPoP": OAuth 2.0 Demonstrating of Proof of Possession (DPoP) [RFC9449] is a mechanism to restrict access tokens to be used only by the client they were issued to. "CORS": Cross-Origin Resource Sharing [Fetch], a mechanism that enables exceptions to the browser's same-origin policy. "CSP": Content Security Policy [W3C.CSP3], a mechanism of restricting which resources a particular web page can fetch or execute. Current: PKCE: Proof Key for Code Exchange [RFC7636]. A mechanism that prevents various attacks on OAuth authorization codes. DPoP: Demonstrating Proof of Possession [RFC9449]. An OAuth 2.0 mechanism that restricts access tokens for use only by the client they were issued to. CORS: Cross-Origin Resource Sharing [Fetch]. A mechanism that enables exceptions to the browser's same-origin policy. CSP: Content Security Policy [W3C.CSP3]. A mechanism that restricts which resources a particular web page can fetch or execute. --> 8) <!--[rfced] We note three instances of "Implicit flow". Should this term be updated as "implicit grant" to match use in RFCs 6749 and 9700 or as "Implicit grant" to match "Implicit grant type" as used elsewhere in this document? Original: This limitation was one of the motivations for the definition of the Implicit flow (Section 4.2 of [RFC6749]), which returns the access token in the front channel via the fragment part of the URL, bypassing the need for a cross-origin POST request. --> 9) <!--[rfced] We added "in requests" before "to resource servers" for clarity. Please let us know if that is not correct. Original: In essence, abusing a stolen refresh token enables long-term impersonation of the legitimate client application to resource servers. Current: In essence, abusing a stolen refresh token enables long-term impersonation of the legitimate client application in requests to resource servers. --> 10) <!--[rfced] Please review whether any of the notes in this document should be in the <aside> element. It is defined as "a container for content that is semantically less important or tangential to the content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside). --> 11) <!--[rfced] FYI: We updated the second sentence as shown below for clarity as "items are only not "MUSTs" reads oddly. Original: Note: In new deployments, all of the above requirements are likely to be straightforward to implement. The "SHOULD" items are only not "MUSTs" so that existing architectures can be compliant. Current: Note: In new deployments, all of the above requirements are likely to be straightforward to implement. The "SHOULD" items are not deemed as "MUST" items so that existing architectures can be compliant. --> 12) <!--[rfced] In Section 6.2.2.3, may we clarify "relying on [RCF8707]"? Original: The token-mediating backend can use a similar mechanism to downscoping when relying on [RFC8707] to obtain access token for a specific resource server. Perhaps: The token-mediating backend can use a similar mechanism to the downscoping mechanism when relying on the extension described in [RFC8707] to obtain an access token for a specific resource server. Similarly, in the list in Section 9.1, may we clarify "Use [RFC8707]"? Original: * Use [RFC8707] to restrict access tokens to a single resource Perhaps: * Restrict access tokens to a single resource using the extension described in [RFC8707] --> 13) <!--[rfced] Is "Serving" correct here, or should it be "Hosting" since "web host" is mentioned in the next sentence? Original: Serving the static JavaScript or WASM code is a separate responsibility from handling interactions with the authorization server. Perhaps: Hosting static JavaScript or WASM code is a separate responsibility from handling interactions with the authorization server. --> 14) <!-- [rfced] Please review. RFC 9700 does not have a Section 4.18. Which section of RFC 9700 should this sentence cite? Current: Section 4.18 of [RFC9700] provides additional details about the security of in-browser communication flows and the countermeasures that browser-based applications and authorization servers MUST apply to defend against these attacks. --> 15) <!-- [rfced] Please review. [HTML] does not contain a section named "Session history and navigation". However, there is a section named "Navigation and session history" (see: https://html.spec.whatwg.org/#navigation-and-session-history). Is this the correct section? Current: Modern browsers now have the Session History API (described in "Session history and navigation" of [HTML]), which provides a mechanism to modify the path and query string component of the URL without triggering a page reload. Perhaps: Modern browsers now have the Session History API (described in "Navigation and session history" of [HTML]), which provides a mechanism to modify the path and query string component of the URL without triggering a page reload. --> 16) <!--[rfced] Should the storage API in [W3C.IndexedDB] be mentioned for consistency? Would adding "IndexedDB" be correct? Original: The persistent storage APIs currently available in browsers as of this writing are localStorage ([WebStorage]), sessionStorage ([WebStorage]), and [W3C.IndexedDB]. Perhaps: The persistent storage APIs currently available in browsers as of this writing are localStorage [WebStorage], sessionStorage [WebStorage], and IndexedDB [W3C.IndexedDB]. --> 17) <!--[rfced] We note that this document uses text styling. Please review the related terms for consistency, and let us know if any further updates are needed. We note the following differences: `httpOnly` vs. httpOnly `<scheme, hostname, port>` vs. *<scheme, hostname, port>* --> 18) <!--[rfced] Terminology a) We updated the following terms to reflect the form on the right for consistency. Please review and let us know if you have any objections. Authorization Server -> authorization server Backend-For-Frontend -> Backend for Frontend CORS-safelisted Requests -> CORS-safelisted requests CRSF -> CSRF ID token -> ID Token OpenID connect -> OpenID Connect Refresh Token request -> refresh token request Token-Mediating Backend -> token-mediating backend b) We note instances of "(step C)" vs. "(C)", "(step E)" vs. "(E)", etc. Is this variance okay, or should any of these instances be made consistent? If so please let us know the preferred form. --> 19) <!--[rfced] Abbreviations a) FYI - We have added expansions for the following abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review these and each expansion in the document carefully to ensure correctness. Content Delivery Network (CDN) Open Worldwide Application Security Project (OWASP) Multiview Video Coding (MVC) WebAssembly (WASM) b) As recommended in the Web Portion of the Style Guide <https://www.rfc-editor.org/styleguide/part2/#exp_abbrev>, once an abbreviation is introduced, the abbreviated form should be used thereafter. Please consider if you would like to apply this style for the following terms: JavaScript -> JS --> 20) <!--[rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. For example, please consider whether the following should be updated: - native In addition, please consider whether "traditional" should be updated for clarity. While the NIST website <https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1> indicates that this term is potentially biased, it is also ambiguous. "Tradition" is a subjective term, as it is not the same for everyone. --> Thank you. Karen Moore and Alanna Paloma RFC Production Center On Jul 17, 2026, at 3:31 PM, [email protected] wrote: *****IMPORTANT***** RFC Author(s): -------------- Your document has now entered Final Review (previously AUTH48). The document was edited in kramdown-rfc as part of the RPC pilot test (see https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc). Final Review is being handled in GitHub as part of the GitHub pilot test (see https://www.rfc-editor.org/rpc/wiki/doku.php?id=rpc-github-phase-0-pilot-test). Your document is available for review at: https://github.com/rfc-editor-drafts/FinalReview-rfc10017 Please do the following: a) provide your GitHub username so that we can send you an invite to join the repo as a collaborator. We can also send an invite to Hannes Tschofenig (WG Chair). We have already added Deb Cooley (AD) and Rifaat Shekh-Yusef (Document Shepherd and WG Chair) b) see the README for details on the Final Review process: https://github.com/rfc-editor-drafts/FinalReview-rfc10017/blob/Approved/README.md c) review the edits in the RPC-edits pull request: https://github.com/rfc-editor-drafts/FinalReview-rfc10017/pulls d) address the issues: https://github.com/rfc-editor-drafts/FinalReview-rfc10017/issues Once the content of the .md file is stable, we will convert it to .xml and provide the .html, .pdf, .txt, and .xml files for review. You and your coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Once the document has been reviewed and approved by all of the authors, it will be published as an RFC. If an author is no longer available, there are several remedies; see the Unavailable Authors section (https://authors.ietf.org/rfc-publication-process#unavailable-authors). Details on the status of your Final Review are here: https://queue.rfc-editor.org/final-review/rfc10017/ Please let us know if you have any questions. Thank you for your cooperation, RFC Production Center -------------------------------------- RFC 10017 (draft-ietf-oauth-browser-based-apps) Title : OAuth 2.0 for Browser-Based Applications Author(s) : A. Parecki, P. Ryck, D. Waite WG Chair(s) : Hannes Tschofenig, Rifaat Shekh-Yusef Area Director(s) : Deb Cooley, Christopher Inacio -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
