Hi Aaron, thanks for your continued work on the topic.
Here are some general remarks on the current revision: 1) This BCP should not be limited to public clients. Your BCP itself already describes an architecture where the OAuth client is a backend that may be a confidential client (see section 6.2 for an example). The text of the BCP generally seems to be inconsistent regarding oauth client types. I suggest to remove the second part of the first paragraph of the abstract (“and should not be issued a client secret when registered.") and other statements limiting the BCP to public clients. 2) Regarding architectures: I think this BCP should focus on recommendations for securely implementing OAuth in the different potential architecture. I don’t think we should get into the business of recommending and assessing other solutions (e.g. section 6.1.). Just to give you an example: Section 6.1. states "OAuth and OpenID Connect provide very little benefit in this deployment scenario, so it is recommended to reconsider whether you need OAuth or OpenID Connect at all in this case.” Really? What experiences is this statement based on? In my experience, sharing the same domain == host name tells you nothing about the overall architecture of a certain deployment. There may be several reasons why OAuth could be good choice in such a scenario, e.g. security considerations (since your common domain is just a proxy server encapsulating a whole universe of systems) or even modularity as an architecture principle. I suggest to remove section 6.1. and to rephrase the second paragraph of the abstract. 3) The naming in section 6 focus on the ways the JS could be served. I personally think the more important aspect is the architecture of the overall application. I suggest the following changes: - 6.2. Apps Served from a Dynamic Application Server -> SPA with backend - 6.3. Apps Served from a Static Web Server -> SPA without backend Note: even an SPA with a backend could use a static web server to serve the JS code. 4) I don’t understand why your BCP distinguishes 1st and 3rd party apps. Neither the Native apps BCP nor security BCP do so and need to. 5) Section 9.8 seems to duplicate portions of the Security BCP (while not giving the complete threat model) - what is the benefit of duplicating this text? 6) I think the BCP would benefit from a refactoring. One idea would be to first state the problem with implicit and give general recommendations (PKCE and so on). The latter part could get into details of access and refresh token protection in the context of different SPA architectures (mTLS, CORS for CSRF prevention, …). kind regards, Torsten. > On 9. Jul 2019, at 01:03, Aaron Parecki <aa...@parecki.com> wrote: > > Hi all, > > I've just uploaded a new version of oauth-browser-based-apps in preparation > for the meeting in Montreal. > > https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-02 > > This draft incorporates much of the feedback I've received over the last > couple months, as well as what we discussed at the last meeting in Prague. > > The primary change is a significant rewrite and addition of Section 6 to > highlight the two common deployment patterns, a SPA with and without a > dynamic backend. > > Please have a look and let me know what you think. I have a slot in the > agenda for Montreal to present on this as well. > > Thanks! > > ---- > Aaron Parecki > aaronparecki.com > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
