[OAUTH-WG] [OPS-DIR] Opsdir telechat review of draft-ietf-oauth-native-apps-10

wangzitao <wangzitao@huawei.com> Mon, 22 May 2017 03:05 UTC

Return-Path: <wangzitao@huawei.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9EE08129515; Sun, 21 May 2017 20:05:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.82
X-Spam-Status: No, score=-2.82 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id KiFsNPJH4Ryt; Sun, 21 May 2017 20:05:14 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33F95124B0A; Sun, 21 May 2017 20:05:13 -0700 (PDT)
Received: from (EHLO lhreml703-cah.china.huawei.com) ([]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DHB06537; Mon, 22 May 2017 03:05:11 +0000 (GMT)
Received: from DGGEMM402-HUB.china.huawei.com ( by lhreml703-cah.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 22 May 2017 04:05:09 +0100
Received: from DGGEMM506-MBX.china.huawei.com ([]) by DGGEMM402-HUB.china.huawei.com ([]) with mapi id 14.03.0301.000; Mon, 22 May 2017 11:05:05 +0800
From: wangzitao <wangzitao@huawei.com>
To: "ops-dir@ietf.org" <ops-dir@ietf.org>
CC: "oauth@ietf.org" <oauth@ietf.org>, "draft-ietf-oauth-native-apps.all@ietf.org" <draft-ietf-oauth-native-apps.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Thread-Topic: [OPS-DIR] Opsdir telechat review of draft-ietf-oauth-native-apps-10
Thread-Index: AdLSqDVW3BTeNlgFQ6WqlwAw3ux67g==
Date: Mon, 22 May 2017 03:05:04 +0000
Message-ID: <E6BC9BBCBCACC246846FC685F9FF41EA2AE094F0@DGGEMM506-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_E6BC9BBCBCACC246846FC685F9FF41EA2AE094F0DGGEMM506MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.59225567.00BB, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 01d0af88b641625d75bea2fdc53aa751
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Sft_2lhHhggRAF1Ls_UU2B6bPW8>
Subject: [OAUTH-WG] [OPS-DIR] Opsdir telechat review of draft-ietf-oauth-native-apps-10
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
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, 22 May 2017 03:05:18 -0000

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


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.

Page 3:     Terminology -- "OAuth".

I suggest modifying to: "OAuth"   The Web Authorization (OAuth) protocol.  In this document, OAuth refers to OAuth 2.0 [RFC6749].

Page 4:     Terminology -- "web-view"  A web browser UI component.

Does it mean "User Information"?  Suggest expanding this abbreviation.

Page 5:     Figure 1.   Does the browser and authorization endpoint are some kinds of "external user-agent"? Suggest describing it more clearly.

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"?

Page10:     However, as the Implicit Flow cannot be protected by PKCE
Seems here, the reference be omitted.

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


  Miscellaneous warnings:


  -- The document date (April 26, 2017) is 14 days in the past.  Is this


  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