Thanks for the review, Erik. Responses inline. On Sun, Apr 20, 2025 at 3:09 PM Erik Kline via Datatracker <[email protected]> wrote:
> > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > # Internet AD comments for draft-ietf-oauth-browser-based-apps-24 > CC @ekline > > * 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/ > > ## Comments > > ### S6.2.* > > * n00b question: does the possibility of a differing apparent source IP > address for the (D,J) vs F requests imply that any attempt at using the > source IP address (or range) for some security check cannot (or, indeed, > MUST NOT) be used? > > Past experience with such tricks showed their limitations when adding > IPv6 addresses to servers -- clients could connect from IPv4 in one > request and use IPv6 in a subsequent one. > > Just curious. Not anything that need be addressed by text here. > The "D" leg (the request to the authorization server) will always be from the user's browser in any architectural pattern, so will often be from a different IP address than the other legs in most OAuth flows, including in the more traditional web server app architecture. There is no concern about this leg as it's not unique to this pattern. The differing IP address in the "F" vs "J" legs (token endpoint vs resource server) is somewhat unique to this pattern, since in most other scenarios both those requests would be made from the same machine. That said, IP address binding of access tokens is not typically done in OAuth for the reasons you mentioned anyway, so I am inclined to not bother pointing it out in the text. > > ## Nits > > ### S6.1.3.2 > > * "___Host" vs "__Host" > > (three leading underscores versus two) > > I am not finding this in the document, I see 2 underscores which appears to be the correct amount.
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
