Elwyn, thanks for your reviews of this document. I think the notion of what is meant by default browser as specified in this document matches the expectations of those likely to be consuming the document, so I don’t see a need for changes there. I have balloted No Objection.
Authors, thanks for your engagement with Elwyn’s previous review. Alissa > On May 23, 2017, at 7:20 PM, Elwyn Davies <[email protected]> wrote: > > Reviewer: Elwyn Davies > Review result: Almost Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-oauth-native-apps-11 > Reviewer: Elwyn Davies > Review Date: 2017-05-23 > IETF LC End Date: 2017-05-16 > IESG Telechat date: 2017-05-25 > > Summary: (still) Almost ready. Thanks for the responses to my last > call review of -10 which have addressed several of the comments. It > seems to me that there still some issues with ensuring the selection > of, and hence the connection to, the browser providing access to the > authorization services is secure (this was referred to in my previous > review but only (IMO)pary addressed). This feels like a considerable > problem but I am neither a deep security expert or OAuth expert so I > may be wrong. My old fogey soul is deeply offended by this new > fangled usage of 'app' which is still in my book an abbreviation, but > I guess I have to bow to the changing times and the acknowledgment > that 'app' is now dignified by an appearance in the OED. >shame<. > Still, given that RFC 6749 lives on the other side of the > app/application divide, I think that the examples in the abstract and > the beginning of s1 should match with RFC 6749 which uses 'native > application(s).' There are also a couple more nits that I missed on > the previous pass. [BTW UI is indeed a well-known abbreviation but > given it is only used once it might be worh expanding it.] > > I understand that -12 has been submitted but had not been placed in > the public repository as of 9pm UTC on 2017/05/23 (Tuesday evening my > time). > > Major issues: > Possibly 2nd minor issue is actually major. > > Minor issues: > Relationship between (web) browser, (operating) system and user choice > of browser: > The terminology definition of 'browser' in s3: > "browser" The default application launched by the operating system > to handle "http" > and "https" scheme URI content. > The terminology of 'system browser' used in version 10 of the draft > has been removed but the term 'default application' could still be > interpreted as a system choice. As far as I know, although some > operating systems have a preinstalled browser which will be the > 'default browser', this is a commercial decision and users usually > have the option to install an alternative browser and instruct the OS > to use this as the application used to handle http/https content. I > suggest that 'user selected application' would be clearer than > 'default application'. In particular Linux installations have no > default application - the user/installer has to separately install a > browser and set it as the default. > > Security implications of browser application selection and > activation: > [This could possibly be consdiered as a major issue.] > AFAIK the choice of application that is invoked to handle http/https > content is a user choice made on a per-user configuration that does > not require special privileges. Typically a browser application will > allow a user to select it as default http/https content when it is > first run by a given user and the choice can be changed at the user's > whim subsequently. However there is no requirement to involve the > user. A user-level application could (AFAICS) happily hijack the > configuration and install itself as selected browser without any user > intervention. Apart from the obvious possibility of DoS, I am not > sufficiently expert in the details of OAuth to know what the > consequences of a bad actor installing a malicious pseudo-browser, > potentially acting as a MiTM or otherwise, might be. It strikes me > that a user of OAuth might be concerned that the browser acting as > intermediary was what s/he thought it was. > > Nits/editorial comments: > Abstract: 'Native apps' needs a reference to Section 9 of RFC 6749. > I note that there they are (still) called 'native applications'. > Suggest you postpone introducing the shorthand 'native apps' to > section 1 and indicate that the browser is a web browser. Thus: > OLD: > OAuth 2.0 authorization requests from native apps should only be > made > through external user-agents, primarily the user's browser. This > specification details the security and usability reasons why this > is > the case, and how native apps and authorization servers can > implement > this best practice. > NEW: > OAuth 2.0 authorization requests from native applications, as > described > in Section 9 of RFC 6749, should only be made through external > user-agents, > primarily the user's web browser. This specification details the > security and > usability reasons why this is the case, and how native applications > and > authorization servers can implement this best practice. > END > > s1, para 1: In line with the above: s/native apps/native applications > (hereafter known as 'native apps')/ > > s1, para 2: s/browser/web browser/ > > s1, last para: 'AppAuth' needs a reference (a pointer to Appendix B > would provide something suitable I think). > > s3: Needs a definition for 'redirect URI' pointing to RFC 6749 > (possibly to Section 3.1.2 there). > > s4.1, Figure 1: Rather nitty but the equivalence of authz and > authorization should be noted. > > s7.1: Are there any references that an interested reader could follow > to find more info? > > s7.2: Again reference(s) would help. While the draft writes of > operating systems I can only find one (android). Is this in fact > correct? Is there an expectation that this will become more generally > implemented? If not making this a firm requirement is somewhat > dubious. > > s7.1 and s7.2: It might be useful to mention that s8.1 describes means > to protect against bad actors installing malicious URI claiming apps. > (And also helps with s7.3 I believe). > > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
