IETF Logo Mail Archive

Re: [OAUTH-WG] Issue: Authorization endpoint parameter extension policy

Marius Scurtescu <mscurtescu@google.com> Mon, 19 April 2010 17:29 UTC

Return-Path: <mscurtescu@google.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 0679D3A6B0B for <oauth@core3.amsl.com>; Mon, 19 Apr 2010 10:29:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.87
X-Spam-Level:
X-Spam-Status: No, score=-105.87 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 znX74PzZKAfe for <oauth@core3.amsl.com>; Mon, 19 Apr 2010 10:29:09 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 08CF23A6876 for <oauth@ietf.org>; Mon, 19 Apr 2010 10:25:42 -0700 (PDT)
Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id o3JHPXA9031712 for <oauth@ietf.org>; Mon, 19 Apr 2010 10:25:33 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1271697933; bh=kHM8LAddBB+vIG/VwGTpfPBkzd8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=vDTNbb9K7RGVP1aUc+cMCx5oEUXe7Y+JYMBgwbknFjWMFim+MAIeFh8A01pIIpZg1 qJHnLPn2cAinB2fZh74fA==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=JFUJKVUksqjH2Bc+2qLTDhYgkdTiymjnlcaEjxE3wYD7TYggBgVTHoNGhbAf5LuN7 KOzJ1Al8jN++m9ChMcPNw==
Received: from pvd12 (pvd12.prod.google.com [10.241.209.204]) by kpbe14.cbf.corp.google.com with ESMTP id o3JHOVsx029869 for <oauth@ietf.org>; Mon, 19 Apr 2010 10:25:32 -0700
Received: by pvd12 with SMTP id 12so3009722pvd.4 for <oauth@ietf.org>; Mon, 19 Apr 2010 10:25:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.141.107.2 with HTTP; Mon, 19 Apr 2010 10:25:10 -0700 (PDT)
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723438E30A37A3@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <s2m74caaad21004161758scdd1ab27t486ef22b8f12911d@mail.gmail.com> <C7EE5805.3244E%eran@hueniverse.com> <2513A610118CC14C8E622C376C8DEC93D54D66DD94@SC-MBXC1.TheFacebook.com> <o2s74caaad21004181338kbc3e0f29m5c77fb3ddfa55d56@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723438E30A37A3@P3PW5EX1MB01.EX1.SECURESERVER.NET>
From: Marius Scurtescu <mscurtescu@google.com>
Date: Mon, 19 Apr 2010 10:25:10 -0700
Received: by 10.140.251.10 with SMTP id y10mr4468318rvh.260.1271697930396; Mon, 19 Apr 2010 10:25:30 -0700 (PDT)
Message-ID: <v2p74caaad21004191025t7db11ea7t592a1dca3dcc41af@mail.gmail.com>
To: Eran Hammer-Lahav <eran@hueniverse.com>
Content-Type: text/plain; charset="ISO-8859-1"
X-System-Of-Record: true
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Issue: Authorization endpoint parameter extension policy
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: Mon, 19 Apr 2010 17:29:10 -0000

On Sun, Apr 18, 2010 at 11:07 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
>
>
>> -----Original Message-----
>> From: Marius Scurtescu [mailto:mscurtescu@google.com]
>> Sent: Sunday, April 18, 2010 1:38 PM
>
>> Also, when implementing OAuth 2.0 people will take into account existing
>> parameters and will avoid them, they will chose other parameter names (if
>> possible). If the next version of OAuth, let's call it 2.1, adds a few new
>> parameters, how can we chose them so they don't collide with extra
>> parameters used by 2.0 implementations?
>
> By defining an extension policy. Anything that is not in the core spec is an extension.
>
> How about we first figure this out? If we can agree on an extension policy, we can see if it mitigates your concerns.

As Justin mentioned in his reply, this has nothing to do with
extensions. Other parameters will be used just to deal with the
callback implementation, to specify controllers and such.

Maybe we should consider passing parameters some other way, and not
part of query strings. JSON?

Marius

v2.23.0 | Report a Bug | By Email