Re: [OAUTH-WG] Feedback on preliminary draft 11 from implementers of draft 10

Eve Maler <eve@xmlgrrl.com> Sun, 05 December 2010 03:40 UTC

Return-Path: <eve@xmlgrrl.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E9123A69E7 for <oauth@core3.amsl.com>; Sat, 4 Dec 2010 19:40:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.293
X-Spam-Level:
X-Spam-Status: No, score=-1.293 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+4Nye+Hdxd9 for <oauth@core3.amsl.com>; Sat, 4 Dec 2010 19:40:54 -0800 (PST)
Received: from mail.promanage-inc.com (eliasisrael.com [98.111.84.13]) by core3.amsl.com (Postfix) with ESMTP id A00623A69D4 for <oauth@ietf.org>; Sat, 4 Dec 2010 19:40:51 -0800 (PST)
Received: from [192.168.168.185] ([192.168.168.185]) (authenticated bits=0) by mail.promanage-inc.com (8.14.4/8.14.3) with ESMTP id oB53gBgG019878 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 4 Dec 2010 19:42:11 -0800
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Eve Maler <eve@xmlgrrl.com>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343D4B06532D@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Sat, 04 Dec 2010 19:42:11 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <62D210BF-3FA7-4789-9382-5BCCE45C5F84@xmlgrrl.com>
References: <4E1F6AAD24975D4BA5B16804296739432461C3F9@TK5EX14MBXC201.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E72343D4B06532D@P3PW5EX1MB01.EX1.SECURESERVER.NET>
To: "oauth@ietf.org (oauth@ietf.org)" <oauth@ietf.org>
X-Mailer: Apple Mail (2.1082)
Subject: Re: [OAUTH-WG] Feedback on preliminary draft 11 from implementers of draft 10
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sun, 05 Dec 2010 03:40:55 -0000

A comment on Mike's comment on the idea of a "resource" parameter...

On 24 Nov 2010, at 11:31 PM, Eran Hammer-Lahav wrote:

> Thanks Mike! Comments inline.
> 
>> Normative Issues
>> 
>> 4.1, 4.2, 4.3.1, 5, 5.2, 5.3.1, 6.2, 6.2.1 "Scope" parameter should be paired with
>> complimentary "resource" parameter
> 
> I am more inclined to drop 'scope' than to include 'resource'. Scope as currently defined can easily accommodate resource - we specifically chose space-delimited to allow URI values. If you want a new parameter, *you* will have to build consensus. Not wearing my editor hat, I'm -1.

Over in UMA-land we've had to solve for this because our use cases anticipate protecting arbitrary resources, not just singular APIs, and because our loosely coupled resource server and authorization server components need to communicate about this stuff in an organized fashion.

After many months of discussion, as well as UX and implementation work by various participants, in the last week we finally got consensus around having two parts (resource sets and actions, the latter being a close analogue to today's OAuth scopes) rather than a single flat scope namespace.  The degenerate case could be very much like today's common practice, but we believe it handles a lot more use cases.

There's still work to do to propagate information in this two-part form throughout the protocol flow (which is what Mike was directly suggesting), but at least we now have a conceptual foundation for doing that.  If there is consensus here for adding a parameter, it would make UMA's life easier as we wouldn't have to invent anything weird and nonstandard. :-)

See the "Resource Registration" spec link from our Working Drafts page for more info; if there's sufficient interest, we could contribute it as an IETF I-D soonish:

http://kantarainitiative.org/confluence/display/uma/Working+Drafts

	Eve

Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl