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

"Manger, James H" <James.H.Manger@team.telstra.com> Mon, 03 May 2010 13:25 UTC

Return-Path: <James.H.Manger@team.telstra.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 212643A6CBE for <oauth@core3.amsl.com>; Mon, 3 May 2010 06:25:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.02
X-Spam-Level: **
X-Spam-Status: No, score=2.02 tagged_above=-999 required=5 tests=[AWL=-1.503, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_EQ_AU=0.377, J_CHICKENPOX_54=0.6, RDNS_NONE=0.1, RELAY_IS_203=0.994]
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 E9qdbWq7y-En for <oauth@core3.amsl.com>; Mon, 3 May 2010 06:25:38 -0700 (PDT)
Received: from ipxbvo.tcif.telstra.com.au (unknown [203.35.135.204]) by core3.amsl.com (Postfix) with ESMTP id DB23328C1A8 for <oauth@ietf.org>; Mon, 3 May 2010 06:24:07 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.52,319,1270389600"; d="scan'208";a="1919930"
Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 03 May 2010 23:23:52 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,5970"; a="1425410"
Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcavi.tcif.telstra.com.au with ESMTP; 03 May 2010 23:23:52 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Mon, 3 May 2010 23:23:51 +1000
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Date: Mon, 3 May 2010 23:23:50 +1000
Thread-Topic: [OAUTH-WG] Scope - Coming to a Consensus
Thread-Index: Acrpk6vOPnVOdWKjSzqddhqyA+nnWgBJrrYw
Message-ID: <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>
In-Reply-To: <CD5AE76F-61F4-43EA-B97C-5A575C8AA674@gmail.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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 13:25:39 -0000

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