Re: [OAUTH-WG] 'Scope' parameter proposal

Chasen Le Hara <chasen@ironmoney.com> Thu, 22 April 2010 19:53 UTC

Return-Path: <chasen@ironmoney.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 9B2133A68CD for <oauth@core3.amsl.com>; Thu, 22 Apr 2010 12:53:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.221
X-Spam-Level:
X-Spam-Status: No, score=0.221 tagged_above=-999 required=5 tests=[AWL=0.709, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
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 MDOFxumESpCu for <oauth@core3.amsl.com>; Thu, 22 Apr 2010 12:53:48 -0700 (PDT)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 9913E3A6944 for <oauth@ietf.org>; Thu, 22 Apr 2010 12:49:29 -0700 (PDT)
Received: by pwj2 with SMTP id 2so6347002pwj.31 for <oauth@ietf.org>; Thu, 22 Apr 2010 12:49:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.15.68 with HTTP; Thu, 22 Apr 2010 12:49:14 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723438E5C7FD26@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <C7F1D1FC.32809%eran@hueniverse.com> <0D5497F5-75A7-4A42-9A5E-9C2310162B18@jkemp.net> <90C41DD21FB7C64BB94121FBBC2E723438E5C7F30A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <g2mdaf5b9571004221036j5d6837f6z4d7959d69a3cbb2b@mail.gmail.com> <BB02FD4F-071E-4FF5-B3D0-F8D3FA22FEEE@jkemp.net> <90C41DD21FB7C64BB94121FBBC2E723438E5C7FD26@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Date: Thu, 22 Apr 2010 12:49:14 -0700
Received: by 10.140.57.2 with SMTP id f2mr232536rva.210.1271965755124; Thu, 22 Apr 2010 12:49:15 -0700 (PDT)
Message-ID: <u2g4c07358b1004221249r9981bc4fm95534356fea43985@mail.gmail.com>
From: Chasen Le Hara <chasen@ironmoney.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>
Content-Type: multipart/alternative; boundary="001636b2b01c0063dd0484d89b3c"
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] 'Scope' parameter proposal
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: Thu, 22 Apr 2010 19:53:49 -0000

On Thu, Apr 22, 2010 at 12:07 PM, Eran Hammer-Lahav <eran@hueniverse.com>wrote:

> This suggests we need to rethink our goal of interop and replace it with
> library re-use.
>
> To me interop means that a client can interact with an unknown server by
> simply speaking the protocol (the way an email can be delivered to any
> server). Library re-use means that we define a set of configuration values
> (client identifier, endpoints, cryptographic algorithms, scope, realm
> policy, etc.) and once those are manually set (or via a discovery
> specification that is completely out of scope) to make the library work.
>
> If we are not going to enable a client to access a protected resource
> hosted by an unfamiliar server, we need to stop pretending this (alone) is
> about interop. In other words, if we take this approach we are mandating
> paperwork to make the protocol work, at least based on this single
> specification. We can also drop advertising the authorization and token
> endpoints in a 401 or really *any* parameter in a WWW-Authenticate response.
>

In my case, the proposed "bucket of opaque strings separated by spaces" does
enable a client to access protected resources without knowing the details of
Iron Money’s permission system.

In 1.0, there was no set way of doing scope/permissions, which led me to a
custom solution in which it’s not possible to access any protected resources
without reading the documentation. With scope, the client wouldn’t need to
know anything about the permission system; Iron Money could simply reply
with the required scope values to access the resource.

It seems as if this would also fit Facebook’s requirements, and I’m guessing
this would fit the bill for most service providers as well.
-Chasen