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

Mike Jones <Michael.Jones@microsoft.com> Mon, 26 September 2011 19:00 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 93B081F0C68 for <oauth@ietfa.amsl.com>; Mon, 26 Sep 2011 12:00:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.494
X-Spam-Level:
X-Spam-Status: No, score=-10.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 ucLWTBLYZi4E for <oauth@ietfa.amsl.com>; Mon, 26 Sep 2011 12:00:49 -0700 (PDT)
Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 776A01F0CEE for <oauth@ietf.org>; Mon, 26 Sep 2011 12:00:37 -0700 (PDT)
Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 26 Sep 2011 12:03:20 -0700
Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.193]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0339.002; Mon, 26 Sep 2011 12:03:20 -0700
From: Mike Jones <Michael.Jones@microsoft.com>
To: Barry Leiba <barryleiba@computer.org>
Thread-Topic: [OAUTH-WG] Proposed resolution for issue 26
Thread-Index: Acx5+RoYuC5sLQs0Spy/pi+T441Q9ABABAUAAGEPyiA=
Date: Mon, 26 Sep 2011 19:03:19 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739435C2148B5@TK5EX14MBXC285.redmond.corp.microsoft.com>
References: <4E1F6AAD24975D4BA5B16804296739435C1FC6A1@TK5EX14MBXC285.redmond.corp.microsoft.com> <CAC4RtVDOPaMif55L6JAU4C8aERHgt6M0ntet7GKwgQJbUQKMZw@mail.gmail.com>
In-Reply-To: <CAC4RtVDOPaMif55L6JAU4C8aERHgt6M0ntet7GKwgQJbUQKMZw@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.74]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "oauth@ietf.org" <oauth@ietf.org>
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: Mon, 26 Sep 2011 19:00:50 -0000

Sounds good to me.  Are others good with this wording?

				-- Mike

-----Original Message-----
From: barryleiba.mailing.lists@gmail.com [mailto:barryleiba.mailing.lists@gmail.com] On Behalf Of Barry Leiba
Sent: Saturday, September 24, 2011 6:33 AM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Proposed resolution for issue 26

> My proposed resolution is that %-encoding not be required in the 
> specification

I agree with your analysis, now that I see it laid out clearly.  I would feel better, though, if there were text in the document that explained that to others, who read it later.  Perhaps, using your words, we could make this change to section 2.4:

OLD
   The "scope" attribute is a space-delimited list of scope values
   indicating the required scope of the access token for accessing the
   requested resource.  The "scope" attribute MUST NOT appear more than
   once.

NEW
   The "scope" attribute is a space-delimited list of scope values
   indicating the required scope of the access token for accessing the
   requested resource.  The "scope" attribute MUST NOT appear more than
   once.

   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.

Does that work?

Barry