Re: [OAUTH-WG] Proposed resolution for issue 26

Mike Jones <Michael.Jones@microsoft.com> Wed, 28 September 2011 15:55 UTC

Return-Path: <Michael.Jones@microsoft.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 B640811E80BD for <oauth@ietfa.amsl.com>; Wed, 28 Sep 2011 08:55:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.502
X-Spam-Level:
X-Spam-Status: No, score=-10.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 TXys8xgE3l7m for <oauth@ietfa.amsl.com>; Wed, 28 Sep 2011 08:55:48 -0700 (PDT)
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id B651A11E80C1 for <oauth@ietf.org>; Wed, 28 Sep 2011 08:55:48 -0700 (PDT)
Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 28 Sep 2011 08:58:37 -0700
Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.193]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.01.0339.002; Wed, 28 Sep 2011 08:58:36 -0700
From: Mike Jones <Michael.Jones@microsoft.com>
To: Barry Leiba <barryleiba@computer.org>, "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] Proposed resolution for issue 26
Thread-Index: Acx5+RoYuC5sLQs0Spy/pi+T441Q9ABABAUAAGEPyiAAQvblAAAlYWwAAAnX4mA=
Date: Wed, 28 Sep 2011 15:58:36 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739435C21877F@TK5EX14MBXC285.redmond.corp.microsoft.com>
References: <4E1F6AAD24975D4BA5B16804296739435C1FC6A1@TK5EX14MBXC285.redmond.corp.microsoft.com> <CAC4RtVDOPaMif55L6JAU4C8aERHgt6M0ntet7GKwgQJbUQKMZw@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739435C2148B5@TK5EX14MBXC285.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1128FF826E5@WSMSG3153V.srv.dir.telstra.com> <CAC4RtVAj7UG-7kgo3CU5Q6eeJFXi2VciQHUoGL5WJ8iq5cmykg@mail.gmail.com>
In-Reply-To: <CAC4RtVAj7UG-7kgo3CU5Q6eeJFXi2VciQHUoGL5WJ8iq5cmykg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.35]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Proposed resolution for issue 26
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: Wed, 28 Sep 2011 15:55:49 -0000

I'd also like to see more working group participation in this discussion.

				Thanks,
				-- Mike

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Barry Leiba
Sent: Wednesday, September 28, 2011 6:40 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Proposed resolution for issue 26

I'd like to see more participation in this thread, besides just from Mike and James.  What do others think?

Barry, as chair

On Mon, Sep 26, 2011 at 3:05 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
> While you take the viewpoint that the bearer spec is restricting scope 
> values, in fact, the spec intentionally allows all characters that can 
> be safely communicated in an HTTP response header parameter to be 
> used.  About whether those characters employ an encoding methodology 
> to sometimes represent other characters or abstractions, I believe 
> that Barry's proposed wording hits the nail on the head:
>
>   Interpretation of scope strings requires semantic agreement on the
>   meaning of the scope strings between the parties participating the
>   OAuth flow.  Should an encoding be used for scope strings in a
>   particular deployment context, participants have to have agreed
>   upon that encoding, just as they agree on other OAuth configuration
>   parameters.
>
>                                Best wishes,
>                                -- Mike


On Mon, Sep 26, 2011 at 8:20 PM, Manger, James H <James.H.Manger@team.telstra.com> wrote:
>> While you take the viewpoint that the bearer spec is restricting 
>> scope values, in fact, the spec intentionally allows all characters 
>> that can be safely communicated in an HTTP response header parameter to be used.
>
> But "all characters that can be safely communicated in an HTTP 
> response header parameter" is only a subset of the characters that 
> OAuth Core allows in a scope value (any Unicode string excluding 
> space). I don't understand how this isn't the Bearer spec restricting scope values.
>
>
> P.S. You recognize here that non-ASCII chars cannot be safely 
> communicated in an HTTP response header parameter. This is why Julian 
> was concerned about the spec saying the error_description holds raw 
> UTF-8.
> [Actually the ABNF for error_description restricts it to 93 ASCII 
> chars so when the text says it is UTF-8 encoded it is raising the 
> potential problem of arbitrary UTF-8 in HTTP headers unnecessarily.]
>
> --
> James Manger


On Tue, Sep 27, 2011 at 11:50 PM, Manger, James H <James.H.Manger@team.telstra.com> wrote:
> I'll have another go trying to explain the problem I see with the 
> scope parameter in the Bearer spec.
>
> Consider a French social network that decides to offer an API using OAuth2.
> It chooses 3 scope values for parts of the API related to family, 
> friends, and business colleagues:
> * "famille"
> * "ami"
> * "collègues"
> Let's focus on the last scope.
>
> The site describes the scope and its semantics in HTML developer docs.
> That works.
>  <dt>coll&#xE8;gues</dt><dd>...</dd>
>
> Client apps construct authorization URIs to which users are sent.
> That works.
>  https://example.fr/authz?scope=coll%C3%A8gues...
>
> The authorization server issues credentials in a JSON token response.
> That works.
>  { "access_token":"SlAV32hkKG", "scope":"coll\u00E8gues", ...}
>
> The authorization server also supports implicit grants. That works.
>  Location: https://app.client.org/callback#scope=coll%C3%A8gues...
>
> Client apps request protected resources (without needing to mention scope).
> That works.
>  Authorization: Bearer vF9dft4qmT
>
> A protected resource server responds with a 401 error when a bearer 
> token is wrong. They don't know what to put in the HTTP response 
> header scope
> parameter: "collègues" does not fit.
>
> One server knows HTTP headers have historically used ISO-8859-1.
>  WWW-Authenticate: Bearer scope="coll<E8>gues", error_description="opps"...
>
> Another server sees that error_description is specified as UTF-8 so uses that.
>  WWW-Authenticate: Bearer scope="coll<C3><A8>gues", error_description="opps"...
>
> A third server reasons that the value will be copied to an authz URI 
> so uses URI-escaping.
>  WWW-Authenticate: Bearer scope="coll%C3%A8gues", error_description="opps"...
>
> A fourth server thinks JSON-escaping looks most like HTTP's 
> quoted-string quoting (both use '\').
>  WWW-Authenticate: Bearer scope="coll\u00E8gues", error_description="opps"...
>
> A fifth uses RFC 5987 "Character Set and Language Encoding for HTTP 
> Header Field Parameters":
>  WWW-Authenticate: Bearer scope*=UTF-8''coll%C3%A8gues, error_description="opps"...
>
> It is a total interoperability failure for the client apps. The 
> paragraph in the Bearer spec saying the encoding of the scope values 
> is up to each "particular deployment context" looks like a cruel joke to the app and library developers.
>
> --
> James Manger
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth