Thank you, Thomas, for your reply (and also thanks to Philippe 😊 ). Using “browser-based app” instead of “JS app” seems more useful to the readers.
Regards -éric From: Aaron Parecki <aa...@parecki.com> Date: Friday, 4 July 2025 at 03:16 To: Eric Vyncke (evyncke) <evyn...@cisco.com> Cc: The IESG <i...@ietf.org>, draft-ietf-oauth-browser-based-a...@ietf.org <draft-ietf-oauth-browser-based-a...@ietf.org>, oauth-cha...@ietf.org <oauth-cha...@ietf.org>, oauth@ietf.org <oauth@ietf.org>, rifaat.s.i...@gmail.com <rifaat.s.i...@gmail.com> Subject: Re: Éric Vyncke's No Objection on draft-ietf-oauth-browser-based-apps-24: (with COMMENT) Hi Éric, thanks for your review. Responses inline. On Mon, Apr 21, 2025 at 3:31 AM Éric Vyncke via Datatracker <nore...@ietf.org> wrote: > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > # Éric Vyncke, INT AD, comments for draft-ietf-oauth-browser-based-apps-24 > > CC @evyncke > > Thank you for the work put into this document. The text is interesting and > quite educational. Thanks also for using SVG graphics, so nicer figures! > > Please find below some non-blocking COMMENT points (but replies would be > appreciated even if only for my own education). > > Special thanks to Rifaat Shekh-Yusef for the shepherd's write-up including the > WG consensus and some justification of the intended status. > > I hope that this review helps to improve the document, > > Regards, > > -éric > > ## COMMENTS (non-blocking) > > ### As curious as Erik Kline > > I am eager to read the authors/WG reply to Erik Kline's comment on section 6.2 > as indeed the IP address*ES* can change a lot: multi-interfaces, multiple IPv6 > addresses per interface, happy eyeball switching from v4 to v6, ... > > ### Section 3 > > `this document uses the term "JavaScript" to refer to all mechanisms ` is > rather an abuse of language... Anyway, if I am the only one to complain, then > ignore this comment. You were not the only one. I did a big pass to update the usage of the terms here: https://github.com/oauth-wg/oauth-browser-based-apps/commit/f33b5f02b67de0aea697f4a45a5970e7df7d4b8f > ### Section 5 > > While interesting, aren't this section lead paragraphs applicable to any > "Javascript" page ? Yes, but we wanted to call out the ones that are most relevant to websites dealing with OAuth tokens. > ### Section 6.1 > > It seems that this section goes in way more details/depth than sections 6.2 > and > 6.3. Is there a reason for this ? e.g., more complex or more deployed ? (just > curious) From co-author Philippe: Section 6.1 introduces a new component into the architecture, and requires a lot of details on how to integrate this component. Section 6.2 is a variation of 6.1, so it re-uses a lot of the context that was defined earlier. 6.3 does not have a server-side component, making the architecture simpler (but also less secure). A good comparison to make this clear would be to look at the content discussing OAuth client behavior. In 6.3, the browser-based app acts as the client directly, while 6.1 and 6.2 require an additional component to take that role. I believe that in all sections the Oauth-specific content is fairly comparable in length. It's mostly the stuff around it that requires detailed discussion. > ### Section 6.1.3.2 > > Should there be more explanation about __Host ? I.e., w/o referring to the > normative reference, it is unclear whether it is the fixed constant string or > a > FQDN ;-) This is in fact the literal string __Host, defined in the document referenced. I changed the formatting to backticks to hopefully make this clearer.
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
