[OAUTH-WG] Genart last call review of draft-ietf-oauth-native-apps-10

Elwyn Davies <elwynd@dial.pipex.com> Mon, 15 May 2017 23:41 UTC

Return-Path: <elwynd@dial.pipex.com>
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D21129BE0; Mon, 15 May 2017 16:41:51 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Elwyn Davies <elwynd@dial.pipex.com>
To: <gen-art@ietf.org>
Cc: draft-ietf-oauth-native-apps.all@ietf.org, ietf@ietf.org, oauth@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.50.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149489171188.11868.13336890952697460283@ietfa.amsl.com>
Date: Mon, 15 May 2017 16:41:51 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/F1NFLR-YReJm7_W1nHSleN1tXLE>
Subject: [OAUTH-WG] Genart last call review of draft-ietf-oauth-native-apps-10
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 May 2017 23:41:52 -0000

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