Re: [OAUTH-WG] [Gen-art] Gen-ART review of draft-ietf-oauth-v2-bearer-15.txt

Alexey Melnikov <alexey.melnikov@isode.com> Tue, 10 April 2012 13:47 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFED21F85F4; Tue, 10 Apr 2012 06:47:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.32
X-Spam-Level:
X-Spam-Status: No, score=-102.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrIGDDjWgWMK; Tue, 10 Apr 2012 06:47:45 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC6021F85D6; Tue, 10 Apr 2012 06:47:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1334065664; d=isode.com; s=selector; i=@isode.com; bh=XNGmDZTKRipUA6dftlaMuOIziTczDoq3IBCKRkSlcdE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Wd8UspvHARyeVhqASVJhssS1uMUrz2xuTVqBmT30chhQeBQmMsmFiC8O9ggnBsSh/zAGmx BDWCKp7st6OgtPU3pA4uHSOVomY7BHIctfB+ttPw78Flm+IrntNh0bLW7VgKWqROqGEnKv GaBT0eadY24c4fIOPPZMeEgjpSlwI9c=;
Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id <T4Q5=gAg26fi@rufus.isode.com>; Tue, 10 Apr 2012 14:47:43 +0100
X-SMTP-Protocol-Errors: PIPELINING
Message-ID: <4F843A22.4020908@isode.com>
Date: Tue, 10 Apr 2012 14:48:18 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
To: Mike Jones <Michael.Jones@microsoft.com>
References: <4F2575CE.9040001@isode.com> <4E1F6AAD24975D4BA5B16804296739436638B7AD@TK5EX14MBXC284.redmond.corp.microsoft.com> <4F27C37C.1090008@isode.com>
In-Reply-To: <4F27C37C.1090008@isode.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: General Area Review Team <gen-art@ietf.org>, "oauth@ietf.org" <oauth@ietf.org>, "draft-ietf-oauth-v2-bearer.all@tools.ietf.org" <draft-ietf-oauth-v2-bearer.all@tools.ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [OAUTH-WG] [Gen-art] Gen-ART review of draft-ietf-oauth-v2-bearer-15.txt
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: Tue, 10 Apr 2012 13:47:46 -0000

Hi Mike,

On 31/01/2012 10:33, Alexey Melnikov wrote:
> On 30/01/2012 05:20, Mike Jones wrote:
>> Thanks for your useful feedback, Alexey.
> Hi Mike,
>>    Below, I'll respond to each of your comments.  I've also added the 
>> OAuth working group to the thread, so they are aware of them as well 
>> and can participate in the discussion.
  [...]
>> About your comments on scope:  OAuth 2.0 (both the Core and Bearer 
>> specs) is designed to be deployed in diverse and non-interoperable 
>> application contexts, meeting a variety of application needs.  In 
>> those various settings, which are often distinct and potentially 
>> non-interoperable, parameters such as scope, realm, etc. may have 
>> very different meanings.  This is not a bug; it is a feature, because 
>> it allows the OAuth pattern to meet the needs of numerous, often 
>> distinct, application environments.  For that reason, a registry of 
>> scope (or realm) parameters would be ill-advised and 
>> counterproductive.  It's perfectly OK and expected for a scope value 
>> such as "email" to have one meaning in one application context and a 
>> different meaning in a different, but distinct application context.  
>> Trying to impose a single meaning on particular scope values across 
>> distinct application contexts is both unnecessary and could break 
>> many existing deployments.  That being said, we fully expect
>> interoperability profiles to emerge that define interoperable sets of 
>> scope values within particular application contexts.  (The OpenID 
>> Connect specifications are one such set of profiles.)  But these 
>> meanings will always be context-specific - not global in scope.
> The way "scope" is currently defined in the document is completely 
> useless. You don't have a single example in the document. You don't 
> say how the semantics of the value differs from realm. You don't say 
> that its values are deployment specific and can be profiled in future 
> documents. Please say something about these issues in the document 
> (your explanation above would work.)
  [...]
>> About your second minor issue on error codes, the error codes 
>> registry already exists, but is in the OAuth Core spec.  See 
>> http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-11.4.
> Can you please make this clear in the document (by adding a reference)?

I didn't see any of these addressed in -16...18. If I've missed that or 
if I've missed the discussion why these are not valid concerns, please 
let me know.