Re: [OAUTH-WG] Scope - Coming to a Consensus

Evan Gilbert <uidude@google.com> Mon, 03 May 2010 17:16 UTC

Return-Path: <uidude@google.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 B9FEB3A6A64 for <oauth@core3.amsl.com>; Mon, 3 May 2010 10:16:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.228
X-Spam-Level:
X-Spam-Status: No, score=-100.228 tagged_above=-999 required=5 tests=[AWL=-1.452, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, USER_IN_WHITELIST=-100]
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 vQZ8RK64t-vv for <oauth@core3.amsl.com>; Mon, 3 May 2010 10:16:35 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id 476A03A6A5B for <oauth@ietf.org>; Mon, 3 May 2010 10:16:35 -0700 (PDT)
Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [10.3.21.3]) by smtp-out.google.com with ESMTP id o43HGJ1U021839 for <oauth@ietf.org>; Mon, 3 May 2010 10:16:19 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1272906980; bh=M1dHLFCUHcDbvY+9O+uONc/8H1E=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=WVgOgugC0KY7jywssLIkDycO59+0ve+WLi1zV3napIt9GNtQdplbxcyLiN6cdhOWl MMweTypYPxU/JJGVtBZmA==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=QmhxPCEHkMYnxfwpqsmEyIdqYbx9ItNXJoqjcjPlQAJaB6E/d9PrRNETmoBrgDFva tM4xQGmaCDEbGezvB8cxA==
Received: from ywh41 (ywh41.prod.google.com [10.192.8.41]) by hpaq3.eem.corp.google.com with ESMTP id o43HGHkV003824 for <oauth@ietf.org>; Mon, 3 May 2010 10:16:18 -0700
Received: by ywh41 with SMTP id 41so1155394ywh.9 for <oauth@ietf.org>; Mon, 03 May 2010 10:16:17 -0700 (PDT)
Received: by 10.151.16.4 with SMTP id t4mr9962470ybi.107.1272906976728; Mon, 03 May 2010 10:16:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.94.18 with HTTP; Mon, 3 May 2010 10:15:56 -0700 (PDT)
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1126277CFE7@WSMSG3153V.srv.dir.telstra.com>
References: <90C41DD21FB7C64BB94121FBBC2E723439321772EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <C80078D0.2D681%atom@yahoo-inc.com> <AANLkTikJBx-BwdLvgszIhSo9cf5WsJZvtjrWznei44Te@mail.gmail.com> <60C3123B-4FCF-425C-A808-AFB4745AECC6@facebook.com> <CD5AE76F-61F4-43EA-B97C-5A575C8AA674@gmail.com> <255B9BB34FB7D647A506DC292726F6E1126277CFE7@WSMSG3153V.srv.dir.telstra.com>
From: Evan Gilbert <uidude@google.com>
Date: Mon, 3 May 2010 10:15:56 -0700
Message-ID: <AANLkTimmtcdSzit_MlvoMhpWq_JWWQCZv_WxZwoEe4jG@mail.gmail.com>
To: "Manger, James H" <James.H.Manger@team.telstra.com>
Content-Type: multipart/alternative; boundary=000e0cd5c66e2e35a40485b3c024
X-System-Of-Record: true
Cc: "OAuth WG \(oauth@ietf.org\)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Scope - Coming to a Consensus
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: Mon, 03 May 2010 17:16:36 -0000

+1 on option 3.

Commas seem slightly cleaner, but can go either way.

We should also consider naming this parameter "scopes" if we go with option
3

Evan

On Mon, May 3, 2010 at 6:23 AM, Manger, James H <
James.H.Manger@team.telstra.com> wrote:

> A comma is a better separator here.
> Allow URIs as scopes -- as long as the chosen URIs don't have commas. This
> isn't a big restriction on services.
>
> [If a service provider really needs to include arbitrary URIs in an
> authorization URI they can still do so by defining another parameter, say
> "urls". We are barely defining any semantics for "scope" -- at least none
> that libraries can use -- so not much is lost in using a different parameter
> name.]
>
>
> A space-separated list (encoded as per the transport) sounds nice at a
> logical level, but is just a bit unnecessarily awkward. The only place scope
> values appear is in an authz URI so the only encoding is URI-encoding. Are
> the spaces escaped as "%20" or "+"? Even if we try to pick one answer I
> suspect both will occur (it depends on which part of the software builds the
> authz URI -- ie prepare for interop glitches).
> Any spaces in a URI used as a scope value needs to be %-escaped twice. It
> seems unnecessary to even allow this.
>
>
> Facebook define values like scope=read,write.
> However, if you build an authz URI from an HTML form with an input value of
> "read,write" you get scope=read%2Cwrite -- as comma is not an unreserved
> character.
>  <input name="scope" value="read,write"/>
> I suspect authz services might need to accept "read%2Cwrite" as equivalent
> to "read,write" [I wonder if Facebook does?]. Which gets produced will
> depend on how the client app (or client OAuth library) is designed, and will
> vary between apps. The spec probably need to say services MUST accept ","
> and "%2C" as separators -- and consequently individual scope values MUST NOT
> contain "," or "%2C".
>
>
> I think the best definition (least potential for any developer or interop
> grief) would restrict individual scope values to chars that can be placed in
> a query parameter value without any special treatment.
> Allow any chars allowed in URIs, except "&", "#", "%", or ",".
> This doesn't allow arbitrary URIs, but I suspect it allows any URIs being
> used as scopes at present.
>
> --
> James Manger
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>