[OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23

Songhaibin <haibin.song@huawei.com> Wed, 15 February 2012 09:33 UTC

Return-Path: <haibin.song@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 ADE2421F8737; Wed, 15 Feb 2012 01:33:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.549
X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id UFpVpL4vbL0O; Wed, 15 Feb 2012 01:33:42 -0800 (PST)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com []) by ietfa.amsl.com (Postfix) with ESMTP id EF71621F855F; Wed, 15 Feb 2012 01:33:41 -0800 (PST)
Received: from huawei.com (szxga03-in []) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZF00I1BH5U2B@szxga03-in.huawei.com>; Wed, 15 Feb 2012 17:32:18 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZF0015JH5UW6@szxga03-in.huawei.com>; Wed, 15 Feb 2012 17:32:18 +0800 (CST)
Received: from szxeml214-edg.china.huawei.com ([]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGV90365; Wed, 15 Feb 2012 17:32:17 +0800
Received: from SZXEML410-HUB.china.huawei.com ( by szxeml214-edg.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 15 Feb 2012 17:32:07 +0800
Received: from SZXEML534-MBX.china.huawei.com ([]) by szxeml410-hub.china.huawei.com ([]) with mapi id 14.01.0323.003; Wed, 15 Feb 2012 17:31:56 +0800
Date: Wed, 15 Feb 2012 09:33:22 +0000
From: Songhaibin <haibin.song@huawei.com>
X-Originating-IP: []
To: "tsv-ads@tools.ietf.org" <tsv-ads@tools.ietf.org>, "draft-ietf-oauth-v2@tools.ietf.org" <draft-ietf-oauth-v2@tools.ietf.org>
Message-id: <E33E01DFD5BEA24B9F3F18671078951F156D8F4B@szxeml534-mbx.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset="us-ascii"
Content-language: zh-CN
Content-transfer-encoding: 7bit
Accept-Language: en-US, zh-CN
Thread-topic: tsv-dir review of draft-ietf-oauth-v2-23
Thread-index: AczrxK1m0Cmrx5G1TqO2SHCpS5HjoQ==
X-CFilter-Loop: Reflected
X-Mailman-Approved-At: Wed, 15 Feb 2012 05:23:00 -0800
Cc: Martin Stiemerling <Martin.Stiemerling@neclab.eu>, "oauth@ietf.org" <oauth@ietf.org>, "tsv-dir@ietf.org" <tsv-dir@ietf.org>
Subject: [OAUTH-WG] tsv-dir review of draft-ietf-oauth-v2-23
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Wed, 15 Feb 2012 09:33:42 -0000

I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-dir@ietf.org if you reply to or forward this review.

First, I should apologize for the delay in this review, I should have finished it two days ago. I have some common security knowledge but not an expert.


This draft is basically ready for publication, but has nits that should be fixed before publication.

General issues need discussion: 

1. Section 1.3.3 and 1.3.4 discuss two authorization grant type: resource owner password credentials, and client credentials. These two have the same flow and many in common, and they are significantly different than the authorization code grant type and implicit grant type described in previous sections. And in section 1.3.4, it also says " Client credentials are used as an authorization grant typically when the client is acting on its own behalf (the client is also the resource owner),...". Is it better to combine these two grant types as one "client credentials" grant type where the client can be the resource owner?

2. Two concepts confused me in section 2.4, I don't know if I am the only person who is confusing here. One is user-agent-based application and another is native application, why are they executed on the device used by the resource owner? I think they can run on any device used by resource consumer instead of resource owner. Resource owner is only used to grant access to resources.

1. Section 3.1, paragraph 4, the last sentence is confusing, is it the authorization server who sends the request to the authorization endpoint? Or is it the resource owner?

2. Section 3.1.1, paragraph 3, "...where the order of values does not matter.." I think a little clarification on the reason for this would be better for people like me.

3. Section 3.2, paragraph 4, the last sentence is confusing, is it the authorization server who sends request to the token endpoint?

4. Section 10.12, paragraph 4, should the terminology "end-user" be changed to "resource owner"? There are same issues in other places of this document.

5. Section 10.6, paragraph 2, second sentence, When the attacker is sent to.../ When the authorization code request is sent to...

Kind regards,