Re: [OAUTH-WG] Possible alternative resolution to issue 26
Eran Hammer-Lahav <eran@hueniverse.com> Wed, 05 October 2011 17:25 UTC
Return-Path: <eran@hueniverse.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 01B5C1F0C61 for <oauth@ietfa.amsl.com>; Wed, 5 Oct 2011 10:25:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.56
X-Spam-Level:
X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 H6XRAFyi8Wd5 for <oauth@ietfa.amsl.com>; Wed, 5 Oct 2011 10:25:36 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 050791F0C5A for <oauth@ietf.org>; Wed, 5 Oct 2011 10:25:35 -0700 (PDT)
Received: (qmail 18548 invoked from network); 5 Oct 2011 17:28:44 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 5 Oct 2011 17:28:43 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 5 Oct 2011 10:28:19 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: William Mills <wmills@yahoo-inc.com>, "Thomson, Martin" <Martin.Thomson@commscope.com>, Mike Jones <Michael.Jones@microsoft.com>, Marius Scurtescu <mscurtescu@google.com>, Phil Hunt <phil.hunt@oracle.com>
Date: Wed, 05 Oct 2011 10:28:13 -0700
Thread-Topic: [OAUTH-WG] Possible alternative resolution to issue 26
Thread-Index: AcyC8TXeHr+mLpCCQKK8/zcqiFejegAkmqhg
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723452602A522F@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <4E1F6AAD24975D4BA5B16804296739435C21DD2C@TK5EX14MBXC284.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1129015546C@WSMSG3153V.srv.dir.telstra.com> <1317621663.4810.YahooMailNeo@web31813.mail.mud.yahoo.com> <4E1F6AAD24975D4BA5B16804296739435C226298@TK5EX14MBXC284.redmond.corp.microsoft.com> <1317704315.93442.YahooMailNeo@web31811.mail.mud.yahoo.com> <4E8B2DE1.2090706@mtcc.com> <C2C10679-2611-415B-80B7-8526937C1E82@oracle.com> <1317747487.89926.YahooMailNeo@web31809.mail.mud.yahoo.com> <6B898133-E7D0-45B1-9E3B-3B6DAFCDF671@oracle.com> <CAGdjJpJ+XkyPAJXEJa-3p3tNTxKzMpZXSHmH3H-m-7T9v=4x0Q@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739435C2276BD@TK5EX14MBXC284.redmond.corp.microsoft.com> <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0CAAA@SISPE7MB1.commscope.com> <1317772567.49150.YahooMailNeo@web31811.mail.mud.yahoo.com>
In-Reply-To: <1317772567.49150.YahooMailNeo@web31811.mail.mud.yahoo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723452602A522FP3PW5EX1MB01E_"
MIME-Version: 1.0
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Possible alternative resolution to 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, 05 Oct 2011 17:25:37 -0000
It should be much simpler than that. The v2 spec should simply limit the character set to printable ascii with special meaning for space. Beyond that, these are just ascii strings which can be URIs or anything else. If the server choose to use these strings with some internal meaning (i.e. URI or encoded data), it should specify how normalization may occure. But the point is, these are meant to be opaque, space-delimited string. Any interop beyond that requires additional specification (e.g. comma delimited inner string values, etc.). It would be really helpful if people provide actual use cases and requirements. Everything I have seen so far will work just fine with a limited ascii set. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of William Mills Sent: Tuesday, October 04, 2011 4:56 PM To: Thomson, Martin; Mike Jones; Marius Scurtescu; Phil Hunt Cc: oauth@ietf.org WG Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 Allowing URI requires allowing % encoding, which is workable. As far as the protocol goes URI is a form of space separated string and the protocol doesn't care. URI doesn't include quote or qhitespace in the allowed characters so there's no problem there. I agree that we'd have to write it such that it's clear you don't have to use a URI. Drawing from http://labs.apache.org/webarch/uri/rev-2002/rfc2396bis.html#path perhaps the allowed charset becomes scope = *( unreserved / reserved / pct-encoded ) with the clarification that a scope MAY take the form of a properly formatted URI. -bill ________________________________ From: "Thomson, Martin" <Martin.Thomson@commscope.com<mailto:Martin.Thomson@commscope.com>> To: Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>>; Marius Scurtescu <mscurtescu@google.com<mailto:mscurtescu@google.com>>; Phil Hunt <phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>> Cc: "oauth@ietf.org WG<mailto:oauth@ietf.org%20WG>" <oauth@ietf.org<mailto:oauth@ietf.org>> Sent: Tuesday, October 4, 2011 4:08 PM Subject: Re: [OAUTH-WG] Possible alternative resolution to issue 26 On 2011-10-05 at 05:07:06, Mike Jones wrote: > Existing practice is that simple ASCII strings like "email" "profile", > "openid", etc. are used as scope elements. Requiring them to be URIs > would break most existing practice. Constraining syntax to an ascii token OR a URI (relative reference) might work. Anything with a colon can be interpreted as a URI; anything without better use a constrained set of characters. _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
- [OAUTH-WG] Possible alternative resolution to iss… Mike Jones
- Re: [OAUTH-WG] Possible alternative resolution to… Buhake Sindi
- Re: [OAUTH-WG] Possible alternative resolution to… Julian Reschke
- Re: [OAUTH-WG] Possible alternative resolution to… Mike Jones
- Re: [OAUTH-WG] Possible alternative resolution to… Eran Hammer-Lahav
- Re: [OAUTH-WG] Possible alternative resolution to… Manger, James H
- Re: [OAUTH-WG] Possible alternative resolution to… Eran Hammer-Lahav
- Re: [OAUTH-WG] Possible alternative resolution to… William Mills
- Re: [OAUTH-WG] Possible alternative resolution to… Mike Jones
- Re: [OAUTH-WG] Possible alternative resolution to… Dick Hardt
- Re: [OAUTH-WG] Possible alternative resolution to… Dick Hardt
- Re: [OAUTH-WG] Possible alternative resolution to… William Mills
- Re: [OAUTH-WG] Possible alternative resolution to… Julian Reschke
- Re: [OAUTH-WG] Possible alternative resolution to… Michael Thomas
- Re: [OAUTH-WG] Possible alternative resolution to… Phil Hunt
- Re: [OAUTH-WG] Possible alternative resolution to… William Mills
- Re: [OAUTH-WG] Possible alternative resolution to… Phil Hunt
- Re: [OAUTH-WG] Possible alternative resolution to… Marius Scurtescu
- Re: [OAUTH-WG] Possible alternative resolution to… Mike Jones
- Re: [OAUTH-WG] Possible alternative resolution to… Marius Scurtescu
- Re: [OAUTH-WG] Possible alternative resolution to… John Kemp
- Re: [OAUTH-WG] Possible alternative resolution to… Julian Reschke
- Re: [OAUTH-WG] Possible alternative resolution to… Marius Scurtescu
- Re: [OAUTH-WG] Possible alternative resolution to… Thomson, Martin
- Re: [OAUTH-WG] Possible alternative resolution to… Barry Leiba
- Re: [OAUTH-WG] Possible alternative resolution to… William Mills
- Re: [OAUTH-WG] Possible alternative resolution to… Julian Reschke
- Re: [OAUTH-WG] Possible alternative resolution to… Eran Hammer-Lahav
- Re: [OAUTH-WG] Possible alternative resolution to… William Mills
- Re: [OAUTH-WG] Possible alternative resolution to… Mike Jones
- Re: [OAUTH-WG] Possible alternative resolution to… Mike Jones
- Re: [OAUTH-WG] Possible alternative resolution to… Julian Reschke
- Re: [OAUTH-WG] Possible alternative resolution to… Manger, James H
- Re: [OAUTH-WG] Possible alternative resolution to… Julian Reschke
- Re: [OAUTH-WG] Possible alternative resolution to… William Mills
- Re: [OAUTH-WG] Possible alternative resolution to… Manger, James H
- Re: [OAUTH-WG] Possible alternative resolution to… Julian Reschke