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

Alexey Melnikov <> Tue, 10 April 2012 13:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6AFED21F85F4; Tue, 10 Apr 2012 06:47:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.32
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CrIGDDjWgWMK; Tue, 10 Apr 2012 06:47:45 -0700 (PDT)
Received: from ( []) by (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;; s=selector;; 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 [] ( []) by (submission channel) via TCP with ESMTPSA id <>; Tue, 10 Apr 2012 14:47:43 +0100
X-SMTP-Protocol-Errors: PIPELINING
Message-ID: <>
Date: Tue, 10 Apr 2012 14:48:18 +0100
From: Alexey Melnikov <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
To: Mike Jones <>
References: <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: General Area Review Team <>, "" <>, "" <>, The IESG <>
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-oauth-v2-bearer-15.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 
> 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.