Mohamed Boucadair has entered the following ballot position for draft-ietf-oauth-browser-based-apps-24: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/ ---------------------------------------------------------------------- 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”. 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].” # 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. 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: # 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. # 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. Do we have some reco about how we can seek for user consent? 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. 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? Thank you. Cheers, Med _______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
