Another concern I have with this is that it is an *individual* draft, and not a WG adopted draft. We do not want people to get into the habit of taking individual drafts seriously before they are adopted by a WG, regardless of the quality of this specific document.
Regards, Rifaat On Thu, Dec 19, 2024 at 11:25 AM Aaron Parecki <aa...@parecki.com> wrote: > Brian, as a co-author of the mentioned TMI-BFF draft, do you have an > opinion on whether this draft should mention it inline as is currently in > the doc, or whether we should remove the paragraph and mark the TMI-BFF > draft as replaced by the Browser BCP? > > Aaron > > On Thu, Dec 19, 2024 at 6:11 AM Rifaat Shekh-Yusef < > rifaat.s.i...@gmail.com> wrote: > >> Thanks Aaron and Philippe! >> >> See a few replies below. >> >> Regards, >> Rifaat >> >> >> On Wed, Dec 18, 2024 at 4:08 PM Aaron Parecki <aaron= >> 40parecki....@dmarc.ietf.org> wrote: >> >>> Hi all, the authors have published a new draft of the Browser-Based Apps >>> BCP addressing Rifaat's comments from the shepherd writeup. Notes on the >>> individual points are below, copied from Philippe's PR for these changes on >>> GitHub. >>> >>> Section 6.1.1 >>> “This response to the browser will also trigger the reloading of the >>> JavaScript application (H).” >>> I am assuming that there is a reason for this reload, but that is not >>> clear to me. Can you elaborate on why a reload is needed? >>> >>> Clarified. >>> >>> Section 6.1.2.1 >>> • There are few places where the word “initialize” is used, but I guess >>> you meant to say “initiate”? >>> • “Initialization URI” should that be “authorization URI”? >>> >>> Fixed. >>> >>> Section 6.1.2.2 >>> • “These steps are not shown in the diagram, but would occur between >>> step J and K. ” >>> Should the BFF mint a new access token as soon as the existing access >>> token has expired to allow for faster response to the request in step J? >>> >>> Reworded. >>> >>> • “Therefore, it is recommended to configure the lifetime of the >>> cookie-based session managed by the BFF to be equal to the maximum lifetime >>> of the refresh token. Additionally, when the BFF learns that a refresh >>> token for an active session is no longer valid, it is recommended to >>> invalidate the session.” >>> “recommended” -> “RECOMMENDED”? >>> Since this is a “recommended”, should there be some text to explain to >>> the implementers when this recommendation might be ignored? >>> >>> Changed "recommended" to "makes sense" since this is not really a >>> RECOMMENDATION, but mainly an observation for the implementer. All security >>> hinges on the validity of the access/refresh token, and the session of the >>> BFF is just to keep track of them. Keeping it around after a token expires >>> is mainly ineffecient and pointless, but not really problematic. >>> >>> Section 6.1.3.2 >>> “ >>> • The BFF SHOULD enable the SameSite=Strict flag for its cookies >>> • The BFF SHOULD set its cookie path to / >>> • The BFF SHOULD NOT set the Domain attribute for cookies >>> • The BFF SHOULD start the name of its cookies with the __Host- prefix >>> ([CookiePrefixes]) >>> ” >>> The above statements use “SHOULD”, which implies that in some cases >>> these can be ignored. Section 6.1.3.3.1 then elaborates on the “sameSite” >>> flag. Should there be some text to elaborate on the others? >>> >>> I added a sentence to clarify this a bit. In my opinion, these can >>> definitely all be MUSTs, but that may conflict with certain corner cases or >>> implementation strategies. We can continue this discussion if the current >>> fix is not sufficient. >>> >> I guess my question was: are there valid reasons for an implementer to >> deviate from these security guidelines? >> If the answer is no, then why not change all of them to MUST? >> After all, the goal of this document is to encourage people to do the >> right thing. >> >> >> >> >>> Section 6.2.2.1 >>> “The endpoint that initializes the Authorization Code flow (step C) is …” >>> “initializes” -> “initiates”? >>> >>> Fixed. >>> >>> Section 6.2.2.2 >>> “Therefore, it is recommended to configure the lifetime of the >>> cookie-based session to be equal to the maximum lifetime of the refresh >>> token if such information is known upfront. Additionally, when the >>> token-mediating backend learns that a refresh token for an active session >>> is no longer valid, it is recommended to invalidate the session.” >>> “recommended” -> “RECOMMENDED”? >>> Since this is a “recommended”, should there be some text to explain to >>> the implementers when this recommendation might be ignored? >>> >>> Fixed like before. >>> >>> Section 6.3.2.2 >>> • “using PKCE, and confirming that the authorization server supports >>> PKCE” >>> How would the browser-based app “confirm” that the authorization server >>> supports PKCE? >>> >>> The developer would do that, but I've reworded this to avoid any >>> confusion. >>> >>> Section 6.3.2.3 >>> • “At this point, when the application attempts to use the refresh token >>> after 8 hours, the request will fail and the application will have to >>> re-initialize an Authorization Code flow that relies on the user's >>> authentication or previously established session” >>> “re-initialize” -> “re-initiate”? >>> >>> Fixed. >>> >>> Section 6.3.3.1 >>> >>> “For this reason, and those stated in Section 5.3.1 of [RFC6819], it is >>> NOT RECOMMENDED for authorization servers to require client authentication >>> of browser-based applications using a shared secret, as this serves no >>> value beyond client identification which is already provided by the >>> client_id parameter.” >>> Since this is considered a bad practice, should we be more forceful here >>> and try to change “NOT RECOMMENDED” to “MUST NOT”? >>> >>> Done. >>> >>> Section 6.3.4.2.3 >>> “even when it is associated with a flow that was initialized by the >>> attacker.” >>> “initialized” -> “initiated”? >>> >>> Fixed. >>> >>> >>> Section 7.2.4 >>> “Performing OpenID Connect using the Authorization Code grant type >>> provides the benefit of the client not needing to verify the JWT signature, >>> …” >>> With all kinds of middle boxes being used these days, should we >>> encourage people to verify the JWT signature even if it was obtained over >>> an HTTPS channel? >>> >>> Upon revisiting this section, this paragraph sticks out as somewhat >>> problematic because it's not only a reference to OpenID Connect, but it's >>> the only place where suggested behavior for OpenID Connect is recommended. >>> We decided to just drop this paragraph entirely. (Issue 59 >>> https://github.com/oauth-wg/oauth-browser-based-apps/issues/59) >>> >>> >>> Section 6.2.1 >>> “Note that an early draft ([tmi-bff]) already documented this concept, >>> although the draft is is currently expired and has not been proposed for >>> adoption to the OAuth Working Group.” >>> Is this paragraph really needed? How would that help the implementer? >>> >>> >>> I believe this came out of the discussions at IETF 114. After that >>> meeting, we added the TMI-BFF pattern to the draft, and left this reference >>> to a concrete proposal for implementing the pattern. While this draft was >>> not developed further, it could be picked up again in the future, in which >>> case leaving this reference here would give someone the breadcrumb trail to >>> find. (Issue 58 >>> https://github.com/oauth-wg/oauth-browser-based-apps/issues/58) >>> >>> >>> >> I just do not see the value for an implementer; in fact, it might be a >> distraction. >> If the goal is to allow others to find this draft, then we can add it to >> the "Replaces" header of this document. >> >> >> >> >>> Thanks, >>> >>> >>> Aaron >>> >>> >>> >>> >>> On Wed, Dec 18, 2024 at 1:00 PM <internet-dra...@ietf.org> wrote: >>> >>>> Internet-Draft draft-ietf-oauth-browser-based-apps-20.txt is now >>>> available. It >>>> is a work item of the Web Authorization Protocol (OAUTH) WG of the IETF. >>>> >>>> Title: OAuth 2.0 for Browser-Based Applications >>>> Authors: Aaron Parecki >>>> David Waite >>>> Philippe De Ryck >>>> Name: draft-ietf-oauth-browser-based-apps-20.txt >>>> Pages: 62 >>>> Dates: 2024-12-18 >>>> >>>> Abstract: >>>> >>>> This specification details the threats, attack consequences, security >>>> considerations and best practices that must be taken into account >>>> when developing browser-based applications that use OAuth 2.0. >>>> >>>> Discussion Venues >>>> >>>> This note is to be removed before publishing as an RFC. >>>> >>>> Discussion of this document takes place on the Web Authorization >>>> Protocol Working Group mailing list (oauth@ietf.org), which is >>>> archived at https://mailarchive.ietf.org/arch/browse/oauth/. >>>> >>>> Source for this draft and an issue tracker can be found at >>>> https://github.com/oauth-wg/oauth-browser-based-apps. >>>> >>>> The IETF datatracker status page for this Internet-Draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/ >>>> >>>> There is also an HTML version available at: >>>> >>>> https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-20.html >>>> >>>> A diff from the previous version is available at: >>>> >>>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-browser-based-apps-20 >>>> >>>> Internet-Drafts are also available by rsync at: >>>> rsync.ietf.org::internet-drafts >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list -- oauth@ietf.org >>>> To unsubscribe send an email to oauth-le...@ietf.org >>>> >>> _______________________________________________ >>> OAuth mailing list -- oauth@ietf.org >>> To unsubscribe send an email to oauth-le...@ietf.org >>> >>
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
