Hi Aaron, Thanks for the follow-up and clarifications.
It would help if the various items you tagged as out of scope be explicitly mentioned as such in the doc. Cheers, Med > -----Message d'origine----- > De : Aaron Parecki <aaron=40parecki....@dmarc.ietf.org> > Envoyé : vendredi 4 juillet 2025 02:02 > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> > Cc : The IESG <i...@ietf.org>; OAuth WG <oauth@ietf.org> > Objet : Re: [OAUTH-WG] Mohamed Boucadair's No Objection on draft- > ietf-oauth-browser-based-apps-24: (with COMMENT) > > Hi Med, thanks for your review. Responses inline. > > > > > ------------------------------------------------------------------ > > COMMENT: > > ------------------------------------------------------------------ > > > > Hi Aaron, Philippe, and David, > > > Thank you for the effort put into this specification. > > > Thanks to Qin Wu for the opsdir review and to the authors for > > addressing that review in -22. > > > I support Andy's DISCUSS points on (1) the need to better clarify > the > > relationship vs. 9700 and also "BFF as an HTTP Proxy". Likewise, I > > strongly support Andy's comment on "BFF Operational > Considerations". > > I resolved Andy's comments in a previous response, you can see the > thread here: > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma > ilarchive.ietf.org%2Farch%2Fmsg%2Foauth%2FrMZoJodaMH3G-ZjQzs0WHEZ4- > BU%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C32db473c078448 > 187e5908ddba8e090b%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6388 > 71841388632033%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiO > iIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0% > 7C%7C%7C&sdata=xaUDQpyfighJgoQQ8ZADWOrKa1QuvdJIJvVs7ajnRQ0%3D&reserv > ed=0 > > > Please find below some comments, fwiw: > > > # Which BCP Umbrella? > > Do we plan to include this document under the BCP 212 or BCP 240 > umbrella? Else? > > I guess it is natural to list under BCP240 as the document > currently says: > > "This document expands on and further restricts various > > recommendations given in [RFC9700]." > > I believe this was discussed on a telechat and was determined that > it should be its own BCP. > > > # Heavy use of field specific concept without introducing them It > was > > difficult to got through the text as I had check other OAUTH > > specifications to find and understand some statements and also > digest > > some concepts. The text does not provide pointers to help readers > find > > where to look at. A non-exhaustive list of points that require > > companion citations are: OAuth > > 2.0 clients, first-party context, third-party context, resource > > servers, Implicit flow, public clients, private clients, and so > on. > > Please consider fixing that. > > I went through and added references and made the terminology more > explicit throughout. Here is a diff showing the edits: > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi > thub.com%2Foauth-wg%2Foauth-browser-based- > apps%2Fpull%2F108%2Ffiles&data=05%7C02%7Cmohamed.boucadair%40orange. > com%7C32db473c078448187e5908ddba8e090b%7C90c7a20af34b40bfbc48b9253b6 > f5d20%7C0%7C0%7C638871841388653229%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0e > U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsI > ldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=LKlfLjVZsA%2Fbwt6v7CwutCdiJrxD3PI > XXfu3HPOykvc%3D&reserved=0 > > > Also, enigmatic statements such as the following are not helpful. > > Please list these explicitly. > > > CURRENT: > > In addition to the terms defined in referenced specifications, > this > > document uses the following terms: > > I added a paragraph before this with commonly used OAuth terms, the > same paragraph that we have used in other OAuth RFCs such as RFC > 9700. > > > # Recommendations/Guidance "lost" in the analysis > > > The document includes implementation guidance but that guidance is > > lost in the mass of attack analysis. This may be a matter of > taste, > > but I'm afraid that if we want the guidance to be followed, we > need an > > effort to make that guidance easily identified at the first place. > > Separating (or even offloading) the attack analysis vs actual > recommendations would be cleaner. > > RFC 9700 already has most of the practical guidance to follow. This > document is meant to be a deeper analysis of aspects particular to > browser-based applications. In my experience, simply telling > developers what to do isn't enough to get them to do it. This > document is intended to provide enough context for the > recommendations so that people will actually follow them. > > > # Provisioning and management-related matters > > > CURRENT: > > As stated in Section 10.2 of [RFC6749], the authorization server > > SHOULD NOT process authorization requests automatically without > user > > consent or interaction, except when the authorization server can > > assure the the identity of the client application. > > I removed the duplicate "the". > > > Do we have some reco about how we can seek for user consent? > > This is in the context of an interactive authorization flow, where > the user is typically shown a consent screen. This is not unique to > this draft, and this paragraph is copied from RFC 6749. I don't > think it would be helpful to expand on this point in this draft. > > > More generally, do we expect any knobs for users to interact with > the > > clients and provide some policies? Maybe the same considerations > apply > > also for native clients? If so, can we say that in the text. > > Similarly, this kind of thing is not specific to browser-based apps, > and is beyond the scope of the OAuth protocol. I don't think it > makes sense to bring this into the draft. > > > As I'm there, can we have a discussion about how to help with > > diagnostic/troubleshooting when problems are encountered? For > example, > > are there same (levels of) logs? How these are accessed by each > app? > > Similarly out of scope. > > > Thank you. > > > Cheers, > > Med > > Thanks for your review! > > > > --- > Aaron Parecki ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
