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

Reply via email to