Thanks for your review Zitao! Version 12 addresses your comments. Detailed responses below:
On Sun, May 21, 2017 at 8:05 PM, wangzitao <wangzi...@huawei.com> wrote: > Reviewer: Zitao Wang (Michael) > > Review result: Has Nits > > > > I have reviewed this document as part of the Operational > directorate’s ongoing effort to review all IETF documents being processed > by the IESG. These comments were written with the intent of improving the > operational aspects of the IETF drafts. Comments that are not addressed in > last call may be included in AD reviews during the IESG review. Document > editors and WG chairs should treat these comments just like any other last > call comments. > > > > Document reviewed: draft-ietf-oauth-native-apps-10 > > > > Summary: > > > > 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. > > > > I think the document is written very clear, except some small nits: > > Page 3: The last sentence of introduction-- “This practice is also > known as the AppAuth pattern”. > > I suggest adding a reference to explain the AppAuth pattern. > > Done > Page 3: Terminology -- "OAuth". > > I suggest modifying to: "OAuth" The Web Authorization (OAuth) protocol. > In this document, OAuth refers to OAuth 2.0 [RFC6749]. > I went with: "In this document, OAuth refers to the OAuth 2.0 Authorization Framework [RFC6749]." The phrase "Web Authorization (OAuth) protocol" only seems to appear in our WG Charter, and not general usage <https://www.google.com/search?q=web+authorization+protocol>. > Page 4: Terminology -- "web-view" A web browser UI component. > > Does it mean "User Information"? Suggest expanding this abbreviation. > > Done. > Page 5: Figure 1. Does the browser and authorization endpoint are > some kinds of "external user-agent"? Suggest describing it more clearly. > Now states: "illustrates the interaction of the native app with a browser external user-agent to authorize the user. " Page 9: PKCE [RFC7636] details how this limitation can be used to > execute a code interception attack (see Figure 1). > > Does the Figure 1 means “Figure 1 of RFC7636”? > Good catch. I delete the figure reference, since the entire spec talks about this attack, which is likely sufficient. > > Page10: However, as the Implicit Flow cannot be protected by PKCE > > Seems here, the reference be omitted. > Added. > A run of idnits revealed no errors, flaws. There were 1 warning and 1 > comments though > > > > == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the > > document. > > > > I ran it myself with verbose output, and got: tmp/draft-ietf-oauth-native-apps__1_.txt(435): Found possible FQDN 'com.example.app' in position 5; this doesn't match RFC 2606's suggested ".example" or ".example.(com|org|net)". We are actually using a RFC2606 domain name here, but in reverse domain name notation which is causing this warning. No changes required. > Miscellaneous warnings: > > ---------------------------------------------------------------------------- > > > > -- The document date (April 26, 2017) is 14 days in the past. Is this > > intentional? > > > > > > Checking references for intended status: Best Current Practice > > ---------------------------------------------------------------------------- > > > > (See RFCs 3967 and 4897 for information about using normative references > > to lower-maturity documents in RFCs) > > > > No issues found here. > > > > Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). > > > > > > _______________________________________________ > > OPS-DIR mailing list > > ops-...@ietf.org > > https://www.ietf.org/mailman/listinfo/ops-dir > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
