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 treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-oauth-native-apps-10 Reviewer: Elwyn Davies Review Date: 2017-05-15 IETF LC End Date: 2017-05-16 IESG Telechat date: 2017-05-25 Summary: Almost ready. A couple of simple minor issues could do with addressing. Major issues: None. Minor issues: s3: "browser": The browser that acts as the Oauth user-agent is conflated with the user's choice of default browser. Firstly this is not something that is discussed in RFC 6749. Secondly, the concept of 'default browser' would normally be thought of by users as the browser that is used to display the content associated with hyperlinks rather than providing Oauth services. I suggest that the implication in the body of the draft that 'the browser' is the user selected or system selected default browser needs to be at least discussed explicitly rather than buried in the terminology definitions in s3. I wonder whether ths connection is something that should be made by a separate OS setting or a setting in each native app rather than conflated with the default browser. The term "designated browser" might be useful. In all cases there might be secuity implications if a bad actor could subvert the designated browser setting. s8.1, Requirement of use of PKCE in some cases: This strict requirement really needs to be introduced in the body of the discussion rather than buried in the seurity considerations. Nits/editorial comments: General: s/i.e./i.e.,/ (3 places) Title and Abstract: s/apps/applications/g (uses before we get to terminology in s3) s1, para 1: Suggest the following to make it clear that the definition is in RFC 6749 rather than here. OLD: The OAuth 2.0 [RFC6749] authorization framework documents two approaches in Section 9 for native apps to interact with the authorization endpoint: an embedded user-agent, and an external user- agent. NEW: The OAuth 2.0 [RFC6749] authorization framework defines "native applications" in Section 9 of RFC 6749 (see also Section 3 below) and documents two approaches by whch they can interact with the authorization endpoint: an embedded user-agent, and an external user-agent. END s1, para 2: s/apps/applications/(2places) . For second case: s/native apps/native applications (shortened to "native apps" or just "apps" hereafter)/ s3, "native app": s/app/application/g in the definition. After that in the document "[native] app" is fine except for the definitions mentioned in the next comment. Worth repeating the link to Section 9 of RFC 6749. s3, All definitions after "app"; s/app/application/g in the definitions as these are not restricted to (native) apps as defined here. s3, "embedded user-agent": s/modify/modifyng/ s4, last para: s/emcompasses/encompasses/ s4, last para: s/inter-process/inter-app/ (since this term is defined) s4, last para: Might be worth pointing to the 'SHOULD' about client type assumptions in s2.1 of RFC 6749 withe reference to servers that do make assumptions. s4.1, para below figure 1: s/system browser/browser/ (or maybe "designated browser"). s5, paras 1 and 2: Reword to clarify and remove 'we gain' usage (not allowed in RFCs): OLD: Just as URIs are used for OAuth 2.0 [RFC6749] on the web to initiate the authorization request and return the authorization response to the requesting website, URIs can be used by native apps to initiate the authorization request in the device's browser and return the response to the requesting native app. By applying the same principles from the web to native apps, we gain benefits seen on the web, like the usability of a single sign-on session and the security of a separate authentication context. It also reduces the implementation complexity by reusing similar flows as the web, and increases interoperability by relying on standards- based web flows that are not specific to a particular platform. NEW: Just as URIs are used for OAuth 2.0 [RFC6749] in the HTTP protocol on the web to initiate the authorization request and return the authorization response to the requesting website, URIs can be used by native apps to initiate the authorization request in the device's browser and return the response to the requesting native app. By extending the techniques from the web to native apps, the benefits gained in the web context will also be reaped when using OAuth with native apps; benefits include the usability of a single sign-on session and the security of a separate authentication context. Use of the techniques also reduces implementation complexity by reusing similar flows to those employed on the web, and increases interoperability by relying on standards- based web flows that are not specific to a particular platform. END s5, para 3: Suggest prefixing this para with: "To conform to this best practise," - the MUST is not derived from RFC 6749. s7.1, last para: s/URI like it/URI as it/; s/like normal/as it would normally/ s7.2, next to last para: OLD: Due to this reason, they SHOULD be used over the other redirect choices for native apps where possible. NEW: For this reason, they SHOULD be used in preference to the other redirect options for native apps where possible. END s7.2, last para: s/it REQUIRED/it is REQUIRED/ s8.1, para 2: Need to expand acronym PKCE at first use (currently expanded in para 4). s8.1, para 4: s/sends data/send data/ s8.2: It would be more consistent with RFC 6749 to refer to "Implicit Flow" as "Implicit Grant authorization flow" at least for the title and first occurrence. The second and third occurrences in para 1 should s/Implicit Flow/implicit flow/ for consistency with para 2. s8.2, para 2: s/code flow/Authorization Code Grant flow/ s8.3, last para: Is a reminder to choose the 'right' type of IP literal (IPv4 or v6) desirable? Doing an address lookup on "localhost" presumably tells you which one to use! [perhaps?] s8.7, para 4: s/like/such as/ s8.8; need to expand CSRF (Cross Site Request Forgery) and maybe explain a it how CSRGF and the cross-app case are related