[OAUTH-WG] Review comments to PoP Architecture

"Kepeng Li" <kepeng.lkp@alibaba-inc.com> Fri, 18 September 2015 16:56 UTC

Return-Path: <kepeng.lkp@alibaba-inc.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5398A1A6F1E for <oauth@ietfa.amsl.com>; Fri, 18 Sep 2015 09:56:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.702
X-Spam-Level:
X-Spam-Status: No, score=0.702 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvaVhip8YoTe for <oauth@ietfa.amsl.com>; Fri, 18 Sep 2015 09:56:04 -0700 (PDT)
Received: from out4133-18.mail.aliyun.com (out4133-18.mail.aliyun.com [42.120.133.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7C39F1A6EFE for <oauth@ietf.org>; Fri, 18 Sep 2015 09:56:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1442595362; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=33IUmRp6ktweR821eSD3iKAyG3yuSam/j29JbOzS5xM=; b=polb3nP1B9QnoPUkAIT7eMl0q0GkNQDqZRr7zh/rjmzx9jmb8UcoroIVhDfM/x+2ESaB7hKW8G5O8x/HGcoYJFMxIlATfB0JaJQV5TpCWylP1fr/q4xleTvXlIP3PRcM042PAqJf8+rpqdEyotWIqzdzOx5/492JGy3F5fwcnEU=
X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R211e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03292; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=1; SR=0;
Received: from 10.22.58.231(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.208) by smtp.aliyun-inc.com(127.0.0.1); Sat, 19 Sep 2015 00:55:54 +0800
User-Agent: Microsoft-MacOutlook/14.4.8.150116
Date: Sat, 19 Sep 2015 00:55:48 +0800
From: Kepeng Li <kepeng.lkp@alibaba-inc.com>
To: oauth@ietf.org
Message-ID: <D2226314.1D0D1%kepeng.lkp@alibaba-inc.com>
Thread-Topic: Review comments to PoP Architecture
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3525468954_38358161"
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/VRzM3F5C33Z9I780sB0nKARg0dI>
Subject: [OAUTH-WG] Review comments to PoP Architecture
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 18 Sep 2015 16:56:07 -0000

Hello authors,



Please find my review comments to PoP Architecture document:

https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-02



1.    Introduction:

At the time of writing the OAuth 2.0 protocol family ([RFC6749],
[RFC6750], and [RFC6819]) offer a single standardized security mechanism to
access protected resources, namely the bearer token.
[Kepeng]  This sentences seem to be incomplete. What offers a security
mechanism? Also why do we mention “at the time of writing”? Is the situation
changed now?
 

2. Section 3:
The main use case that motivates better-than-bearer token security is    the
desire of resource servers to obtain additional assurance that   the client
is indeed authorized to present an access token.
[Kepeng] About “better-than-bear”, is it a word? Maybe reword the sentence a
little bit.
 
3.Section 3.1
1) In a legitimate use case consider chaining of computations whereby a
resource server needs to consult other third party resource servers to
complete the requested operation.
[Kepeng] This sentence seems to be incomplete. Maybe reword it a little bit?
 
2) In this use case additional information is conveyed to the resource
server to ensure that no entity entity has tampered with the TLS connection.
[Kepeng] Change “is conveyed” to “should be conveyed”?
 
4. Section 3.3:
First, an eavesdropper may steal an access token and represent it at a
different resource server.
[Kepeng] Change “represent it at” to “present it to”?
 
5. Section 3.4:
These load balancers may terminate the TLS connection setup and HTTP traffic
is transmitted in the clear from the load balancer to the resource server.
[Kepeng] Don’t understand “in the clear”. Should it be “in the wire”?


Kind Regards
Kepeng