Re: [OAUTH-WG] OMA Liaison Has Arrived! scope-v

"Manger, James H" <James.H.Manger@team.telstra.com> Thu, 18 August 2011 11:14 UTC

Return-Path: <James.H.Manger@team.telstra.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC5321F8AD2 for <oauth@ietfa.amsl.com>; Thu, 18 Aug 2011 04:14:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.134
X-Spam-Level:
X-Spam-Status: No, score=-4.134 tagged_above=-999 required=5 tests=[AWL=-3.233, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhNmwW+uKB9S for <oauth@ietfa.amsl.com>; Thu, 18 Aug 2011 04:14:30 -0700 (PDT)
Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 7355B21F8ADE for <oauth@ietf.org>; Thu, 18 Aug 2011 04:14:28 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.68,244,1312120800"; d="scan'208";a="42850022"
Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipoavi.tcif.telstra.com.au with ESMTP; 18 Aug 2011 21:15:21 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,6441"; a="34563783"
Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcavi.tcif.telstra.com.au with ESMTP; 18 Aug 2011 21:15:21 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Thu, 18 Aug 2011 21:15:20 +1000
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: Barry Leiba <barryleiba@computer.org>, "oauth@ietf.org" <oauth@ietf.org>
Date: Thu, 18 Aug 2011 21:15:18 +1000
Thread-Topic: [OAUTH-WG] OMA Liaison Has Arrived! scope-v
Thread-Index: AcxdHRt2KDLjqfJoQaO9VydhcegKRwAVKytw
Message-ID: <255B9BB34FB7D647A506DC292726F6E1128B5BB96C@WSMSG3153V.srv.dir.telstra.com>
References: <CAC4RtVCafc=sTUOZ0h7BtXZ2rmZGpZ5xRCrsP=0fHRh8kOF3Cg@mail.gmail.com>
In-Reply-To: <CAC4RtVCafc=sTUOZ0h7BtXZ2rmZGpZ5xRCrsP=0fHRh8kOF3Cg@mail.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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] OMA Liaison Has Arrived! scope-v
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 18 Aug 2011 11:14:31 -0000

>> *	For bearer tokens: clarification whether the non-support of percent
encoding for scope-v element of WWW-Authenticate Response Header Field
grammar is intentional.

> Answer:
> In the bearer token document (Section 2.4 of
> draft-ietf-oauth-v2-bearer-08, "The WWW-Authenticate Response Header
> Field"), the "scope-v" element is unambiguously defined to allow a
> specific set of characters.  That set of characters does permit, but
> does not mandate, support for percent-encoding of characters.


This is a poor answer.
A client app receiving a scope value in an "WWW-Authenticate: Bearer scope=..." response will either compare it with strings from a OAuth2 JSON-encoded token response, or copy it into a request to an authorization server. It needs to know if it needs to %-decode the value or not before doing these things. Clients cannot be expected to behave differently for different servers in this respect.

OAuth2 core (implicitly) allows a scope to use any Unicode char except space (as space is used as a delimiter).
Bearer restricts scopes to 93 ASCII chars.
OMA are asking if this is intentional.

If we really want to restrict scope values it would be better done in OAuth2 core.
If we don't want to restrict values then the bearer spec needs to be able to handle any possible scope value by defining an escaping mechanism for scope-v (or by not having a scope parameter).

--
James Manger