Re: [OAUTH-WG] Proposed change to OAuth parameters registry
Eran Hammer-Lahav <eran@hueniverse.com> Wed, 06 April 2011 14:17 UTC
Return-Path: <eran@hueniverse.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 1094528C0DB for <oauth@core3.amsl.com>; Wed, 6 Apr 2011 07:17:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.629
X-Spam-Level:
X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 2ov+u65axgnf for <oauth@core3.amsl.com>; Wed, 6 Apr 2011 07:17:42 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id F387828C0E4 for <oauth@ietf.org>; Wed, 6 Apr 2011 07:17:41 -0700 (PDT)
Received: (qmail 13636 invoked from network); 6 Apr 2011 14:19:25 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 6 Apr 2011 14:19:23 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 6 Apr 2011 07:19:23 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Eliot Lear <lear@cisco.com>
Date: Wed, 06 Apr 2011 07:19:16 -0700
Thread-Topic: [OAUTH-WG] Proposed change to OAuth parameters registry
Thread-Index: Acv0QWfxW9I+WavsRdCmzb44rAf9cwAI9SFA
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234465664DF8A@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E723446564305DE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D9C3980.2000609@cisco.com>
In-Reply-To: <4D9C3980.2000609@cisco.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_90C41DD21FB7C64BB94121FBBC2E7234465664DF8AP3PW5EX1MB01E_"
MIME-Version: 1.0
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Proposed change to OAuth parameters registry
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: Wed, 06 Apr 2011 14:17:43 -0000
Hi Eliot, Prefixing query parameter names with a full domain is not likely to be an acceptable style. For example, Facebook uses fb_ as their prefix (most of the time) but my guess is not likely to go with fb.com.param or fb.com_param, not to mention facebook.com.param. I think the consensus here is that some collisions between vendors are going to happen and that’s it ok. When new registered extension are introduced, vendors will need to figure out how to work alongside. EHL From: Eliot Lear [mailto:lear@cisco.com] Sent: Wednesday, April 06, 2011 2:59 AM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] Proposed change to OAuth parameters registry Sorry for the late comment on this, Eran. I like your idea, but would suggest that better than company name would be domain name or based on domain name (I don't recall if '.' is allowed in this context). Company names are by no means unique, and even within a large company one could envision clashes. Eliot On 3/30/11 1:13 AM, Eran Hammer-Lahav wrote: I would like to make the following change to section 8.2: New request or response parameters for use with the authorization endpoint or the token endpoint are defined and registered in the parameters registry following the procedure in Section 10.2<http://tools.ietf.org/html/draft-ietf-oauth-v2-13#section-10.2>. Parameter names MUST conform to the param-name ABNF and parameter values syntax MUST be well-defined (e.g., using ABNF, or a reference to the syntax of an existing parameter). Unregistered vendor-specific parameter extensions that are not commonly applicable, and are specific to the implementation details of the authorization server where they are used SHOULD utilize a vendor-specific prefix that is not likely to conflict with other registered values (e.g. begin with 'companyname_'). This is a more pragmatic (and less ugly) solution to vendor specific parameters. Instead of using the ‘x_’ prefix, vendors (have and) will use something else that is unique to them. For example Facebook uses ‘fb_’ for many of their parameters. Feedback requested by 4/1 for inclusion in -14. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
- [OAUTH-WG] Proposed change to OAuth parameters re… Eran Hammer-Lahav
- Re: [OAUTH-WG] Proposed change to OAuth parameter… Justin Richer
- Re: [OAUTH-WG] Proposed change to OAuth parameter… Eran Hammer-Lahav
- Re: [OAUTH-WG] Proposed change to OAuth parameter… Eliot Lear
- Re: [OAUTH-WG] Proposed change to OAuth parameter… Eran Hammer-Lahav